On 2013-04-14 12:07, Gleb Natapov wrote: > On Sun, Apr 14, 2013 at 01:00:10PM +0300, Gleb Natapov wrote: >> On Sun, Apr 14, 2013 at 12:51:34PM +0300, Abel Gordon wrote: >>> >>> >>> Gleb Natapov <gleb@xxxxxxxxxx> wrote on 12/04/2013 01:48:04 PM: >>> >>>> On Fri, Apr 12, 2013 at 01:44:14PM +0300, Abel Gordon wrote: >>>>> >>>>> Ok, so then you prefer to add the inline functions to read/write to the >>>>> vmcs12 >>>>> fields, (to set the request bit if shadowed field changed) and you are >>> not >>>>> concerned >>>>> about any merge/rebase mess. I will work on this direction. >>>>> I'll first send an independent patch to introduce the accessors. Once >>> you >>>>> apply this patch, I'll continue and send you v2 patches for shadow >>> vmcs. >>>>> >>>>> Do you agree ? >>>> Yes. >>> >>> Looking again at the code it seems like we could avoid adding the >>> accessors. >>> We could just set a flag in nested_vmx_vmexit and >>> nested_vmx_entry_failure. Then, in vmx_vcpu_run we check/reset the flag and >>> call copy_vmcs12_to_shadow (if required). >>> >>> What do you think ? >> Good idea! With accessors we can do further optimization by copying only >> things that changed, but it will be premature optimization at this >> point. >> > Actually this is good idea only if we know for sure that VMX emulation > changes vmcs12 only during guest entry/exit. Is this the case? I think > so. Some vmcs12 fields that are exposed to L1 are changed outside L2<->L1 transitions. What comes to my mind: L0 emulates some change that L1 does not trap, e.g. CRx accesses. Or what do you mean? Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
