Re: [PATCH v5 12/41] KVM: arm64: Use kernel-space partid configuration for hypercalls

Marc Zyngier
2026-03-02T18:15:39Z

On Tue, 24 Feb 2026 17:56:51 +0000,
Ben Horgan <ben.horgan@arm.com> wrote:
>
> On nVHE systems whether or not MPAM is enabled, EL2 continues to use
> partid-0 for hypercalls, even when the host may have configured its kernel
> threads to use a different partid. 0 may have been assigned to another
> task. Copy the EL1 MPAM register to EL2. This ensures hypercalls use the
> same partid as the kernel thread does on the host.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
> Tested-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Tested-by: Peter Newman <peternewman@google.com>
> Tested-by: Zeng Heng <zengheng4@huawei.com>
> Reviewed-by: Shaopeng Tan <tan.shaopeng@jp.fujitsu.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Changes since v2:
> Use mask
> Use read_sysreg_el1 to cope with hvhe
>
> Changes since v3:
> Set MPAM2_EL2.MPAMEN to 1 as we rely on that before and after
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..80e71eeddc03 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -638,6 +638,15 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
> unsigned long hcall_min = 0;
> hcall_t hfn;
>
> + if (system_supports_mpam()) {
> + u64 mask = MPAM1_EL1_PARTID_D | MPAM1_EL1_PARTID_I |
> + MPAM1_EL1_PMG_D | MPAM1_EL1_PMG_I;
> + u64 val = MPAM2_EL2_MPAMEN | (read_sysreg_el1(SYS_MPAM1) & mask);
> +
> + write_sysreg_s(val, SYS_MPAM2_EL2);
> + isb();
> + }
> +
> /*
> * If pKVM has been initialised then reject any calls to the
> * early "privileged" hypercalls. Note that we cannot reject

It is extremely debatable whether this is desirable:

- pKVM really shouldn't be influenced by what the host does, which
means reserving PARTIDs and indirecting what the host sees. This can
be deferred until pKVM is actually useful upstream.

- repeatedly hammering that register plus an ISB on the hot path of a
hypercall is a sure way to make things worse than they should be,
and that should be fixed now.

Do you really expect the EL1 settings to change on a regular basis? If
so, I'd rather you use a specific host hypercall, or even a trap to
propagate the EL1 configuration. If not, just set it as part of the
KVM init and be done with it.

Thanks,

M.

--
Without deviation from the norm, progress is not possible.