Re: Nested virtualization and software page walks in the L1 hypervsior

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Tue, Mar 03, 2020 at 04:22:57PM -0800, Peter Feiner wrote:
> On Sat, Feb 29, 2020 at 2:31 PM Jim Mattson <jmattson@google.com> wrote:
> >
> > Peter Feiner asked me an intriguing question the other day. If you
> > have a hypervisor that walks  its guest's x86 page tables in software
> > during emulation, how can you make that software page walk behave
> > exactly like a hardware page walk? In particular, when the hypervisor
> > is running as an L1 guest, how is it possible to write the software
> > page walk so that accesses to L2's x86 page tables are treated as
> > reads if L0 isn't using EPT A/D bits, but they're treated as writes if
> > L0 is using EPT A/D bits? (Paravirtualization is not allowed.)
> >
> > It seems to me that this behavior isn't virtualizable. Am I wrong?
> 
> Jim, I thought about this some more after talking to you. I think it's
> entirely moot what L0 sees so long as L1 and L2 work correctly. So,
> the question becomes, is there anything that L0 could possibly rely on
> this behavior for? My first thought was dirty tracking, but that's not
> a problem because *writes* to the L2 x86 page tables' A/D bits will
> still be intercepted by L0. The missing D bit on a guest page that
> doesn't actually change doesn't matter :-)

Ya.  The hardware behavior of setting the Dirty bit is effectively a
spurious update.  Not emulating that behavior is arguably a good thing :-).

Presumably, the EPT walks are overzealous in treating IA32 page walks as
writes to allow for simpler hardware implementations, e.g. the mechanism to
handle A/D bit updates doesn't need to handle the case where setting an A/D
bit in an IA32 page walk would also trigger an D bit update for the
associated EPT walk.