Xen users - Apr 2005 - [Fwd: Re: [Xen-devel] Run X in other domains?]

Re-posting here after xen-devel@lists.sourceforge.net failed.

-- 
Sean Atkinson <sean@netproject.com>
Netproject


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

Sean Atkinson <sean@netproject.com> writes:
> The output from lspci lists everything but the VGA card in domain 0,
> unless "lspci -H 1" is used.  In other domains, lspci reports
only the
> VGA card and "lspci -H 1" reports "You need to be root to
have access to
> I/O ports".  However X still starts OK in domain 0, which surprised
my.
X wants bang directly on the Hardware.  Try "X -scanpci" in domain 0,
most likely you''ll see the hidden gfx card listed there.
> Does anybody have any experience with X in other domains, or thoughts on
> how I might proceed please?
I tried the same some time ago in user mode linux (tried to make X11
run on top of a virtual framebuffer device) and ran into simliar
issues.  It simply didn''t work without hacking the X-Server.  X11 was
very unhappy about not being able to access hardware directly, even
though there was absolutely no need to do that.  I wanted it simply
open and use the /dev/fb0 device ...

X.org has several ways of accessing the PCI bus, you can play with
that using the "scanpci" utility.  "OS config" (-O switch
for scanpci)
should in theory use /proc/bus/pci, work fine without direct hardware
access enabled and list the gfx card in the domain you''ve assigned it
to.  In practice it doesn''t, scanpci refuses to work without iopl
access and also doesn''t use /proc/bus/pci due to a bug.  It should
have improved in x.org tree, cvs HEAD, because I bugged the suse x.org
guy to look into this because of the uml issues mentioned above.
Havn''t tested that recently though.

HTH,

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

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

Hi Gerd,

Thanks for the response and your tips.

On Tue, 2005-04-19 at 11:07 +0200, Gerd Knorr wrote:
> Sean Atkinson <sean@netproject.com> writes:
> 
> > The output from lspci lists everything but the VGA card in domain 0,
> > unless "lspci -H 1" is used.  In other domains, lspci
reports only the
> > VGA card and "lspci -H 1" reports "You need to be root
to have access to
> > I/O ports".  However X still starts OK in domain 0, which
surprised my.
> 
> X wants bang directly on the Hardware.  Try "X -scanpci" in
domain 0,
> most likely you''ll see the hidden gfx card listed there.
"X -scanpci" silently exits in every environment I tried, except in
domain 1 where it fails with "xf86EnableIOPorts: Failed to set IOPL for
I/O".  Perhaps I''m missing something?
> > Does anybody have any experience with X in other domains, or thoughts
on
> > how I might proceed please?
> 
> I tried the same some time ago in user mode linux (tried to make X11
> run on top of a virtual framebuffer device) and ran into simliar
> issues.  It simply didn''t work without hacking the X-Server.  X11
was
> very unhappy about not being able to access hardware directly, even
> though there was absolutely no need to do that.  I wanted it simply
> open and use the /dev/fb0 device ...
Oh dear - this doesn''t sound too encouraging ... :o(
> X.org has several ways of accessing the PCI bus, you can play with
> that using the "scanpci" utility.  "OS config" (-O
switch for scanpci)
> should in theory use /proc/bus/pci, work fine without direct hardware
> access enabled and list the gfx card in the domain you''ve assigned
it
> to.  In practice it doesn''t, scanpci refuses to work without iopl
> access and also doesn''t use /proc/bus/pci due to a bug.  It should
> have improved in x.org tree, cvs HEAD, because I bugged the suse x.org
> guy to look into this because of the uml issues mentioned above.
> Havn''t tested that recently though.
In domain 0 with my graphics card hidden, passing "-O" to the scanpci
binary or "-H 1" to lspci adds 3 devices to the output - the VGA card,
AGP bridge and a SMBus device.  In domain 1 both binaries fail reporting
I/O port problems.

Guess I''ll have to wait to try these upcoming X fixes ...

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject


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

Gerd Knorr wrote:
> I tried the same some time ago in user mode linux (tried to make X11
> run on top of a virtual framebuffer device) and ran into simliar
> issues.  It simply didn''t work without hacking the X-Server.  X11
was
> very unhappy about not being able to access hardware directly, even
> though there was absolutely no need to do that.  I wanted it simply
> open and use the /dev/fb0 device ...
if I''m understanding correctly, this sounds very similar to what the 
colinux folks are trying to do with making and X11 run out of their 
virtual machine on Windows.

it may be worth speaking with them and try to build a common solution.

---eric

-- 
http://www.wired.com/wired/archive/13.03/view.html?pg=5

The result of the duopoly that currently defines "competition" is that
prices and service suck. We''re the world''s leader in Internet
technology - except that we''re not.

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

> > X wants bang directly on the Hardware.  Try "X -scanpci" in
domain 0,
> > most likely you''ll see the hidden gfx card listed there.
> 
> "X -scanpci" silently exits in every environment I tried, except
in
> domain 1 where it fails with "xf86EnableIOPorts: Failed to set IOPL
for
> I/O".  Perhaps I''m missing something?
Hmm, strange.  Works fine here, both on the bare metal and within domain
0.  xorg 6.8.2.

Failure in domain 1 isn''t surprising as it can''t access the
hardware
directly.
> > X.org has several ways of accessing the PCI bus, you can play with
> > that using the "scanpci" utility.  "OS config" (-O
switch for scanpci)
> > should in theory use /proc/bus/pci, work fine without direct hardware
> > access enabled and list the gfx card in the domain you''ve
assigned it
> > to.  In practice it doesn''t, scanpci refuses to work without
iopl
> > access and also doesn''t use /proc/bus/pci due to a bug.  It
should
> > have improved in x.org tree, cvs HEAD, because I bugged the suse x.org
> > guy to look into this because of the uml issues mentioned above.
> > Havn''t tested that recently though.
> 
> In domain 0 with my graphics card hidden, passing "-O" to the
scanpci
> binary or "-H 1" to lspci adds 3 devices to the output - the VGA
card,
> AGP bridge and a SMBus device.
Well, that''s exactly the scanpci bug mentioned.  With "-O" it
*should*
use /proc/bus/pci (and thus list the same devices lspci lists without
"-H 1").  But it doesn''t :-/
> In domain 1 both binaries fail reporting I/O port problems.
That''s the other issue.  Both refuse to work without iopl, even if they
don''t need it, thus fail to work in domain-1.
> Guess I''ll have to wait to try these upcoming X fixes ...
Well, as mentioned it *should* be fixed in the X.org cvs now (but it was
checked in after the 6.8.2 release), so you could try building a fresh
checkout and see if that works better.  I hope it does, but havn''t
verified it yet ...

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

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

On Tue, Apr 19, 2005 at 07:34:54AM -0400, Eric S. Johansson
wrote:
> Gerd Knorr wrote:
> >I tried the same some time ago in user mode linux (tried to make X11
> >run on top of a virtual framebuffer device) and ran into simliar
> >issues.  It simply didn''t work without hacking the X-Server. 
X11 was
> >very unhappy about not being able to access hardware directly, even
> >though there was absolutely no need to do that.  I wanted it simply
> >open and use the /dev/fb0 device ...
> 
> if I''m understanding correctly, this sounds very similar to what
the
> colinux folks are trying to do with making and X11 run out of their 
> virtual machine on Windows.
Probably, that''s the most obvious way of doing this in a virtualized
environment.  It''s also a sensible approach for X11 support in xen
domU''s, once we have a paravirtualized linux framebuffer driver ;)

I hope with the next X.org release it "just works".

  Gerd

-- 
#define printk(args...) fprintf(stderr, ## args)

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