From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36348 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pof8E-0007KS-3A for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:49:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pof8B-0000DJ-K4 for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:49:05 -0500 Received: from mail-gw0-f45.google.com ([74.125.83.45]:47138) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pof8B-0000D2-Cp for qemu-devel@nongnu.org; Sun, 13 Feb 2011 11:49:03 -0500 Received: by gwaa12 with SMTP id a12so1920846gwa.4 for ; Sun, 13 Feb 2011 08:49:02 -0800 (PST) Message-ID: <4D580B79.3090603@codemonkey.ws> Date: Sun, 13 Feb 2011 10:48:57 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO 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> <1297613262.14982.647.camel@pasglop> In-Reply-To: <1297613262.14982.647.camel@pasglop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: "qemu-devel@nongnu.org List" , Alexander Graf , Blue Swirl , Paul Mackerras , anton@samba.org, David Gibson On 02/13/2011 10:07 AM, Benjamin Herrenschmidt wrote: > On Sun, 2011-02-13 at 10:08 +0200, Blue Swirl wrote: > >> This is a bit of a special case, much like semihosting modes for m68k >> or ARM, or like MOL hacks which were removed recently. From QEMU point >> of view, the most natural way of handling this would be hypervisor >> implemented in the guest side (for example BIOS). Then the hypervisor >> would use normal IO (or virtio) to communicate with the host. If >> inside QEMU, the interface of the hypervisor to the devices needs some >> thought. We'd like to avoid ugly interfaces like vmmouse where a >> device probes CPU registers directly or spaghetti interfaces like >> APIC. >> > I'm not sure I understand your point. We are emulating a guest running > under pHyp, ie, qemu in that case is the hypervisor, and provides the > same interfaces as pHyp does (the IBM proprietary hypervisor, aka > sPAPR). This is how we enable booting existing kernels and distributions > inside qemu/kvm. > > >> Is the interface new design, or are you implementing what is used also >> on real HW? >> > We are implementing a subset of the interfaces implemented by pHyp today > on "real HW". In the long run, when you throw KVM into the picture, on > machines (hypothetical machines at this stage) where one can run a KVM > has a hypervisor (currently you can only run pHyp on all released IBM > machines), this will give you an environment that is compatible with > pHyp and thus supports existing distributions and kernels. > We try very, very hard to make our paravirtualization look like real hardware. When the paravirtualization interfaces are already defined, we have no choice in supporting those interfaces although sometimes we try to push that to firmware (like with Xenner). It's better from a security PoV. But in this case, we have no choice but to implement the paravirtualization interfaces in QEMU because of the way the hardware works and because these interfaces are already well defined. Regards, Anthony Liguori > We -will- add support for the "real" virtio on top of that, but those > will require modified guest kernels (and will provide better > performances than the sPAPR emulation). But the sPAPR emulation is a > necessary step to enable existing stuff to run. > > Cheers, > Ben. > > >