On 21/10/2019 11:40, Marc Zyngier wrote: > On 2019-10-21 11:21, Steven Price wrote: >> On 19/10/2019 12:12, Marc Zyngier wrote: >>> On Fri, 11 Oct 2019 13:59:25 +0100, >>> Steven Price <steven.price@xxxxxxx> wrote: >>>> >>>> Implement the service call for configuring a shared structure between a >>>> VCPU and the hypervisor in which the hypervisor can write the time >>>> stolen from the VCPU's execution time by other tasks on the host. >>>> >>>> User space allocates memory which is placed at an IPA also chosen by >>>> user >>>> space. The hypervisor then updates the shared structure using >>>> kvm_put_guest() to ensure single copy atomicity of the 64-bit value >>>> reporting the stolen time in nanoseconds. >>>> >>>> Whenever stolen time is enabled by the guest, the stolen time >>>> counter is >>>> reset. >>>> >>>> The stolen time itself is retrieved from the sched_info structure >>>> maintained by the Linux scheduler code. We enable SCHEDSTATS when >>>> selecting KVM Kconfig to ensure this value is meaningful. >>>> >>>> Signed-off-by: Steven Price <steven.price@xxxxxxx> >>>> --- >>>> arch/arm/include/asm/kvm_host.h | 20 +++++++++++ >>>> arch/arm64/include/asm/kvm_host.h | 21 +++++++++++- >>>> arch/arm64/kvm/Kconfig | 1 + >>>> include/linux/kvm_types.h | 2 ++ >>>> virt/kvm/arm/arm.c | 11 ++++++ >>>> virt/kvm/arm/hypercalls.c | 3 ++ >>>> virt/kvm/arm/pvtime.c | 56 +++++++++++++++++++++++++++++++ >>>> 7 files changed, 113 insertions(+), 1 deletion(-) > > [...] > >>>> +long kvm_hypercall_stolen_time(struct kvm_vcpu *vcpu) >>> >>> Why long? If that's a base address, then it is either a phys_addr_t or >>> a gpa_t. I'd suggest you move the error check to the caller. >> >> This is a bit more tricky. It's a long because that's the declared type >> of the SMCCC return in kvm_hvc_call_handler(). I can't (easily) move the >> code into kvm_hvc_call_handler() because that is compiled for arm (as >> well as arm64) and we don't have the definitions for stolen time there. >> The best option I could come up with is to have a dummy stub for arm and >> use generic types for this function. >> >> This means we need a type which can contain both a gpa_t and the >> SMCCC_RET_NOT_SUPPORTED error code. >> >> I'm open to alternative suggestions on how to make this work. > > My suggestion would be to always return a gpa_t from this function, and > change the 32bit stub for kvm_hypercall_stolen_time() to always return > GPA_INVALID. Ok, fair enough. Although it ends up with this strange looking fragment in kvm_hvc_call_handler(): case ARM_SMCCC_HV_PV_TIME_ST: gpa = kvm_init_stolen_time(vcpu); if (gpa != GPA_INVALID) val = gpa; break; But I agree the gpa_t return type is clearer. Thanks, Steve _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
