Re: [Qemu-devel] About qemu emulation speed (a question) and supported OS

[Mark Williamson]

> No, I got the impression that Fabrice was taking about virtualization the
> way VMware, old plex86, and vmbear (new FOSS x86 virtualizer in the works)
> do it.
>
> So it'll work w/o needing a 64bit chip.

I hadn't seen vmbear, looks interesting...  Full virtualisation on vanilla x86 
would be really handy (until everyone is running VT or SVM chips).  It 
requires a brave coder, though - some of that stuff is going to be pretty 
entertaining to write!

> > FWIW, Xen is already using QEMU in this way.  It would be very neat to
> > see this technique applied to a Type II VMM.
>
> Do you have any details on this?

Lightning overview -

In Xen we have no host / guest: Xen runs on the bare metal and hosts all the 
OSes in the system.  One of them "Domain 0" is privileged to access the 
hardware devices - it normally uses explicit inter-VM communication to supply 
device services to other guests (using Xen-specific device drivers).  This is 
OK for Xen-native guests, since they're explicitly aware of the hypervisor.  
For fully virtualised guests we need a different approach.

We're not attempting to make full virtualisation work on vanilla x86 - you 
need a virtualisation-aware chip.  Domain 0 must still be a "native" 
Xen-aware OS.  For unprivileged guests, Xen handles the low-level work of 
managing its shadow pagetables, trapping and (perhaps) emulating privileged 
instructions, etc.  Xen doesn't contain any device virtualisation code, so 
instead it passes up IO port / IO memory accesses to the "device model"  
which runs as a daemon process in domain 0.

The device model daemon receives these IO port accesses and feeds them to the 
"device models".  These run in userspace, emulating real PCI hardware using 
the QEmu code (+ one extra network device model, IIRC).  They perform the 
appropriate emulation actions, do any necessary IO, then feed a response to 
the IO instruction back to Xen.

This way, the device models are kept out of Xen, however it's a bit 
inefficient to have so many context switches.  Work is planned (underway?) to 
restructure the device models, porting them to run in specialised virtual 
machines that will "shadow" the real VMs and provide IO services.

(side note: originally Bochs code supplied the device models, QEmu replaced it 
later on because it was technically a better fit)

Does that all make sense?  I know I've been a bit brief - do ask if anything 
wasn't sufficiently well explained.

Cheers,
Mark

> > Regards,
> >
> > Anthony Liguori
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel