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