[Top][All Lists]

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

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

From: Philippe Mathieu-Daudé
Subject: Re: [PULL 00/19] riscv-to-apply queue
Date: Fri, 19 Feb 2021 14:31:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0

Hi Peter,


On 2/18/21 3:22 PM, Peter Maydell wrote:
> 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
> 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.

ram_addr_t is restricted to system emulation. I understand
it as the limit addressable by a CPU.

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

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).



reply via email to

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