> 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 > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel