[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/19] riscv-to-apply queue

From: Peter Maydell
Subject: Re: [PULL 00/19] riscv-to-apply queue
Date: Thu, 18 Feb 2021 14:22:10 +0000

On Thu, 18 Feb 2021 at 14:07, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Thu, Feb 18, 2021 at 9:26 PM Peter Maydell <peter.maydell@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

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]