14 messages in com.xensource.lists.xen-ia64-develRe: [Xen-devel] [RFC] hvm-stub for ia64
FromSent OnAttachments
tgin...@free.fr21 Nov 2007 19:59 
Keir Fraser22 Nov 2007 00:41 
tgin...@free.fr22 Nov 2007 01:31 
Keir Fraser22 Nov 2007 01:44 
tgin...@free.fr22 Nov 2007 02:00 
Keir Fraser22 Nov 2007 02:34 
Samuel Thibault22 Nov 2007 02:53 
tgin...@free.fr22 Nov 2007 03:12 
Samuel Thibault22 Nov 2007 03:20 
tgin...@free.fr22 Nov 2007 05:04 
Samuel Thibault22 Nov 2007 14:20 
Tristan Gingold22 Nov 2007 19:30 
Samuel Thibault23 Nov 2007 02:08 
Samuel Thibault27 Nov 2007 09:16 
Subject:Re: [Xen-devel] [RFC] hvm-stub for ia64
From:Samuel Thibault (samu@eu.citrix.com)
Date:11/22/2007 03:20:22 AM
List:com.xensource.lists.xen-ia64-devel

tgin@free.fr, le Thu 22 Nov 2007 12:12:31 +0100, a écrit :

Quoting Samuel Thibault <samu@eu.citrix.com>:

That's the main difference between your approach (reimplement a firmware) and the approach being developped here at XenSource (embed qemu in a tiny stubdomain). Your VMX work in Xen is most probably something useful, but reimplementing the hardware emulation support of qemu looks to me like duplicate work.

Of course it doesn't reimplement the emulation. The current biggest emulation is the IDE and I have copied ide.c from qemu and made almost no modification.

That's still forking. And you'll also need to do it for vga, network, ...

The advantage is my approach is no need for scheduling between two domains for hardware emulation.

Ah, yes, on ia64 you have room to load your firmware in the domain itself, which makes an extra benefit (with the stubdomain we avoid the need for linux scheduling, but not the need for xen scheduling).

With the current hvm model, I reach the EFI prompt in about 10sec. With my hvmstub it took less than 2 seconds.

And I wonder how much it would take with a stub domain, probably somewhere in between.

Samuel

_______________________________________________ Xen-devel mailing list Xen-@lists.xensource.com http://lists.xensource.com/xen-devel