Thanks Jeff,
That certainly answered my previous questions. But leads to other ones :)
1. Why is the code for binary translation and emulation of MIPs, Sparc... and so on still exists in xen.3.4.2 default source ball (in tools\ioemu-qemu-xen). Is it because no one find the need / or want to go through all the hassle to remove them from qemu-xen code just to save a few KB?
2. If PV domains don't use QEMU. How are core devices normally attached to the motherboard, such as keyboard controller, floppy disk controller, pc speaker, emulated for PV domains? Do they also follow the frontend / backend drivers model? If so where can I find the code for their frontend / backend drivers?
Thanks a lot,
On Tue, May 4, 2010 at 10:20 AM, Jeff Sturm <jeff.sturm@xxxxxxxxxx> wrote:
Xen does virtualization, not emulation. It supports
several CPU architectures, but your domU sees the same CPU as your dom0.
That said, on x86-64 platforms you can mix/match 32-bit and
64-bit domains provided the hypervisor is a 64-bit build. This works
because the underlying hardware supports it, not because any emulation is
taking place.
As I understand it Xen uses QEMU solely for device
emulation. It's required for HVM domains. Pavarvirtualized domains
don't need QEMU at all.
Hi everyone,
1. Does anyone knows if Xen supports running Dom U (guest)
platforms other than x86 and amd64? For examples: MIPs, arm...
I see MIPs and ARM related code inside tools\ioemu-qemu-xen
but I am not sure if that is enough.
2. My understanding is Xen uses QEMU for HVM device
emulation, and QEMU uses binary translation. Does that mean Xen HVM guests will
have to go through the binary translation layer? Is this the case if the guest
platform and the host platform are the same?
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|