On 10/06/15 10:54, Igor Mammedov wrote: > On Tue, 09 Jun 2015 15:35:21 +0100 > Marc Zyngier <marc.zyngier@xxxxxxx> wrote: > >> On 09/06/15 15:01, Peter Maydell wrote: >>> On 9 June 2015 at 15:00, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >>>> >>>> Yeah, what I had in mind was something along the lines of: >>>> - kernel computes its "default MPDIR" >>>> - kernel exposes a new capability "KVM_ARM_ALLOW_MPIDR_OVERRIDE" (or >>>> something along those lines) >>>> - userspace does the right thing. >>> >>> You forgot the "???" step :-) >> >> 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). Overall, this looks awfully architecture specific, so it seems unlikely we can reuse that aspect. 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. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
