From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1161094AbcIGLXs (ORCPT <rfc822;w@1wt.eu>);
        Wed, 7 Sep 2016 07:23:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43954 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1161077AbcIGLXq (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 7 Sep 2016 07:23:46 -0400
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Julien Grall <julien.grall@arm.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
        xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
        x86@kernel.org, Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        David Vrabel <david.vrabel@citrix.com>,
        Juergen Gross <jgross@suse.com>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Jan Beulich <JBeulich@suse.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>,
        Steve Capper <Steve.Capper@arm.com>, Wei Chen <Wei.Chen@arm.com>,
        Kaly Xin <Kaly.Xin@arm.com>
Subject: Re: [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping
References: <1469536228-29932-1-git-send-email-vkuznets@redhat.com>
        <1469536228-29932-4-git-send-email-vkuznets@redhat.com>
        <258e8e2e-29c4-1a88-2271-581f2ea59ec2@arm.com>
        <87d1kiwum9.fsf@vitty.brq.redhat.com>
        <alpine.DEB.2.10.1609051213470.4105@sstabellini-ThinkPad-X260>
        <87d1khv38p.fsf@vitty.brq.redhat.com>
        <alpine.DEB.2.10.1609061104140.4105@sstabellini-ThinkPad-X260>
        <87d1kgt6vs.fsf@vitty.brq.redhat.com>
        <beb1a4d7-0737-049a-4e74-5c6a95fe8b43@arm.com>
Date: Wed, 07 Sep 2016 13:23:41 +0200
In-Reply-To: <beb1a4d7-0737-049a-4e74-5c6a95fe8b43@arm.com> (Julien Grall's
        message of "Wed, 7 Sep 2016 10:35:19 +0100")
Message-ID: <878tv4t0le.fsf@vitty.brq.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 07 Sep 2016 11:23:46 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Julien Grall <julien.grall@arm.com> writes:

> Hi Vitaly,
>
> On 07/09/2016 10:07, Vitaly Kuznetsov wrote:
>> Stefano Stabellini <sstabellini@kernel.org> writes:
>>> I don't know that much about cpuid, but the virtual MPIDR is constructed
>>> from the vcpu id right now:
>>>
>>>     v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
>>>
>>>     [...]
>>>
>>>     static inline register_t vcpuid_to_vaffinity(unsigned int vcpuid)
>>>     {
>>>         register_t vaff;
>>>
>>>         vaff = (vcpuid & 0x0f) << MPIDR_LEVEL_SHIFT(0);
>>>         vaff |= ((vcpuid >> 4) & MPIDR_LEVEL_MASK) << MPIDR_LEVEL_SHIFT(1);
>>>
>>>         return vaff;
>>>     }
>>
>> This could work but only in case there is a way to get MPIDR for _other_
>> cpu (e.g. CPU0 needs to get MPIDR of CPU1 when CPU1 is not yet runnning)
>> or we'll have to change the machinery of how we bring up secondary CPUs
>> - e.g. CPUn starts, writes its id somewhere and 'hangs' waiting for CPU0
>> to set up event channels.
>
> You can get the MPIDR from both the device tree and ACPI. The firmware
> table is parsed at boot time and the value is stored in
> cpu_logical_map().

Good,

in this case we can easily do the same trick we did for x86 and we
don't need to change the way secondary CPUs are strarted.

BTW, were you able to try the patch I suggested? In my opinion it would
be preferable to fix the immediate SMP issue now and play with MPIDR
info later.

>
> Regards,

-- 
  Vitaly