From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan de Konink Subject: Re: Re: [PATCH] qemu-xen: Fix PV segfault Date: Wed, 02 Jul 2008 16:35:52 +0200 Message-ID: <486B9248.9060202@xs4all.nl> References: <4863E1F6.60909@suse.de> <18538.27111.959001.890654@mariner.uk.xensource.com> <486B3428.5000006@suse.de> <486B3E88.1020904@redhat.com> <20080702141917.GD23929@totally.trollied.org.uk> <18539.37231.372982.478747@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <18539.37231.372982.478747@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com, Gerd Hoffmann , Kevin Wolf , John Levon List-Id: xen-devel@lists.xenproject.org Ian Jackson schreef: > John Levon writes ("Re: [Xen-devel] Re: [PATCH] qemu-xen: Fix PV segfault"): >> On Wed, Jul 02, 2008 at 10:38:32AM +0200, Gerd Hoffmann wrote: >>> While I'm at it: There is a patch queue with at >>> http://kraxel.fedorapeople.org/patches/ >>> >>> The plan is to submit that stuff upstream, so regular qemu will have xen >>> support. Right now the patch queue has only paravirt bits. It comes >> I'm confused, I thought that was the point of the qemu-xen tree > > Gerd Hoffman's tree seems to be something entirely different. I'm not > sure I understand what the point of it is. The reason why everyone is > using qemu is that it has all of the hardware emulation device models. > > Qemu proper (ie upstream) also uses the CPU emulator (translator, > now). KVM and Xen don't use that because they run the code on the > physical CPU one way or another. > > Gerd Hoffman's setup doesn't use the device models, nor the CPU > emulator. Really as far as I can tell the only thing he wants from > qemu is the command line parser ! This is quite bizarre as it's not a > very good command line parser (qemu upstream are considering replacing > it with something more data-driven and more modular). I think the primary idea is to get away from xend, and qemu gets the job done. Stefan