From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 28854C636D3 for ; Mon, 30 Jan 2023 22:11:52 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.487248.754826 (Exim 4.92) (envelope-from ) id 1pMcNB-0005pr-Af; Mon, 30 Jan 2023 22:11:33 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 487248.754826; Mon, 30 Jan 2023 22:11:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pMcNB-0005pk-7c; Mon, 30 Jan 2023 22:11:33 +0000 Received: by outflank-mailman (input) for mailman id 487248; Mon, 30 Jan 2023 22:11:32 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pMcNA-0005pe-Bu for xen-devel@lists.xenproject.org; Mon, 30 Jan 2023 22:11:32 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1pMcN9-00066a-IM; Mon, 30 Jan 2023 22:11:31 +0000 Received: from gw1.octic.net ([88.97.20.152] helo=[10.0.1.102]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pMcN9-0005tS-CI; Mon, 30 Jan 2023 22:11:31 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject: From:References:Cc:To:MIME-Version:Date:Message-ID; bh=W0g9OHm+SaI85wEZniYACedt3YZ8DzwJcSmRkBFvQuo=; b=3jdS8nomV2jVFDhv7C76GIuJBl tndVjl4Je7Hs9dYP46mf4cPl4vhVc9x2z/ksi02/24VNWBCqXH7XuKWhv72huyw+/H3mKhWEo3A0T VLpmkniEoG/JUILabwSeAPWfZYnf18GXawBfzZI0IDQL6E9ogoB+t2nYOXgSLsmR2g2M=; Message-ID: <8c0bce0b-05bd-5f4b-7b66-f6668ad34899@xen.org> Date: Mon, 30 Jan 2023 22:11:29 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: Oleksii , xen-devel@lists.xenproject.org Cc: Jan Beulich , Andrew Cooper , Stefano Stabellini , Gianluca Guida , Bob Eshleman , Alistair Francis , Connor Davis , Bobby Eshleman References: <652289358975cf869e4bc0a6a70e3aba7bd2fbf6.1674818705.git.oleksii.kurochko@gmail.com> <27469e861d4777af42b84fb637b24ed47a187647.camel@gmail.com> From: Julien Grall Subject: Re: [PATCH v2 07/14] xen/riscv: introduce exception context In-Reply-To: <27469e861d4777af42b84fb637b24ed47a187647.camel@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 30/01/2023 11:40, Oleksii wrote: > On Fri, 2023-01-27 at 14:54 +0000, Julien Grall wrote: >> Hi Oleksii, >> >> On 27/01/2023 13:59, Oleksii Kurochko wrote: >>> +static inline void wfi(void) >>> +{ >>> +    __asm__ __volatile__ ("wfi"); >> >> I have starred at this line for a while and I am not quite too sure >> to >> understand why we don't need to clobber the memory like we do on Arm. >> > I don't have an answer. The code was based on Linux so... Hmmm ok. It would probably wise to understand how code imported from Linux work so we don't end up introducing bug when calling such function. From your current use in this patch, I don't expect any issue. That may chance for the others use. >> FWIW, Linux is doing the same, so I guess this is correct. For Arm we >> also follow the Linux implementation. >> >> But I am wondering whether we are just too strict on Arm, RISCv >> compiler >> offer a different guarantee, or you expect the user to be responsible >> to >> prevent the compiler to do harmful optimization. >> >>> +/* >>> + * panic() isn't available at the moment so an infinite loop will >>> be >>> + * used temporarily. >>> + * TODO: change it to panic() >>> + */ >>> +static inline void die(void) >>> +{ >>> +    for( ;; ) wfi(); >> >> Please move wfi() to a newline. > Thanks. > > I thought that it is fine to put into one line in this case but I'll > move it to a newline. It's fine. I am not aware of any place in Xen where we would combine the lines. Also, you want a space after 'for'. Cheers, -- Julien Grall