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 >
