On Thu, May 07, 2020 at 03:36:33PM +0100, Quentin Perret wrote: > On Thursday 07 May 2020 at 15:01:07 (+0100), Marc Zyngier wrote: > > > /* > > > - * u64 __kvm_call_hyp(void *hypfn, ...); > > > + * u64 __kvm_call_hyp(unsigned long arg, ...); > > > * > > > * This is not really a variadic function in the classic C-way and care must > > > * be taken when calling this to ensure parameters are passed in registers > > > * only, since the stack will change between the caller and the callee. > > > - * > > > - * Call the function with the first argument containing a pointer to the > > > - * function you wish to call in Hyp mode, and subsequent arguments will be > > > - * passed as x0, x1, and x2 (a maximum of 3 arguments in addition to the > > > - * function pointer can be passed). The function being called must be mapped > > > - * in Hyp mode (see init_hyp_mode in arch/arm/kvm/arm.c). Return values are > > > - * passed in x0. > > > - * > > > - * A function pointer with a value less than 0xfff has a special meaning, > > > - * and is used to implement hyp stubs in the same way as in > > > - * arch/arm64/kernel/hyp_stub.S. > > > > I don't think any of this becomes obsolete with this patch (apart from > > the reference to 32bit), and only changes with patch #2. Or am I > > misunderstanding something? > > Nope, I think you're right. To be fair, this patch has changed quite > a bit since the first version (which did change that comment a little > later IIRC), but David has done all the hard work on top so I'll let > him answer that one. They have a different meaning in the three different contexts: 1) hyp-stub HVC: hcall ID + 3 args 2) hyp-init HVC: 4 args (no hcall ID) 3) host HVC: function pointer + 3 args The patch was meant to have all three use the same HVC routine, eventually converging on host HVCs also using 'hcall ID + 3 args' in patch 02, but it is a bit forced at this point. I can drop this patch from the series and we can clean this up later if it still makes sense. > > And David, feel free to take the authorship for this patch -- I barely > recognize it (for the better), so it's more than fair if you get the > credit :) _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
