On Thu, Aug 19, 2021, Robert Hoo wrote:
> On Wed, 2021-08-18 at 23:10 +0000, Sean Christopherson wrote:
> > > My this implementation: once VMX MSR's updated, the update needs to be
> > > passed to bitmap, this is 1 extra step comparing to aforementioned above.
> > > But, later, when query field existence, especially the those consulting
> > > vm{entry,exit}_ctrl, they usually would have to consult both MSRs if
> > > otherwise no bitmap, and we cannot guarantee if in the future there's no
> > > more complicated dependencies. If using bitmap, this consult is just
> > > 1-bit reading. If no bitmap, several MSR's read and compare happen.
> >
> > Yes, but the bitmap is per-VM and likely may or may not be cache-hot for
> > back-to-back VMREAD/VMWRITE to different fields, whereas the shadow
> > controls are much more likely to reside somewhere in the caches.
>
> Sorry I don't quite understand the "shadow controls" here. Do you mean
> shadow VMCS? what does field existence to do with shadow VMCS?
vmcs->controls_shadow.*
> emm, here you indeed remind me a questions: what if L1 VMREAD/VMWRITE a
> shadow field that doesn't exist?
Doesn't exist in hardware? KVM will intercept the access by leaving the
corresponding bit set in the VMREAD/VMWRITE bitmaps. This is handled by
init_vmcs_shadow_fields(). Note, KVM will still incorrectly emulate the access,
but on the plus side that means L2 will see consistent behavior regardless of
underlying hardware.
