From: Alex Williamson <alex.williamson@redhat.com> To: David Woodhouse <dwmw2@infradead.org>, "Tian, Kevin" <kevin.tian@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>, Gerd Hoffmann <kraxel@redhat.com> Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Eduardo Habkost <ehabkost@redhat.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Cao jin <caoj.fnst@cn.fujitsu.com>, "vfio-users@redhat.com" <vfio-users@redhat.com> Subject: Re: [Qemu-devel] [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks Date: Tue, 02 Feb 2016 07:54:00 -0700 [thread overview] Message-ID: <1454424840.10542.18.camel@redhat.com> (raw) In-Reply-To: <1454413825.4788.49.camel@infradead.org> On Tue, 2016-02-02 at 11:50 +0000, David Woodhouse wrote: > On Tue, 2016-02-02 at 06:42 +0000, Tian, Kevin wrote: > > > From: Kay, Allen M > > > Sent: Tuesday, February 02, 2016 8:04 AM > > > > > > > > David notes in the latter commit above: > > > > > > > > "We should be able to successfully assign graphics devices to guests too, as > > > > long as the initial handling of stolen memory is reconfigured appropriately." > > > > > > > > What code is supposed to be doing that reconfiguration when a device is > > > > assigned? Clearly we don't have it yet, making assignment of these devices > > > > very unsafe. It seems like vfio or IOMMU code in the kernel needs device > > > > specific code to clear these settings to make it safe for userspace, then > > > > perhaps VM BIOS support to reallocate. Is there any consistency across IGD > > > > revisions for doing this? Is there a spec? > > > > Thanks, > > I haven't ever successfully assigned an IGD device to a VM myself, but > my understanding was that it *has* been done. So when the code was > changed to prevent assignment of devices afflicted by RMRRs (except USB > where we know it's OK), I just added the integrated graphics to that > same exception as USB, to preserve the status quo ante. It had been successfully done on /Xen/, not on anything that actually made use of that exclusion, so there was no status quo to preserve. > > I don't think stolen memory should be handled explicitly. If yes, it should be > > listed as a RMRR region so general RMRR setup will cover it. But as Allen > > pointed out, the whole RMRR becomes unnecessary if we target only secondary > > device for IGD. > > Perhaps the best option is *not* to have special cases in the IOMMU > code for "those devices which can safely be assigned despite RMRRs". > > Instead, let's let the device driver — or whatever — tell the IOMMU > code when it's *stopped* the firmware from (ab)using the device's DMA > facilities. > > So when the USB code does the handoff thing to quiesce the firmware's > access to USB and take over in the OS, it would call the IOMMU function > to revoke the RMRR for the USB controller. > > And if/when the graphics driver resets its device into a state where > it's no longer accessing stolen memory and can be assigned to a VM, it > can also call that 'RMRR revoke' function. > > Likewise, if we teach device drivers to cancel whatever abominations > the HP firmware tends to set up behind the OS's back on other PCI > devices, we can cancel the RMRRs for those too. > > Then the IOMMU code has a simple choice and no special cases — we can > assign a device iff it has no active RMRR. I first glance I like it, but there's a problem, it assumes there is a host driver for the device that will permanently release the device from the RMRR even after the device is unbound. Currently we don't have a requirement that the user must first bind the device to a native host driver, unbind it, and only then is it eligible for device assignment. In fact with GPUs we often blacklist the native driver or attach them directly to a stub driver to avoid the host driver. Maybe that issue works itself out since the IOMMU won't allow access to the device without this step, but it means that i915 needs to be better than most graphics drivers when it comes to unbinding the device (which is not a very high bar). Of course as I've shown on IGD, it's not simply a matter of declaring the RMRR unused, some reconfiguration of the device is necessary such that the guest driver doesn't try to start using that same reserved range. Thanks, Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com> To: David Woodhouse <dwmw2@infradead.org>, "Tian, Kevin" <kevin.tian@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>, Gerd Hoffmann <kraxel@redhat.com> Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Eduardo Habkost <ehabkost@redhat.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>, Cao jin <caoj.fnst@cn.fujitsu.com>, "vfio-users@redhat.com" <vfio-users@redhat.com> Subject: Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks Date: Tue, 02 Feb 2016 07:54:00 -0700 [thread overview] Message-ID: <1454424840.10542.18.camel@redhat.com> (raw) In-Reply-To: <1454413825.4788.49.camel@infradead.org> On Tue, 2016-02-02 at 11:50 +0000, David Woodhouse wrote: > On Tue, 2016-02-02 at 06:42 +0000, Tian, Kevin wrote: > > > From: Kay, Allen M > > > Sent: Tuesday, February 02, 2016 8:04 AM > > > > > > > > David notes in the latter commit above: > > > > > > > > "We should be able to successfully assign graphics devices to guests too, as > > > > long as the initial handling of stolen memory is reconfigured appropriately." > > > > > > > > What code is supposed to be doing that reconfiguration when a device is > > > > assigned? Clearly we don't have it yet, making assignment of these devices > > > > very unsafe. It seems like vfio or IOMMU code in the kernel needs device > > > > specific code to clear these settings to make it safe for userspace, then > > > > perhaps VM BIOS support to reallocate. Is there any consistency across IGD > > > > revisions for doing this? Is there a spec? > > > > Thanks, > > I haven't ever successfully assigned an IGD device to a VM myself, but > my understanding was that it *has* been done. So when the code was > changed to prevent assignment of devices afflicted by RMRRs (except USB > where we know it's OK), I just added the integrated graphics to that > same exception as USB, to preserve the status quo ante. It had been successfully done on /Xen/, not on anything that actually made use of that exclusion, so there was no status quo to preserve. > > I don't think stolen memory should be handled explicitly. If yes, it should be > > listed as a RMRR region so general RMRR setup will cover it. But as Allen > > pointed out, the whole RMRR becomes unnecessary if we target only secondary > > device for IGD. > > Perhaps the best option is *not* to have special cases in the IOMMU > code for "those devices which can safely be assigned despite RMRRs". > > Instead, let's let the device driver — or whatever — tell the IOMMU > code when it's *stopped* the firmware from (ab)using the device's DMA > facilities. > > So when the USB code does the handoff thing to quiesce the firmware's > access to USB and take over in the OS, it would call the IOMMU function > to revoke the RMRR for the USB controller. > > And if/when the graphics driver resets its device into a state where > it's no longer accessing stolen memory and can be assigned to a VM, it > can also call that 'RMRR revoke' function. > > Likewise, if we teach device drivers to cancel whatever abominations > the HP firmware tends to set up behind the OS's back on other PCI > devices, we can cancel the RMRRs for those too. > > Then the IOMMU code has a simple choice and no special cases — we can > assign a device iff it has no active RMRR. I first glance I like it, but there's a problem, it assumes there is a host driver for the device that will permanently release the device from the RMRR even after the device is unbound. Currently we don't have a requirement that the user must first bind the device to a native host driver, unbind it, and only then is it eligible for device assignment. In fact with GPUs we often blacklist the native driver or attach them directly to a stub driver to avoid the host driver. Maybe that issue works itself out since the IOMMU won't allow access to the device without this step, but it means that i915 needs to be better than most graphics drivers when it comes to unbinding the device (which is not a very high bar). Of course as I've shown on IGD, it's not simply a matter of declaring the RMRR unused, some reconfiguration of the device is necessary such that the guest driver doesn't try to start using that same reserved range. Thanks, Alex
next prev parent reply other threads:[~2016-02-02 14:54 UTC|newest] Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-01-05 11:41 [Qemu-devel] [PATCH v3 00/11] igd passthrough chipset tweaks Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 01/11] pc: wire up TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE for !xen Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 02/11] pc: remove has_igd_gfx_passthru global Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 14:32 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini 2016-01-06 14:32 ` Stefano Stabellini 2016-01-19 15:09 ` [Qemu-devel] " Eduardo Habkost 2016-01-19 15:09 ` Eduardo Habkost 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 03/11] pc: move igd support code to igd.c Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 04/11] igd: switch TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE to realize Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 14:32 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 14:32 ` Stefano Stabellini 2016-01-23 14:51 ` [Qemu-devel] " Eduardo Habkost 2016-01-23 14:51 ` Eduardo Habkost 2016-01-25 8:59 ` [Qemu-devel] " Gerd Hoffmann 2016-01-25 8:59 ` Gerd Hoffmann 2016-01-25 11:53 ` [Qemu-devel] " Stefano Stabellini 2016-01-25 11:53 ` Stefano Stabellini 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 05/11] igd: TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE: call parent realize Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 14:41 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 14:41 ` Stefano Stabellini 2016-01-06 15:45 ` [Qemu-devel] " Gerd Hoffmann 2016-01-06 15:45 ` Gerd Hoffmann 2016-01-19 15:13 ` [Qemu-devel] " Eduardo Habkost 2016-01-19 15:13 ` Eduardo Habkost 2016-01-20 9:10 ` [Qemu-devel] " Gerd Hoffmann 2016-01-20 9:10 ` Gerd Hoffmann 2016-01-23 14:52 ` [Qemu-devel] " Eduardo Habkost 2016-01-23 14:52 ` Eduardo Habkost 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 06/11] igd: use defines for standard pci config space offsets Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 14:43 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 14:43 ` Stefano Stabellini 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 07/11] igd: revamp host config read Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 15:02 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 15:02 ` Stefano Stabellini 2016-01-06 15:51 ` [Qemu-devel] " Gerd Hoffmann 2016-01-06 15:51 ` Gerd Hoffmann 2016-01-06 16:23 ` [Qemu-devel] [Xen-devel] " Stefano Stabellini 2016-01-06 16:23 ` Stefano Stabellini 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 08/11] igd: add q35 support Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 09/11] igd: move igd-passthrough-isa-bridge to igd.c too Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 10/11] igd: handle igd-passthrough-isa-bridge setup in realize() Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 15:29 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 15:29 ` Stefano Stabellini 2016-01-06 15:52 ` [Qemu-devel] " Gerd Hoffmann 2016-01-06 15:52 ` Gerd Hoffmann 2016-01-05 11:41 ` [Qemu-devel] [PATCH v3 11/11] igd: move igd-passthrough-isa-bridge creation to machine init Gerd Hoffmann 2016-01-05 11:41 ` Gerd Hoffmann 2016-01-06 15:36 ` [Qemu-devel] " Stefano Stabellini 2016-01-06 15:36 ` Stefano Stabellini 2016-01-07 7:38 ` [Qemu-devel] " Gerd Hoffmann 2016-01-07 7:38 ` Gerd Hoffmann 2016-01-07 13:10 ` [Qemu-devel] " Stefano Stabellini 2016-01-07 13:10 ` Stefano Stabellini 2016-01-07 15:50 ` [Qemu-devel] " Gerd Hoffmann 2016-01-07 15:50 ` Gerd Hoffmann 2016-01-08 11:20 ` Stefano Stabellini 2016-01-08 11:20 ` Stefano Stabellini 2016-01-08 12:12 ` [Qemu-devel] " Stefano Stabellini 2016-01-08 12:12 ` Stefano Stabellini 2016-01-08 12:32 ` Gerd Hoffmann 2016-01-08 12:32 ` Gerd Hoffmann 2016-01-08 12:38 ` [Qemu-devel] " Stefano Stabellini 2016-01-08 12:38 ` Stefano Stabellini 2016-01-05 13:07 ` [Qemu-devel] [PATCH v3 00/11] igd passthrough chipset tweaks Michael S. Tsirkin 2016-01-05 13:07 ` Michael S. Tsirkin 2016-01-28 19:35 ` [Qemu-devel] [vfio-users] " Alex Williamson 2016-01-28 19:35 ` Alex Williamson 2016-01-29 2:22 ` [Qemu-devel] [iGVT-g] " Kay, Allen M 2016-01-29 2:22 ` Kay, Allen M 2016-01-29 2:54 ` [Qemu-devel] " Alex Williamson 2016-01-29 2:54 ` Alex Williamson 2016-01-29 6:21 ` [Qemu-devel] " Jike Song 2016-01-29 6:21 ` Jike Song 2016-01-29 21:58 ` [Qemu-devel] " Kay, Allen M 2016-01-29 21:58 ` Kay, Allen M 2016-02-02 7:07 ` [Qemu-devel] " Tian, Kevin 2016-02-02 7:07 ` Tian, Kevin 2016-02-02 19:10 ` [Qemu-devel] " Kay, Allen M 2016-02-02 19:10 ` [iGVT-g] " Kay, Allen M 2016-02-02 19:37 ` [Qemu-devel] [iGVT-g] [vfio-users] " Alex Williamson 2016-02-02 19:37 ` Alex Williamson 2016-02-02 23:32 ` [Qemu-devel] " Kay, Allen M 2016-02-02 23:32 ` Kay, Allen M 2016-01-29 7:09 ` [Qemu-devel] " Gerd Hoffmann 2016-01-29 7:09 ` Gerd Hoffmann 2016-01-29 17:59 ` [Qemu-devel] " Alex Williamson 2016-01-29 17:59 ` Alex Williamson 2016-01-30 1:18 ` [Qemu-devel] [iGVT-g] " Kay, Allen M 2016-01-30 1:18 ` Kay, Allen M 2016-01-31 17:42 ` [Qemu-devel] " Alex Williamson 2016-01-31 17:42 ` Alex Williamson 2016-02-02 0:04 ` [Qemu-devel] " Kay, Allen M 2016-02-02 0:04 ` Kay, Allen M 2016-02-02 6:42 ` [Qemu-devel] [Xen-devel] " Tian, Kevin 2016-02-02 6:42 ` Tian, Kevin 2016-02-02 11:50 ` [Qemu-devel] " David Woodhouse 2016-02-02 11:50 ` David Woodhouse 2016-02-02 14:54 ` Alex Williamson [this message] 2016-02-02 14:54 ` Alex Williamson 2016-02-02 15:06 ` [Qemu-devel] " David Woodhouse 2016-02-02 15:06 ` David Woodhouse 2016-02-02 14:38 ` [Qemu-devel] " Alex Williamson 2016-02-02 14:38 ` Alex Williamson 2016-02-01 12:49 ` [Qemu-devel] " Gerd Hoffmann 2016-02-01 12:49 ` Gerd Hoffmann 2016-02-01 22:16 ` [Qemu-devel] " Alex Williamson 2016-02-01 22:16 ` Alex Williamson 2016-02-02 7:43 ` [Qemu-devel] [vfio-users] " Gerd Hoffmann 2016-02-02 7:43 ` Gerd Hoffmann 2016-02-02 7:01 ` [Qemu-devel] [iGVT-g] " Tian, Kevin 2016-02-02 7:01 ` [iGVT-g] " Tian, Kevin 2016-02-02 8:56 ` [Qemu-devel] [iGVT-g] [vfio-users] " Gerd Hoffmann 2016-02-02 8:56 ` Gerd Hoffmann 2016-02-02 16:31 ` [Qemu-devel] " Kevin O'Connor 2016-02-02 16:31 ` Kevin O'Connor 2016-02-02 16:49 ` [Qemu-devel] " Laszlo Ersek 2016-02-02 16:49 ` Laszlo Ersek 2016-02-02 20:18 ` [Qemu-devel] " Alex Williamson 2016-02-02 20:18 ` Alex Williamson 2016-02-03 6:08 ` [Qemu-devel] " Tian, Kevin 2016-02-03 6:08 ` Tian, Kevin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1454424840.10542.18.camel@redhat.com \ --to=alex.williamson@redhat.com \ --cc=allen.m.kay@intel.com \ --cc=caoj.fnst@cn.fujitsu.com \ --cc=dwmw2@infradead.org \ --cc=ehabkost@redhat.com \ --cc=igvt-g@ml01.01.org \ --cc=kevin.tian@intel.com \ --cc=kraxel@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=stefano.stabellini@eu.citrix.com \ --cc=vfio-users@redhat.com \ --cc=xen-devel@lists.xensource.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.