Re: [PATCH 2/9] KVM: nVMX: Initialize #VE info page for vmcs02 when proving #VE support

[Huang, Kai]

On 21/05/2024 11:22 am, Sean Christopherson wrote:
> On Tue, May 21, 2024, Kai Huang wrote:
> > On 18/05/2024 12:04 pm, Sean Christopherson wrote:
> > > Point vmcs02.VE_INFORMATION_ADDRESS at the vCPU's #VE info page when
> > > initializing vmcs02, otherwise KVM will run L2 with EPT Violation #VE
> > > enabled and a VE info address pointing at pfn 0.
> >
> > How about we just clear EPT_VIOLATION_VE bit in 2nd_exec_control
> > unconditionally for vmcs02?
>
> Because then KVM wouldn't get any EPT Violation #VE coverage for L2, and as
> evidence by the KVM-Unit-Test failure, running L2 with EPT Violation #VEs enabled
> provides unique coverage.  Doing so definitely provides coverage beyond what is
> strictly needed for TDX, but it's just as easy to set the VE info page in vmcs02
> as it is so clear EPT_VIOLATION_VE, so why not.
>
> > Your next patch says:
> >
> > "
> > Always handle #VEs, e.g. due to prove EPT Violation #VE failures, in L0,
> > as KVM does not expose any #VE capabilities to L1, i.e. any and all #VEs
> > are KVM's responsibility.
> > "
>
> I don't see how that's relevant to whether or not KVM enables EPT Violation #VEs
> while L2 is running.  That patch simply routes all #VEs to L0, it doesn't affect
> whether or not it's safe to enable EPT Violation #VEs for L2.

My logic is, if #VE exit cannot possibly happen for L2, then we don't 
need to deal whether to route #VE exits to L1. :-)

Well, actually I think conceptually, it kinda makes sense to route #VE 
exits to L1:

L1 should never enable #VE related bits so L1 is certainly not expecting 
to see #VE from L2.  But how to act should be depending on L1's logic? 
E.g., it can choose to ignore, or just kill the L2 etc?

Unconditionally disable #VE in vmcs02 can avoid such issue because it's 
just not possible for L2 to have the #VE exit.