Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
- Original Message - From: Michael S. Tsirkin m...@redhat.com To: Igor Mammedov imamm...@redhat.com Cc: gham...@redhat.com, Yan Vugenfirer yvuge...@redhat.com, qemu-devel@nongnu.org Sent: Sunday, April 19, 2015 10:52:37 AM Subject: Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID On Wed, Apr 15, 2015 at 03:59:09PM +0200, Igor Mammedov wrote: On Wed, 15 Apr 2015 12:38:57 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote: Changes since v13: * fix comment style to /*... */ in testcase * make BAR TARGET_PAGE_SIZE as required by spec * make BAR prefetchable, spec also says that it shouldn't be marked as non cached * ACPI part * merge separate VGID device with PCI device description * mark device as not shown in UI, it hides VM Generation ID device from device manager and leaves only PCI Standard RAM Controller device there In an offline chat, Yan (Cc) mentioned that with windows guests, PCI rebalancing can move BAR values around. Yan, could you comment on-list please? Is there a way to force this, for testing? Yes. It is part of HCK test kit: https://msdn.microsoft.com/en-us/library/windows/hardware/jj673015(v=vs.85).aspx#About_rebalance_tests ACPI spec mentions this: If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs. It seems that WS2012R2 doesn't honor this part of spec, it still tries to find matching driver and load it. Interesting. Looking at msdn: https://msdn.microsoft.com/en-us/library/windows/hardware/ff563877(v=vs.85).aspx Looks like what windows does to rebalance is query device for rebalancing support, stop driver, rebalance, and restart driver. If device has no driver, it seems likely windows will assume it's safe to rebalance the resources. There's also a very old document: http://www.microsoft.com/whdc/connect/pci/PCI-rsc.mspx which says it's possible to implement _DSM method to deny rebalance requests. Alternatively, we could put this device behind a pci extender, e.g. as implemented by Marcel. The resources would then be limited by the _CRS or the root. This might also avoid driver prompt from windows? it isn't.
Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
On Wed, Apr 15, 2015 at 03:59:09PM +0200, Igor Mammedov wrote: On Wed, 15 Apr 2015 12:38:57 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote: Changes since v13: * fix comment style to /*... */ in testcase * make BAR TARGET_PAGE_SIZE as required by spec * make BAR prefetchable, spec also says that it shouldn't be marked as non cached * ACPI part * merge separate VGID device with PCI device description * mark device as not shown in UI, it hides VM Generation ID device from device manager and leaves only PCI Standard RAM Controller device there In an offline chat, Yan (Cc) mentioned that with windows guests, PCI rebalancing can move BAR values around. Yan, could you comment on-list please? Is there a way to force this, for testing? ACPI spec mentions this: If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs. It seems that WS2012R2 doesn't honor this part of spec, it still tries to find matching driver and load it. Interesting. Looking at msdn: https://msdn.microsoft.com/en-us/library/windows/hardware/ff563877(v=vs.85).aspx Looks like what windows does to rebalance is query device for rebalancing support, stop driver, rebalance, and restart driver. If device has no driver, it seems likely windows will assume it's safe to rebalance the resources. There's also a very old document: http://www.microsoft.com/whdc/connect/pci/PCI-rsc.mspx which says it's possible to implement _DSM method to deny rebalance requests. Alternatively, we could put this device behind a pci extender, e.g. as implemented by Marcel. The resources would then be limited by the _CRS or the root. This might also avoid driver prompt from windows? it isn't.
Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
On Wed, 15 Apr 2015 12:38:57 +0200 Michael S. Tsirkin m...@redhat.com wrote: On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote: Changes since v13: * fix comment style to /*... */ in testcase * make BAR TARGET_PAGE_SIZE as required by spec * make BAR prefetchable, spec also says that it shouldn't be marked as non cached * ACPI part * merge separate VGID device with PCI device description * mark device as not shown in UI, it hides VM Generation ID device from device manager and leaves only PCI Standard RAM Controller device there In an offline chat, Yan (Cc) mentioned that with windows guests, PCI rebalancing can move BAR values around. Yan, could you comment on-list please? Is there a way to force this, for testing? ACPI spec mentions this: If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs. It seems that WS2012R2 doesn't honor this part of spec, it still tries to find matching driver and load it. This might also avoid driver prompt from windows? it isn't.
Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
On Tue, Mar 03, 2015 at 05:18:12PM +0100, Igor Mammedov wrote: Changes since v13: * fix comment style to /*... */ in testcase * make BAR TARGET_PAGE_SIZE as required by spec * make BAR prefetchable, spec also says that it shouldn't be marked as non cached * ACPI part * merge separate VGID device with PCI device description * mark device as not shown in UI, it hides VM Generation ID device from device manager and leaves only PCI Standard RAM Controller device there In an offline chat, Yan (Cc) mentioned that with windows guests, PCI rebalancing can move BAR values around. Yan, could you comment on-list please? Is there a way to force this, for testing? ACPI spec mentions this: If a platform uses a PCI BAR Target operation region, an ACPI OS will not load a native device driver for the associated PCI function. For example, if any of the BARs in a PCI function are associated with a PCI BAR Target operation region, then the OS will assume that the PCI function is to be entirely under the control of the ACPI BIOS. No driver will be loaded. Thus, a PCI function can be used as a platform controller for some task (hot-plug PCI, and so on) that the ACPI BIOS performs. This might also avoid driver prompt from windows? -- MST
