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