[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,
[+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.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
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).
Regards,
Phil.
- [PULL 14/19] goldfish_rtc: re-arm the alarm after migration, (continued)
- [PULL 14/19] goldfish_rtc: re-arm the alarm after migration, Alistair Francis, 2021/02/17
- [PULL 15/19] MAINTAINERS: Add a SiFive machine section, Alistair Francis, 2021/02/17
- [PULL 16/19] hw/riscv: Drop 'struct MemmapEntry', Alistair Francis, 2021/02/17
- [PULL 17/19] hw/riscv: virt: Drop the 'link_up' parameter of gpex_pcie_init(), Alistair Francis, 2021/02/17
- [PULL 18/19] hw/riscv: virt: Limit RAM size in a 32-bit system, Alistair Francis, 2021/02/17
- [PULL 19/19] hw/riscv: virt: Map high mmio for PCIe, Alistair Francis, 2021/02/17
- Re: [PULL 00/19] riscv-to-apply queue, Peter Maydell, 2021/02/18