>>> On 10.11.17 at 15:46, <igor.druzhi...@citrix.com> wrote: > On 10/11/17 10:30, Jan Beulich wrote: >>>>> On 10.11.17 at 09:41, <sergey.dya...@citrix.com> wrote: >>> 2. Drop v->is_running check inside vmx_ctxt_switch_from() making >>> vmx_vmcs_reload() unconditional. >> >> This is an option, indeed (and I don't think it would have a >> meaningful performance impact, as vmx_vmcs_reload() does >> nothing if the right VMCS is already in place). Iirc I had added the >> conditional back then merely to introduce as little of a behavioral >> change as was (appeared to be at that time) necessary. What I'm >> not certain about, however, is the final state we'll end up in then. >> Coming back to your flow scheme (altered to represent the >> suggested new flow): >> > > I was thinking of this approach for a while and I couldn't find anything > dangerous that can be potentially done by vmcs_reload() since it looks > like that it already has all the necessary checks inside. > >> pCPU1 pCPU2 >> ===== ===== >> current == vCPU1 >> context_switch(next == idle) >> !! __context_switch() is skipped >> vcpu_migrate(vCPU1) >> RCU callbacks >> vmx_vcpu_destroy() >> vmx_vcpu_disable_pml() >> current_vmcs = 0 >> >> schedule(next == vCPU1) >> vCPU1->is_running = 1; >> context_switch(next == vCPU1) >> flush_tlb_mask(&dirty_mask); >> >> <--- IPI >> >> __sync_local_execstate() >> __context_switch(prev == vCPU1) >> vmx_ctxt_switch_from(vCPU1) >> vmx_vmcs_reload() >> ... >> >> We'd now leave the being destroyed vCPU's VMCS active in pCPU1 >> (at least I can't see where it would be deactivated again). > > This would be VMCS of the migrated vCPU - not the destroyed one.
Oh, right. Nevertheless I favor the other approach (or some of the possible variants of it). In particular, I'm increasingly in favor of moving the sync up the call stack, at least into complete_domain_destroy(), or even rcu_do_batch(), as mentioned before. The former would be more clearly of no concern performance wise (to please Dario), while the latter would be the obvious and clean equivalent of the old tasklet commit I've pointed out last week. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
