Re: [PATCH v3 1/2] qpci_device_enable: Allow for command bits hardwired to 0

[Lev Kujawski]

Michael S. Tsirkin writes:

> On Sun, Sep 25, 2022 at 09:37:58AM +0000, Lev Kujawski wrote:
>> Devices like the PIIX3/4 IDE controller do not support certain modes
>> of operation, such as memory space accesses, and indicate this lack of
>> support by hardwiring the applicable bits to zero.  Extend the QEMU
>> PCI device testing framework to accommodate such devices.
>> 
>> * tests/qtest/libqos/pci.h: Add the command_disabled word to indicate
>>   bits hardwired to 0.
>> * tests/qtest/libqos/pci.c: Verify that hardwired bits are actually
>>   hardwired.
>> 
>> Signed-off-by: Lev Kujawski <lkujaw@mailbox.org>
>> ---
>>  tests/qtest/libqos/pci.c | 13 +++++++------
>>  tests/qtest/libqos/pci.h |  1 +
>>  2 files changed, 8 insertions(+), 6 deletions(-)
>> 
>> diff --git a/tests/qtest/libqos/pci.c b/tests/qtest/libqos/pci.c
>> index b23d72346b..4f3d28d8d9 100644
>> --- a/tests/qtest/libqos/pci.c
>> +++ b/tests/qtest/libqos/pci.c
>> @@ -220,18 +220,19 @@ int qpci_secondary_buses_init(QPCIBus *bus)
>>  
>>  void qpci_device_enable(QPCIDevice *dev)
>>  {
>> -    uint16_t cmd;
>> +    const uint16_t enable_bits =
>> +        PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
>> +    uint16_t cmd, new_cmd;
>>  
>>      /* FIXME -- does this need to be a bus callout? */
>>      cmd = qpci_config_readw(dev, PCI_COMMAND);
>> -    cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
>> +    cmd |= enable_bits;
>>      qpci_config_writew(dev, PCI_COMMAND, cmd);
>>  
>>      /* Verify the bits are now set. */
>> -    cmd = qpci_config_readw(dev, PCI_COMMAND);
>> -    g_assert_cmphex(cmd & PCI_COMMAND_IO, ==, PCI_COMMAND_IO);
>> -    g_assert_cmphex(cmd & PCI_COMMAND_MEMORY, ==, PCI_COMMAND_MEMORY);
>> -    g_assert_cmphex(cmd & PCI_COMMAND_MASTER, ==, PCI_COMMAND_MASTER);
>> +    new_cmd = qpci_config_readw(dev, PCI_COMMAND);
>> +    new_cmd &= enable_bits;
>> +    g_assert_cmphex(new_cmd, ==, enable_bits & ~dev->command_disabled);
>>  }
>>  
>>  /**
>> diff --git a/tests/qtest/libqos/pci.h b/tests/qtest/libqos/pci.h
>> index 8389614523..eaedb98588 100644
>> --- a/tests/qtest/libqos/pci.h
>> +++ b/tests/qtest/libqos/pci.h
>> @@ -68,6 +68,7 @@ struct QPCIDevice
>>      bool msix_enabled;
>>      QPCIBar msix_table_bar, msix_pba_bar;
>>      uint64_t msix_table_off, msix_pba_off;
>> +    uint16_t command_disabled;
>
>
> Can we get this from device's wmask?
>

I have not seen any way to pass the wmask from the underlying PCI device
without violating the abstraction of the driver testing framework.

Another approach might be to omit the verification of the PCI command
bits in the assumption that some filtering mechanism like wmask is
active, but I think the advantage of this patch is that it makes the
expected (albeit abnormal) behavior explicit in the device test.

Kind regards,
Lev Kujawski