"Parker, Ron" wrote:
>
> > -----Original Message-----
> > From: Max-Wilhelm Bruker [mailto:[EMAIL PROTECTED]]
>
> > Wouldn't it be a lot easier if we just emulated an existing video card
> > instead
> > of defining new protocols? I hate installing the VMWare tools
> > in VMWare.
> > We could also run some other guests, such as BeOS, without thinking of
> > drivers
> > then.
>
> This is precisely what Connectix has done with Virtual PC. They emulate an
> older chipset, the S3 Trio 32 IIRC. They also have some guest level tools
> that can be installed which provide seamless mouse movement into and out of
> the VM.
These are good points. For emulating a video card which doesn't have
many constraints on the VM, we could do reasonably well with emulating
the real hardware. If you have only a straight video frame buffer, page
access bits from the VM can let us know which pages were updated, and
pass this on to host user space video emulation for the GUI updates.
In this model, guest OS accesses to the video frame buffer are asynchronous
to the video logic (like GUI updates) in host user space.
The +/-'s. A benefit is that drivers that come with each guest OS
can work "out of the box". The trade-off is that those drivers,
especially if they're ring0 level, are running much slower than
native speed. (Emulated, or DT'd later). And they're moving data
around in the guest, so it's important to recognize block moves
to video memory and emulate them efficiently. Then, when the
GUI component of the video card emulation runs (every N hertz),
video memory is again copied (unless we map the video card into
the guest directly).
The other strategy is to just make up a pseudo video card device
and write a driver for each guest-OS, if you want something more
than VGA. Writing such drivers, and requiring the user to install
them would be on the '-' list. The benefit, is that more of the
driver logic can be moved outside the VM, where it runs at native
speed.
This second strategy might sound faster, but there is also the
consideration that round trip time:
VM -> host-kernel -> host-user -> host-kernel -> VM
-or-
VM -> host-kernel -> VM
can also be expensive to only move some pixels around, if we
resort to the host to do the graphics ops processing.
A variation of this, is to load the graphics ops processing
into the VM monitor, but leave the GUI stuff to the host user
program. Same idea can be done for hard drive, floppy, etc.
Just bring the hardware emulation closer to the VM monitor.
Thus special guest drivers can execute at native CPU speed,
because the VM monitor is really just a kernel. If we map
the video memory directly into the VM, then it's possible
we can do the video memory copies only once here.
Back to the 1st strategy. If ring3 (application code) is updating
a straight frame buffer directly, and since we can let guest
application code run native in ring3 (soon to come), then
arguments of double copies or slower emulation speed could disappear.
Ideally, emulating a real video card would be the way to go.
Let's hear any arguments/notes/thoughts you have on this for
say a week or so. Then let's make a call and start doing one of
them.
-Kevin
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Kevin Lawton [EMAIL PROTECTED]
MandrakeSoft, Inc. Plex86 developer
http://www.linux-mandrake.com/ http://www.plex86.org/
