Re: [Qemu-devel] should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?

[Radim]

2015-06-10 11:31+0100, Marc Zyngier:
>On 10/06/15 10:54, Igor Mammedov wrote:
>> On Tue, 09 Jun 2015 15:35:21 +0100
>> Marc Zyngier <address@hidden> wrote:
>>> Indeed. I also missed the step that says "kernel is able to convert
>>> arbitrary MPIDR to vcpu_id in an efficient manner...". GICv3 is
>>> definitely going to require this.
>> x86 probably already has code that does this for APIC ID -> vcpu_id
> 
> Apparently not. kvm_irq_delivery_to_apic seems to iterate over the vcpus
> to find a match, and kvm_irq_delivery_to_apic_fast seems to rely on
> knowing some form of topology (and some more iteration).

kvm_irq_delivery_to_apic_fast optimizes APIC ID -> vcpu_id, by using
simple lookup arrays for various modes, with fallback to iteration for
broadcast and unlikely configurations.

Fast path only does iteration for multicast.  The APIC ID space is
sliced by 4(clustered xAPIC)/8(flat xAPIC)/16(x2APIC) APICs and any
number of APICs in a slice can be selected for delivery.
The guest can configure topology (xAPIC) or it is set by hardware
(x2APIC) and matches "real" topology only in rare cases.  ("Real"
topology is encoded in x2APIC ID by reserving bit ranges for "levels".)

> Overall, this looks awfully architecture specific, so it seems unlikely
> we can reuse that aspect.

Yes, the most that can be reused is an idea for a structure that gets
recomputed every time MPIDR -> vcpu_id mapping changes.

>                           I'm inclined to go for an rbtree mapping
> MPIDRs to vcpus. As this is likely to be on the fast path, I'd like this
> to me as lockless as possible though, which probably means that MPIDR
> would become RO as soon as any vcpu has started executing.

x86 KVM uses RCU protected structure for it, and even though APIC IDs
can be sparse, x86 prefers a single array.  (IDs usually aren't very
sparse, so a more complicated structure would be slower, harder to
handle, and take up more memory.)