On Wed, 2021-09-01 at 20:42 +0000, Sean Christopherson wrote:
> 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.*
OK, I see now. But I still don't understand why is these shadow
controls related to field existence. They not in
handle_vm{read,write}() path. Would you shed more light? Thanks.
>
> > 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?
I mean doesn't exist in VMCS12, per the bitmap. In this case, when L1
read/write the field, it is shadowed, won't be trapped by vmx.
> 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.
