Re: [PATCH 03/26] KVM: arm64: Factor out stage 2 page table data from struct kvm

Marc Zyngier
2020-05-06T09:30:37Z

On Tue, 05 May 2020 18:59:56 +0100
Marc Zyngier <maz@kernel.org> 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...