From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1euIDv-0005E2-Ca for qemu-devel@nongnu.org; Fri, 09 Mar 2018 08:38:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1euIDu-0000KV-Jk for qemu-devel@nongnu.org; Fri, 09 Mar 2018 08:38:15 -0500 Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230]:38334) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1euIDu-0000KD-DY for qemu-devel@nongnu.org; Fri, 09 Mar 2018 08:38:14 -0500 Received: by mail-oi0-x230.google.com with SMTP id h23so6974933oib.5 for ; Fri, 09 Mar 2018 05:38:14 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1518893216-9983-1-git-send-email-eric.auger@redhat.com> <1518893216-9983-5-git-send-email-eric.auger@redhat.com> From: Peter Maydell Date: Fri, 9 Mar 2018 13:37:53 +0000 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH v9 04/14] hw/arm/smmuv3: Skeleton List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Auger Eric Cc: eric.auger.pro@gmail.com, qemu-arm , QEMU Developers , Prem Mallappa , Alex Williamson , Tomasz Nowicki , "Michael S. Tsirkin" , Christoffer Dall , Bharat Bhushan , Jean-Philippe Brucker , "Edgar E. Iglesias" , linuc.decode@gmail.com, Peter Xu On 9 March 2018 at 13:19, Auger Eric wrote: > On 08/03/18 15:27, Peter Maydell wrote: >> Consider specifically catching 8-byte accesses to non-64-bit registers? >> This is CONSTRAINED UNPREDICTABLE (see spec section 6.2), and "one >> of the registers is read/written and other half is RAZ/WI" is permitted >> behaviour, but it does mean you need to be a little careful about not >> letting the top 32 bits of val become non-zero for the 32-bit register >> codepaths. Logging bad 64-bit accesses as LOG_GUEST_ERROR and making >> them RAZ/WI might be nicer for guest software developers. > > I moved to ops with attrs and if a 64-bit access is attempted on > something not a 64b reg base, I return an error + log a guest error. Ah, you probably don't want to return MEMTX_ERROR, because that becomes a guest CPU external-abort exception. An abort is listed as one of the permitted constrained-unpredictable behaviours for bad 64-bit accesses, but there is a note that "strongly recommends" not to abort for cases where the registers might be used by software associated with lower exception levels. Rather than trying to decide which registers do or don't get to return MEMTX_ERROR, it's probably easier just to RAZ/WI and return MEMTX_OK. (We had to fix a bug like this in the gicv3 in commits f1945632b43e3 and 0cf09852015e when we started making MEMTX_ERROR generate aborts, though in that case the spec is more definite that abort is not a permitted behaviour.) thanks -- PMM