[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Status of ioemu code in unstable?

Arun Sharma wrote:
John Byrne wrote:


I've been trying to find out from the xen-devel archives and Google and I cannot seem to find the information I'm looking for.

I assume the goal of the ioemu is to provide necessary support for non-paravirtualized guess running on VT-x hardware. At a minimum I'd guess you'd need BIOS emulation, display card emulation, and timer/ interrupt emulation.

See foil 10 of:


for a summary of what's working.

Since then, we've added support for BIOS emulation (tools/firmware).
The current device models are based on qemu-0.6.1.

I'd like to know what's there; what works; and what else might be needed. A pointer to the information or a summary would be appreciated. Also, there is one item in the todo list in the wiki that suggests that the ioemu code will all be re-written. Is this for performance reasons?

Yes, switching to dom0 for every I/O request is very expensive. But that was the easiest and cleanest initial implementation.

We've also accelerated the PIT by moving it into the hypervisor and have patches for implementing the local APIC support in xen.



Can any of this be tested with non-VT-x hardware?

There appears to be VNC support in qemu which I assume will allow you to see both the text and graphics (X) mode of the emulated console. If so, is there a way to achieve this with a para-virtualized kernel? My undertanding is that the xen changes to the Linux kernel include changes to the console driver to talk to the xen tools and that is you want and X server, you run Xvnc. So, looking at the text console and the X server require different tools.

If I were trying to manage virtual machines, I'd want a solution that didn't care about what kind of kernel I was running.

John Byrne

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.