> > Does usb devices works with Xen2.0, even when only domaim0 is present? > > Yes, we''ve had success reports.Works great for me :-)> > does it work with multiple domains? > > Depends what you mean. Dom0 will by default control all the USB devices. > If you want another domain to control a USB root hub device, you can > assign it permissions, as for a driver domain.I have multiple (currently 3) usb host controllers in my system, and for as far as I can tell, they all work fine in domain 0. I''ve started experimenting with allowing other domains to access them, and so far it looks good, they are recognised properly, and lspci and lsusb show that the hardware is present in the domain. Running ''cat /dev/input/mouse0'' and ''cat /dev/input/event0'' (kbd) shows that they receive input from mouse and keyboard. I have yet to try my other usb equipment, a harddisk, dvd drive, printer, scanner and usb-lan adapter.> My USB virtualisation stuff (give guests control of individual USB ports) > is in progess but I keep getting distracted by other things (most > recently the 2.0 release).I''m eagerly awaiting this functionality (then I can remove at least 1 usb controller :-), how''s it approaching? If you have some patches, I''d be willing to give it a try :-)> > if Yes, how to make it work? > > To make it work in dom0, just stick it in the Linux kernel config and it > should Just Work(TM).Yep, to make it work for domain 0, just enable it in the kernel (I used 2.6.8.1-xen0). To enable it in other domains, you have to pass an option to your kernel in grub, (add the ''pci_dom0_hide=(xx:yy.zz)'' boot option) to hide it from domain 0, and also enable the device in your other domain config (using pci=[''xx,yy,zz''] ). Good luck, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Running ''cat /dev/input/mouse0'' and ''cat /dev/input/event0'' (kbd) shows > that they receive input from mouse and keyboard. > I have yet to try my other usb equipment, a harddisk, dvd drive, printer, > scanner and usb-lan adapter.Sounds like it''ll probably work. We know the driver domains stuff works, so there''s no reason for this not to. There''s one caveat to using the PCI device driver domain stuff - if you give a domain access to a device, all processes in that domain can (if they try) acescs it directly. This is due to the way we use x86 features to control IO port access and doesn''t really matter as long as you trust the processes in the domains :-) Changing this behaviour is a fairly small amount of code but we haven''t needed it with dedicated driver domains.> > My USB virtualisation stuff (give guests control of individual USB ports) > > is in progess but I keep getting distracted by other things (most > > recently the 2.0 release). > > I''m eagerly awaiting this functionality (then I can remove at least 1 usb > controller :-), how''s it approaching? If you have some patches, I''d be > willing to give it a try :-)Glad to hear it! Give us 1-2 weeks to get Xen 2.0 finally released, then I''ll get back to this code. When I''ve got things into a sane state, I''ll check them in to xeno-unstable and you can try it out... On a related node, are you the brave chap who was trying to get a domain to drive its own monitor? How did that go? Did Ian''s suggestion (about getting X to be less polite about virtual terminals) work? It''d be really interesting to get this going... ------------------------------------------------------- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > > My USB virtualisation stuff (give guests control of individual USB ports) > > > is in progess but I keep getting distracted by other things (most > > > recently the 2.0 release). > > > > I''m eagerly awaiting this functionality (then I can remove at least 1 usb > > controller :-), how''s it approaching? If you have some patches, I''d be > > willing to give it a try :-) > > Glad to hear it! Give us 1-2 weeks to get Xen 2.0 finally released, then I''ll > get back to this code. When I''ve got things into a sane state, I''ll check > them in to xeno-unstable and you can try it out...Ah, that is good news :-)> On a related node, are you the brave chap who was trying to get a domain to > drive its own monitor? How did that go? Did Ian''s suggestion (about getting > X to be less polite about virtual terminals) work? It''d be really > interesting to get this going...Yeah, I''m still busy trying :-), I''ve managed to get a patched X version that doesn''t require a true vt, but ran into some IO problem. I think I still need to do some more experiments. It looks very promising, since I can do ''cat /dev/hda1 > /dev/fb0'' and see the output on the display, I can do ''cat /dev/input/mouse0'' and ''cat /dev/input/event0'', and see the input of the mouse and keyboard, and with the patched xorg rpm I found, X should be able to use the event0 device as input. Now if I can work around that IO access problem (probably need to use one of the new options the patch provides), then I should have X running in domain1... but I''m not there yet, so bare with me for a while :-) On another track, would it be possible to write a backend & frontend for framebuffer devices? That could be another way to get X running in other domains, in case my current path is a dead end (it would certainly be nice for people who own a dualhead card, and want to use the second head in a second domain). But that still wouldn''t solve the vt problem :-(. Best wishes, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > On a related node, are you the brave chap who was trying to get a domain > > to drive its own monitor? How did that go? Did Ian''s suggestion (about > > getting X to be less polite about virtual terminals) work? It''d be > > really interesting to get this going... > > Yeah, I''m still busy trying :-), I''ve managed to get a patched X version > that doesn''t require a true vt, but ran into some IO problem. I think I > still need to do some more experiments.Interesting... Feel free to post back to this list if you''re in need of assistance. This is something we''d be really pleased to see working, particularly if the process can be simplified and streamlined for routine use. 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.> It looks very promising, since I can do ''cat /dev/hda1 > /dev/fb0'' and > see the output on the display, I can do ''cat /dev/input/mouse0'' and ''cat > /dev/input/event0'', and see the input of the mouse and keyboard, and > with the patched xorg rpm I found, X should be able to use the event0 > device as input.This sounds very promising!> On another track, would it be possible to write a backend & frontend for > framebuffer devices? That could be another way to get X running in other > domains, in case my current path is a dead end (it would certainly be > nice for people who own a dualhead card, and want to use the second head > in a second domain).Yes, it would be possible to do that for framebuffer devices. The Nemesis operating system (also from Cambridge Computer Laboratory) did something similar to allow individual processes to do their own rendering. I''m not sure this provides a huge advantage over existing remote-desktop protocols although the performance could be better. A more difficult problem is that of virtualising 3D graphics hardware. I think there''s some ideas hanging around and it''d certainly be cool if domains could use the 3D hardware. This is one of those "on the horizon" things at the moment, as far as Xen is concerned. 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Yeah, I''m still busy trying :-), I''ve managed to get a patched X version > > that doesn''t require a true vt, but ran into some IO problem. I think I > > still need to do some more experiments. > > Interesting... Feel free to post back to this list if you''re in need of > assistance. This is something we''d be really pleased to see working, > particularly if the process can be simplified and streamlined for routine > use. > > 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.I''ve been puzzling for a few hours now, and don''t seem to get past the following IO error: "xf86EnableIOPorts: Failed to set IOPL for I/O" Finally I decided to run ''scanpci'' to see what it could find, and it ends up with the same error (is that normal for non dom0 domains?). I guess I''m going to have to dive into the xorg code to find out what exactly it is trying to do :-( Is there anything else I can still do here? lspci shows this: 02:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 85) 03:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 03:06.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 03:06.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61) 03:06.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63) 03:06.3 FireWire (IEEE 1394): NEC Corporation IEEE 1394 Host Controller (rev 01) (I''m running in domain1, with xen0 kernel, using Fedora Core 2. I''ve installed the xorg rpm for multi-console which I found here: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/yenya/ , instructions here: http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/ ) Any help here would be very welcome! Greetings, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark Hurenkamp
2004-Oct-21 22:28 UTC
[Xen-devel] Trying to run X in domain 1: Failed to do IOPL (was Re:USB with Xen 2.0)
> 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"); Since I have no clue what ioperm or iopl do, I looked up the man pages, and found this: int ioperm(unsigned long from, unsigned long num, int turn_on); Ioperm sets the port access permission bits for the process for num bytes starting from port address from to the value turn_on. The use of ioperm requires root privileges. Only the first 0x3ff I/O ports can be specified in this manner. For more ports, the iopl function must be used. Permissions are not inherited on fork, but on exec they are. This is useful for giving port access permissions to non-privileged tasks. int iopl(int level); iopl changes the I/O privilege level of the current process, as specified in level. This call is necessary to allow 8514-compatible X servers to run under Linux. Since these X servers require access to all 65536 I/O ports, the ioperm call is not sufficient. In addition to granting unrestricted I/O port access, running at a higher I/O privilege level also allows the process to disable interrupts. This will probably crash the system, and is not recommended. 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? Best Regards, 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Mark A. Williamson
2004-Oct-21 22:48 UTC
[Xen-devel] Re: Trying to run X in domain 1: Failed to do IOPL (was Re:USB with Xen 2.0)
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Keir Fraser
2004-Oct-22 07:37 UTC
Re: [Xen-devel] Re: Trying to run X in domain 1: Failed to do IOPL (was Re:USB with Xen 2.0)
> > 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Steven Hand
2004-Oct-22 08:10 UTC
Re: [Xen-devel] Re: Trying to run X in domain 1: Failed to do IOPL (was Re:USB with Xen 2.0)
>> > 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.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.