| Message ID | 1485511238.19754.58.camel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote: > Hi folks, > > Problem at hand: A virtual machine, equipped with two display devices, > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu). > > There is no easy way for the user to configure which of the two display > devices fbcon should run on. i915 happens to win over bochs-drm or qxl, > so you can't use the emulated gfx device as text console. > > One way out would be to add a module option to each driver, to turn off > fbdev emulation. Attached patch does that for i915. > > Comments? Better ideas? fbcon can be switched between different fbdev afaik, but don't ask me how. I'd say if you want to keep fbcon (and not switch to something like kmscon), then that's where this logic should be. Might even exist already. Having a per-driver knob won't work, since then the next person complains about his multi-amd setup using the wrong gpu :-) -Daniel > > cheers, > Gerd > > From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001 > From: Gerd Hoffmann <kraxel@redhat.com> > Date: Fri, 27 Jan 2017 08:05:40 +0100 > Subject: [PATCH] drm i915: add fbdev option > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > --- > drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c > index 3e3632c..cc0ba3e 100644 > --- a/drivers/gpu/drm/i915/intel_fbdev.c > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > @@ -45,6 +45,11 @@ > #include <drm/i915_drm.h> > #include "i915_drv.h" > > +static bool enable_fbdev = true; > +module_param_named(fbdev, enable_fbdev, bool, 0600); > +MODULE_PARM_DESC(fbdev, > + "Enable legacy fbdev emulation [default=true]"); > + > static int intel_fbdev_set_par(struct fb_info *info) > { > struct drm_fb_helper *fb_helper = info->par; > @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev) > struct drm_i915_private *dev_priv = to_i915(dev); > int ret; > > + if (!enable_fbdev) > + return 0; > + > if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0)) > return -ENODEV; > > @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev) > { > struct intel_fbdev *ifbdev = to_i915(dev)->fbdev; > > + if (!ifbdev) > + return; > ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev); > } > > -- > 1.8.3.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jan 27, 2017 at 03:02:42PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote: > > Hi folks, > > > > Problem at hand: A virtual machine, equipped with two display devices, > > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu). > > > > There is no easy way for the user to configure which of the two display > > devices fbcon should run on. i915 happens to win over bochs-drm or qxl, > > so you can't use the emulated gfx device as text console. > > > > One way out would be to add a module option to each driver, to turn off > > fbdev emulation. Attached patch does that for i915. > > > > Comments? Better ideas? > > fbcon can be switched between different fbdev afaik, but don't ask me how. Hint: Documentation/fb/fbcon.txt says fbcon=map:<ttynumbers> Best regards, Liviu > I'd say if you want to keep fbcon (and not switch to something like > kmscon), then that's where this logic should be. Might even exist already. > Having a per-driver knob won't work, since then the next person complains > about his multi-amd setup using the wrong gpu :-) > -Daniel > > > > > cheers, > > Gerd > > > > > From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001 > > From: Gerd Hoffmann <kraxel@redhat.com> > > Date: Fri, 27 Jan 2017 08:05:40 +0100 > > Subject: [PATCH] drm i915: add fbdev option > > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > > --- > > drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c > > index 3e3632c..cc0ba3e 100644 > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > @@ -45,6 +45,11 @@ > > #include <drm/i915_drm.h> > > #include "i915_drv.h" > > > > +static bool enable_fbdev = true; > > +module_param_named(fbdev, enable_fbdev, bool, 0600); > > +MODULE_PARM_DESC(fbdev, > > + "Enable legacy fbdev emulation [default=true]"); > > + > > static int intel_fbdev_set_par(struct fb_info *info) > > { > > struct drm_fb_helper *fb_helper = info->par; > > @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev) > > struct drm_i915_private *dev_priv = to_i915(dev); > > int ret; > > > > + if (!enable_fbdev) > > + return 0; > > + > > if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0)) > > return -ENODEV; > > > > @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev) > > { > > struct intel_fbdev *ifbdev = to_i915(dev)->fbdev; > > > > + if (!ifbdev) > > + return; > > ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev); > > } > > > > -- > > 1.8.3.1 > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, 27 Jan 2017 11:00:38 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi folks, > > Problem at hand: A virtual machine, equipped with two display devices, > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu). > > There is no easy way for the user to configure which of the two display > devices fbcon should run on. i915 happens to win over bochs-drm or qxl, > so you can't use the emulated gfx device as text console. > > One way out would be to add a module option to each driver, to turn off > fbdev emulation. Attached patch does that for i915. > > Comments? Better ideas? The vgaarb code has a concept of a vga_default_device(), it's rather PCI-centric, but maybe better than nothing. This is typically the first VGA class code device found with I/O and MMIO enabled. If fbcon defaulted to running on the vga_default_device(), a user could select which to use by re-ordering the VM hardware. The problem isn't absent on bare metal, though re-ordering hardware isn't always as simple, or necessarily possible. The problem might run deeper there too dealing with vesafb and simplefb, as well as the more device specific drivers. Rerouting legacy resources isn't always an option, but some sort of primary selection for non-encumbered devices would be useful. Thanks, Alex
Hi, > The vgaarb code has a concept of a vga_default_device(), it's rather > PCI-centric, but maybe better than nothing. This is typically the > first VGA class code device found with I/O and MMIO enabled. If fbcon > defaulted to running on the vga_default_device(), a user could select > which to use by re-ordering the VM hardware. The qemu drivers don't register as vgaarb clients though. Which easily explains why igd always wins the primary selection, no matter how you order your hardware. So, should they register? The drivers don't need access to the vga registers[1][2]. cheers, Gerd [1] Well, except cirrus, but that is deprecated anyway. [2] And bochs-drm, when running on old qemu versions, where the stdvga has no mmio bar yet. But those qemu versions don't support igd pass-through.
On Mon, 30 Jan 2017 09:15:50 +0100 Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > > > The vgaarb code has a concept of a vga_default_device(), it's rather > > PCI-centric, but maybe better than nothing. This is typically the > > first VGA class code device found with I/O and MMIO enabled. If fbcon > > defaulted to running on the vga_default_device(), a user could select > > which to use by re-ordering the VM hardware. > > The qemu drivers don't register as vgaarb clients though. Which easily > explains why igd always wins the primary selection, no matter how you > order your hardware. > > So, should they register? The drivers don't need access to the vga > registers[1][2]. The VGA arbiter sets up a notifier on the PCI bus and will add any VGA class code devices it finds. So even if the driver doesn't participate, it'll still be tracked and might be marked as primary. If a graphics driver claims a VGA device that does not depend on VGA region access then the driver should configure the device not to claim VGA accesses (maybe only relevant for integrated graphics - i915 gets this wrong), and register with the arbiter to opt-out of VGA arbitration. Picking a "primary" can be done w/o any of that latter if we agree on the arbiter algorithm of picking the first device with VGA routing to it (or it can be overridden by arch/platform code). Thanks, Alex
On Mon, Jan 30, 2017 at 10:45:22AM -0700, Alex Williamson wrote: > On Mon, 30 Jan 2017 09:15:50 +0100 > Gerd Hoffmann <kraxel@redhat.com> wrote: > > > Hi, > > > > > The vgaarb code has a concept of a vga_default_device(), it's rather > > > PCI-centric, but maybe better than nothing. This is typically the > > > first VGA class code device found with I/O and MMIO enabled. If fbcon > > > defaulted to running on the vga_default_device(), a user could select > > > which to use by re-ordering the VM hardware. > > > > The qemu drivers don't register as vgaarb clients though. Which easily > > explains why igd always wins the primary selection, no matter how you > > order your hardware. > > > > So, should they register? The drivers don't need access to the vga > > registers[1][2]. > > The VGA arbiter sets up a notifier on the PCI bus and will add any VGA > class code devices it finds. So even if the driver doesn't > participate, it'll still be tracked and might be marked as primary. If > a graphics driver claims a VGA device that does not depend on VGA > region access then the driver should configure the device not to claim > VGA accesses (maybe only relevant for integrated graphics - i915 gets > this wrong), and register with the arbiter to opt-out of VGA > arbitration. Picking a "primary" can be done w/o any of that latter if > we agree on the arbiter algorithm of picking the first device with VGA > routing to it (or it can be overridden by arch/platform code). Thanks, Fyi we don't get this wrong, we indeed need vga access in some cases. Broken hw :( The other issue is that the X server asks for vga access (or at least did in the past) for every render op, even if it's a kms driver. Which makes X crawl if you have multi-gpu system. Those two things combined means vgaarb is essentially dead on any system with intel gfx. -Daniel
Hi, > > The VGA arbiter sets up a notifier on the PCI bus and will add any VGA > > class code devices it finds. So even if the driver doesn't > > participate, it'll still be tracked and might be marked as primary. If > > a graphics driver claims a VGA device that does not depend on VGA > > region access then the driver should configure the device not to claim > > VGA accesses (maybe only relevant for integrated graphics - i915 gets > > this wrong), and register with the arbiter to opt-out of VGA > > arbitration. Picking a "primary" can be done w/o any of that latter if > > we agree on the arbiter algorithm of picking the first device with VGA > > routing to it (or it can be overridden by arch/platform code). Thanks, > > Fyi we don't get this wrong, we indeed need vga access in some cases. > Broken hw :( The other issue is that the X server asks for vga access (or > at least did in the past) for every render op, even if it's a kms driver. > Which makes X crawl if you have multi-gpu system. Those two things > combined means vgaarb is essentially dead on any system with intel gfx. > -Daniel Various qemu display devices exist in vga and non-vga variants. So we can sidestep the vgaarb issues by using one of those, so igd is the only CLASS_DISPLAY_VGA device in the system. That causes some other problems though. First the vga variants are supported better by the firmware because it is easy to create a simple framebuffer with them. With the non-vga variants you usually don't have a display until the linux kms driver loads. Also the vgaarb will not pick them up, so they will not be considered as primary display. With the vga variants primary selection by ordering the devices works for me. kms drivers for both igd and emulated graphics must be loaded. fbcon will pick up whatever vgaarb declared as boot device. cheers, Gerd
From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann <kraxel@redhat.com> Date: Fri, 27 Jan 2017 08:05:40 +0100 Subject: [PATCH] drm i915: add fbdev option Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> --- drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 3e3632c..cc0ba3e 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -45,6 +45,11 @@ #include <drm/i915_drm.h> #include "i915_drv.h" +static bool enable_fbdev = true; +module_param_named(fbdev, enable_fbdev, bool, 0600); +MODULE_PARM_DESC(fbdev, + "Enable legacy fbdev emulation [default=true]"); + static int intel_fbdev_set_par(struct fb_info *info) { struct drm_fb_helper *fb_helper = info->par; @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev) struct drm_i915_private *dev_priv = to_i915(dev); int ret; + if (!enable_fbdev) + return 0; + if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0)) return -ENODEV; @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev) { struct intel_fbdev *ifbdev = to_i915(dev)->fbdev; + if (!ifbdev) + return; ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev); } -- 1.8.3.1