WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: Trying to run X in domain 1: Failed to do IOPL (was Re:U

On Thursday 21 October 2004 22:28, Mark Hurenkamp wrote:
> > I guess the X server might try doing IO to some things that Xen won't let
> > it access.  By default, the domain will only have access to the IO ports
> > and IO memory regions of the graphics card and USB controller themselves.
>
> As reported earlier, I'm receiving an 'Failed to do IOPL' message when
> starting X in domain 1. It seems to be also triggered when running scanpci
> in the same domain, or in domain 0 as non-root user.
>
> So I untarred myself the X sources (it is sometimes handy to have a gentoo
> distro installed :-), and started to look for the mentioned error.
> I found the following code, which seems to trigger the problem:
>
>         if (ioperm(0, 1024, 1) || iopl(3))
>                 FatalError("xf86EnableIOPorts: Failed to set IOPL for
> I/O\n");
>

If you're feeling brave, as a quick and very dirty hack you could comment out 
lines 98 and 99 of xen/common/dom0_ops.c - i.e. these ones:

    if ( !IS_PRIV(current) )
        return -EPERM;

Do read on for an explanation of what this will do, before trying it ;-)

> Although I don't want X to touch hardware in other domains, it is ok for me
> if it touches any hardware which I assigned to domain 1.
>
> Why are these calls not working? Does Xen need to intercept these calls
> to keep things working? Can I do anything to get passed this problem?

When a userspace process does an iopl or ioperm call, the XenLinux kernel does 
an iopl call into Xen (that's not a typo, there's no ioperm hypercall).  Xen 
checks whether the domain is privileged enough to be trusted with a higher IO 
privileges level and only allows the call to succeed if it is.

Domains which have PCI access don't need to do an IOPL call because they are 
(implicitly) given access to their IO ports they need.  They're therefore not 
given privileges to do it.  Unfortunately, it seems that X wants to do this 
anyhow.

Commenting out those lines will allow any domain to do an IOPL call (amongst 
other things).  This should keep X happy.  I'm not sure exactly what X will 
try and access - if it tries to poke about in the BIOS or in hardware that 
dom0 is using, bad things may happen.  If it were my system (and in the 
absence of other suggestions), I'd cross my fingers and give it a shot.

Obviously, allowing all domains to make privileged calls is not ideal ;-)  If 
X really only does need to access IO ports of its PCI device, we can tighten 
this up trivially by adding better support for the ioperm call.  I'll 
implement this if it looks like it'll work.

HTH,
Mark


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel