[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-users] doubts: hardware access overhead on domUs, desktop environment layout


  • To: "Eduardo Costa Lisboa" <eduardo.linux@xxxxxxxxx>, xen-users@xxxxxxxxxxxxxxxxxxx
  • From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
  • Date: Fri, 10 Feb 2006 17:44:19 +0100
  • Delivery-date: Fri, 10 Feb 2006 16:56:13 +0000
  • List-id: Xen user discussion <xen-users.lists.xensource.com>
  • Thread-index: AcYuXR7Q5jFAkpR+ScCE52rsZNs5JQAAqdSQ
  • Thread-topic: [Xen-users] doubts: hardware access overhead on domUs, desktop environment layout

 

> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Eduardo Costa Lisboa
> Sent: 10 February 2006 16:11
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] doubts: hardware access overhead on 
> domUs, desktop environment layout
> 
> Hi, guys. I am new to Xen but already work (should I say 
> play?) with it enough to know the basics of it's characteristics.
> 
> My questions are the following:
> 
> - is there much overhead on accessing hardware via a domU, 
> like a graphics card?

Not if the version of Xen you're using allows you to give the PCI device
to the DomU - there's no difference between a DomU accessing a device
and Dom0 accessing the device - it's just whatever CPU operation that
the original hardware requires, either IO operations like OUT/IN or
reguler memory operations (mov instructions). 

Currently, however, Xen 3.0 doesn't allow the PCI device to be "given"
to DomU. 

Further, currently, graphics is one of the devices that may not be
trivial to pass over to the DomU, since you will need to have Dom0
handle the graphics until you've got a DomU - and now what do you do
with the Dom0's handle to the graphics card and any possibly outstanding
requests from the Dom0 graphics driver to the hardware - some careful
handshaking is needed here, and stock drivers don't undetrstand this
need: most drivers do not understand hotpluggable graphics cards, which
is the model we'd have to work along. It may be possible to pass a
"powersave" event to the driver and get it to unload itself, but some
work is defintely needed for this - it's certainly not in place today. 

[After writing the above, I realized you've already discussed it below -
that's what you get from not reading the entire post before writing the
answer. I think there's still some interesting ideas on the why
not/solutions above].

> 
> - I am planning to use Xen on my notebook, so I could learn a 
> bit more and even boot my other distro's without rebooting 
> and stuff; so, would it be better to have a idle dom0 and a 
> main desktop on a domU or use the dom0 itself as the graphic 
> desktop environment?

I think you'll HAVE to use Dom0 to run the graphics. 

> 
> I have heard that if I gave to a domU direct control of a 
> video card, I wouldn't be able to use it on my dom0. Thus, I 
> should have two video cards, one for each one of the domains. 
> Is it correct? And, can I even have 3D acceleration (on X, 
> via NVIDIA's proprietary driver) on a domU?

Yes, two graphics cards would work, assuming you have a Xen that can
pass a PCI device to the DomU. 

Probably not if you're running a para-virtualized DomU - as I think
nVidia's driver doesn't work in Dom0 because it's different enough to
regular Linux. On the other hand, if you're running a fully virtualized
domain, any driver that can handle the hardware should be fair game.
Again, conditions mentioned above still apply. 

--
Mats
> 
> Thanks in advance,
> 
> 
> --
> Eduardo Costa Lisboa
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
> 
> 


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.