Re: [PATCH 06/14] KVM: arm/arm64: Factor out VMID into struct kvm_vmid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 21 Feb 2019 11:02:56 +0000
Julien Grall <Julien.Grall@xxxxxxx> wrote:

Hi Julien,

> Hi Christoffer,
> 
> On 24/01/2019 14:00, Christoffer Dall wrote:
> > Note that to avoid mapping the kvm_vmid_bits variable into hyp, we
> > simply forego the masking of the vmid value in kvm_get_vttbr and rely on
> > update_vmid to always assign a valid vmid value (within the supported
> > range).  
> 
> [...]
> 
> > -	kvm->arch.vmid = kvm_next_vmid;
> > +	vmid->vmid = kvm_next_vmid;
> >   	kvm_next_vmid++;
> > -	kvm_next_vmid &= (1 << kvm_vmid_bits) - 1;
> > -
> > -	/* update vttbr to be used with the new vmid */
> > -	pgd_phys = virt_to_phys(kvm->arch.pgd);
> > -	BUG_ON(pgd_phys & ~kvm_vttbr_baddr_mask(kvm));
> > -	vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK(kvm_vmid_bits);
> > -	kvm->arch.vttbr = kvm_phys_to_vttbr(pgd_phys) | vmid | cnp;
> > +	kvm_next_vmid &= (1 << kvm_get_vmid_bits()) - 1;  
> 
> The arm64 version of kvm_get_vmid_bits does not look cheap. Indeed it required 
> to read the sanitized value of SYS_ID_AA64MMFR1_EL1 that is implemented using 
> the function bsearch.
> 
> So wouldn't it be better to keep kvm_vmid_bits variable for use in update_vttbr()?

How often does this happen? Can you measure this overhead at all?

My understanding is that we hit this path on rollover only, having IPIed
all CPUs and invalidated all TLBs. I seriously doubt you can observe
any sort of overhead at all, given that it is so incredibly rare. But
feel free to prove me wrong!

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux