From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40189) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZzvv-00071V-T1 for qemu-devel@nongnu.org; Wed, 08 May 2013 04:41:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZzvu-0002K0-HF for qemu-devel@nongnu.org; Wed, 08 May 2013 04:41:07 -0400 Received: from mx3-phx2.redhat.com ([209.132.183.24]:50178) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZzvu-0002Jn-97 for qemu-devel@nongnu.org; Wed, 08 May 2013 04:41:06 -0400 Date: Wed, 8 May 2013 04:41:02 -0400 (EDT) From: Paolo Bonzini Message-ID: <208981062.7629748.1368002462336.JavaMail.root@redhat.com> In-Reply-To: <518946A5.5080503@siemens.com> References: <29d07f201f1ae231f543e8884c0eb67278b105e1.1367849167.git.jan.kiszka@siemens.com> <5188F4FD.4000506@redhat.com> <51893933.4070508@siemens.com> <518946A5.5080503@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC][PATCH 10/15] memory: Rework sub-page handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Liu Ping Fan , qemu-devel , Andreas =?utf-8?Q?F=C3=A4rber?= > On 2013-05-07 19:26, Jan Kiszka wrote: > > Well, the alternative is to handle a sub-page dispatch (ie. calling into > > subpage_[ram_]read/write just like address_space_rw: take the necessary > > lock that protect mapping changes, look into the sub-page and pick up > > the target region, invoke memory_region_ref on it, perform the access > > and unref the region again. Slow, but that's how sub-pages are. And it > > only affects TCG. Hmm, or does your IOMMU core cache translations on a > > per-page base as well? > > OK, there is no translation caching in the memory core. So I will > preserve the dispatching functions of sub-pages, just like the term > "sub-page" - along with a comment why we depend on page granularity. Note that TCG will cache translations because the TLB entry is filled with the page after translation has taken place. In fact, this is the main change from Avi's series to mine, and a side-effect of centralizing the translation in address_space_translate. It shouldn't be a problem though, the TLB entry will point to the subpage and the compiled code will dispatch to it. Paolo