On Thu, Aug 19, 2021, Kalra, Ashish wrote:

quoted

On Aug 20, 2021, at 3:38 AM, Kalra, Ashish [off-list ref] 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.

quoted

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.