On 19/07/2016 01:36, Bandan Das wrote: >> However, on a related note, I have preserved the existing ordering >> of VMPTRLD followed by adding the VMCS to the loaded_vmcss_on_cpu. >> Is this ordering safe in the event of a KEXEC? > > So, there might be the possibility that kexec doesn't clear the > recently loaded vmcs since it was not on the list ? Looks like an > issue to me but I have cc-ed Paolo to comment/confirm. Indeed it would be better to order them the other way round. >> Are you are suggesting that the invariant should be that the shadow >> VMCS is on the loaded_vmcss_on_cpu list iff it is referenced by the >> link pointer in the parent? Maintaining that invariant will require >> some extra work. The shadow VMCS will have to be removed from the >> loaded_vmcss_on_cpu list in nested_release_vmcs12, and >> vmx_vcpu_load will have to check vmx->nested.current_vmptr before >> the loaded_vmcss_on_cpu operations involving the shadow VMCS. > > Hmm... It just seemed like managing shadow_vmcs() is more of a > vmptrld/vmclear operation but that also means removing/adding vmcss > everytime vmclear is called and iirc the current code does a good job > of reusing vmcss. So, I think this is fine. Yeah, it's extra work for little reason. Doing an extra vmclear on kexec is not an issue. Paolo -- 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
