On Fri, 19 Feb 2021 at 13:31, Philippe Mathieu-Daudé <f4...@amsat.org> wrote:
>
> Hi Peter,
>
> [+John/Richards/Paolo/Gueunter]
>
> On 2/18/21 3:22 PM, Peter Maydell wrote:
> > On Thu, 18 Feb 2021 at 14:07, Bin Meng <bmeng...@gmail.com> wrote:
> >> On Thu, Feb 18, 2021 at 9:26 PM Peter Maydell <peter.mayd...@linaro.org>
> >> wrote:
> >>> Fails to compile, 32 bit hosts:
> >>>
> >>> ../../hw/riscv/virt.c: In function 'virt_machine_init':
> >>> ../../hw/riscv/virt.c:621:43: error: comparison is always false due to
> >>> limited range of data type [-Werror=type-limits]
> >>> if ((uint64_t)(machine->ram_size) > 10 * GiB) {
> >>> ^
> >>> ../../hw/riscv/virt.c:623:33: error: large integer implicitly
> >>> truncated to unsigned type [-Werror=overflow]
> >>> machine->ram_size = 10 * GiB;
> >>> ^~
> >>
> >> This kind of error is tricky. I wonder whether we should deprecate
> >> 32-bit host support though.
> >
> > 32-bit host is still not uncommon outside the x86 world...
> >
> > The thing that makes this particular check awkward is that
> > 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.
> >
> > It might be a good idea if we decided that we would just make
> > ram_addr_t 64-bits everywhere, to avoid this kind of "we
> > have an unusual config only on some more-obscure hosts" issue.
> > (We did that for hwaddr back in commit 4be403c8158e1 in 2012,
> > when it was still called target_phys_addr_t.) This change
> > would probably be a performance hit for 32-bit-non-x86 hosts;
> > it would be interesting to see whether it was measurably
> > significant.
>
> You once explained me we have 'hwaddr' (physical address)
> of 64-bit because we can 64-bit buses on 32-bit targets.
> hwaddr is available in all emulation modes.
Yes, but also we have 64-bit hwaddr everywhere because trying
to deal with different build configs having different sizes
of this type is just painful for development compared to its
benefit.
> ram_addr_t is restricted to system emulation. I understand
> it as the limit addressable by a CPU.
It's the type used internally to QEMU to represent an address
within guest RAM in a unique way. CODING_STYLE.rst describes it as:
# ram_addr_t is a QEMU internal address space that maps
# guest RAM physical addresses into an intermediate address
# space that can map to host virtual address spaces.
It doesn't correspond to anything in particular in the guest.
> Back to your comment, we only have 32-bit ram_addr_t on
> system-emulation on 32-bit (non-x86) hosts.
>
> Question I asked yesterday on IRC, do you know if there
> is still interest in having system-emulation on 32-bit
> hosts?
>
> It is important to keep user-mode emulation on 32-bit hosts,
> but I doubt there are many uses of system-emulation on them
> (even less non non-x86 archs).
I'm sure you can find some people who are using it...
thanks
-- PMM
