MAINTAINERS | 3 + hw/riscv/boot.c | 97 ++++++++++++++++--------- hw/riscv/microchip_pfsoc.c | 12 +-- hw/riscv/opentitan.c | 4 +- hw/riscv/sifive_e.c | 4 +- hw/riscv/sifive_u.c | 12 +-- hw/riscv/spike.c | 14 +--- hw/riscv/virt.c | 12 +-- include/hw/riscv/boot.h | 3 +- pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 117704 -> 123072 bytes pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 115344 -> 121800 bytes roms/opensbi | 2 +- target/riscv/cpu.c | 2 +- target/riscv/cpu_helper.c | 2 +- target/riscv/csr.c | 21 ++---- target/riscv/pmp.c | 9 ++- target/riscv/vector_helper.c | 4 +- 17 files changed, 99 insertions(+), 102 deletions(-)
The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6:
tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 11:23:53 +0000)
are available in the Git repository at:
https://github.com/palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230217
for you to fetch changes up to e8c0697d79ef05aa5aefb1121dfede59855556b4:
target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-16 08:10:40 -0800)
----------------------------------------------------------------
Fourth RISC-V PR for QEMU 8.0
* A triplet of cleanups to the kernel/initrd loader that avoids
duplication between the various boards.
* OpenSBI has been updated to version 1.2.
* Weiwei Li, Daniel Henrique Barboza, and Liu Zhiwei have been added as
reviewers. Thanks for the help!
* A fix for PMP matching to avoid incorrectly appling the default
permissions on PMP permission violations.
* A cleanup to avoid an unnecessary avoid env_archcpu() in
cpu_get_tb_cpu_state().
* Fixes for the vector slide instructions to avoid truncating 64-bit
values (such as doubles) on 32-bit targets.
----------------------------------------------------------------
Alistair is going to be out for a bit, so I'm going to pick up the pull
requests for a bit until he's back online. It's been a while so
apologies in advance if anything has gone off the rails, the only thing
I know of is that I moved to a Yubikey a while ago so there's likely
some new subkeys involved in the signing here.
This is all passing my standard tests (make check along with a handful
of Linux boots), both on its own and when merge into master from this
morning. There has been some flakiness in both of those for a while
now, but it doesn't appear to be anything new here (and I think might
just be flaky infrastructure on my end).
----------------------------------------------------------------
Alistair Francis (1):
MAINTAINERS: Add some RISC-V reviewers
Bin Meng (1):
roms/opensbi: Upgrade from v1.1 to v1.2
Daniel Henrique Barboza (4):
hw/riscv: handle 32 bit CPUs kernel_entry in riscv_load_kernel()
hw/riscv/boot.c: consolidate all kernel init in riscv_load_kernel()
hw/riscv/boot.c: make riscv_load_initrd() static
target/riscv: avoid env_archcpu() in cpu_get_tb_cpu_state()
Frank Chang (1):
target/riscv: Remove privileged spec version restriction for RVV
Himanshu Chauhan (1):
target/riscv: Smepmp: Skip applying default rules when address matches
LIU Zhiwei (1):
target/riscv: Fix vslide1up.vf and vslide1down.vf
MAINTAINERS | 3 +
hw/riscv/boot.c | 97 ++++++++++++++++---------
hw/riscv/microchip_pfsoc.c | 12 +--
hw/riscv/opentitan.c | 4 +-
hw/riscv/sifive_e.c | 4 +-
hw/riscv/sifive_u.c | 12 +--
hw/riscv/spike.c | 14 +---
hw/riscv/virt.c | 12 +--
include/hw/riscv/boot.h | 3 +-
pc-bios/opensbi-riscv32-generic-fw_dynamic.bin | Bin 117704 -> 123072 bytes
pc-bios/opensbi-riscv64-generic-fw_dynamic.bin | Bin 115344 -> 121800 bytes
roms/opensbi | 2 +-
target/riscv/cpu.c | 2 +-
target/riscv/cpu_helper.c | 2 +-
target/riscv/csr.c | 21 ++----
target/riscv/pmp.c | 9 ++-
target/riscv/vector_helper.c | 4 +-
17 files changed, 99 insertions(+), 102 deletions(-)
On Fri, 17 Feb 2023 at 17:53, Palmer Dabbelt <palmer@rivosinc.com> wrote: > > The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6: > > tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 11:23:53 +0000) > > are available in the Git repository at: > > https://github.com/palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230217 > > for you to fetch changes up to e8c0697d79ef05aa5aefb1121dfede59855556b4: > > target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-16 08:10:40 -0800) > > ---------------------------------------------------------------- > Fourth RISC-V PR for QEMU 8.0 > > * A triplet of cleanups to the kernel/initrd loader that avoids > duplication between the various boards. > * OpenSBI has been updated to version 1.2. > * Weiwei Li, Daniel Henrique Barboza, and Liu Zhiwei have been added as > reviewers. Thanks for the help! > * A fix for PMP matching to avoid incorrectly appling the default > permissions on PMP permission violations. > * A cleanup to avoid an unnecessary avoid env_archcpu() in > cpu_get_tb_cpu_state(). > * Fixes for the vector slide instructions to avoid truncating 64-bit > values (such as doubles) on 32-bit targets. This seems to have caused CI to decide it needs to rerun the 'docker-opensbi' job, which doesn't work: https://gitlab.com/qemu-project/qemu/-/jobs/3808319659 I don't understand what exactly is going on here -- Alex, Bin, any ideas? Why do we build the firmware in CI if we have checked in binaries in pc-bios? Should .gitlab-ci.d/opensbi/Dockerfile really still be starting with Ubuntu 18.04 ? That is already older than our set of supported platforms, and falls out of support from Ubuntu in a couple of months. (.gitlab-ci.d/edk2/Dockerfile is also using 18.04.) thanks -- PMM
On Tue, 21 Feb 2023 08:43:47 PST (-0800), Peter Maydell wrote: > On Fri, 17 Feb 2023 at 17:53, Palmer Dabbelt <palmer@rivosinc.com> wrote: >> >> The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6: >> >> tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 11:23:53 +0000) >> >> are available in the Git repository at: >> >> https://github.com/palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230217 >> >> for you to fetch changes up to e8c0697d79ef05aa5aefb1121dfede59855556b4: >> >> target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-16 08:10:40 -0800) >> >> ---------------------------------------------------------------- >> Fourth RISC-V PR for QEMU 8.0 >> >> * A triplet of cleanups to the kernel/initrd loader that avoids >> duplication between the various boards. >> * OpenSBI has been updated to version 1.2. >> * Weiwei Li, Daniel Henrique Barboza, and Liu Zhiwei have been added as >> reviewers. Thanks for the help! >> * A fix for PMP matching to avoid incorrectly appling the default >> permissions on PMP permission violations. >> * A cleanup to avoid an unnecessary avoid env_archcpu() in >> cpu_get_tb_cpu_state(). >> * Fixes for the vector slide instructions to avoid truncating 64-bit >> values (such as doubles) on 32-bit targets. > > This seems to have caused CI to decide it needs to rerun the > 'docker-opensbi' job, which doesn't work: > https://gitlab.com/qemu-project/qemu/-/jobs/3808319659 > > I don't understand what exactly is going on here -- Alex, > Bin, any ideas? > > Why do we build the firmware in CI if we have checked in > binaries in pc-bios? > > Should .gitlab-ci.d/opensbi/Dockerfile really still be > starting with Ubuntu 18.04 ? That is already older than our > set of supported platforms, and falls out of support from > Ubuntu in a couple of months. I just sent along a patch <https://lore.kernel.org/r/20230222154938.9201-1-palmer@rivosinc.com/>. I have no idea how to test it in the CI, though... > (.gitlab-ci.d/edk2/Dockerfile is also using 18.04.) I guess I'd missed this in the original email, I stumbled on that one as well <https://lore.kernel.org/r/20230222155341.10127-1-palmer@rivosinc.com/>. > > thanks > -- PMM
On Wed, 22 Feb 2023 07:56:10 PST (-0800), Palmer Dabbelt wrote: > On Tue, 21 Feb 2023 08:43:47 PST (-0800), Peter Maydell wrote: >> On Fri, 17 Feb 2023 at 17:53, Palmer Dabbelt <palmer@rivosinc.com> wrote: >>> >>> The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6: >>> >>> tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 11:23:53 +0000) >>> >>> are available in the Git repository at: >>> >>> https://github.com/palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230217 >>> >>> for you to fetch changes up to e8c0697d79ef05aa5aefb1121dfede59855556b4: >>> >>> target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-16 08:10:40 -0800) >>> >>> ---------------------------------------------------------------- >>> Fourth RISC-V PR for QEMU 8.0 >>> >>> * A triplet of cleanups to the kernel/initrd loader that avoids >>> duplication between the various boards. >>> * OpenSBI has been updated to version 1.2. >>> * Weiwei Li, Daniel Henrique Barboza, and Liu Zhiwei have been added as >>> reviewers. Thanks for the help! >>> * A fix for PMP matching to avoid incorrectly appling the default >>> permissions on PMP permission violations. >>> * A cleanup to avoid an unnecessary avoid env_archcpu() in >>> cpu_get_tb_cpu_state(). >>> * Fixes for the vector slide instructions to avoid truncating 64-bit >>> values (such as doubles) on 32-bit targets. >> >> This seems to have caused CI to decide it needs to rerun the >> 'docker-opensbi' job, which doesn't work: >> https://gitlab.com/qemu-project/qemu/-/jobs/3808319659 >> >> I don't understand what exactly is going on here -- Alex, >> Bin, any ideas? >> >> Why do we build the firmware in CI if we have checked in >> binaries in pc-bios? >> >> Should .gitlab-ci.d/opensbi/Dockerfile really still be >> starting with Ubuntu 18.04 ? That is already older than our >> set of supported platforms, and falls out of support from >> Ubuntu in a couple of months. > > I just sent along a patch > <https://lore.kernel.org/r/20230222154938.9201-1-palmer@rivosinc.com/>. > I have no idea how to test it in the CI, though... Nobody's replied, so I'm inclined to just drop the OpenSBI bump and re-send the PR. At least that way we can avoid getting blocked on the CI issues. There's some more in flight so there'll probably be a 5th round before the freeze either way, at least this way the stuff that works can avoid getting blocked. >> (.gitlab-ci.d/edk2/Dockerfile is also using 18.04.) > > I guess I'd missed this in the original email, I stumbled on that one as > well > <https://lore.kernel.org/r/20230222155341.10127-1-palmer@rivosinc.com/>. > >> >> thanks >> -- PMM
Hi!
On 23/02/2023 23.49, Palmer Dabbelt wrote:
> On Wed, 22 Feb 2023 07:56:10 PST (-0800), Palmer Dabbelt wrote:
>> On Tue, 21 Feb 2023 08:43:47 PST (-0800), Peter Maydell wrote:
...
>>> This seems to have caused CI to decide it needs to rerun the
>>> 'docker-opensbi' job, which doesn't work:
>>> https://gitlab.com/qemu-project/qemu/-/jobs/3808319659
>>>
>>> I don't understand what exactly is going on here -- Alex,
>>> Bin, any ideas?
>>>
>>> Why do we build the firmware in CI if we have checked in
>>> binaries in pc-bios?
>>>
>>> Should .gitlab-ci.d/opensbi/Dockerfile really still be
>>> starting with Ubuntu 18.04 ? That is already older than our
>>> set of supported platforms, and falls out of support from
>>> Ubuntu in a couple of months.
>>
>> I just sent along a patch
>> <https://lore.kernel.org/r/20230222154938.9201-1-palmer@rivosinc.com/>.
>> I have no idea how to test it in the CI, though...
1) Fork the qemu repository in gitlab to your account
2) Add a remote to your repo on your PC to point to the
forked gitlab repo (git remote add ...)
3) Read docs/devel/ci-jobs.rst.inc - you basically want
these two things:
git config --local alias.push-ci "push -o ci.variable=QEMU_CI=1"
git config --local alias.push-ci-now "push -o ci.variable=QEMU_CI=2"
4) If you now do a "git push-ci ..." to your forked repo,
you should be able to see the CI pipelines there
> Nobody's replied, so I'm inclined to just drop the OpenSBI bump and re-send
> the PR. At least that way we can avoid getting blocked on the CI issues.
> There's some more in flight so there'll probably be a 5th round before the
> freeze either way, at least this way the stuff that works can avoid getting
> blocked.
Please note that pull requests are currently not processed
anyway ('til March 1st), see:
https://lore.kernel.org/qemu-devel/CAFEAcA83u_ENxDj3GJKa-xv6eLJGJPr_9FRDKAqm3qACyhrTgg@mail.gmail.com/
Thomas
On Fri, 24 Feb 2023 at 06:56, Thomas Huth <thuth@redhat.com> wrote:
>
> Hi!
>
> On 23/02/2023 23.49, Palmer Dabbelt wrote:
> > Nobody's replied, so I'm inclined to just drop the OpenSBI bump and re-send
> > the PR. At least that way we can avoid getting blocked on the CI issues.
> > There's some more in flight so there'll probably be a 5th round before the
> > freeze either way, at least this way the stuff that works can avoid getting
> > blocked.
>
> Please note that pull requests are currently not processed
> anyway ('til March 1st), see:
>
> https://lore.kernel.org/qemu-devel/CAFEAcA83u_ENxDj3GJKa-xv6eLJGJPr_9FRDKAqm3qACyhrTgg@mail.gmail.com/
I've been able to do some pullreq processing with a combination
of the private CI runners, my personal gitlab account's CI minute
allowance, and local ad-hoc jobs. So probably best not to wait
til March 1st before sending.
thanks
-- PMM
On Fri, 24 Feb 2023 10:52:34 PST (-0800), Peter Maydell wrote:
> On Fri, 24 Feb 2023 at 06:56, Thomas Huth <thuth@redhat.com> wrote:
>>
>> Hi!
>>
>> On 23/02/2023 23.49, Palmer Dabbelt wrote:
>> > Nobody's replied, so I'm inclined to just drop the OpenSBI bump and re-send
>> > the PR. At least that way we can avoid getting blocked on the CI issues.
>> > There's some more in flight so there'll probably be a 5th round before the
>> > freeze either way, at least this way the stuff that works can avoid getting
>> > blocked.
>>
>> Please note that pull requests are currently not processed
>> anyway ('til March 1st), see:
>>
>> https://lore.kernel.org/qemu-devel/CAFEAcA83u_ENxDj3GJKa-xv6eLJGJPr_9FRDKAqm3qACyhrTgg@mail.gmail.com/
>
> I've been able to do some pullreq processing with a combination
> of the private CI runners, my personal gitlab account's CI minute
> allowance, and local ad-hoc jobs. So probably best not to wait
> til March 1st before sending.
Ok, I'm just going to send a v2 with the OpenSBI bump removed. No big
deal if it doesn't get merged, there's more to do in RISC-V land either
way.
I'll also poke aroun with the CI some and try to see if I can get local
stuff working to debug the OpenSBI issue.
Thanks!
© 2016 - 2026 Red Hat, Inc.