From: David Woodhouse <dwmw2@infradead.org> To: "Tian, Kevin" <kevin.tian@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>, Alex Williamson <alex.williamson@redhat.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 11:50:25 +0000 [thread overview] Message-ID: <1454413825.4788.49.camel@infradead.org> (raw) In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F793FB1@SHSMSX101.ccr.corp.intel.com> [-- Attachment #1: Type: text/plain, Size: 2592 bytes --] 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. > 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. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: David Woodhouse <dwmw2@infradead.org> To: "Tian, Kevin" <kevin.tian@intel.com>, "Kay, Allen M" <allen.m.kay@intel.com>, Alex Williamson <alex.williamson@redhat.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 11:50:25 +0000 [thread overview] Message-ID: <1454413825.4788.49.camel@infradead.org> (raw) In-Reply-To: <AADFC41AFE54684AB9EE6CBC0274A5D15F793FB1@SHSMSX101.ccr.corp.intel.com> [-- Attachment #1: Type: text/plain, Size: 2592 bytes --] 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. > 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. -- David Woodhouse Open Source Technology Centre David.Woodhouse@intel.com Intel Corporation [-- Attachment #2: smime.p7s --] [-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]
next prev parent reply other threads:[~2016-02-02 11:50 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 ` David Woodhouse [this message] 2016-02-02 11:50 ` David Woodhouse 2016-02-02 14:54 ` [Qemu-devel] " Alex Williamson 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=1454413825.4788.49.camel@infradead.org \ --to=dwmw2@infradead.org \ --cc=alex.williamson@redhat.com \ --cc=allen.m.kay@intel.com \ --cc=caoj.fnst@cn.fujitsu.com \ --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.