On Thu, Mar 21, 2013 at 09:52:16AM +0100, Alexander Graf wrote: > > +/* Platform specific hcalls, used by KVM */ > > +#define H_RTAS 0xf000 > > How about you define a different hcall ID for this? Then QEMU would > create its "rtas entry blob" such that KVM-routed RTAS handling goes > to KVM directly. QEMU can still do that, and I don't see that it would change the kernel side if it did. We would still have to have agreement between the kernel and userspace as to what the hcall number for invoking the in-kernel RTAS calls was, and the kernel would still have to keep a list of token numbers and how they correspond to the functions it provides. The only thing different would be that the in-kernel RTAS hcall could return to the guest if it didn't recognize the token number, rather than pushing the problem up to userspace. However, that wouldn't make the code any simpler, and it isn't a situation where performance is an issue. Do you see some kernel-side improvements or simplifications from your suggestion that I'm missing? Remember, the guest gets the token numbers from the device tree (properties under the /rtas node), so they are under the control of userspace/QEMU. Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
