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

[Anthony Liguori]

On 02/13/2011 12:29 PM, Blue Swirl wrote:
> On Sun, Feb 13, 2011 at 5:08 PM, Anthony Liguori<address@hidden>  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