[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 03/26] Add a hook to allow hypercalls to be emul
Re: [Qemu-devel] [PATCH 03/26] Add a hook to allow hypercalls to be emulated on PowerPC
Fri, 18 Mar 2011 15:03:22 +1100
On Thu, Mar 17, 2011 at 08:20:52AM -0500, Anthony Liguori wrote:
> 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:
> >>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.
I'm still not sure what you're getting at here. I can't see how a
generic (as in across architectures) hypercall infrastructure makes
sense when clearly both the implemenentation of a hypercall, and the
trigger to fire it off will be ISA specific.
> 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.
So I don't see the point of having this arch-specific wrapper function
which will do nothing but call a hypervisor platform specific hook,
presumably set by the machine. There's only one callsite for the
hypercall function, why not just call the hook straight from there.
So, for the moment, I'm just going to take the hypercall hook out of
the CPUState and make it a global. We can have the next round of
objections from there :).
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_!
[Qemu-devel] [PATCH 01/26] Clean up PowerPC SLB handling code, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 02/26] Allow qemu_devtree_setprop() to take arbitrary values, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 04/26] Implement PowerPC slbmfee and slbmfev instructions, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 05/26] Implement missing parts of the logic for the POWER PURR, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 07/26] Clean up slb_lookup() function, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 08/26] Parse SDR1 on mtspr instead of at translate time, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 09/26] Use "hash" more consistently in ppc mmu code, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 10/26] Better factor the ppc hash translation path, David Gibson, 2011/03/16
[Qemu-devel] [PATCH 06/26] Correct ppc popcntb logic, implement popcntw and popcntd, David Gibson, 2011/03/16