On Tue, 05 May 2020 18:59:56 +0100
Marc Zyngier <[email protected]> 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
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
