mbox

[PULL,00/19] riscv-to-apply queue

Message ID 20210218015934.1623959-1-alistair.francis@wdc.com (mailing list archive)
State New, archived
Headers show

Pull-request

git@github.com:alistair23/qemu.git tags/pull-riscv-to-apply-20210217-1

Message

Alistair Francis Feb. 18, 2021, 1:59 a.m. UTC
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

Comments

Peter Maydell Feb. 18, 2021, 1:25 p.m. UTC | #1
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
Bin Meng Feb. 18, 2021, 2:07 p.m. UTC | #2
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
Peter Maydell Feb. 18, 2021, 2:22 p.m. UTC | #3
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
Bin Meng Feb. 19, 2021, 12:36 p.m. UTC | #4
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
Philippe Mathieu-Daudé Feb. 19, 2021, 1:31 p.m. UTC | #5
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.
Peter Maydell Feb. 19, 2021, 1:40 p.m. UTC | #6
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
Richard W.M. Jones Feb. 19, 2021, 4:12 p.m. UTC | #7
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.