[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: xen-devel@xxxxxxxxxxxxxxxxxxx
  • From: Pavel MatÄja <pavel@xxxxxxxxxx>
  • Date: Wed, 25 Jan 2012 21:48:42 +0100
  • Delivery-date: Wed, 25 Jan 2012 20:49:20 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

On Wed 25. of January 2012 21:29:13 you 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?)

It makes sense and it's quite complicated.
Primary card is "bound" to those ports by PCI bridge. When you access legacy 
IO port the PCI will examine all bridges looking for VGA Enable bit in the 
Bridge Control register and pass the call to such such bridge. So there should 
be linux syscall to vgaarb before and after each ioport access which will set 
and unset the bit for right card's bridge.
But this setup works anyway! Windows driver doesn't access ioports. Just VGA 
BIOS does. It means loading the BIOS will mess image on primary card.
In the end I'm able to boot three virtual machines all with passed (AMD) VGA.
-- 
Pavel Mateja

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.