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

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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Trying to run X in domain 1: Failed to do IOPL (was Re:USB with Xen 2.0)
From: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Date: Fri, 22 Oct 2004 09:10:26 +0100
Cc: mark.williamson@xxxxxxxxxxxx, Mark Hurenkamp <Mark.Hurenkamp@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Steven.Hand@xxxxxxxxxxxx
Delivery-date: Fri, 22 Oct 2004 09:10:26 +0100
Envelope-to: Steven.Hand@xxxxxxxxxxxx
In-reply-to: Message from Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> of "Fri, 22 Oct 2004 08:37:40 BST." <E1CKtzY-00053q-00@xxxxxxxxxxxxxxxxx>
>> > 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");
>
>> Obviously, allowing all domains to make privileged calls is not ideal ;-)  I
f 
>> 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.
>
>Unfortunately the code looks wrong to me --- it requires *both* the
>ioperm() and the iopl() call to succeed. Even if you tighten up
>ioperm, only a privileged domain can do iopl. So it looks like X
>server domains will have to be privileged.

Hmm -- does X really need iopl() in all cases? The iopl() man page 
seems to suggest it does, but perhaps worth tracing the X server's
accesses under linux to check. If it only needs a (perhaps slightly 
larger) port range, then we can make the iopl(3) 'succeed' for 
unpriv domains by being equivalent to ioperm(0, 1024, 1).

Pretty cheesy though :-) 

cheers, 

S.

<Prev in Thread] Current Thread [Next in Thread>