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

Re: [PATCH] xen: arm: Don't use stop_cpu() in halt_this_cpu()


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Thu, 30 Jun 2022 07:16:40 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • 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=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Fd6wSu+qKNtqeVHQ1WoRks56L1+aBjZnNjDttmTySE=; b=maJCFoH5wHyQPJL0kr2Y21tyzgIxtuKH15Rx5AjdCRhBsWKRJFAMFHvFZ22dCS/J5fGxwwy2LxgIC0Oi0/vijrrDIw717bKJqza0KGagSsol7C4kohyWbH3Z30PHAe5/TT8XPKrRn2ekxuoFIH8tRP9vzZuDPmx47haaLajNqKp4ngG5x+iN8qQULajjRz/MpDRkXBmmgZrlCkJonDrTVCCg3zf9wh9mG+e49Q0E2UkMqmtJVMoTcfn9L91w0HuKedxjIEzFvc5xSufNE7xzBjNRf1hh8ZE0XfygdHxLNAl/RpEV0f+ExI9x05ehD6Jpy22JM72dU0EMiO9zMoaMCw==
  • 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Fd6wSu+qKNtqeVHQ1WoRks56L1+aBjZnNjDttmTySE=; b=j8OzeNtse7fTrC2nARrGQf1M5gVnYZ2AWaPOe0+QDSY99NIxpNoCqgK7BxeC4721vFmEsjXGVPfNYT8bIRtQ381uaC1G8tvcdZvguLgGkVHEWde9FXLhe1CUykX1a6/ud4o5WvtpC+RhnO+3zwfFV21akokTVgfOv3FeK5Cmpk/67G5pIpfN0nHTwVDskNgXpmG/YAwJLioh0JOjgfOKLzCWqiiPBokIgwbsnSb4+3SPgcS7aaR58EEBimoxsBGKRFDA4TQNA4MVKQheIP4RkhvpXKNlP80ZaUrn6lmBMAnMEtKZPyR5IDWnQySLXShlXycR5vKLeCqcEQaFrEM4cA==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=RXp8sCqtZxGs8+wadxtNiD9ZS7zxsndBX/lSTkI2oH8CiigKruoVlrZ1wUud4UiwSU+kw0ziCu9DU5PyUoQ5LVyN33v6hjxZ3OJ+rWNZfnMiDThNlxWHJUkSsswmDff3lczKtNE7Y/5Eb8kd1oqLFFqth7zAxIRRp1mO8UiTmXQn2HmQ4aqGLEA1Ts60zuMD7WPcLFCHLXOfyKu5c+7Qjh9EIuD+mimCGgq+8dbZu66q4Sjeq8G71LuH234Op/wLriLlgp6dAFsY5Loe7LkRB/C/FLKyZpgDEktnhlvHraSkPaOjZMtFWw5Gb0v39tyyGT0O09HDbJ91/1czv+/64w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DDWnN9wlTMiLOX5MIldeFxT0OXFMtwIS/AT31nx+IIb6cgdaQ3uWNZR6jyPAyZpN9uiJMeR4NTHGC8P6t+wVjOiCHNi8t1j0WgBCkEtwVYgSedvg4BBop5dCzi6+pvG22slkt7N0kbIPRwgy0eNqjJSP8wO3uBKrqWMuS6eAuh1Om4DimeMlr5bUuzZTXsOkyframNP6RAnLDrTa8+cDB8Azhc0Avrr7ULpv5RnbFtGnYE7O6vD7avXb/zS/ydfQuuXP2zL2zKzwLcN98P3SE4PAF+y8PJSmcUrE1RZc/G9gMz0nAYfBKgKD+HOSf9yVkY/OysLAcz/KgaFr4BI1Qw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Julien Grall <julien@xxxxxxx>, "dmitry.semenets@xxxxxxxxx" <dmitry.semenets@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Dmytro Semenets <dmytro_semenets@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Thu, 30 Jun 2022 07:16:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYhtUZsflIoxNljUat3Yz6tc+m161djY6AgAC0bgCAANP9AIABIMQAgAVAMgCAAJ5ngIAAlakAgADqBgA=
  • Thread-topic: [PATCH] xen: arm: Don't use stop_cpu() in halt_this_cpu()

Hi,

> On 29 Jun 2022, at 18:19, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Wed, 29 Jun 2022, Julien Grall wrote:
>> On 28/06/2022 23:56, Stefano Stabellini wrote:
>>>> The advantage of the panic() is it will remind us that some needs to be
>>>> fixed.
>>>> With a warning (or WARN()) people will tend to ignore it.
>>> 
>>> I know that this specific code path (cpu off) is probably not super
>>> relevant for what I am about to say, but as we move closer to safety
>>> certifiability we need to get away from using "panic" and BUG_ON as a
>>> reminder that more work is needed to have a fully correct implementation
>>> of something.
>> 
>> I don't think we have many places at runtime using BUG_ON()/panic(). They are
>> often used because we think Xen would not be able to recover if the condition
>> is hit.
>> 
>> I am happy to remove them, but this should not be at the expense to introduce
>> other potential weird bugs.
>> 
>>> 
>>> I also see your point and agree that ASSERT is not acceptable for
>>> external input but from my point of view panic is the same (slightly
>>> worse because it doesn't go away in production builds).
>> 
>> I think it depends on your target. Would you be happy if Xen continue to run
>> with potentially a fatal flaw?
> 
> Actually, this is an excellent question. I don't know what is the
> expected behavior from a safety perspective in case of serious errors.
> How the error should be reported and whether continuing or not is
> recommended. I'll try to find out more information.

I think there are 2 answers to this:
- as much as possible: those case must be avoided and it must be demonstrated 
that they are impossible and hence removed or turn the system in a failsafe 
mode so that actions can be handle (usually reboot after saving some data)
- in some cases this can be robustness code (more for security)

I think in our case that if we know that we are ending in a case where the 
system is unstable we should:
- stop the guest responsible for this (if a guest is the origin) or return an 
error to the guest and cancel the operation if suitable
- panic if this is internal or dom0

A warning informing that something not supported was done and ending in an 
unexpected behaviour is for sure not acceptable.

Cheers
Bertrand




 


Rackspace

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