[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2] piix: fix regression during unplug in Xen HVM domUs
Am 27. Juni 2023 07:11:33 UTC schrieb Paolo Bonzini <pbonzini@xxxxxxxxxx>: >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 > >
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |