Re: [Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
- Original Message - > From: "Michael S. Tsirkin" > To: "Igor Mammedov" > Cc: gham...@redhat.com, "Yan Vugenfirer" , > 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" 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" 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" 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
[Qemu-devel] [PATCH V14 0/3] Virtual Machine Generation ID
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 Note to maintainer: this patch set doesn't include the *.hex.generated files and updated test ACPI tables blobs. Hex files for [q35-]acpi-dsdt should be updated. Tested with WS2012R2DCx64, thanks Gal for providing test utilities. Based on top of mst's PCI tree. Git branch: https://github.com/imammedo/qemu.git vmgenid_v14 Gal Hammer (1): docs: vm generation id device's description Igor Mammedov (2): pc: add a Virtual Machine Generation ID device tests: add a unit test for the vmgenid device. default-configs/i386-softmmu.mak | 1 + default-configs/x86_64-softmmu.mak | 1 + docs/specs/pci-ids.txt | 1 + docs/specs/vmgenid.txt | 36 ++ hw/i386/acpi-build.c | 69 +-- hw/i386/acpi-dsdt.dsl | 2 - hw/i386/q35-acpi-dsdt.dsl | 2 - hw/misc/Makefile.objs | 1 + hw/misc/vmgenid.c | 134 + include/hw/acpi/acpi.h | 1 + include/hw/misc/vmgenid.h | 21 ++ include/hw/pci/pci.h | 1 + tests/Makefile | 2 + tests/vmgenid-test.c | 92 + 14 files changed, 356 insertions(+), 8 deletions(-) create mode 100644 docs/specs/vmgenid.txt create mode 100644 hw/misc/vmgenid.c create mode 100644 include/hw/misc/vmgenid.h create mode 100644 tests/vmgenid-test.c -- 2.1.0
