On Tuesday 16 Mar 2021 at 13:28:42 (+0100), Mate Toth-Pal wrote: > Testing the latest version of the patchset, we seem to have found another > thing related to FEAT_S2FWB. Argh! I wish I could put my hands on hardware with FWB. Thanks again for the report. > This function always sets Normal memory in the stage 2 table, even if the > address in stage 1 was mapped as a device memory. However with the current > settings for normal memory (i.e. MT_S2_FWB_NORMAL being defined to 6) > according to the architecture (See Arm ARM, 'D5.5.5 Stage 2 memory region > type and cacheability attributes when FEAT_S2FWB is implemented') the > resulting attributes will be 'Normal Write-Back' even if the stage 1 mapping > sets device memory. Accessing device memory mapped like this causes an > SError on some platforms with FEAT_S2FWB being implemented. Right. > Changing the value of MT_S2_FWB_NORMAL to 7 would change this behavior, and > the resulting memory type would be device. Sounds like the correct fix here -- see below. > Another solution would be to add an else branch to the last 'if' above like > this: > > diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c > b/arch/arm64/kvm/hyp/nvhe/mem_protect.c > index fffa432ce3eb..54e5d3b0b2e1 100644 > --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c > +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c > @@ -214,6 +214,8 @@ static int host_stage2_idmap(u64 addr) > > if (is_memory) > prot |= KVM_PGTABLE_PROT_X; > + else > + prot |= KVM_PGTABLE_PROT_DEVICE; > > hyp_spin_lock(&host_kvm.lock); > ret = kvm_pgtable_stage2_find_range(&host_kvm.pgt, addr, prot, > &range); While this would work in this particular case, I don't think we should force all non-RAM accesses as device as the host may have reasons not to want this (e.g. accessing SRAM). Your first suggestions allows us to do just that, so it is preferable I think. Thanks, Quentin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
