On 07/04/2016 08:18 PM, Julien Grall wrote: > > > On 04/07/16 17:43, Andrew Cooper wrote: >> On 04/07/16 17:40, Sergej Proskurin wrote: >>> >>>>> { >>>>> - struct p2m_domain *p2m = &d->arch.p2m; >>>>> + int ret = 0; >>>>> + >>>>> + spin_lock_init(&p2m->lock); >>>>> + INIT_PAGE_LIST_HEAD(&p2m->pages); >>>>> + >>>>> + spin_lock(&p2m->lock); >>>>> + >>>>> + p2m->domain = d; >>>>> + p2m->access_required = false; >>>>> + p2m->mem_access_enabled = false; >>>>> + p2m->default_access = p2m_access_rwx; >>>>> + p2m->p2m_class = p2m_host; >>>>> + p2m->root = NULL; >>>>> + >>>>> + /* Adopt VMID of the associated domain */ >>>>> + p2m->vmid = d->arch.p2m.vmid; >>>> It looks like to me that re-using the same VMID will require more TLB >>>> flush (such as when a VCPU is migrated to another physical CPU). So >>>> could you explain why you decided to re-use the same VMID? >>>> >>> Please correct me if I am wrong, but I associate a VMID with an entire >>> domain. Since, the altp2m view still belongs to the same domain >>> (p2m_init_one is called only from p2m_init_altp2m), the code re-uses the >>> old VMID. >> >> (I am not an ARM expert but) looking into VMIDs from the last time, they >> are the TLB tag for the address space in use. > > Correct. > >> >> Does ARM have shared TLBs between multiple cores? If so, you must a >> separate VMID, otherwise an ALT2PM used by one vcpu could cause a >> separate vcpu with a different ALTP2M to reuse the wrong translation. > > From the ARM ARM, I cannot rule out that TLBs cannot be shared from > multiple cores (CC a couple of ARM folks to confirm). > > Nevertheless, using a different VMID per P2M would avoid to care about > flushing when moving the vCPU around. >
I see what you mean. This would definitely improve the context switch performance. That is, instead of adopting the hostp2m's vmid during altp2m table initialization, I will allocate a new VMID for every altp2m table --as you said before. This would simply eliminate the need for explicit TLB flushing. Thank you very much. > Regards, > Best regards, Sergej _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel