[Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Dmitry Fleytman]

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(-)

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);
-- 
2.9.4

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Marcel Apfelbaum]

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);
> 

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Dmitry Fleytman]

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);

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Marcel Apfelbaum]

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);
> 

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Michael S. Tsirkin]

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 );


-- 
MST

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Dmitry Fleytman]

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

Re: [Qemu-devel] [PATCH] pci: honor PCI_COMMAND_MEMORY

[Michael S. Tsirkin]

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
> 
>