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

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/13/2011 12:29 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>>
>> 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.
>>      
> Nice idea. Then the part handling CPUState probably should belong to
> target-ppc/ rather than hw/.
>    

Would be nice to have the target-ppc/ hypercall handlers call into a 
higher level VIO interface that didn't deal directly with CPUState.  The 
actual hardware emulation would then be implemented in hw/ and would not 
be compiled for a specific target.  That helps avoid future sloppiness.

Regards,

Anthony Liguori