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

[Ben Horgan <ben.horgan@arm.com>]

Hi Marc,

On 3/2/26 18:15, Marc Zyngier wrote:
> 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.

Would a read modify write be preferable?

> 
> Do you really expect the EL1 settings to change on a regular basis? If

The MPAM EL1 partid/pmg configuration is kept in sync with the MPAM EL0
partid/pmg configuration (see mpam_thread_switch() in patch 4) which
means that the EL1 configuration will change whenever the user changes
the EL0 configuration.

> 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

I think this ends up trapping context switch which doesn't seem any more
desirable.

> KVM init and be done with it.

If we just forego this patch then the MPAM configuration for el2 as
initially configured, partid=0, pmg=0 would be used. This is also the
default for requestors that aren't MPAM aware or unconfigured, like
trusted firmware, its, gpu. VHE mode (required from 8.1?) should be
available in any platform that has MPAM (introduced in 8.4, back
portable to 8.3) and so using nvhe with MPAM seems unlikely and the
amount of data should be small enough. That leaves pKVM for which,
perhaps, doing nothing is also the correct answer.

What do you think? Drop, read modify write, or something else?

> 
> Thanks,
> 
> 	M.
> 

Thanks,

Ben