Re: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO

[Benjamin Herrenschmidt]

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.