From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: [RFC] hvm-stub for ia64 Date: Thu, 22 Nov 2007 11:20:45 +0000 Message-ID: <20071122112045.GG4242@implementation.uk.xensource.com> References: <1195725624.47455338d0e37@imp.free.fr> <20071122105359.GF4242@implementation.uk.xensource.com> <1195729951.4745641f64fd6@imp.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1195729951.4745641f64fd6@imp.free.fr> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: tgingold@free.fr Cc: Xen-devel , Xen-ia64-devel List-Id: xen-devel@lists.xenproject.org tgingold@free.fr, le Thu 22 Nov 2007 12:12:31 +0100, a =E9crit : > Quoting Samuel Thibault : >=20 > > 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 o= f > > qemu looks to me like duplicate work. >=20 > Of course it doesn't reimplement the emulation. The current biggest em= ulation > is the IDE and I have copied ide.c from qemu and made almost no modific= ation. That's still forking. And you'll also need to do it for vga, network,=A0... > The advantage is my approach is no need for scheduling between two doma= ins > 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