On Tue, 05 May 2020 18:59:56 +0100 Marc Zyngier <maz@xxxxxxxxxx> wrote: Hi James, > > But accessing VTCR is why the stage2_dissolve_p?d() stuff still > > needs the kvm pointer, hence the backreference... it might be neater > > to push the vtcr properties into kvm_s2_mmu that way you could drop > > the kvm backref, and only things that take vm-wide locks would need > > the kvm pointer. But I don't think it matters. > > That's an interesting consideration. I'll have a look. So I went back on forth on this (the joys of not sleeping), and decided to keep the host's VTCR_EL2 where it is today (in the kvm structure). Two reasons for this: - This field is part of the host configuration. Moving it to the S2 MMU structure muddies the waters a bit once you start nesting, as this structure really describes an inner guest context. It has its own associated VTCR, which lives in the sysreg file, and it becomes a bit confusing to look at a kvm_s2_mmu structure in isolation and wonder whether this field is directly related to the PTs in this structure, or to something else. - It duplicates state. If there is one thing I have learned over the past years, it is that you should keep a given state in one single place at all times. Granted, VTCR doesn't change over the lifetime of the guest, but still. I guess the one thing that would push me to the other side of the debate is if we can show that the amount of pointer chasing generated by the mmu->kvm->vtcr dance is causing actual performance issues. So far, I haven't measured such an impact. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
