[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] On Wndows, Video and Sound
> -----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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |