include/exec/cpu-common.h | 6 ------ 1 file changed, 6 deletions(-)
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(-)
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 */
--
2.7.4
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
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
© 2016 - 2024 Red Hat, Inc.