diff mbox series

Make ram_addr_t 64 bits unconditionally

Message ID 1613739127-61825-1-git-send-email-bmeng.cn@gmail.com (mailing list archive)
State New, archived
Headers show
Series Make ram_addr_t 64 bits unconditionally | expand

Commit Message

Bin Meng Feb. 19, 2021, 12:52 p.m. UTC 
From: Bin Meng <bin.meng@windriver.com>

Currently machine->ram_size is a ram_addr_t, whose size is 64 bits
if either (a) the host is 64 bits or (b) CONFIG_XEN_BACKEND is
enabled, so it's effectively only 32 bits on 32-bit-not-x86.

commit 4be403c8158e ("Make target_phys_addr_t 64 bits unconditionally")
did the change for target_phys_addr_t which is now hwaddr to be 64 bits
unconditionally. Let's do the same to ram_addr_t.

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Bin Meng <bin.meng@windriver.com>
---

 include/exec/cpu-common.h | 6 ------
 1 file changed, 6 deletions(-)

Comments

Peter Maydell Feb. 19, 2021, 1:11 p.m. UTC | #1 
On Fri, 19 Feb 2021 at 12:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> From: Bin Meng <bin.meng@windriver.com>
>
> Currently machine->ram_size is a ram_addr_t, whose size is 64 bits
> if either (a) the host is 64 bits or (b) CONFIG_XEN_BACKEND is
> enabled, so it's effectively only 32 bits on 32-bit-not-x86.
>
> commit 4be403c8158e ("Make target_phys_addr_t 64 bits unconditionally")
> did the change for target_phys_addr_t which is now hwaddr to be 64 bits
> unconditionally. Let's do the same to ram_addr_t.
>
> Suggested-by: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> --

As noted on the other thread, I like this in principle,
but I think it would be interesting to check whether it
has a measurable perf impact on the non-x86-32-bit hosts
that it affects.

-- PMM
Bin Meng Feb. 28, 2021, 5:13 a.m. UTC | #2 
Hi Peter,

On Fri, Feb 19, 2021 at 9:11 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 19 Feb 2021 at 12:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > From: Bin Meng <bin.meng@windriver.com>
> >
> > Currently machine->ram_size is a ram_addr_t, whose size is 64 bits
> > if either (a) the host is 64 bits or (b) CONFIG_XEN_BACKEND is
> > enabled, so it's effectively only 32 bits on 32-bit-not-x86.
> >
> > commit 4be403c8158e ("Make target_phys_addr_t 64 bits unconditionally")
> > did the change for target_phys_addr_t which is now hwaddr to be 64 bits
> > unconditionally. Let's do the same to ram_addr_t.
> >
> > Suggested-by: Peter Maydell <peter.maydell@linaro.org>
> > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > --
>
> As noted on the other thread, I like this in principle,
> but I think it would be interesting to check whether it
> has a measurable perf impact on the non-x86-32-bit hosts
> that it affects.

What measures should we take to move this on? I don't have any access
to non-x86 32-bit hosts.

Regards,
Bin
diff mbox series

Patch

diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
index 5a0a2d9..c36904d 100644
--- a/include/exec/cpu-common.h
+++ b/include/exec/cpu-common.h
@@ -32,15 +32,9 @@  enum device_endian {
 #endif
 
 /* address in the RAM (different from a physical address) */
-#if defined(CONFIG_XEN_BACKEND)
 typedef uint64_t ram_addr_t;
 #  define RAM_ADDR_MAX UINT64_MAX
 #  define RAM_ADDR_FMT "%" PRIx64
-#else
-typedef uintptr_t ram_addr_t;
-#  define RAM_ADDR_MAX UINTPTR_MAX
-#  define RAM_ADDR_FMT "%" PRIxPTR
-#endif
 
 /* memory API */