> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] 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@xxxxxxx
>
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home