On Thu, Aug 19, 2021, Kalra, Ashish wrote: > > > On Aug 20, 2021, at 3:38 AM, Kalra, Ashish <Ashish.Kalra@xxxxxxx> wrote: > > I think it makes more sense to stick to the original approach/patch, i.e., > > introducing a new private hypercall interface like kvm_sev_hypercall3() and > > let early paravirtualized kernel code invoke this private hypercall > > interface wherever required. I don't like the idea of duplicating code just because the problem is tricky to solve. Right now it's just one function, but it could balloon to multiple in the future. Plus there's always the possibility of a new, pre-alternatives kvm_hypercall() being added in generic code, at which point using an SEV-specific variant gets even uglier. > > This helps avoiding Intel CPUs taking unnecessary #UDs and also avoid using > > hacks as below. > > > > TDX code can introduce similar private hypercall interface for their early > > para virtualized kernel code if required. > > Actually, if we are using this kvm_sev_hypercall3() and not modifying > KVM_HYPERCALL() then Intel CPUs avoid unnecessary #UDs and TDX code does not > need any new interface. Only early AMD/SEV specific code will use this > kvm_sev_hypercall3() interface. TDX code will always work with > KVM_HYPERCALL(). Even if VMCALL is the default, i.e. not patched in, VMCALL it will #VE on TDX. In other words, VMCALL isn't really any better than VMMCALL, TDX will need to do something clever either way.
