bhyve: Treat the COMMAND register for PCI passthru devices as emulated

[jhb]

Summary

Don't pass through writes of the command register through to the
physical device. These registers do not need to be in sync, and in
some cases (e.g. when the guest is sizing the BAR and temporarily
disables decoding), the states need to diverge.

PR: 205549
Sponsored by: Chelsio Communications

[corvink]

Shouldn't we set the command register to a known good value or do we expect that the host always sets a good value? If the host disables mem/io decoding for some reason, we're unable to read any values from the BARs MMIO space.

[jhb]

In D46179#1052757, @corvink wrote:

Shouldn't we set the command register to a known good value or do we expect that the host always sets a good value? If the host disables mem/io decoding for some reason, we're unable to read any values from the BARs MMIO space.

No, this is the responsibility of the host kernel and in particular the ppt(4) driver. For example, when the ppt(4) driver maps the physical BARs via bus_alloc_resource() with RF_ACTIVE, that enables the relevant decoding bits in the command register. Similarly, the host kernel takes clear of setting/clearing INTxDIS as needed when enabling/disabling MSI interrupts. I hadn't really realized this until yesterday, but ppt(4)'s actions as a device driver is what determines the correct values of the physical command register. For example, during guest boot while the guest is messing with the guest BARs to size the BAR, etc. the physical BAR remains unchanged and should remain enabled the entire time.