Writes to the BARs are ignored if memory decoding is enabled for the device, and the same happen with ROM BARs if the write is an attempt to change the position of the BAR without disabling it first.
The reason of ignoring such writes is a limitation in Xen, as it would need to unmap the BAR, change the address, and remap the BAR at the new position, which the current logic doesn't support. Some devices however seem to have the memory decoding bit hardcoded to enabled, and attempts to disable it don't get reflected on the command register. This causes issues for well behaved guests that disable memory decoding and then try to size the BARs, as vPCI will think memory decoding is still enabled and ignore the write. Since vPCI doesn't explicitly care about whether the memory decoding bit is disabled as long as the BAR is not mapped in the guest p2m use the information in the vpci_bar to check whether the BAR is mapped, and refuse writes only based on that information. Signed-off-by: Roger Pau Monné <[email protected]> --- xen/drivers/vpci/header.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c index 4d7f8f4a30..4b39737b76 100644 --- a/xen/drivers/vpci/header.c +++ b/xen/drivers/vpci/header.c @@ -388,7 +388,7 @@ static void cf_check bar_write( else val &= PCI_BASE_ADDRESS_MEM_MASK; - if ( pci_conf_read16(pdev->sbdf, PCI_COMMAND) & PCI_COMMAND_MEMORY ) + if ( bar->enabled ) { /* If the value written is the current one avoid printing a warning. */ if ( val != (uint32_t)(bar->addr >> (hi ? 32 : 0)) ) @@ -425,7 +425,7 @@ static void cf_check rom_write( uint16_t cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND); bool new_enabled = val & PCI_ROM_ADDRESS_ENABLE; - if ( (cmd & PCI_COMMAND_MEMORY) && header->rom_enabled && new_enabled ) + if ( rom->enabled && new_enabled ) { gprintk(XENLOG_WARNING, "%pp: ignored ROM BAR write with memory decoding enabled\n", -- 2.37.3
