qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] should KVM or userspace be the one which decides what M


From: Marc Zyngier
Subject: Re: [Qemu-devel] should KVM or userspace be the one which decides what MIPIDR/affinity values to assign to vcpus?
Date: Wed, 10 Jun 2015 11:31:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

On 10/06/15 10:54, Igor Mammedov wrote:
> On Tue, 09 Jun 2015 15:35:21 +0100
> Marc Zyngier <address@hidden> wrote:
> 
>> On 09/06/15 15:01, Peter Maydell wrote:
>>> On 9 June 2015 at 15:00, Marc Zyngier <address@hidden> 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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]