Re: [PATCH v2] x86/PCI: Prefer MMIO over PIO on all hypervisor

From: Alexander Graf
Date: Tue Oct 04 2022 - 04:23:24 EST

Hey Nadav,

On 03.10.22 19:34, Nadav Amit wrote:
On Oct 3, 2022, at 8:03 AM, Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> wrote:

Not my but rather PCI maintainer's call but IMHO dropping 'const' is
better, introducing a new global var is our 'last resort' and should be
avoided whenever possible. Alternatively, you can add a
raw_pci_ext_ops_preferred() function checking somethin within 'struct
hypervisor_x86' but I'm unsure if it's better.

Also, please check Alex' question/suggestion.
Here is my take (and Ajay knows probably more than me):

Looking briefly on MCFG, I do not see a clean way of using the ACPI table.
The two options are either to use a reserved field (which who knows, might
be used one day) or some OEM ID. I am also not familiar with
PCI_COMMAND.MEMORY=0, so Ajay can hopefully give some answer about that.

Anyhow, I understand (although not relate) to the objection for a new global
variable. How about explicitly calling this hardware bug a “bug” and using
the proper infrastructure? Calling it explicitly a bug may even push whoever
can to resolve it.

I am a lot more concerned with how we propagate it externally than within Linux. If we hard code that all Linux kernels 6.2+ that are running in VMware prefer ECAM over PIO, we lock ourselves into that stance for better or worse, which means:

* All past and future versions of any VMware hypervisor product have to always allow ECAM access for any PCIe config space write
* No other hypervisor benefits from any of this without upstream code change
* No real hardware platform benefits from this without upstream code change

By moving it into MCFG, we can create a path for the outside environment to tell the OS whether it's safe to use ECAM always. This obviously doesn't work with MCFG as it stands today, we'd have to propose an MCFG spec change to the PCI SIG's "PCI Firmware Specification" to add the respective field. Future VMware versions could then always expose the flag - and if you find it broken, remove it again.

Putting all of the logic on which system potentially prefers ECAM over PIO config space access into Linux is just a big hack that we should avoid as much as possible.


Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879