Re: Unreachable cards in vgaarb

[Bjorn Helgaas <helgaas@kernel.org>]

[+cc Alex]

On Thu, Nov 06, 2025 at 12:16:24PM +0900, Simon Richter wrote:
> Hi,
> 
> I have a card whose VGA registers are not actually reachable, for multiple
> reasons:
> 
> 1. the system in question has multiple PCI domains
> 2. the system in question does not support IO access
> 3. one of the bridges involved does not support VGA register forwarding
> 
> Obviously, the "works for me" solution would be to teach vgaarb to check if
> the VGA bit actually got set in the bridge control register (because
> apparently, that is how a bridge indicates missing support), and return an
> error. I plan to do that, but that doesn't solve the others.
> 
> The specific actual problem I'm trying to solve here is that there is a
> workaround in the i915 and xe drivers that pokes the VGA register space on
> the same card after changing power states, and this falls over on my system.
> Skipping this is safe if we can guarantee that vgacon will not generate
> accesses later, so I think having vgaarb recognize that the card is
> unreachable and returning an error is sufficient here.
> 
> I have no idea whether this will break other systems though -- can we
> reasonably assume that any PCI or PCIe bridge that is capable of forwarding
> VGA accesses will proudly display the VGA bit set in the bridge control
> register, or is a quirk needed here?

I think we can assume that a bridge with PCI_BRIDGE_CTL_VGA set
forwards VGA accesses, and bridges without it do not.

> For multiple PCI domains, I have no clue how to determine where accesses end
> up. My feeling is that it's supposed to be "all of them, mediated by VGA
> bits on root bridges", but I don't know if this is actually true. Is anyone
> actually building machines with a CPU architecture that has a separate IO
> range, and multiple PCI domains?

Multiple PCI domains were supported on ia64, and I think multiple VGA
devices were also supported, but I don't remember the details about
how.  That code has all been removed but should still be in the git
history.

> For "no IO access", it is even more complex -- it appears that the approach
> on POWER is to define inb/outb as MMIO, offset from a global variable that
> points at a PCI range, which means this access will only show up in one of
> the PCI(e) controllers.
> 
> What is unclear to me is
> 
> 1. whether there is supposed to be a mechanism to generate IO accesses from
> those,
> 2. whether this range should be excluded from MMIO to not accidentally
> create conflicts
> 3. whether vgaarb needs to adjust this variable too
> 4. if this variable should instead be maintained by vgaarb
> 5. if we should have dedicated vga_inb/vga_outb macros or if we can assume
> that any inb/outb on machines that don't have an IO range will be VGA
> accesses anyway
> 6. whether it is interesting to create special handling for cards that have
> VGA registers at the beginning of their non-prefetchable MMIO range (AFAIK,
> some Intel cards do, and you can address them either via IO or via MMIO to
> their non-prefetchable mapping).
> 7. whether this affects more than two users.
> 
>    Simon