[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
|