On 12/5/20 6:51 PM, David Woodhouse wrote: > On 5 December 2020 18:42:53 GMT, Joao Martins <joao.m.martins@xxxxxxxxxx> wrote: >> 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. > You might be right. I had always had the impression that the above was is geared towards PV guests hypercalls IIRC which are not VMMCALL/VMCALL. Xen doesn't explicitly check you initialized an hypercall page for HVM guests. > But if they do just do the VMCALL, that *will* work as I have it, won't it? > It would work indeed. What I was mentioning is the possibility that you let userspace fill the hcall page data, while enabling hcall intercept () so 0x3 as xen hvm config flags i.e. you pass a blob with hcall intercept set. I think it's good as is given that interception is tied in with what you fill in the hcall page. >> >> 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. >
