[PATCH] Consider a VGA to be active if it responds to either IO or memory access

[PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Ian Campbell]

Under Xen the VGA card ends up configured for memory access only.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 src/pci.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/pci.c b/src/pci.c
index 944a393..471733c 100644
--- a/src/pci.c
+++ b/src/pci.c
@@ -130,7 +130,7 @@ pci_find_vga(void)
         }
         if (cls == PCI_CLASS_DISPLAY_VGA) {
             u16 cmd = pci_config_readw(bdf, PCI_COMMAND);
-            if (cmd & PCI_COMMAND_IO && cmd & PCI_COMMAND_MEMORY)
+            if (cmd & PCI_COMMAND_IO || cmd & PCI_COMMAND_MEMORY)
                 // Found active vga card
                 return bdf;
         }
-- 
1.7.2.5

Re: [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Kevin O'Connor]

On Thu, May 26, 2011 at 03:43:28PM +0100, Ian Campbell wrote:
> Under Xen the VGA card ends up configured for memory access only.

That's odd.  How does the vga bios work if the Xen VGA device doesn't
handle inb/outb accesses?

-Kevin

Re: [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Ian Campbell]

On Fri, 2011-05-27 at 01:59 +0100, Kevin O'Connor wrote:
> On Thu, May 26, 2011 at 03:43:28PM +0100, Ian Campbell wrote:
> > Under Xen the VGA card ends up configured for memory access only.
> 
> That's odd.  How does the vga bios work if the Xen VGA device doesn't
> handle inb/outb accesses?

I'm not entirely sure, but it does...

The Xen VGA device is the Cirrus GD 5446 provided by qemu. The I/O ports
are the VGA control registers at 0x3xx which are not covered by any PCI
BARS (FWIW this device has no I/O BARS, and two memory BARS).

It's not obvious whether the I/O space enable bit in the PCI cfg command
register is supposed to control the availability of non-PCI registers or
not. Neither the PCI spec nor the GD-5446 datasheet are particularly
clear on the matter.

I've just discovered that the ancient pentium box I use as a home
firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O
BARS but it does have the I/O bit set in the PCI command register.

It's not clear who was responsible for setting that bit, in general in
the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that
either the VGA BIOS is expected to enable it if the hardware it drives
requires it or that BIOSen special case class=VGA devices and always
enable I/O for one of them.

It looks like coreboot always forces this bit on for the VGA device
which it determines to be the primary, which is good enough for me --
I'll make a patch to the Xen pci setup code to implement that instead of
this change to SeaBIOS.

Cheers,
Ian.

Re: [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Marc Jones]

On Fri, May 27, 2011 at 2:44 AM, Ian Campbell
<Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2011-05-27 at 01:59 +0100, Kevin O'Connor wrote:
>> On Thu, May 26, 2011 at 03:43:28PM +0100, Ian Campbell wrote:
>> > Under Xen the VGA card ends up configured for memory access only.
>>
>> That's odd.  How does the vga bios work if the Xen VGA device doesn't
>> handle inb/outb accesses?
>
> I'm not entirely sure, but it does...
>
> The Xen VGA device is the Cirrus GD 5446 provided by qemu. The I/O ports
> are the VGA control registers at 0x3xx which are not covered by any PCI
> BARS (FWIW this device has no I/O BARS, and two memory BARS).
>
> It's not obvious whether the I/O space enable bit in the PCI cfg command
> register is supposed to control the availability of non-PCI registers or
> not. Neither the PCI spec nor the GD-5446 datasheet are particularly
> clear on the matter.
>
> I've just discovered that the ancient pentium box I use as a home
> firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O
> BARS but it does have the I/O bit set in the PCI command register.
>
> It's not clear who was responsible for setting that bit, in general in
> the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that
> either the VGA BIOS is expected to enable it if the hardware it drives
> requires it or that BIOSen special case class=VGA devices and always
> enable I/O for one of them.
>
> It looks like coreboot always forces this bit on for the VGA device
> which it determines to be the primary, which is good enough for me --
> I'll make a patch to the Xen pci setup code to implement that instead of
> this change to SeaBIOS.
>

Hi Ian,

There are some exceptions around VGA and PCI. The primary display is
usually the first VGA device found, by checking device class code.
Enabling the IO bit on a VGA device causes it to claim the legacy
cycles. It doesn't matter if the device has an IO bar.
If the VGA device also has the device's palette snoop bit set, it
claims reads and snarfs writes allowing a downstream device to also
get the writes. Note that there is also the VGA enable to be set on
bridges above the device and VGA palette snoop for bridges that a VGA
device is behind below the primary device bus.

Marc



-- 
http://se-eng.com

Re: [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Ian Campbell]

On Fri, 2011-05-27 at 16:35 +0100, Marc Jones wrote:
> On Fri, May 27, 2011 at 2:44 AM, Ian Campbell
> <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2011-05-27 at 01:59 +0100, Kevin O'Connor wrote:
> >> On Thu, May 26, 2011 at 03:43:28PM +0100, Ian Campbell wrote:
> >> > Under Xen the VGA card ends up configured for memory access only.
> >>
> >> That's odd.  How does the vga bios work if the Xen VGA device doesn't
> >> handle inb/outb accesses?
> >
> > I'm not entirely sure, but it does...
> >
> > The Xen VGA device is the Cirrus GD 5446 provided by qemu. The I/O ports
> > are the VGA control registers at 0x3xx which are not covered by any PCI
> > BARS (FWIW this device has no I/O BARS, and two memory BARS).
> >
> > It's not obvious whether the I/O space enable bit in the PCI cfg command
> > register is supposed to control the availability of non-PCI registers or
> > not. Neither the PCI spec nor the GD-5446 datasheet are particularly
> > clear on the matter.
> >
> > I've just discovered that the ancient pentium box I use as a home
> > firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O
> > BARS but it does have the I/O bit set in the PCI command register.
> >
> > It's not clear who was responsible for setting that bit, in general in
> > the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that
> > either the VGA BIOS is expected to enable it if the hardware it drives
> > requires it or that BIOSen special case class=VGA devices and always
> > enable I/O for one of them.
> >
> > It looks like coreboot always forces this bit on for the VGA device
> > which it determines to be the primary, which is good enough for me --
> > I'll make a patch to the Xen pci setup code to implement that instead of
> > this change to SeaBIOS.
> >
> 
> Hi Ian,
> 
> There are some exceptions around VGA and PCI. The primary display is
> usually the first VGA device found, by checking device class code.
> Enabling the IO bit on a VGA device causes it to claim the legacy
> cycles. It doesn't matter if the device has an IO bar.
> If the VGA device also has the device's palette snoop bit set, it
> claims reads and snarfs writes allowing a downstream device to also
> get the writes. Note that there is also the VGA enable to be set on
> bridges above the device and VGA palette snoop for bridges that a VGA
> device is behind below the primary device bus.

Useful info, thanks Marc!

Ian.

Re: [PATCH] Consider a VGA to be active if it responds to either IO or memory access

[Scott Duplichan]

Ian Campbell wrote:

]It's not obvious whether the I/O space enable bit in the PCI cfg command
]register is supposed to control the availability of non-PCI registers or
]not. Neither the PCI spec nor the GD-5446 datasheet are particularly
]clear on the matter.

The VGA class code indicates that the legacy I/O ranges are decoded,
when enabled in the command register. True the PCI spec does not spell
this out. But there is really no other way it could work. The BAR 
mechanism does not provide a way to either report or accept programming
for a range such as 3b0-3bb.

]I've just discovered that the ancient pentium box I use as a home
]firewall has a GD 5446 in it (useful to know!), it doesn't have any I/O
]BARS but it does have the I/O bit set in the PCI command register.
]
]It's not clear who was responsible for setting that bit, in general in
]the absence of an I/O BAR the BIOS wouldn't know to do so. I expect that
]either the VGA BIOS is expected to enable it if the hardware it drives
]requires it or that BIOSen special case class=VGA devices and always
]enable I/O for one of them.

BIOS or some other firmware (coreboot) must enable I/O decode in 
the command register for VGA class devices. Option ROMs in general do
not enable it.

]It looks like coreboot always forces this bit on for the VGA device
]which it determines to be the primary, which is good enough for me --
]I'll make a patch to the Xen pci setup code to implement that instead of
]this change to SeaBIOS.

Yes, right here:
http://tracker.coreboot.org/trac/coreboot/browser/trunk/src/devices/pci_devi
ce.c#L619

Thanks,
Scott