| Message ID | 20170716082917.720-1-dmitry@daynix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 16/07/2017 11:29, Dmitry Fleytman wrote: > According to PCI spec. bit 1 of command > register (PCI_COMMAND_MEMORY) controls > a device's response to memory space accesses. > A value of 0 disables the device response. > A value of 1 allows the device to respond > to memory space accesses. > Hi Dmitry, > Current behavior introduced by commit > > commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d > Author: Avi Kivity <avi@redhat.com> > Date: Wed Oct 3 17:42:58 2012 +0200 > > pci: honor PCI_COMMAND_MASTER > > is to ignore device memory space accesses unless > bit 2 (PCI_COMMAND_MASTER) is set. > > Aforementioned commit introduced regression of > Windows hibernation (S4) functionality support > because on resume Windows kernel sets bits 0 and 1 > (PCI_COMMAND_MEMORY | PCI_COMMAND_IO) of boot > device's (piix3-ide in our specific case) command > register and tries to work with the device. > > Since PCI_COMMAND_MASTER bit is not set, device > does not answer and Windows fails to resume from > hibernation. > As far as I am aware "Bus master" is needed for a device to start PCI transactions, while PCI_COMMAND_MEMORY/IO controls the device ability to respond to memory/IO accesses, not to start them. If "Bus master" is needed for DMA access or MSI, the OS should explicitly set the PCI_COMMAND_MASTER, right? > As a result following BSOD happens: > > BugCheck A0, {10e, a, aa00, 418} > > Probably caused by : ntkrnlmp.exe ( nt!PopHiberChecksumHiberFileData+b346 ) > > Followup: MachineOwner > --------- > > 0: kd> !analyze -v > ******************************************************************************* > * * > * Bugcheck Analysis * > * * > ******************************************************************************* > > INTERNAL_POWER_ERROR (a0) > The power policy manager experienced a fatal error. > Arguments: > Arg1: 000000000000010e, The disk subsystem returned corrupt data while reading from the > hibernation file. > Arg2: 000000000000000a > Arg3: 000000000000aa00, Incorrect checksum > Arg4: 0000000000000418, Previous disk read's checksum > Does piix3-ide fail to respond to IO/MEM accesses if PCI_COMMAND_MASTER is not set? Or is it a DMA issue? Thanks, Marcel > According to our tests this problem happens at least on > Windows 8/8.1/2012/2012R2/10/2016. > > This patch solves https://bugzilla.redhat.com/show_bug.cgi?id=988351 > > Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> > --- > hw/pci/pci.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/hw/pci/pci.c b/hw/pci/pci.c > index 0c6f74a..10af82f 100644 > --- a/hw/pci/pci.c > +++ b/hw/pci/pci.c > @@ -480,7 +480,7 @@ static int get_pci_config_device(QEMUFile *f, void *pv, size_t size, > > memory_region_set_enabled(&s->bus_master_enable_region, > pci_get_word(s->config + PCI_COMMAND) > - & PCI_COMMAND_MASTER); > + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); > > g_free(config); > return 0; > @@ -1356,7 +1356,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in, int > pci_update_irq_disabled(d, was_irq_disabled); > memory_region_set_enabled(&d->bus_master_enable_region, > pci_get_word(d->config + PCI_COMMAND) > - & PCI_COMMAND_MASTER); > + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); > } > > msi_write_config(d, addr, val_in, l); >
On 16 Jul 2017, at 19:56 PM, Marcel Apfelbaum <marcel@redhat.com> wrote: > > On 16/07/2017 11:29, Dmitry Fleytman wrote: >> According to PCI spec. bit 1 of command >> register (PCI_COMMAND_MEMORY) controls >> a device's response to memory space accesses. >> A value of 0 disables the device response. >> A value of 1 allows the device to respond >> to memory space accesses. >> > > Hi Dmitry, Hi Marcel, > > >> Current behavior introduced by commit >> commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d >> Author: Avi Kivity <avi@redhat.com> >> Date: Wed Oct 3 17:42:58 2012 +0200 >> pci: honor PCI_COMMAND_MASTER >> is to ignore device memory space accesses unless >> bit 2 (PCI_COMMAND_MASTER) is set. >> Aforementioned commit introduced regression of >> Windows hibernation (S4) functionality support >> because on resume Windows kernel sets bits 0 and 1 >> (PCI_COMMAND_MEMORY | PCI_COMMAND_IO) of boot >> device's (piix3-ide in our specific case) command >> register and tries to work with the device. >> > Since PCI_COMMAND_MASTER bit is not set, device >> does not answer and Windows fails to resume from >> hibernation. > > As far as I am aware "Bus master" is needed for a device > to start PCI transactions, while PCI_COMMAND_MEMORY/IO > controls the device ability to respond to memory/IO accesses, > not to start them. > If "Bus master" is needed for DMA access or MSI, the OS should > explicitly set the PCI_COMMAND_MASTER, right? > > > >> As a result following BSOD happens: >> BugCheck A0, {10e, a, aa00, 418} >> Probably caused by : ntkrnlmp.exe ( nt!PopHiberChecksumHiberFileData+b346 ) >> Followup: MachineOwner >> --------- >> 0: kd> !analyze -v >> ******************************************************************************* >> * * >> * Bugcheck Analysis * >> * * >> ******************************************************************************* >> INTERNAL_POWER_ERROR (a0) >> The power policy manager experienced a fatal error. >> Arguments: >> Arg1: 000000000000010e, The disk subsystem returned corrupt data while reading from the >> hibernation file. >> Arg2: 000000000000000a >> Arg3: 000000000000aa00, Incorrect checksum >> Arg4: 0000000000000418, Previous disk read's checksum > > Does piix3-ide fail to respond to IO/MEM accesses if > PCI_COMMAND_MASTER is not set? Or is it a DMA issue? > It is a DMA issue. After some additional research I see that this patch is wrong, please ignore it. Windows expects DMA transfers from device but does not set bus master bit in PCI command register. Am I understand correctly that there are no special cases for IDE controllers, i.e. bus master bit must be set by SW same way as for other PCI devices? Thanks, Dmitry. > > Thanks, > Marcel > >> According to our tests this problem happens at least on >> Windows 8/8.1/2012/2012R2/10/2016. >> This patch solves https://bugzilla.redhat.com/show_bug.cgi?id=988351 >> Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> >> --- >> hw/pci/pci.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> diff --git a/hw/pci/pci.c b/hw/pci/pci.c >> index 0c6f74a..10af82f 100644 >> --- a/hw/pci/pci.c >> +++ b/hw/pci/pci.c >> @@ -480,7 +480,7 @@ static int get_pci_config_device(QEMUFile *f, void *pv, size_t size, >> memory_region_set_enabled(&s->bus_master_enable_region, >> pci_get_word(s->config + PCI_COMMAND) >> - & PCI_COMMAND_MASTER); >> + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); >> g_free(config); >> return 0; >> @@ -1356,7 +1356,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in, int >> pci_update_irq_disabled(d, was_irq_disabled); >> memory_region_set_enabled(&d->bus_master_enable_region, >> pci_get_word(d->config + PCI_COMMAND) >> - & PCI_COMMAND_MASTER); >> + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); >> } >> msi_write_config(d, addr, val_in, l);
On 17/07/2017 15:48, Dmitry Fleytman wrote: > On 16 Jul 2017, at 19:56 PM, Marcel Apfelbaum <marcel@redhat.com > <mailto:marcel@redhat.com>> wrote: >> >> On 16/07/2017 11:29, Dmitry Fleytman wrote: >>> According to PCI spec. bit 1 of command >>> register (PCI_COMMAND_MEMORY) controls >>> a device's response to memory space accesses. >>> A value of 0 disables the device response. >>> A value of 1 allows the device to respond >>> to memory space accesses. >>> >> >> Hi Dmitry, > > Hi Marcel, > >> >> >>> Current behavior introduced by commit >>> commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d >>> Author: Avi Kivity <avi@redhat.com <mailto:avi@redhat.com>> >>> Date: Wed Oct 3 17:42:58 2012 +0200 >>> pci: honor PCI_COMMAND_MASTER >>> is to ignore device memory space accesses unless >>> bit 2 (PCI_COMMAND_MASTER) is set. >>> Aforementioned commit introduced regression of >>> Windows hibernation (S4) functionality support >>> because on resume Windows kernel sets bits 0 and 1 >>> (PCI_COMMAND_MEMORY | PCI_COMMAND_IO) of boot >>> device's (piix3-ide in our specific case) command >>> register and tries to work with the device. >>> > Since PCI_COMMAND_MASTER bit is not set, device >>> does not answer and Windows fails to resume from >>> hibernation. >> >> As far as I am aware "Bus master" is needed for a device >> to start PCI transactions, while PCI_COMMAND_MEMORY/IO >> controls the device ability to respond to memory/IO accesses, >> not to start them. >> If "Bus master" is needed for DMA access or MSI, the OS should >> explicitly set the PCI_COMMAND_MASTER, right? >> >> >> >>> As a result following BSOD happens: >>> BugCheck A0, {10e, a, aa00, 418} >>> Probably caused by : ntkrnlmp.exe ( >>> nt!PopHiberChecksumHiberFileData+b346 ) >>> Followup: MachineOwner >>> --------- >>> 0: kd> !analyze -v >>> ******************************************************************************* >>> * >>> * >>> * Bugcheck Analysis >>> * >>> * >>> * >>> ******************************************************************************* >>> INTERNAL_POWER_ERROR (a0) >>> The power policy manager experienced a fatal error. >>> Arguments: >>> Arg1: 000000000000010e, The disk subsystem returned corrupt data >>> while reading from the >>> hibernation file. >>> Arg2: 000000000000000a >>> Arg3: 000000000000aa00, Incorrect checksum >>> Arg4: 0000000000000418, Previous disk read's checksum >> >> Does piix3-ide fail to respond to IO/MEM accesses if >> PCI_COMMAND_MASTER is not set? Or is it a DMA issue? >> > > It is a DMA issue. > > After some additional research I see that this patch is wrong, please > ignore it. > > Windows expects DMA transfers from device but does not set > bus master bit in PCI command register. > > Am I understand correctly that there are no special cases for > IDE controllers, i.e. bus master bit must be set by SW same > way as for other PCI devices? > If is a PCI device it has to comply with the same set of rules. The interesting part is the hibernation. Maybe there is a mismatch with Windows expectations regarding the state of the command register after hybernation? Thanks, Marcel > Thanks, > Dmitry. > >> >> Thanks, >> Marcel >> >>> According to our tests this problem happens at least on >>> Windows 8/8.1/2012/2012R2/10/2016. >>> This patch solves https://bugzilla.redhat.com/show_bug.cgi?id=988351 >>> Signed-off-by: Dmitry Fleytman <dmitry@daynix.com >>> <mailto:dmitry@daynix.com>> >>> --- >>> hw/pci/pci.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c >>> index 0c6f74a..10af82f 100644 >>> --- a/hw/pci/pci.c >>> +++ b/hw/pci/pci.c >>> @@ -480,7 +480,7 @@ static int get_pci_config_device(QEMUFile *f, >>> void *pv, size_t size, >>> memory_region_set_enabled(&s->bus_master_enable_region, >>> pci_get_word(s->config + PCI_COMMAND) >>> - & PCI_COMMAND_MASTER); >>> + & (PCI_COMMAND_MASTER | >>> PCI_COMMAND_MEMORY)); >>> g_free(config); >>> return 0; >>> @@ -1356,7 +1356,7 @@ void pci_default_write_config(PCIDevice *d, >>> uint32_t addr, uint32_t val_in, int >>> pci_update_irq_disabled(d, was_irq_disabled); >>> memory_region_set_enabled(&d->bus_master_enable_region, >>> pci_get_word(d->config + PCI_COMMAND) >>> - & PCI_COMMAND_MASTER); >>> + & (PCI_COMMAND_MASTER | >>> PCI_COMMAND_MEMORY)); >>> } >>> msi_write_config(d, addr, val_in, l); >
On Mon, Jul 17, 2017 at 03:48:03PM +0300, Dmitry Fleytman wrote: > Am I understand correctly that there are no special cases for > IDE controllers, i.e. bus master bit must be set by SW same > way as for other PCI devices? Bus mastering is typically enabled by the driver. E.g. under linux: static int virtio_pci_restore(struct device *dev) { struct pci_dev *pci_dev = to_pci_dev(dev); struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev); int ret; ret = pci_enable_device(pci_dev); if (ret) return ret; pci_set_master(pci_dev); return virtio_device_restore(&vp_dev->vdev); } As an exception, in case of BIOS booting using device ROM, it is set by the ROM. E.g. src/hw/virtio-pci.c: vp_reset(vp); pci_enable_busmaster(pci); vp_set_status(vp, VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER );
On 17 Jul 2017, at 19:59 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Mon, Jul 17, 2017 at 03:48:03PM +0300, Dmitry Fleytman wrote: >> Am I understand correctly that there are no special cases for >> IDE controllers, i.e. bus master bit must be set by SW same >> way as for other PCI devices? > > Bus mastering is typically enabled by the driver. > E.g. under linux: > > static int virtio_pci_restore(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); > struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev); > int ret; > > ret = pci_enable_device(pci_dev); > if (ret) > return ret; > > pci_set_master(pci_dev); > return virtio_device_restore(&vp_dev->vdev); > } > > > As an exception, in case of BIOS booting using device ROM, it is set by > the ROM. E.g. src/hw/virtio-pci.c: > > vp_reset(vp); > pci_enable_busmaster(pci); > vp_set_status(vp, VIRTIO_CONFIG_S_ACKNOWLEDGE | > VIRTIO_CONFIG_S_DRIVER ); Thanks, Michael. After some more investigations, there are additional interesting details. First of all, resume from hibernation succeeds without USB host controller (-usbtablet). I did tracing of PCI configuration space writes and here is what I see: ========= Booting with -usbtablet (piix3-usb-uhci) ================ ++ pci_init_bus_master:93: i440FX, enabled: 0 ++ pci_init_bus_master:93: PIIX3, enabled: 0 ++ pci_init_bus_master:93: piix3-ide, enabled: 0 ++ pci_init_bus_master:93: piix3-usb-uhci, enabled: 0 ++ pci_init_bus_master:93: PIIX4_PM, enabled: 0 ++ pci_init_bus_master:93: VGA, enabled: 0 ++ pci_init_bus_master:93: e1000, enabled: 0 All devices start with bus master disabled ++ piix3_reset:121 ++ pci_default_write_config:1363: i440FX, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: PIIX3, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 259, l 2, enabled: 0 Guest writes 259 (2 bytes) to PCI_COMMAND, i.e. PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_SERR. This way it effectively disables PCI_COMMAND_MASTER event if it was enabled from the beginning. ++ pci_default_write_config:1363: piix3-usb-uhci, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: PIIX4_PM, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: VGA, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-usb-uhci, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-usb-uhci, addr 4, val_in 263, l 2, enabled: 4 At the same time it enables PCI_COMMAND_MASTER for piix3-usb-uhci. After that it does a bunch of sector reads without DMA and then switches to DMA mode and eventually crashes ========= Booting without -usbtablet (piix3-usb-uhci) ================ ++ pci_init_bus_master:93: i440FX, enabled: 0 ++ pci_init_bus_master:93: PIIX3, enabled: 0 ++ pci_init_bus_master:93: piix3-ide, enabled: 0 ++ pci_init_bus_master:93: PIIX4_PM, enabled: 0 ++ pci_init_bus_master:93: VGA, enabled: 0 ++ pci_init_bus_master:93: e1000, enabled: 0 All devices start with bus master disabled ++ piix3_reset:121 ++ pci_default_write_config:1363: i440FX, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: PIIX3, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: PIIX4_PM, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: VGA, addr 4, val_in 259, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 259, l 2, enabled: 0 Again it writes 259 to PCI_COMMAND After that it does a bunch of sector reads without DMA as before. ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1285, l 2, enabled: 4 And after that it enables PCI bus master on piix3-ide, starts DMA transfers and SUCEEDS resume from hibernation ++ pci_default_write_config:1363: VGA, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: VGA, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: VGA, addr 4, val_in 1287, l 2, enabled: 4 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1287, l 2, enabled: 4 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1287, l 2, enabled: 4 ++ pci_default_write_config:1363: e1000, addr 4, val_in 1287, l 2, enabled: 4 ++ pci_default_write_config:1363: e1000, addr 4, val_in 263, l 2, enabled: 4 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1280, l 2, enabled: 0 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 1285, l 2, enabled: 4 ++ pci_default_write_config:1363: piix3-ide, addr 4, val_in 261, l 2, enabled: 4 It also enables bus master for all other devices at some point. Do you have any idea for possible directions? Regards, Dmitry > > > -- > MST
On Tue, Jul 18, 2017 at 10:23:06AM +0300, Dmitry Fleytman wrote: > On 17 Jul 2017, at 19:59 PM, Michael S. Tsirkin <mst@redhat.com> wrote: > > > On Mon, Jul 17, 2017 at 03:48:03PM +0300, Dmitry Fleytman wrote: > > Am I understand correctly that there are no special cases for > IDE controllers, i.e. bus master bit must be set by SW same > way as for other PCI devices? > > > Bus mastering is typically enabled by the driver. > E.g. under linux: > > static int virtio_pci_restore(struct device *dev) > { > struct pci_dev *pci_dev = to_pci_dev(dev); > struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev); > int ret; > > ret = pci_enable_device(pci_dev); > if (ret) > return ret; > > pci_set_master(pci_dev); > return virtio_device_restore(&vp_dev->vdev); > } > > > As an exception, in case of BIOS booting using device ROM, it is set by > the ROM. E.g. src/hw/virtio-pci.c: > > vp_reset(vp); > pci_enable_busmaster(pci); > vp_set_status(vp, VIRTIO_CONFIG_S_ACKNOWLEDGE | > VIRTIO_CONFIG_S_DRIVER ); > > > > Thanks, Michael. > > After some more investigations, there are additional interesting details. > > First of all, resume from hibernation succeeds without USB host controller > (-usbtablet). > > I did tracing of PCI configuration space writes and here is what I see: All I can say is uhci confuses windows somehow. Try another type of controller? > -- > MST > >
diff --git a/hw/pci/pci.c b/hw/pci/pci.c index 0c6f74a..10af82f 100644 --- a/hw/pci/pci.c +++ b/hw/pci/pci.c @@ -480,7 +480,7 @@ static int get_pci_config_device(QEMUFile *f, void *pv, size_t size, memory_region_set_enabled(&s->bus_master_enable_region, pci_get_word(s->config + PCI_COMMAND) - & PCI_COMMAND_MASTER); + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); g_free(config); return 0; @@ -1356,7 +1356,7 @@ void pci_default_write_config(PCIDevice *d, uint32_t addr, uint32_t val_in, int pci_update_irq_disabled(d, was_irq_disabled); memory_region_set_enabled(&d->bus_master_enable_region, pci_get_word(d->config + PCI_COMMAND) - & PCI_COMMAND_MASTER); + & (PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY)); } msi_write_config(d, addr, val_in, l);
According to PCI spec. bit 1 of command register (PCI_COMMAND_MEMORY) controls a device's response to memory space accesses. A value of 0 disables the device response. A value of 1 allows the device to respond to memory space accesses. Current behavior introduced by commit commit 1c380f9460522f32c8dd2577b2a53d518ec91c6d Author: Avi Kivity <avi@redhat.com> Date: Wed Oct 3 17:42:58 2012 +0200 pci: honor PCI_COMMAND_MASTER is to ignore device memory space accesses unless bit 2 (PCI_COMMAND_MASTER) is set. Aforementioned commit introduced regression of Windows hibernation (S4) functionality support because on resume Windows kernel sets bits 0 and 1 (PCI_COMMAND_MEMORY | PCI_COMMAND_IO) of boot device's (piix3-ide in our specific case) command register and tries to work with the device. Since PCI_COMMAND_MASTER bit is not set, device does not answer and Windows fails to resume from hibernation. As a result following BSOD happens: BugCheck A0, {10e, a, aa00, 418} Probably caused by : ntkrnlmp.exe ( nt!PopHiberChecksumHiberFileData+b346 ) Followup: MachineOwner --------- 0: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* INTERNAL_POWER_ERROR (a0) The power policy manager experienced a fatal error. Arguments: Arg1: 000000000000010e, The disk subsystem returned corrupt data while reading from the hibernation file. Arg2: 000000000000000a Arg3: 000000000000aa00, Incorrect checksum Arg4: 0000000000000418, Previous disk read's checksum According to our tests this problem happens at least on Windows 8/8.1/2012/2012R2/10/2016. This patch solves https://bugzilla.redhat.com/show_bug.cgi?id=988351 Signed-off-by: Dmitry Fleytman <dmitry@daynix.com> --- hw/pci/pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)