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; }
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
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.
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
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
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.
-
Ian Campbell -
Ian Campbell -
Kevin O'Connor -
Marc Jones -
Scott Duplichan