On 5 December 2020 18:42:53 GMT, Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: >On 12/4/20 1:18 AM, David Woodhouse wrote: >> @@ -3742,6 +3716,9 @@ int kvm_vm_ioctl_check_extension(struct kvm >*kvm, long ext) >> case KVM_CAP_ENFORCE_PV_FEATURE_CPUID: >> r = 1; >> break; >> + case KVM_CAP_XEN_HVM: >> + r = 1 | KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL; >> + break; > >Maybe: > > r = KVM_XEN_HVM_CONFIG_HYPERCALL_MSR | > KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL; Yeah, I already did that as I did the docs. In my tree it's already folded into this patch for when I post v2. Thanks. >I suppose it makes sense restricting to INTERCEPT_HCALL to make sure >that the kernel only >forwards the hcall if it is control off what it put there in the >hypercall page (i.e. >vmmcall/vmcall). hcall userspace exiting without INTERCEPT_HCALL would >break ABI over how >this ioctl was used before the new flag... In case >kvm_xen_hypercall_enabled() would >return true with KVM_XEN_HVM_CONFIG_HYPERCALL_MSR, as now it needs to >handle a new >userspace exit. Right. >If we're are being pedantic, the Xen hypercall MSR is a utility more >than a necessity as >the OS can always do without the hcall msr IIUC. But it is defacto used >by enlightened Xen >guests included FreeBSD. Not sure about that. Xen doesn't guarantee that the hypercall will be VMCALL; the ABI *is* ",use the hypercall page MSR and call it" I believe. But if they do just do the VMCALL, that *will* work as I have it, won't it? > >And adding: > >#define KVM_XEN_HVM_CONFIG_HYPERCALL_MSR (1 << 0) > >Of course, this is a nit for readability only, but it aligns with what >you write >in the docs update you do in the last patch. Yep, already there. Thanks. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
