Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e852e15b-88f3-ae15-2ffd-ee2e5ffa9bdf@hisilicon.com>
Date:   Mon, 29 May 2023 21:35:48 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.0.2
Subject: Re: [Question about gic vmovp cmd] Consider adding VINVALL after
 VMOVP
To:     Marc Zyngier <maz@kernel.org>
References: <ba387464-59d5-0639-1d05-84bb7e764231@hisilicon.com>
 <87v8gfo9rg.wl-maz@kernel.org>
 <7f07c54fb0a4448fbccce0f97cb5e512@hisilicon.com>
 <ec4cba70-ba6f-2de6-29e8-945b0f52ed88@hisilicon.com>
 <86leh9di4l.wl-maz@kernel.org>
 <f1f7296dc4fa429d97f7a48c8c4552ae@hisilicon.com>
CC:     <linux-kernel@vger.kernel.org>
From:   wangwudi <wangwudi@hisilicon.com>
In-Reply-To: <f1f7296dc4fa429d97f7a48c8c4552ae@hisilicon.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Precedence: bulk


在 2023/5/29 21:24, wangwudi 写道:
> 
> 
> -----邮件原件-----
> 发件人: Marc Zyngier [mailto:maz@kernel.org] 
> 发送时间: 2023年5月27日 21:22
> 收件人: wangwudi <wangwudi@hisilicon.com>
> 抄送: linux-kernel@vger.kernel.org
> 主题: Re: [Question about gic vmovp cmd] Consider adding VINVALL after VMOVP
> 
> On Sat, 27 May 2023 10:51:50 +0100,
> wangwudi <wangwudi@hisilicon.com> wrote:
>>
>>
>>
>> 在 2023/5/27 16:56, wangwudi 写道:
>>>
>>>
>>> -----邮件原件-----
>>> 发件人: Marc Zyngier [mailto:maz@kernel.org]
>>> 发送时间: 2023年5月26日 15:03
>>> 收件人: wangwudi <wangwudi@hisilicon.com>
>>> 抄送: linux-kernel@vger.kernel.org
>>> 主题: Re: [Question about gic vmovp cmd] Consider adding VINVALL after 
>>> VMOVP
>>>
>>> On Fri, 26 May 2023 07:04:34 +0100,
>>> wangwudi <wangwudi@hisilicon.com> wrote:
>>>>
>>>> Hi Marc,
>>>>
>>>> During vpe migration, VMOVP needs to be executed.
>>>> If the vpe is migrated for the first time, especially before it is 
>>>> scheduled for the first time, there may be some unusual hanppens 
>>>> over kexec.
>>>
>>> What may happen?
>>
>> Actually, I'm not sure.
> 
> Then what is that all for?
> 
>>
>>>
>>>> We might consider adding a VINVALL cmd after VMOVP to increase 
>>>> robustness.
>>>
>>> What are you trying to guarantee by adding this? From a performance 
>>> perspective, this is terrible as you're forcing the ITS to drop its 
>>> caches and reload everything, making the interrupt latency far worse 
>>> than what it should be on each and every vcpu migration.
>>
>> Agree, this reduces performance.
>>
>>>
>>> We already issue a VINVALL when a VPE is mapped. Why would you need 
>>> anything else?
>>>
>>
>> It is just for robustness, like the VINALL when a VPE is mapped.
> 
> The VINVALL at the point a VPE is mapped serves a purpose: to invalidate the caches from a previous instance of a VPE with the same VPEID. It's not for "robustness" but for *correctness*.
> 
>>
>>>>
>>>> @@ -1327,6 +1327,7 @@ static void its_send_vmovp(struct its_vpe 
>>>> *vpe)
>>>>
>>>>                 desc.its_vmovp_cmd.col = &its->collections[col_id];
>>>>                 its_send_single_vcommand(its, its_build_vmovp_cmd, 
>>>> &desc);
>>>> +               its_send_vinvall(its, vpe);
>>>>         }
>>>>
>>>> Do you think it's all right?
>>>
>>> I think this is pretty bad. If your HW requires this, then we can 
>>> add it as a workaround for your particular platform, but in general, 
>>> this is not needed.
>>
>> Got it, you are right :-).
> 
> May I suggest that in the future, you post patches that actually serve a real purpose and avoid wasting people's time? Your company employs a bunch of good people, some of which are pretty knowledgeable when it comes to the GIC. Please consult with them before posting such thing.
> 

Okay, thank you for your patience.

> Thanks,
> 
> 	M.
> 
> --
> Without deviation from the norm, progress is not possible.