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@xxxxxxx
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|