Re: [Qemu-devel] [PATCH 03/26] Add a hook to allow hypercalls to be emulated on PowerPC

[David Gibson]

On Wed, Mar 16, 2011 at 03:44:49PM -0500, Anthony Liguori wrote:
> On 03/15/2011 11:56 PM, David Gibson wrote:
> >From: David Gibson<address@hidden>
> >
> >PowerPC and POWER chips since the POWER4 and 970 have a special
> >hypervisor mode, and a corresponding form of the system call
> >instruction which traps to the hypervisor.
> >
> >qemu currently has stub implementations of hypervisor mode.  That
> >is, the outline is there to allow qemu to run a PowerPC hypervisor
> >under emulation.  There are a number of details missing so this
> >won't actually work at present, but the idea is there.
> >
> >What there is no provision at all, is for qemu to instead emulate
> >the hypervisor itself.  That is to have hypercalls trap into qemu
> >and their result be emulated from qemu, rather than running
> >hypervisor code within the emulated system.
> >
> >Hypervisor hardware aware KVM implementations are in the works and
> >it would  be useful for debugging and development to also allow
> >full emulation of the same para-virtualized guests as such a KVM.
> >
> >Therefore, this patch adds a hook which will allow a machine to
> >set up emulation of hypervisor calls.
> >
> >Signed-off-by: David Gibson<address@hidden>
> >---
> >  target-ppc/cpu.h    |    2 ++
> >  target-ppc/helper.c |    4 ++++
> >  2 files changed, 6 insertions(+), 0 deletions(-)
> >
> >diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
> >index a20c132..eaddc27 100644
> >--- a/target-ppc/cpu.h
> >+++ b/target-ppc/cpu.h
> >@@ -692,6 +692,8 @@ struct CPUPPCState {
> >      int bfd_mach;
> >      uint32_t flags;
> >      uint64_t insns_flags;
> >+    void (*emulate_hypercall)(CPUState *, void *);
> >+    void *hcall_opaque;
> 
> Is the hypercall handler ever specific to a CPU?

If you mean, "is the hypercall environment ever different from one cpu
to another within the same guest at the same time", then no.  Or at
least, no for any platform that exists now, and anything plausible I
can think of.

If you mean can the hypercall ABI and handling be different for
different CPU models within an architecture, then yes.  It's not there
yet, but BookE CPUs *will* have a quite different hypercall
environment to the PAPR hypercall environment used on IBM servers.

> I'd prefer to see this as a generic interface that wasn't specific
> to target-ppc.

> 
> Basically, add a:
> 
> void cpu_hypercall(CPUState *env);
> 
> And then implement it within your target.

I'm not exactly sure what you mean by "target" here.  It is *not*
sufficient to make the hypercall function per guest architecture, it
must be per machine.  However, it could be a global hook rather than
in the CPUState.

>  I'm not sure I get the
> opaque argument.

Well, my hypercall code needs to get at various device structures
established during machine init.  I use the opaque argument to pass a
context with this information, rather than having globals for the
things I need.  I could use a global instead, if you'd prefer.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson