Re: [RFC v1 05/26] x86/traps: Add #VE support for TDX guest

[Dave Hansen <dave.hansen@intel.com>]

On 2/12/21 12:37 PM, Sean Christopherson wrote:
> There needs to be a mechanism for lazy/deferred/on-demand acceptance of pages.
> E.g. pre-accepting every page in a VM with hundreds of GB of memory will be
> ridiculously slow.
> 
> #VE is the best option to do that:
> 
>   - Relatively sane re-entrancy semantics.
>   - Hardware accelerated.
>   - Doesn't require stealing an IRQ from the guest.

TDX already provides a basic environment for the guest when it starts
up.  The guest has some known, good memory.  The guest also has a very,
very clear understanding of which physical pages it uses and when.  It's
staged, of course, as decompression happens and the guest comes up.

But, the guest still knows which guest physical pages it accesses and
when.  It doesn't need on-demand faulting in of non-accepted pages.  It
can simply decline to expose non-accepted pages to the wider system
before they've been accepted.

It would be nuts to merrily free non-accepted pages into the page
allocator and handle the #VE fallout as they're touched from
god-knows-where.

I don't see *ANY* case for #VE to occur inside the guest kernel, outside
of *VERY* narrow places like copy_from_user().  Period.  #VE from ring-0
is not OK.

So, no, #VE is not the best option.  No #VE's in the first place is the
best option.