From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43435 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PoeZE-0004r7-5n for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:12:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PoeZC-0000L5-1a for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:12:55 -0500 Received: from gate.crashing.org ([63.228.1.57]:47998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PoeZB-0000K1-Mr for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:12:53 -0500 Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO From: Benjamin Herrenschmidt In-Reply-To: References: <1297522467-5975-1-git-send-email-david@gibson.dropbear.id.au> <1297522467-5975-16-git-send-email-david@gibson.dropbear.id.au> <1BA55C28-0AAF-46A5-A14F-04B0B61419DB@suse.de> <1297544424.14982.628.camel@pasglop> <1297552503.14982.637.camel@pasglop> <20110213111245.GC18294@yookeroo> Content-Type: text/plain; charset="UTF-8" Date: Sun, 13 Feb 2011 10:12:36 -0600 Message-ID: <1297613556.14982.652.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Graf , "qemu-devel@nongnu.org List" , Paul Mackerras , anton@samba.org, David Gibson , Alexander@gnu.org On Sun, 2011-02-13 at 14:15 +0200, Blue Swirl wrote: > > Maybe it would be more complex but also emulation accuracy would be > increased and the interfaces would be saner. We don't shortcut BIOS > and implement its services to OS in QEMU for other machines either. But that is not comparable. BIOS is comparable for example to Open Firmware and we do not 'emulate' OF, we will provide an implementation that runs inside the guest, just like you do for BIOS (SLOF based, tho people are welcome to play with OpenBIOS if they want, but SLOF is what we will provide and support). In this case, we are talking about a hypervisor which is somewhat a different beast. Sure you -could- run it into the guest, I suppose, if emulation accuracy was your ultimate goal. That would entail at least the followings: - Implement support for the complete "hypervisor" mode inside qemu - Re-implement a complete hypervisor compatible with pHyp An enormous amount of work, for a result that would have low performances and about zero interest to anybody. The goal here is to provide a runtime environment for kernels and distributions that is -compatible- with sPAPR/pHyp to enable existing distributions to operate in KVM. > I'd expect one problem with that approach though, the interface used > on real HW between the hypervisor and the underlying HW may be > undocumented, but then it could use for example existing virtio > devices. But what would be the point ? > One way to handle this could be to add the hypervisor interface now to > QEMU and switch to guest hypervisor when (if) it becomes available. > I'd just like to avoid duplication with virtio or messy interfaces > like vmport. Again, what would be the point ? Eventually, KVM will be available as an "alternate" hypervisor to pHyp which I suppose one could run entirely inside qemu once we add support for the HV mode to it, and that would somewhat do what you describe but that isn't what we are trying to get at here. Cheers, Ben.