Hey Marc, On Monday 22 Mar 2021 at 13:44:38 (+0000), Marc Zyngier wrote: > I can't say I'm thrilled with this. Actually, it is fair to say that I > don't like it at all! ;-) :-) > Copying whole structures with pointers that > make no sense at EL2 feels... wrong. And I don't disagree at all. I tried to keep this as small as possible as the series is already quite intrusive, but I certainly understand the concern. > As we discussed offline, the main reason for this infrastructure is > that the read_ctr macro directly uses arm64_ftr_reg_ctrel0.sys_val > when ARM64_MISMATCHED_CACHE_TYPE is set. Indeed that is the only reason. > One thing to realise is that with the protected mode, we can rely on > patching as there is no such thing as a "late" CPU. So by specialising > read_ctr when compiled for nVHE, we can just make it give us the final > value, provided that KVM's own __flush_dcache_area() is limited to > protected mode. > > Once this problem is solved, this whole patch can mostly go, as we are > left with exactly *two* u64 quantities to be populated, something that > we can probably do in kvm_sys_reg_table_init(). > > I'll post some patches later today to try and explain what I have in > mind. Sounds great, thank you very much for the help! Quentin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
