Jan Kiszka <jan.kiszka@xxxxxx> wrote on 14/04/2013 01:27:10 PM: > 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? If L0 emulates some change that L1 does not trap, L1 will not read (vmread) the change until we switch to L1 (for other exit). So, later we will do nested_vmx_vmexit and sync the shadowed field. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
