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

Re: [PATCH] xen/arm: Warn user on cpu errata 832075


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Wed, 21 Oct 2020 09:44:52 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qQRXNdeNhZJ+HP9AUpIowYt4o9AC864aJmcwQyxp1Aw=; b=QkCnZpJBIWhQJR59fJQbAHIEGSZx2RFO4uVFgQwoxFz/Rm1s3GDZhroSxoblgQz41x5YodxFTtaudiKNB0ntaZnKboueZrFZbeuAUE9cyrWUUfdm8ue1Yj3r3Zwqb1culP4aFb6LCTed3lIlNACuKJKHhoE7s/PD+4W8bcDB2gUQFY0mywFTijItYaXHbOpnRUl5PPv8o5rTxhRwf/XEflmxS3+Fjywsd2gg1JIY9ggMxzm0vYEkftAoMqFW+REGGfVO+jCB+rmG+B7Y6cZOvo2vo6jGy5eljqkqLdJwbAOfuWvBVggRvvpdRwpsieEKJWLAulkSu0BPqUdFxlyY2w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=baCO6QASQsu16i3fTmemANkcqOYKsLU1sfzm51GGTjz90H2LQePtdPKVMy0OZlk0oLsfYCFH/GnHyTRKzWuFYASkMwHdGupQXLMrTOw77JNe0BVuRetWZQ/Ic453WglOu3WZZl8WTXiHsmuGJctyUe8C6jLS3KPqcnLGGsPdqToCYhg1YS5D7FqVwU+K2OGX5zy9jKfypqHrxFIj03jdaniNf2N6lqloY8HHvkMWLiJacwF4esxjY1NFZCDn6uxKaFEMK+xqgkidlLtZnHdhpXqKlDvQ+T4bfrYtPGNM+z6UdLujhUZoGjxOxksKqqDo5QWrNjVzVt2B6CUHTnI8hg==
  • Authentication-results-original: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, "open list:X86" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 21 Oct 2020 09:45:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHWohbM+uoR14U9oEmwJFjy+kmnIqmW9/2AgABK1ACAABYOAIAAQVGAgADYZ4CAAITigIAI1nwAgAALgoA=
  • Thread-topic: [PATCH] xen/arm: Warn user on cpu errata 832075

Hi,

> On 21 Oct 2020, at 10:03, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi,
> 
> On 15/10/2020 19:05, Stefano Stabellini wrote:
>> On Thu, 15 Oct 2020, Bertrand Marquis wrote:
>>>> On 14 Oct 2020, at 22:15, Stefano Stabellini <sstabellini@xxxxxxxxxx> 
>>>> wrote:
>>>> 
>>>> On Wed, 14 Oct 2020, Julien Grall wrote:
>>>>> On 14/10/2020 17:03, Bertrand Marquis wrote:
>>>>>>> On 14 Oct 2020, at 12:35, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> On 14/10/2020 11:41, Bertrand Marquis wrote:
>>>>>>>> When a Cortex A57 processor is affected by CPU errata 832075, a guest
>>>>>>>> not implementing the workaround for it could deadlock the system.
>>>>>>>> Add a warning during boot informing the user that only trusted guests
>>>>>>>> should be executed on the system.
>>>>>>>> An equivalent warning is already given to the user by KVM on cores
>>>>>>>> affected by this errata.
>>>>>>>> 
>>>>>>>> Signed-off-by: Bertrand Marquis <bertrand.marquis@xxxxxxx>
>>>>>>>> ---
>>>>>>>> xen/arch/arm/cpuerrata.c | 21 +++++++++++++++++++++
>>>>>>>> 1 file changed, 21 insertions(+)
>>>>>>>> 
>>>>>>>> diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
>>>>>>>> index 6c09017515..8f9ab6dde1 100644
>>>>>>>> --- a/xen/arch/arm/cpuerrata.c
>>>>>>>> +++ b/xen/arch/arm/cpuerrata.c
>>>>>>>> @@ -240,6 +240,26 @@ static int enable_ic_inv_hardening(void *data)
>>>>>>>> 
>>>>>>>> #endif
>>>>>>>> 
>>>>>>>> +#ifdef CONFIG_ARM64_ERRATUM_832075
>>>>>>>> +
>>>>>>>> +static int warn_device_load_acquire_errata(void *data)
>>>>>>>> +{
>>>>>>>> +    static bool warned = false;
>>>>>>>> +
>>>>>>>> +    if ( !warned )
>>>>>>>> +    {
>>>>>>>> +        warning_add("This CPU is affected by the errata 832075.\n"
>>>>>>>> +                    "Guests without required CPU erratum 
>>>>>>>> workarounds\n"
>>>>>>>> +                    "can deadlock the system!\n"
>>>>>>>> +                    "Only trusted guests should be used on this
>>>>>>>> system.\n");
>>>>>>>> +        warned = true;
>>>>>>> 
>>>>>>> This is an antipattern, which probably wants fixing elsewhere as well.
>>>>>>> 
>>>>>>> warning_add() is __init.  It's not legitimate to call from a non-init
>>>>>>> function, and a less useless build system would have modpost to object.
>>>>>>> 
>>>>>>> The ARM_SMCCC_ARCH_WORKAROUND_1 instance asserts based on system state,
>>>>>>> but this provides no safety at all.
>>>>>>> 
>>>>>>> 
>>>>>>> What warning_add() actually does is queue messages for some point near
>>>>>>> the end of boot.  It's not clear that this is even a clever thing to do.
>>>>>>> 
>>>>>>> I'm very tempted to suggest a blanket change to printk_once().
>>>>>> 
>>>>>> If this is needed then this could be done in an other serie ?
>>>>> 
>>>>> The callback ->enable() will be called when a CPU is onlined/offlined. So 
>>>>> this
>>>>> is going to require if you plan to support CPU hotplugs or suspend resume.
>>>>> 
>>>>>> Would be good to keep this patch as purely handling the errata.
>>>> 
>>>> My preference would be to keep this patch small with just the errata,
>>>> maybe using a simple printk_once as Andrew and Julien discussed.
>>>> 
>>>> There is another instance of warning_add potentially being called
>>>> outside __init in xen/arch/arm/cpuerrata.c:
>>>> enable_smccc_arch_workaround_1. So if you are up for it, it would be
>>>> good to produce a patch to fix that too.
>>>> 
>>>> 
>>>>> In the case of this patch, how about moving the warning_add() in
>>>>> enable_errata_workarounds()?
>>>>> 
>>>>> By then we should now all the errata present on your platform. All CPUs
>>>>> onlined afterwards (i.e. runtime) should always abide to the set discover
>>>>> during boot.
>>>> 
>>>> If I understand your suggestion correctly, it would work for
>>>> warn_device_load_acquire_errata, because it is just a warning, but it
>>>> would not work for enable_smccc_arch_workaround_1, because there is
>>>> actually a call to be made there.
>>>> 
>>>> Maybe it would be simpler to use printk_once in both cases? I don't have
>>>> a strong preference either way.
>>> 
>>> I could do the following (in a serie of 2 patches):
>>> - modify enable_smccc_arch_workaround_1 to use printk_once with a
>>>   prefix/suffix “****” on each line printed (and maybe adapting print to 
>>> fit a
>>>   line length of 80)
>>> - modify my patch to do the print in enable_errata_workarounds using also
>>>   the prefix/suffix and printk_once
>>> 
>>> Please confirm that this strategy would fit everyone.
>> I think it is OK but if you are going to use printk_once in your patch
>> you might as well leave it in the .enable implementation.
>> Julien, what do you think?
> 
> Bertrand reminded me today that I forgot to answer the e-mail (sorry). I am 
> happy with using printk_once().

Shall i also keep the .enable implementation ?
At the end having:
 if ( cpus_have_cap(ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE) ) 
in enable_errata_workarounds is quite clean.

> 
> I am also wondering if we should also taint the hypervisor (via add_taint()). 
> This would be helpful if someone reports error on a Xen running on such 
> platform.

Good idea yes.
I will add that and removing the core from the security supported ones to my 
patch.

Cheers
Bertrand


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.