> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Alexander Myodov
> Sent: 24 January 2006 01:48
> To: Petersson, Mats
> Cc: Xen-users
> Subject: RE: [Xen-users] On Wndows, Video and Sound
>
> 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 :) ?
I'm more familiar with the Windows display driver than I am with the
X-drivers, so I'll take it from a Windows perspective. In theory, it's
possible to implement a Windows driver that supports around three
drawing primitives (essentially, Read Pixels, Write Pixels and one or
two other functions), but for performance reasons, it's probably a good
idea to implement at least half a dozen or more of the basic functions
to begin with. If a call is made to a function that isn't supported by
the driver, the OS will perform the operation using the more basic
functionality. For example, an Alpha blended blit[1] can be performed as
a "standard" blit + "manual" alpha-blend + "standard" blit. Of course, a
GPU will perform the same alpha-blended blit MUCH faster because it can
be done in essentially one operation (although the GPU wil still have to
read the frame-buffer and modify it).
DirectX or OpenGL would have a similar scenario where you'd take a small
subset (to begin with) where the un-implemented functions are supported
by the Native OS fallback methods.
[1] Blit = BitBlt, Bit-block-transfer, or "copy a block of pixels".
>
> > 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.
DEV wouldn't help much in implementing this - DEV is a help to make
systems secure by avoiding a (buggy or malicious) driver from setting a
DMA address to memory that it doesn't own...
>
> > 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.
Yes, and technically it's possible to do this, but the drivers involved
need to know about Xen for this to work. It's much easier to implement a
driver that doesn't rely on other drivers to get involved.
Imagine for instance that Xen is handling the C-A-F#, and that we're
currently in Windows, doing some COMPLEX 3D drawing that takes several
milliseconds, so the driver is currently waiting for an interrupt,
C-A-F# is pressed, and we switch screens. Where does the drawing from
the original commands sent to the graphics card go? What happens with
the interrupt that we were waiting for? This sort of thing will ONLY
work if there's a dedicated driver that understands Xen - something I
predict will take quite some time to get, if it ever happens.
A much simpler method would be to have the driver I suggested above, and
using a Xen-aware driver in Dom0. We can certainly implement some sort
of frame/screen switching in that scenario, no big deal.
A single PCI device needs to be owned by a single domain. Anything else
will lead to all sorts of difficulties.
>
> > 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 .
Well, I'm not making any promises about when device hiding and DomU
device handling will be there. From what I understood when I was at the
Xen summit, it shouldn't be TOO far away, but there are other things
that have higher priority - like getting the SVM parts into mainstream
Xen... ;-)
>
>
> PS Sorry all, just mentioned that I initially picked the
> proper thread but somehow missed the subject line for my messages.
That's why I changed it...
--
Mats
>
> --
> With best regards,
> Alexander mailto:maa_subscriptions@xxxxxxx
>
>
>
> _______________________________________________
> 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
|
Home