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

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

On 3/3/26 16:33, Ben Horgan wrote:
> 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?

As discussed offline, I'll drop this patch.

Thanks,

Ben