On Thursday 22 Jul 2021 at 06:45:14 (+0000), Shameerali Kolothum Thodi wrote: > > From: Will Deacon [mailto:will@xxxxxxxxxx] > > > diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c > > b/arch/arm64/kvm/hyp/nvhe/mem_protect.c > > > index 4b60c0056c04..a02c4877a055 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c > > > +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c > > > @@ -106,8 +106,7 @@ int kvm_host_prepare_stage2(void *mem_pgt_pool, > > void *dev_pgt_pool) > > > mmu->pgd_phys = __hyp_pa(host_kvm.pgt.pgd); > > > mmu->arch = &host_kvm.arch; > > > mmu->pgt = &host_kvm.pgt; > > > - mmu->vmid.vmid_gen = 0; > > > - mmu->vmid.vmid = 0; > > > + atomic64_set(&mmu->vmid.id, 0); > > > > I think this is the first atomic64 use in the EL2 object, which may pull in > > some fatal KCSAN instrumentation. Quentin, have you run into this before? > > > > Might be simple just to zero-initialise mmu for now, if it isn't already. > > I will check that. Yes I think what saves us here is that, AFAICT. arm64 doesn't support KCSAN yet. But the day it does, this should fail to link (hopefully) because of out-of-line calls into e.g. __kasan_check_write(). So yes, a simple zeroing here is probably preferable. Thanks, Quentin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
