All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: nd@arm.com, xen-devel@lists.xen.org
Subject: Re: [PATCH 3/4] xen/arm: set vpidr on the pcpu where the vcpu will run
Date: Fri, 16 Feb 2018 20:45:56 +0000	[thread overview]
Message-ID: <a77a3058-c1f2-3d5e-e9b4-7daec6bae89d@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1802161220100.5392@sstabellini-ThinkPad-X260>



On 16/02/2018 20:31, Stefano Stabellini wrote:
> On Fri, 16 Feb 2018, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 15/02/18 23:16, Stefano Stabellini wrote:
>>> On big.LITTLE systems not all cores have the same midr. Instead of
>>> initializing the vpidr to the boot cpu midr, set it to the value of the
>>> midr of the pcpu where the vcpu will run.
>>>
>>> This way, assuming that the vcpu has been created with the right pcpu
>>> affinity, the guest will be able to read the right vpidr value, matching
>>> the one of the physical cpu.
>>>
>>> Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
>>> ---
>>>    xen/arch/arm/domain.c | 19 ++++++++++++++++---
>>>    1 file changed, 16 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
>>> index 532e824..280125f 100644
>>> --- a/xen/arch/arm/domain.c
>>> +++ b/xen/arch/arm/domain.c
>>> @@ -315,6 +315,22 @@ static void schedule_tail(struct vcpu *prev)
>>>    static void continue_new_vcpu(struct vcpu *prev)
>>>    {
>>>        current->arch.actlr = READ_SYSREG32(ACTLR_EL1);
>>> +    /*
>>> +     * Default the virtual ID to match the physical.
>>> +     *
>>> +     * In case the big.LITTLE systems, a guest should be created with
>>> +     * cpu affinity set so that all vcpus run on the same kind of pcpus.
>>> +     * Warn if it is not the case.
>>
>> continue_new_vcpu is only called once at domain creation. So this looks
>> pointless to check that here and probably in ctxt_switch_to.
>>
>> But I don't want to see such check at every context switch. This is expensive
>> and we should not impact all the platforms for the benefits of an unsafe
>> configuration.
>>
>> If you really want to do that, then it should only be done when the vCPU is
>> migrating. That will reduce a lot the performance impact.
> 
> I don't want a check for every context switch either. I added it here
> because continue_new_vcpu is only called once per vcpu at domain
> creation -- it is a one time check. vcpus are supposed to be pinned (or
> cpu affinity specified) anyway, so I thought I wouldn't add the check in
> vcpu_migrate too. In any case, I am also happy to remove the check
> completely, as we have already warned the user enough.
If you agree that continue_new_vcpu is only called once per vCPU. Then I 
am not sure to understand the purpose of the check. What are you trying 
to warn the user with that?

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-02-16 20:45 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15 23:16 [PATCH 0/4] unsafe big.LITTLE support Stefano Stabellini
2018-02-15 23:16 ` [PATCH 1/4] xen/arm: Park CPUs with a MIDR different from the boot CPU Stefano Stabellini
2018-02-15 23:16   ` [PATCH 2/4] xen/arm: read ACTLR on the pcpu where the vcpu will run Stefano Stabellini
2018-02-16 10:45     ` Julien Grall
2018-02-17  1:39       ` Stefano Stabellini
2018-02-15 23:16   ` [PATCH 3/4] xen/arm: set vpidr " Stefano Stabellini
2018-02-16 11:01     ` Julien Grall
2018-02-16 20:31       ` Stefano Stabellini
2018-02-16 20:45         ` Julien Grall [this message]
2018-02-16 20:59           ` Stefano Stabellini
2018-02-16 21:09             ` Julien Grall
2018-02-16 21:34               ` Stefano Stabellini
2018-02-16 21:39                 ` Julien Grall
2018-02-15 23:17   ` [PATCH 4/4] xen/arm: update the docs about heterogeneous computing Stefano Stabellini
2018-02-16 11:22     ` Julien Grall
2018-02-16 20:50       ` Stefano Stabellini
2018-02-16 21:01         ` Julien Grall
2018-02-16 21:15           ` Stefano Stabellini
2018-02-16 21:57             ` Julien Grall
2018-02-17  0:31               ` Stefano Stabellini
2018-02-17 10:23                 ` Julien Grall
2018-02-19 20:28                   ` Stefano Stabellini
2018-02-19 20:47                     ` Julien Grall
2018-02-19 21:05                       ` Stefano Stabellini
2018-02-19 21:17                         ` Julien Grall
2018-02-19 21:34                           ` Stefano Stabellini
2018-02-16 11:58 ` [PATCH 0/4] unsafe big.LITTLE support Julien Grall
2018-02-16 22:07   ` Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a77a3058-c1f2-3d5e-e9b4-7daec6bae89d@arm.com \
    --to=julien.grall@arm.com \
    --cc=nd@arm.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.