| Message ID | 20230217175203.19510-1-palmer@rivosinc.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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!
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(-)