Unreachable cards in vgaarb

Unreachable cards in vgaarb

[Simon Richter]

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?

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?

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

Re: Unreachable cards in vgaarb

[Bjorn Helgaas]

[+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