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: mark.williamson@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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Fri, 22 Oct 2004 08:37:40 +0100
Cc: Mark Hurenkamp <Mark.Hurenkamp@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 22 Oct 2004 08:42:34 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 21 Oct 2004 22:48:27 -0000." <200410212248.27429.mark.williamson@xxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > 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 ;-)  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.

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.

I also hadn't considered that, in giving a domain selective I/O port
access, we are actually giving everything that runs in that domain
that access (i.e., all random user space programs, because we do not
change the bitmap on process switches, or user/kernel transitions).
Of course our intention is that usually such a domain won't have a
fully-fledged user space so I guess we don't really care that much.
It can also only affect the device that domian controls, and we can
detect and restart on failure. :-)

 -- Keir


-------------------------------------------------------
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