From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41504) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU4GK-0000T3-Ul for qemu-devel@nongnu.org; Mon, 24 Aug 2015 22:47:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZU4GH-0006Re-PV for qemu-devel@nongnu.org; Mon, 24 Aug 2015 22:47:00 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:36418) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZU4GH-0006RY-Iy for qemu-devel@nongnu.org; Mon, 24 Aug 2015 22:46:57 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id C390720947 for ; Mon, 24 Aug 2015 22:46:56 -0400 (EDT) Date: Mon, 24 Aug 2015 22:47:19 -0400 From: "Emilio G. Cota" Message-ID: <20150825024719.GC8880@flamenco> References: <1440375847-17603-1-git-send-email-cota@braap.org> <1440375847-17603-15-git-send-email-cota@braap.org> <55DA7B36.4030702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55DA7B36.4030702@redhat.com> Subject: Re: [Qemu-devel] [RFC 14/38] softmmu: add helpers to get ld/st physical addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: mttcg@greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, alex.bennee@linaro.org, Frederic Konrad On Sun, Aug 23, 2015 at 19:02:30 -0700, Paolo Bonzini wrote: > On 23/08/2015 17:23, Emilio G. Cota wrote: > > This will be used by the atomic instruction emulation code. > > Is this a fast path? If not, we can use the existing addend field and > convert the host address to a ram_addr_t easily. On x86 this is a fast path because the helper that goes before every store (aie_st_pre, p.17/38) checks whether any atomic operations on the store's cache line have been done before. The check is done using a bitmap (p.16/38); the input to the bitmap is the physical address with the last 6 bits shifted out (I'm assuming 2**6=64-byte cache lines). That said: How would the conversion via the addend field look like? If it's just an addition it might be cheap enough--and we wouldn't bloat CPUTLBEntry. Thanks, Emilio