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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0ED5FC433DF for ; Sat, 13 Jun 2020 00:24:55 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id D661520739 for ; Sat, 13 Jun 2020 00:24:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="UMVjGDNQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D661520739 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjtyB-0000L8-Cm; Sat, 13 Jun 2020 00:24:23 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jjty9-0000L3-Ib for xen-devel@lists.xenproject.org; Sat, 13 Jun 2020 00:24:21 +0000 X-Inumbo-ID: 3940eb90-ad0c-11ea-b62a-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 3940eb90-ad0c-11ea-b62a-12813bfff9fa; Sat, 13 Jun 2020 00:24:20 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 283A820739; Sat, 13 Jun 2020 00:24:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592007859; bh=WtYzOAGm8F6NDuTj6ACYHcybAzqMxQYB6yVaeujxXg4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=UMVjGDNQNPjMH6f6ROfdzAO4EotnlBf2VCN+udDI481c5B5qjkpBQX6JqG/kWucua ZhrRLDORFSFoOJgY47b1nZLIv+TCtD3el6xMv11aLIIYrNVBFdel/VYz4w7lMccRpt 7xKAP7xKU4qKtsoFVbCFFNGaRTQnvk7kaN4vLDyg= Date: Fri, 12 Jun 2020 17:24:18 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Julien Grall Subject: Re: [PATCH 1/2] xen/arm: Convert runstate address during hypcall In-Reply-To: Message-ID: References: <8b450dddb2c855225c97741dce66453a80b9add2.1591806713.git.bertrand.marquis@arm.com> <74475748-e884-1e6e-633d-bf67d5ed32fe@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , Bertrand Marquis , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Jan Beulich , xen-devel , nd , Volodymyr Babchuk , Julien Grall Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Fri, 12 Jun 2020, Julien Grall wrote: > > Writing byte by byte is a different case. That is OK. In that case, the > > guest could see the state after 3 bytes written and it would be fine and > > consistent. > > Why? What does actually prevent a guest to see an in-between value? > > To give a concrete example, if the original value is 0xabc and you want to > write 0xdef. Why would the guest never see 0xabf or 0xaec? That is a good question, but the minimum granularity is 1 byte, so if current: 0xaabbcc new: 0xddeeff Can the guest see one of the following? 0xaabbff 0xaaeecc Yes, it can. I don't think it is a problem in this case because we only change 1 byte, so to continue with the example: current: 0xaabbcc new: 0xffbbcc So the only values the VM can see are either 0xaabbcc or 0xffbbcc. > > If this hadn't been the case, then yes, the existing code > > would also be buggy. > > > > So if we did the write with a memcpy, it would be fine, no need for > > atomics: > > > > memcpy(&guest_runstate->state_entry_time, > > &v->runstate.state_entry_time, > > XXX); > > > > > > The |= case is different: GCC could implement it in any way it likes, > > including going through a zero-write to any of the bytes in the word, or > > doing an addition then a subtraction. GCC doesn't make any guarantees. > > If we want guarantees we need to use atomics. > > Yes GCC can generate assembly for |= in any way it likes. But so does for > memcpy(). So I still don't understand why one would be fine for you and not > the other... It is down to the implementation of memcpy to guarantee that the only thing memcpy does is memory copies. memcpy doesn't specify whether it is going to use byte-copies or word-copies, but it should only do copies. If we have to write memcpy in assembly to make it so, so be it :-)