Re: [Xen-devel] [Xen-users] VGA passthough still not working

[Pavel MatÄja <pavel@xxxxxxxxxx>]

On Wed 25. of January 2012 21:29:13 Doug Magee wrote:
> On Wed, 2012-01-25 at 20:52 +0100, Pavel MatÄja wrote:
> > On Wed 25. of January 2012 20:29:12 Pavel MatÄja wrote:
> > > On Wed 25. of January 2012 17:52:11 Doug Magee wrote:
> > > > Also, i believe you said the card you're trying to pass through is
> > > > not the primary card in your host system.  If that's the case, don't
> > > > use gfx_passthru or expect to get the video bios working.  The
> > > > 'primary' video adapter owns certain io ports and memory areas that
> > > > are consitent from machine to machine.  Also, the system will copy
> > > > the vbios from the card to a location in memory (0xc0000) so it can
> > > > execute at boot time.
> > > > 
> > > > Xen's gfx_passthru code depends on all of these factors.  As the code
> > > > stands, if you use gfx_passthru on a secondary card, it will still
> > > > copy the vbios from the primary card (as it simply reads memory from
> > > > 0xc0000), and directly map io ports and low memory areas to those
> > > > used by the primary card in the host system.  In this case the guest
> > > > will almost certainly never get past executing ROMBIOS, and the host
> > > > may or may not lock up or experience 'issues'.
> > > 
> > > This will do the trick with secondary card (replace path to VGA BIOS):
> > > 
> > > --- xen-unstable.hg.working/tools/ioemu-remote/hw/pt-graphics.c
> > > 2012-01-25 20:26:37.927654890 +0100
> > > +++ xen-unstable.hg.working.generic/tools/ioemu-remote/hw/pt-graphics.c
> > > 2011-07-30 13:57:57.347396095 +0200
> > > @@ -487,10 +487,10 @@
> > > 
> > >  {
> > >  
> > >      int fd;
> > >      uint32_t bios_size = 0;
> > > 
> > > -    uint32_t start = 0;
> > > +    uint32_t start = 0xC0000;
> > > 
> > >      uint16_t magic = 0;
> > > 
> > > -    if ( (fd = open("/lib/firmware/ASUS.HD6850.1024.101007.bin",
> > > O_RDONLY)) < 0 )
> > > +    if ( (fd = open("/dev/mem", O_RDONLY)) < 0 )
> > > 
> > >      {
> > >      
> > >          PT_LOG("Error: Can't open /dev/mem: %s\n", strerror(errno));
> > >          return 0;
> > 
> > Sorry, switch the + and -.
> 
> This will load the proper BIOS, but it seems this wouldn't be enough.
> In hw/pt-graphics.c:register_vga_regions(), we map 1:1 ioports
> 0x3b0-0x3bb, 0x3c0-0x3df, and memory at 0xa0000-0xbffff.
> 
> If i understand this correctly, these ioports and memory areas are bound
> to the primary video adapter in the host on boot by the BIOS, depending
> on what device you've selected in the BIOS setup screen to be your
> primary adapter.  Therefore, you could load the proper bios, but it
> would still write to memory and io ports that are bound to the primary
> card in the host, not the card being passed through to the guest.
> 
> Does this make sense? (Or, am i nuts?)

To save you some time:

Linux VGA arbiter:
http://lwn.net/Articles/346404/

PCI specification:
4.5.1. VGA Compatible Addressing
The VGA Enable bit in the Bridge Control register is used to control response 
by the bridge to both the VGA frame buffer addresses and to the VGA register 
addresses. If a VGA compatible device is located downstream of a bridge, the 
VGA Enable bit must be set. If the VGA Enable bit is set, the bridge will 
positively decode and forward memory accesses to VGA frame buffer
addresses and I/O accesses to VGA registers from the primary interface to the 
secondary interface (and block forwarding from the secondary to primary 
interface of these same accesses). A bridge never forwards transactions that 
access VGA BIOS memory addresses (regardless of the setting of the VGA Enable 
bit). ROM code provided by PCI compatible devices must be copied to system 
memory before execution and may be mapped to any address in PCI memory
address space via the Expansion ROM Base Address register in the deviceâs 
configuration header.
VGA memory addresses
â
0A 0000h through 0B FFFFh
VGA I/O addresses (including ISA aliases - AD[15::10] are not decoded)
â
AD[9::0] = 3B0h through 3BBh, and 3C0h through 3DFh
-- 
Pavel Mateja

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