On Thu, 2020-08-20 at 12:18 +0200, Paolo Bonzini wrote:
> On 20/08/20 12:05, Maxim Levitsky wrote:
> > > You probably should set clean to 0 also if the guest doesn't have the
> > > VMCBCLEAN feature (so, you first need an extra patch to add the
> > > VMCBCLEAN feature to cpufeatures.h). It's probably best to cache the
> > > guest vmcbclean in struct vcpu_svm, too.
> > Right, I totally forgot about this one.
> >
> > One thing why I made this patch optional, is that I can instead drop it,
> > and not 'read back' the saved area on vmexit, this will probably be faster
> > that what this optimization does. What do you think? Is this patch worth it?
> > (I submitted it because I already implemented this and wanted to hear
> > opinion
> > on this).
>
> Yeah, good point. It's one copy either way, either on vmexit (and
> partly on vmentry depending on clean bits) or on vmentry. I had not
> considered the need to copy from vmcb02 to the cached vmcb12 on vmexit. :(
>
> Let's shelve this for a bit, and revisit it once we have separate vmcb01
> and vmcb02. Then we might still use the clean bits to avoid copying
> data from vmcb12 to vmcb02, including avoiding consistency checks
> because we know the vmcb02 data is legit.
It makes sense I guess. The vmcb02 would then play the role of the cache of
vmcb12
>
> Patches 1-5 are still worthwhile, so you can clean them up and send them.
>
> Paolo
OK, on it now.
Best regards,
Maxim Levitsky
>
