On Fri, Sep 03, 2021, Robert Hoo wrote:
> 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.
Hmm, you're confused because my comment about the controls shadows is nonsensical.
I conflated the vmcs->controls_shadow.* with vmx->nested.msrs.*. Sorry for the
confusion :-/
