From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34809 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q0D8V-0004Pq-Tp for qemu-devel@nongnu.org; Thu, 17 Mar 2011 09:21:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q0D8U-0002Tj-9u for qemu-devel@nongnu.org; Thu, 17 Mar 2011 09:21:07 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:58847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q0D8U-0002Tb-5Y for qemu-devel@nongnu.org; Thu, 17 Mar 2011 09:21:06 -0400 Received: by iwl42 with SMTP id 42so3201590iwl.4 for ; Thu, 17 Mar 2011 06:21:05 -0700 (PDT) Message-ID: <4D820AB4.8000803@codemonkey.ws> Date: Thu, 17 Mar 2011 08:20:52 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 03/26] Add a hook to allow hypercalls to be emulated on PowerPC References: <1300251423-6715-1-git-send-email-david@gibson.dropbear.id.au> <1300251423-6715-4-git-send-email-david@gibson.dropbear.id.au> <4D812141.60402@codemonkey.ws> <20110317045557.GM1105@yookeroo> In-Reply-To: <20110317045557.GM1105@yookeroo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: agraf@suse.de, qemu-devel@nongnu.org, paulus@samba.org, anton@samba.org On 03/16/2011 11:55 PM, David Gibson wrote: > 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 >>> >>> 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 >>> --- >>> 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. Yes, that's what I was asking. So having a function pointer in each CPUState isn't necessary. > 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'd suggest a totally generic hypercall infrastructure but I know that's not plausible for Power. So I'm suggesting defining cpu_hypercall() in cpu.h, and then somewhere in target-ppc/, you can implement whatever logic you need to support that function. This fits well with how we dispatch other forms of I/O (cpu_outb, cpu_physical_memory_rw, etc). Regards, Anthony Liguori