From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za2Dz-0000Z8-7K for qemu-devel@nongnu.org; Thu, 10 Sep 2015 09:49:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za2Dv-0007NO-4B for qemu-devel@nongnu.org; Thu, 10 Sep 2015 09:49:15 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:36884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za2Du-0007Mj-UA for qemu-devel@nongnu.org; Thu, 10 Sep 2015 09:49:11 -0400 Received: by wicfx3 with SMTP id fx3so23988210wic.0 for ; Thu, 10 Sep 2015 06:49:10 -0700 (PDT) References: <1440375847-17603-1-git-send-email-cota@braap.org> <1440375847-17603-14-git-send-email-cota@braap.org> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <1440375847-17603-14-git-send-email-cota@braap.org> Date: Thu, 10 Sep 2015 14:49:07 +0100 Message-ID: <87y4ge8jvw.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC 13/38] cputlb: add physical address to CPUTLBEntry List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Emilio G. Cota" Cc: mttcg@listserver.greensocs.com, mark.burton@greensocs.com, a.rigo@virtualopensystems.com, qemu-devel@nongnu.org, guillaume.delbergue@greensocs.com, pbonzini@redhat.com, Frederic Konrad Emilio G. Cota writes: > Having the physical address in the TLB entry will allow us > to portably obtain the physical address of a memory access, > which will prove useful when implementing a scalable emulation > of atomic instructions. > > Signed-off-by: Emilio G. Cota > --- > cputlb.c | 1 + > include/exec/cpu-defs.h | 7 ++++--- > 2 files changed, 5 insertions(+), 3 deletions(-) > > diff --git a/cputlb.c b/cputlb.c > index d1ad8e8..1b3673e 100644 > --- a/cputlb.c > +++ b/cputlb.c > @@ -409,6 +409,7 @@ void tlb_set_page_with_attrs(CPUState *cpu, target_ulong vaddr, > } else { > te->addr_write = -1; > } > + te->addr_phys = paddr; > } > > /* Add a new TLB entry, but without specifying the memory > diff --git a/include/exec/cpu-defs.h b/include/exec/cpu-defs.h > index 5093be2..ca9c85c 100644 > --- a/include/exec/cpu-defs.h > +++ b/include/exec/cpu-defs.h > @@ -60,10 +60,10 @@ typedef uint64_t target_ulong; > /* use a fully associative victim tlb of 8 entries */ > #define CPU_VTLB_SIZE 8 > > -#if HOST_LONG_BITS == 32 && TARGET_LONG_BITS == 32 > -#define CPU_TLB_ENTRY_BITS 4 > -#else > +#if TARGET_LONG_BITS == 32 > #define CPU_TLB_ENTRY_BITS 5 > +#else > +#define CPU_TLB_ENTRY_BITS 6 > #endif > > /* TCG_TARGET_TLB_DISPLACEMENT_BITS is used in CPU_TLB_BITS to ensure that > @@ -110,6 +110,7 @@ typedef struct CPUTLBEntry { > target_ulong addr_read; > target_ulong addr_write; > target_ulong addr_code; > + target_ulong addr_phys; > /* Addend to virtual address to get host address. IO accesses > use the corresponding iotlb value. */ > uintptr_t addend; So this ends up expanding the TLB entry size and either pushing the overall TLB up in size or reducing the number of entries per-TLB so I think we would need some numbers on the impact on performance this has. As far as I can see you never use this value in this patch series so maybe this is worth deferring for now? -- Alex Bennée