[RFC v2] KVM: arm/arm64: optimize vSGI injection performance
zhaoxu
zhaoxu.35 at bytedance.com
Mon Sep 11 21:13:19 PDT 2023
On 2023/9/4 17:57, Marc Zyngier wrote:
> On Fri, 25 Aug 2023 02:58:11 +0100,
> Xu Zhao <zhaoxu.35 at bytedance.com> wrote:
[...]
>> - unsigned long affinity;
>> - int level0;
>> + u64 aff;
>>
>> - /*
>> - * Split the current VCPU's MPIDR into affinity level 0 and the
>> - * rest as this is what we have to compare against.
>> - */
>> - affinity = kvm_vcpu_get_mpidr_aff(vcpu);
>> - level0 = MPIDR_AFFINITY_LEVEL(affinity, 0);
>> - affinity &= ~MPIDR_LEVEL_MASK;
>> + /* aff3 - aff1 */
>> + aff = (((reg) & ICC_SGI1R_AFFINITY_3_MASK) >> ICC_SGI1R_AFFINITY_3_SHIFT) << 16 |
>> + (((reg) & ICC_SGI1R_AFFINITY_2_MASK) >> ICC_SGI1R_AFFINITY_2_SHIFT) << 8 |
>> + (((reg) & ICC_SGI1R_AFFINITY_1_MASK) >> ICC_SGI1R_AFFINITY_1_SHIFT);
>
> Here, you assume that you can directly map a vcpu index to an
> affinity. It would be awesome if that was the case. However, this is
> only valid at reset time, and userspace is perfectly allowed to change
> this mapping by writing to the vcpu's MPIDR_EL1.
>
> So this won't work at all if userspace wants to set its own specific
> CPU numbering.
>
> M.
>
Hi Marc,
Yes, i don't think too much about userspace can change MPIDR value, I
checked the source code of qemu, qemu create vcpu sequentially, so in
this case, vcpu_id is equivalent to vcpu_idx which means vcpu_id
represents the position in vcpu array.
These days, I'm still thinking about whether it is because of the
content related to future vcpu hot-plug feature that vcpu_id can be
modified, but now it seems that's not entirely the case.
I have read your latest patch and have been deeply inspired, and Thanks
for agreeing with this issue.
With Regards
Xu.
More information about the linux-arm-kernel
mailing list