Messages in this thread | | | Subject | Re: [PATCH v8 08/11] x86/tdx: Wire up KVM hypercalls | From | Sathyanarayanan Kuppuswamy <> | Date | Fri, 12 Nov 2021 08:17:50 -0800 |
| |
+Isaku
Hi Isaku/Kirill,
On 11/5/21 1:59 PM, Sean Christopherson wrote: > Why use a magic string? There are already mechanisms for the host to announce > itself to the guest, i.e. the guest shouldn't be attempting these hypercalls unless > it knows it's running on KVM (or something that implements KVM's ABI, whatever > that may be). > > The only use case I can think of is to support multiple flavors of hypercalls in > the VMM, e.g. to let KVM support both KVM and Hyper-V hypercalls when KVM is > masquerading as Hyper-V, but this magic value alone isn't sufficient. > > And if there is a future where KVM wants to support multiple sets of hypercalls, > using the entire 64-bit GPR for a magic value is unnecessary and wasteful, e.g. > it requires an overside MOV imm, reg. > > Why not use a single high bit? Actually, looking at KVM's set of hypercalls, > the guest can literally pass @nr as is. The GHCI defines all non-zero values as > vendor owned, i.e. this needs to ensure only that @nr is non-zero. For whatever > reason, perhaps to avoid false positives if the guest forgets to fill the value, > KVM's hypercalls start at '1'. > > Regardless of what is stuffed into r10 for the TDVMCALL, if it's anything other > than KVM's raw hypercall number, it absolutely must go into > include/uapi/linux/kvm_para.h and it should be done as a standalone commit, > because what you're proposing here is effectively committing KVM to supporting > an ABI. That is not remotely clear from the changelog.
Do you see any issues with using a single bit or just passing the @nr as it is?
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
| |