| Message ID | 20210218015934.1623959-1-alistair.francis@wdc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, 18 Feb 2021 at 01:59, Alistair Francis <alistair.francis@wdc.com> wrote: > > The following changes since commit 1af5629673bb5c1592d993f9fb6119a62845f576: > > Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20210216' into staging (2021-02-17 14:44:18 +0000) > > are available in the Git repository at: > > git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210217-1 > > for you to fetch changes up to d0867d2dad4125d2295b28d6f91fa49cf034ffd2: > > hw/riscv: virt: Map high mmio for PCIe (2021-02-17 17:47:19 -0800) > > ---------------------------------------------------------------- > RISC-V PR for 6.0 > > This PR is a collection of RISC-V patches: > - Improvements to SiFive U OTP > - Upgrade OpenSBI to v0.9 > - Support the QMP dump-guest-memory > - Add support for the SiFive SPI controller (sifive_u) > - Initial RISC-V system documentation > - A fix for the Goldfish RTC > - MAINTAINERS updates > - Support for high PCIe memory in the virt machine 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; ^~ -- PMM
On Thu, Feb 18, 2021 at 9:26 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Thu, 18 Feb 2021 at 01:59, Alistair Francis <alistair.francis@wdc.com> wrote: > > > > The following changes since commit 1af5629673bb5c1592d993f9fb6119a62845f576: > > > > Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20210216' into staging (2021-02-17 14:44:18 +0000) > > > > are available in the Git repository at: > > > > git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210217-1 > > > > for you to fetch changes up to d0867d2dad4125d2295b28d6f91fa49cf034ffd2: > > > > hw/riscv: virt: Map high mmio for PCIe (2021-02-17 17:47:19 -0800) > > > > ---------------------------------------------------------------- > > RISC-V PR for 6.0 > > > > This PR is a collection of RISC-V patches: > > - Improvements to SiFive U OTP > > - Upgrade OpenSBI to v0.9 > > - Support the QMP dump-guest-memory > > - Add support for the SiFive SPI controller (sifive_u) > > - Initial RISC-V system documentation > > - A fix for the Goldfish RTC > > - MAINTAINERS updates > > - Support for high PCIe memory in the virt machine > > 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. Regards, Bin
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. -- PMM
On Thu, Feb 18, 2021 at 10:22 PM Peter Maydell <peter.maydell@linaro.org> 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. Okay, will send a patch to change ram_addr_t to 64-bit. Regards, Bin
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.
On Fri, 19 Feb 2021 at 13:31, Philippe Mathieu-Daudé <f4bug@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.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. 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
On Fri, Feb 19, 2021 at 02:31:20PM +0100, Philippe Mathieu-Daudé 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.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? For _Fedora_ we don't care about 32 bit at all. For the broader ecosystem I have no idea, but it's worth mentioning that all the RV32 systems so far have been embedded-type systems, many lacking even virtual memory (so they don't run Linux), and with so little RAM that virtualization is hardly possible. At this point I'm sure someone will point to a huge RV32 system that I didn't know about :-) Rich. > 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.
The following changes since commit 1af5629673bb5c1592d993f9fb6119a62845f576: Merge remote-tracking branch 'remotes/dgilbert-gitlab/tags/pull-virtiofs-20210216' into staging (2021-02-17 14:44:18 +0000) are available in the Git repository at: git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210217-1 for you to fetch changes up to d0867d2dad4125d2295b28d6f91fa49cf034ffd2: hw/riscv: virt: Map high mmio for PCIe (2021-02-17 17:47:19 -0800) ---------------------------------------------------------------- RISC-V PR for 6.0 This PR is a collection of RISC-V patches: - Improvements to SiFive U OTP - Upgrade OpenSBI to v0.9 - Support the QMP dump-guest-memory - Add support for the SiFive SPI controller (sifive_u) - Initial RISC-V system documentation - A fix for the Goldfish RTC - MAINTAINERS updates - Support for high PCIe memory in the virt machine ---------------------------------------------------------------- Alistair Francis (1): MAINTAINERS: Add a SiFive machine section Bin Meng (16): target/riscv: Declare csr_ops[] with a known size hw/misc: sifive_u_otp: Use error_report() when block operation fails roms/opensbi: Upgrade from v0.8 to v0.9 hw/block: m25p80: Add ISSI SPI flash support hw/block: m25p80: Add various ISSI flash information hw/ssi: Add SiFive SPI controller support hw/riscv: sifive_u: Add QSPI0 controller and connect a flash hw/riscv: sifive_u: Add QSPI2 controller and connect an SD card hw/riscv: sifive_u: Change SIFIVE_U_GEM_IRQ to decimal value docs/system: Sort targets in alphabetical order docs/system: Add RISC-V documentation docs/system: riscv: Add documentation for sifive_u machine hw/riscv: Drop 'struct MemmapEntry' hw/riscv: virt: Drop the 'link_up' parameter of gpex_pcie_init() hw/riscv: virt: Limit RAM size in a 32-bit system hw/riscv: virt: Map high mmio for PCIe Laurent Vivier (1): goldfish_rtc: re-arm the alarm after migration Yifei Jiang (1): target-riscv: support QMP dump-guest-memory docs/system/riscv/sifive_u.rst | 336 +++++++++++++++++++++++ docs/system/target-riscv.rst | 72 +++++ docs/system/targets.rst | 20 +- include/hw/riscv/sifive_u.h | 9 +- include/hw/ssi/sifive_spi.h | 47 ++++ target/riscv/cpu.h | 6 +- target/riscv/cpu_bits.h | 1 + hw/block/m25p80.c | 57 +++- hw/misc/sifive_u_otp.c | 13 +- hw/riscv/microchip_pfsoc.c | 9 +- hw/riscv/opentitan.c | 9 +- hw/riscv/sifive_e.c | 9 +- hw/riscv/sifive_u.c | 102 ++++++- hw/riscv/spike.c | 9 +- hw/riscv/virt.c | 72 +++-- hw/rtc/goldfish_rtc.c | 2 + hw/ssi/sifive_spi.c | 358 +++++++++++++++++++++++++ target/riscv/arch_dump.c | 202 ++++++++++++++ target/riscv/cpu.c | 2 + MAINTAINERS | 9 + hw/riscv/Kconfig | 3 + hw/ssi/Kconfig | 4 + hw/ssi/meson.build | 1 + pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 62144 -> 78680 bytes pc-bios/opensbi-riscv32-generic-fw_dynamic.elf | Bin 558668 -> 727464 bytes pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 70792 -> 75096 bytes pc-bios/opensbi-riscv64-generic-fw_dynamic.elf | Bin 620424 -> 781264 bytes roms/opensbi | 2 +- target/riscv/meson.build | 1 + 29 files changed, 1290 insertions(+), 65 deletions(-) create mode 100644 docs/system/riscv/sifive_u.rst create mode 100644 docs/system/target-riscv.rst create mode 100644 include/hw/ssi/sifive_spi.h create mode 100644 hw/ssi/sifive_spi.c create mode 100644 target/riscv/arch_dump.c