Xen devel - May 2011 - [PATCH] Consider a VGA to be active if it responds to either IO or memory access

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel