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

[Alexander Graf]

On 13.02.2011, at 16:08, Anthony Liguori wrote:

> On 02/13/2011 05:12 AM, David Gibson wrote:
>> On Sun, Feb 13, 2011 at 10:08:23AM +0200, Blue Swirl wrote:
>>   
>>> On Sun, Feb 13, 2011 at 1:15 AM, Benjamin Herrenschmidt
>>> <address@hidden>  wrote:
>>>     
>>>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
>>>>       
>>>>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
>>>>> <address@hidden>  wrote:
>>>>>         
>>>>>> On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
>>>>>>           
>>>>>>> Actually I don't quite understand the need for vty layer, why not use
>>>>>>> the chardev here directly?
>>>>>>>             
>>>>>> I'm not sure what you mean here...
>>>>>>           
>>>>> Maybe it would be reasonable to leave h_put_term_char to spapr_hcall.c
>>>>> instead of moving those to a separate file.
>>>>>         
>>>> Well, the VIO device instance gives the chardev instance which is all
>>>> nicely encapsulated inside spapr-vty... Also VIO devices tend to have
>>>> dedicated hcalls, not only VTY, so it makes a lot of sense to keep them
>>>> close to the rest of the VIO driver they belong to don't you think ?
>>>> 
>>>> (Actually veth does, vscsi uses the more "generic" CRQ stuff which we've
>>>> added to the core VIO but you'll see that when we get those patches
>>>> ready, hopefully soon).
>>>>       
>>> 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 really don't follow what you're saying here.  Running the hypervisor
>> in the guest, rather than emulating its effect in qemu seems like an
>> awful lot of complexity for no clear reason.
>>   
> 
> In KVM for x86, instead of using a secondary interface (like vmmcall/vmcall), 
> we do all of our paravirtualization using native hardware interfaces that we 
> can trap (PIO/MMIO).
> 
> IIUC, on Power, trapping MMIO is not possible due to the MMU mode that is 
> currently used (PFs are delivered directly to the guest).
> 
> So it's not really possible to switch from using hypercalls to using MMIO.
> 
> What I would suggest is modelling hypercalls as another I/O address space for 
> the processor.  So instead of having a function pointer in the CPUState, 
> introduce a:
> 
> typedef void (HypercallFunc)(CPUState *env, void *opaque);
> 
> /* register a hypercall handler */
> void register_hypercall(target_ulong index, HypercallFunc *handler, void 
> *opaque);
> void unregister_hypercall(target_ulong index);
> 
> /* dispatch a hypercall */
> void cpu_hypercall(CPUState *env, target_ulong index);
> 
> This interface could also be used to implement hypercall based interfaces on 
> s390 and x86.
> 
> The arguments will have to be extracted from the CPU state but I don't think 
> we'll really ever have common hypercall implementations anyway so that's not 
> a huge problem.

Is there enough common ground between the hypercall interfaces that this makes 
sense? It sounds nice on paper, but in the end the "hypercall not implemented" 
return codes differ, the argument interpretation differs and even the amount of 
return values differ.

So at the end of the day, all this interface could do is call a machine helper 
function to evaluate the hypercall id from its register state and dispatch to 
that, leaving the rest to the individual hypercall function implementation.

The implementations themselves also couldn't be reused. A PAPR hypercall simply 
doesn't work on x86. PIO and MMIO interfaces make sense to share - devices 
implemented using them could potentially be reused later by other platforms. 
For the hypercall devices, that doesn't work.

> 
>>> on real HW?
>>>     
>> The interface already exists on real HW.  It's described in the PAPR
>> document we keep mentioning.
>>   
> 
> Another thing to note is that the hypercall based I/O devices the interfaces 
> that the current Power hypervisor uses so implementing this interface is 
> necessary to support existing guests.

Yes, implementing the existing PAPR interfaces is crucial to run existing 
guests. Implementing it at the hypercall level is required if we ever want to 
run it with hardware accelerated KVM on ppc, as there hypercalls simply get 
forwarded to the hypervisor (kvm) which would pass them on to qemu. And since 
the interface is not nesting capable, running a hypervisor inside the guest 
doesn't work.


Alex