On Thu, Jul 22, 2021 at 10:11AM +0100, Quentin Perret wrote: > 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. Note: Do not worry about hypothetically breaking with sanitizers here -- whether it's KASAN or KCSAN, they both instrument atomics. In files that enable instrumentation but the atomic instrumentation should not be pulled in, use the arch_ variants, but this doesn't apply here because instrumentation shouldn't even be on. The indicator that when KCSAN is supported on arm64, the Makefile here just needs KCSAN_SANITIZE := n, is that all other instrumentation is also killed entirely: $ grep -E "(PROFILE|SANITIZE|INSTRUMENT)" arch/arm64/kvm/hyp/nvhe/Makefile GCOV_PROFILE := n KASAN_SANITIZE := n UBSAN_SANITIZE := n KCOV_INSTRUMENT := n KCSAN isn't supported on arm64 yet, and when it does, I believe Mark's arm64 KCSAN series should take care of things like this. Thanks, -- Marco _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
