On 2023/9/4 17:57, Marc Zyngier wrote:
On Fri, 25 Aug 2023 02:58:11 +0100,
Xu Zhao <zhaoxu.35@xxxxxxxxxxxxx> 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.
