Xen users - Jan 2006 - RE: On Wndows, Video and Sound

> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com 
> [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of 
> Alexander Myodov
> Sent: 23 January 2006 17:33
> To: Xen-users
> Subject: Re: [Xen-users] setting up private networking 
> between dom0 and domU?
> 
> Hello,
> 
> I am also very interested in running Windows in XEN 
> environment under VT or Pacifica, so I hope you let me ask 
> several questions...
> 
> > > To what avail?
> > > Being able to install unmodified non-graphical 
> (server)systems is a 
> > > fine thing; graphical systems like W2K3/XP is another talk.
> > > No Xen-aware video drivers are available. In a couple of threads,
> > > I''ve argued that Nvidia is interested in developing such
> a driver, 
> > > but won''t do it until deemed nessesary. It will only 
> happen with applied pressure.
> What is known about Nvidia plans - do they plan to develop a 
> dom0-only, or maybe even a domU drivers as well? Do I 
> understand properly that with proper domU-drivers it will be 
> possible... maybe even run OpenGL/DirectX software under 
> guest Windows? As far as I understand, ATI drivers were made 
> compatible with dom0, but no domU yet - so is Nvidia behind 
> ATI in this area yet?
> 
> > There are three aspects here:
> Windows emulation question is pretty interesting... The 
> question about video cards has been discussed - but what 
> about other drivers and hardware?
> Is sound card virtualization now working in any form (at 
> least in "3"-mode, by emulation)? With pretty good state of 
> opensource sound support in Linux, it should be possible to 
> allow soundcards using in domU - but how is it now, and what 
> are the nearest plans in this area?
> And, probably, the most important: how hard drive is emulated 
> for guest Windows? Should it use a dedicated drive, a 
> dedicated partition, or maybe it requires an "image" file 
> (visible to domU-Windows as hard drive, but stored as a file 
> on a real FS for dom-Linux)? Or maybe even file-level access 
> is virtualized, so that we can be able to have paths like 
> /var/Windows/Program Files/ on our Reisers and Exts and to 
> distribute Windows files over LVM?
> 
> And also: currently mostly Intel VT is being discussed, as 
> the only available on the market now. But will advanced AMD 
> Pacifica''s features help with anything of above 
> (video/audio/hard disk), or they will give only performance benefits?
> 
> --
> With best regards,
>  Alexander                          mailto:maa_subscriptions@sinn.ru
> 
This is not a trivial subject, and I''m sure I don''t know more
than a
little bit. 

Currently, Xen 3.0 does not support any real hardware accesses outside
Dom0 - so your only option is to emulate any of the hardware accessibly
by (unmodified) guests inside Dom0 or in the Hypervisor itsels.
Currently, there''s a few devices supported in Xen Hypervisor itself -
most notable the Interrupt controller and the timer. These are pretty
simple devices and can easily be handled in HV. 

As for video emulation, the "most likely to work" approach would be to
construct a generic driver for Windows, that takes a GDI/Dx/OGL call and
translates it to a command that is put into a buffer that is shared with
Dom0. Dom0 picks it up and sends it to the graphics card in one form or
another [either using the X driver or translating it to for instance an
OGL call]. At the Xen summit, I talked to Kip Macy and Jacob Gorm Hansen
and some others, about this subject. This would be a
"para-virtualized"
driver, rather than a native Windows driver, in the sense that this
driver will have to CALL the Xen hypervisor to set itself up and to
transfer information to Dom0 (or wherever we want to transfer
information). It''s theoretically possible to write a driver for Windows
that talks to a Xen-managed piece of hardware, but it''s A LOT more
work,
and will only work for that particular hardware (i.e. you need one
driver for ATI, one for nVidia, one for S3, etc, etc - and a new driver
every time ATI or nVidia makes a new chip...)

Hard disks can be simulated in several different ways. The most simple
way to do it would be using a FAT32/NTFS formatted file in QEMU. QEMU
can use a file as a disk. At this level of operation, QEMU just takes
disk read/write/etc operations and transfer them to a Linux file-system
call. This means that you can not really use /var/Windows/... under
Linux, but you have a file in Linux that looks like a disk to the
Windows OS - this will probably be a large file, several gigabytes if
you want to do anything useful with it... ;-) The file can be on any
file-system that supports read/write in Linux, so Ext1/2/3, Reiser, JFS,
etc, etc. 

Sound is pretty much the same story as video, except it''s also
time-critical, so a little bit harder to achieve when there''s
(potentially) a multitude of other things going on in other domains. 

SVM (aka Pacifica), or Intel''s VT, aren''t different in the way
that
hardware access is done. Both require either direct access to the
hardware from the guest - which will be supported for Xen 3.0.x at some
point 
or paravirtualized drivers [i.e. drivers that are aware of being over
Xen], or software emulation in the service domain (Dom0). 

Note also that giving a domain access to a particular device is not
always a good idea - say for instance Video: The graphics card has to be
under ONE domain''s full control. Normally, this would be Dom0. If you
give Windows control of the graphics card, then Dom0 can no longer
access it at all [unless there''s a driver in Windows that does some
magic to see what''s going on in Dom0 - again we need a para-virtualized
special driver - not a very BIG one, but still needs some driver
development that no one has done so far]. The hard disk interface on IDE
may or may not "split" in the middle if you have a four-disk
interface.
Certainly, on a single controller (i.e. IDE0) you can not share the disk
out, since it''s actually using the SAME bits of wire to talking to the
two disks. So for some cases, you haven''t got a choice but let Dom0
handle the hardware - unless you expect nVidia, ATI, chipset
manufacturers and Microsoft to all of a sudden start producing "Xen
aware" drivers. 

--
Mats


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

> Hard disks can be simulated in several different ways. The most simple
> way to do it would be using a FAT32/NTFS formatted file in QEMU. QEMU
> can use a file as a disk. At this level of operation, QEMU just takes
> disk read/write/etc operations and transfer them to a Linux file-system
> call. This means that you can not really use /var/Windows/... under
> Linux, but you have a file in Linux that looks like a disk to the
> Windows OS - this will probably be a large file, several gigabytes if
> you want to do anything useful with it... ;-) The file can be on any
> file-system that supports read/write in Linux, so Ext1/2/3, Reiser, JFS,
> etc, etc.
The other option for exporting something like /var/Windows would be to emulate 
a "virtual FAT device" on top of a Linux filesystem.  This allows read
only
access to a host directory structure, by exporting it to the guest *as if* it 
were a FAT-formatted block device.  You could export 
a /var/ShareThisWithWindows read-only to the guest using this approach.

Under QEmu there''s a patch to do this already, so it should be portable
to the
current device model code.  A good way to do it under Xen if we move away 
from the userspace device emulation might be to rewrite that code to use the 
blktap driver (then it''d work for paravirtualised domains too - if you
really
wanted to do that!).
> development that no one has done so far]. The hard disk interface on IDE
> may or may not "split" in the middle if you have a four-disk
interface.
> Certainly, on a single controller (i.e. IDE0) you can not share the disk
> out, since it''s actually using the SAME bits of wire to talking to
the
> two disks. So for some cases, you haven''t got a choice but let
Dom0
> handle the hardware - unless you expect nVidia, ATI, chipset
> manufacturers and Microsoft to all of a sudden start producing "Xen
> aware" drivers.
I think hard drives are less of a pain, since they have reasonably high 
latencies even without virtualisation.  Graphics and network both have huge 
bandwidth and special state / latency requirements so they should definitely 
benefit from support in the peripherals themselves.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Hello, Mats,
> As for video emulation, the "most likely to work" approach would
be to
> construct a generic driver for Windows, that takes a GDI/Dx/OGL call and
> translates it to a command that is put into a buffer that is shared with
> Dom0. Dom0 picks it up and sends it to the graphics card in one form or
> another [either using the X driver or translating it to for instance an
> OGL call].
Generally, this sounds reasonable and pretty much easy for an
unexperienced person like me. But can it be N*M-hard (i.e., some
specific conversion code is manually implemented for each available
GDI/Dx/OGL call on each vendor or even chipset), N-hard (manual
conversion for each call regardless of a vendor), or maybe even C-hard
(just grab all "raw calls" on guest-OS, maybe implement some
processing
common for all calls, and pass them to Dom0 then to X/OpenGL - or
maybe even to some dom0-code which will just pass those "raw calls" to
video card, without even thinking what are they)?
For me, that means - can we expect it never, in years or in months :) ?
> SVM (aka Pacifica), or Intel''s VT, aren''t different in
the way that
> hardware access is done.
I was expecting some unique magic from DEV feature, that''s why I was
asking.
> Note also that giving a domain access to a particular device is not
> always a good idea - say for instance Video: The graphics card has to be
> under ONE domain''s full control. Normally, this would be Dom0. If
you
> give Windows control of the graphics card, then Dom0 can no longer
> access it at all [unless there''s a driver in Windows that does
some
> magic to see what''s going on in Dom0 - again we need a
para-virtualized
> special driver - not a very BIG one, but still needs some driver
> development that no one has done so far].
From my dumb-user-view, I was expecting something like Ctrl-Alt-F#
console switching. You press C-A-F1, and come the console on
Linux/dom0, you press C-A-F7 and come to X/Dom0, and you press
something like C-A-F4 and come to Windows/DomU where their driver
steals all the video card from Dom0 (and as it gets the video card for
dedicated use, it could probably use full 3D capabilities),... but,
since it runs on DomU, it can somehow be "forced out of the card" by
Dom0 supervisor by pressing another C-A-F#. Seems that this is exactly
what is technically planned, and with your explanation I can imagine
its implementation in more details.
> Both require either direct access to the hardware from the guest -
> which will be supported for Xen 3.0.x at some point
Oh - "3.0" part in your words seems encouraging. I was trying to find
any fresh roadmap for XEN - particularly, how things are going with
Pacifica support, and what we may expect in the soonest time, but did
not find anything better than
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html .


PS Sorry all, just mentioned that I initially picked the proper thread
but somehow missed the subject line for my messages.

-- 
With best regards,
 Alexander                          mailto:maa_subscriptions@sinn.ru



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