Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs

[Bernhard Beschow]

Am 27. Juni 2023 07:11:33 UTC schrieb Paolo Bonzini <pbonzini@redhat.com>:
>On 6/26/23 23:19, Olaf Hering wrote:
>> I need advice on how to debug this.
>> 
>> One thing that stands out is uhci_irq().
>> It reads a u16 from the USBSTS register.
>> 
>> On the qemu side, this read is served from bmdma_read. Since the read
>> size is 2, the result is ~0, and uhci_irq() turns the controller off.
>> In other words, memory_region_ops_read from addr=0xc102 is served from 
>> "piix-bmdma"
>> 
>> If the pci_set_word calls in piix_ide_reset are skipped, the read is
>> served from uhci_port_write. This is the expected behavior.
>> In other words, memory_region_ops_read from addr=0xc102 is served from 
>> "uhci".
>
>I think what's happening is that
>
>    pci_set_byte(pci_conf + 0x20, 0x01);  /* BMIBA: 20-23h */
>
>is setting the BAR to 0xC100, therefore overlapping the UHCI device's region.  
>In principle this line shouldn't be necessary at all though; it's enough to 
>clear the COMMAND register.

Interesting. The BAR is a 32 bit register whose default value is 0x00000001. I 
think what's supposed to happen here is a pci_set_long() rather than a 
pci_set_byte().

Bits 4..15 represent the BAR address, and pci_set_byte() only clears bits 4..7, 
leaving bits 8..15 unchanged. Perhaps this causes the BAR to be moved into the 
UHCI region? Does changing the call to pci_set_long() fix the problem?

Best regards,
Bernhard

>
>Can you check the value of the COMMAND register (pci_conf + 0x04, 16 bits, 
>little endian)?  Something might be causing the register to be set back to a 
>nonzero value, therefore re-enabling the I/O at the address that overlaps the 
>UHCI device.
>
>Paolo
>
>