On 28.06.2010, at 10:13, Avi Kivity wrote: > On 06/28/2010 10:49 AM, Alexander Graf wrote: >> >>> I don't believe we support the kernel actually doing a syscall to itself >>> anymore, at least on powerpc. The callers call the underlying system >>> call function, or kernel_thread. >>> >>> That said, I would suggest we allocate a syscall number for this, as it >>> would document the usage. (In additon to 0..nr_syscalls - 1 we have >>> 0x1ebe in use). >>> >> That's actually a pretty good idea. >> > > Since the syscall register is not architectual (or rather it is architectural but Linux ignores it) I don't see the point. It would work for Linux but may alias some random parameter for a different guest. We need a reliable method of distinguishing between syscalls and hypercalls. Matching pc would work (but is defeated by inlining) so long as we find some other way of identifying the hc pc to the hypervisor. The other alternative I'd see is to reuse an instruction that is not sc. We could for example pull the mfpvr trick again, but pass a different magic value in the register this time that tells the hypervisor "this is a hypercall". Or we could reserve a different SPR. But from what I've seen there are already quite a lot of SPRs out there. More than available numbers :). The hypercall technique I used here is actually inspired by MOL. They use magic constants in r3 and r4 for their "OSI" identification. I'm frankly not sure what the best approach is, but considering that syscalls from the kernel lie in the guest kernel's hand, we could just declare any breakage a guest kernel bug. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
