On Thu, Oct 22, 2026 at 04:43:27PM +0100, Marc Zyngier wrote:
> > +struct kvm_arch_guest_mmu *kvm_arch_get_guest_mmu(struct kvm *kvm)
> > +{
> > + int ret;
> > + struct kvm_arch_guest_mmu *mmu;
> > +
> > + guard(mutex)(&kvm->arch.config_lock);
> > +
> > + if (is_protected_kvm_enabled())
> > + return ERR_PTR(-EOPNOTSUPP);
>
> How does this compose with CCA?
This function would reject realm VMs once they're supported. If we
wanted to assign a CLA device to a realm VM, I think it would be managed
entirely outside the host:
* EL3 driver reconfigures the device's accesses to
physical memory (security state, memory encryption etc),
* RMM driver owns the PL2 registers to program the stage 2 MTC,
* the VM owns the rest of the device.
Lack of interrupts should make this assignment relatively simple.
> Can it be restricted to exclusively running VHE rather than also
> dealing with the lesser configurations?
Yes, I don't think we want to support any nVHE config at this point.
> > + mmu->vtcr = kvm->arch.mmu.vtcr;
> > + mmu->vttbr = kvm_get_vttbr(&kvm->arch.mmu);
> > + mmu->hcr = kvm_mmu_get_hcr(kvm, 0);
>
> How about the hcrx field in the structure?
It's 0 because HCRX doesn't seem to have bits relevant to MMU
translation, except maybe EnSDERR and EnSNERR that KVM doesn't set.
But it's not entirely clear which bits are relevant to this function,
because other possible users may access memory differently (eg. no
instruction fetch or CMO from a CLA device). Your suggestion below
should simplify this.
> > +
> > + return mmu;
> > +
> > +err_unpin_vmid:
> > + kvm_arm_pinned_vmid_put(kvm);
> > + return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(kvm_arch_get_guest_mmu);
>
> It really feels like this is a bit upside down. Since you are actively
> pinning the S2 MMU context, it should only be a matter of taking a
> reference on the kvm struct (just like KVM devices do), and handing
> off the kvm_s2_mmu structure, rather than copying things. When you're
> done with it, drop the reference.
OK, I'll update this. The reason for this copy was to keep a clear
separation between KVM and the CLA driver, so the driver wouldn't have
to use KVM internals like kvm_get_vttbr() and kvm_has_mte(). I think
those are the only ones at the moment.
> If there is a need to deal with a different value for HCR_EL2 (or
> anything else), it can be done in the code that makes use of it,
> rather than being in the KVM code.
Makes sense
Thanks,
Jean
