docs/system/riscv/virt.rst | 29 +++++++++++++++++++ hw/riscv/virt.c | 58 ++++++++++++++++---------------------- 2 files changed, 53 insertions(+), 34 deletions(-)
This series improves the pflash usage in RISC-V virt machine with solutions to below issues. 1) Currently the first pflash is reserved for ROM/M-mode firmware code. But S-mode payload firmware like EDK2 need both pflash devices to have separate code and variable store so that OS distros can keep the FW code as read-only. The issue is reported at https://salsa.debian.org/qemu-team/edk2/-/commit/c345655a0149f64c5020bfc1e53c619ce60587f6 2) The latest way of using pflash devices in other architectures and libvirt is by using -blockdev and machine options. However, currently this method is not working in RISC-V. With above issues fixed, added documentation on how to use pflash devices in RISC-V virt machine. This patch series is based on Alistair's riscv-to-apply.next branch. Changes since v3: 1) Converted single patch to a series with a cover letter since there are multiple patches now. 2) Added a new patch to enable pflash usage via -blockdev option. 3) Separated the documentation change into new patch and updated the documentation to mention only -blockdev option which seems to be the recommended way of using pflash. Changes since v2: 1) Reverted v2 changes and used v1 approach so that pflash0 can be used for code and pflash1 for variable store. 2) Rebased to latest riscv-to-apply.next branch. 3) Added documentation for pflash usage. Changes since v1: 1) Simplified the fix such that it doesn't break current EDK2. Sunil V L (3): hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none" riscv/virt: Support using pflash via -blockdev option docs/system: riscv: Add pflash usage details docs/system/riscv/virt.rst | 29 +++++++++++++++++++ hw/riscv/virt.c | 58 ++++++++++++++++---------------------- 2 files changed, 53 insertions(+), 34 deletions(-) -- 2.34.1
On Thu, May 25, 2023 at 10:18:00PM +0530, Sunil V L wrote: > This series improves the pflash usage in RISC-V virt machine with solutions to > below issues. > > 1) Currently the first pflash is reserved for ROM/M-mode firmware code. But S-mode > payload firmware like EDK2 need both pflash devices to have separate code and variable > store so that OS distros can keep the FW code as read-only. > > The issue is reported at > https://salsa.debian.org/qemu-team/edk2/-/commit/c345655a0149f64c5020bfc1e53c619ce60587f6 > > 2) The latest way of using pflash devices in other architectures and libvirt > is by using -blockdev and machine options. However, currently this method is > not working in RISC-V. > > With above issues fixed, added documentation on how to use pflash devices > in RISC-V virt machine. > > This patch series is based on Alistair's riscv-to-apply.next branch. > > Changes since v3: > 1) Converted single patch to a series with a cover letter since there are > multiple patches now. > 2) Added a new patch to enable pflash usage via -blockdev option. > 3) Separated the documentation change into new patch and updated the > documentation to mention only -blockdev option which seems to be the > recommended way of using pflash. Success! \o/ With these patches applied, libvirt built from the master branch, edk2 built from your branch and a JSON firmware descriptor for it installed (attached), it's finally possible to boot an unmodified openSUSE Tumbleweed RISC-V disk image by simply including <os firmware='efi'> in the domain XML, which is the same experience you'd have with x86_64 or aarch64. That's a *massive* leap forward when it comes to giving developers convenient access to a reasonable RISC-V environment they can play around with! Thanks a lot for your work on this, and I can't wait to see it all merged :) Tested-by: Andrea Bolognani <abologna@redhat.com> -- Andrea Bolognani / Red Hat / Virtualization
On Thu, May 25, 2023 at 11:03:52AM -0700, Andrea Bolognani wrote: > On Thu, May 25, 2023 at 10:18:00PM +0530, Sunil V L wrote: > > This series improves the pflash usage in RISC-V virt machine with solutions to > > below issues. > > > > 1) Currently the first pflash is reserved for ROM/M-mode firmware code. But S-mode > > payload firmware like EDK2 need both pflash devices to have separate code and variable > > store so that OS distros can keep the FW code as read-only. > > > > The issue is reported at > > https://salsa.debian.org/qemu-team/edk2/-/commit/c345655a0149f64c5020bfc1e53c619ce60587f6 > > > > 2) The latest way of using pflash devices in other architectures and libvirt > > is by using -blockdev and machine options. However, currently this method is > > not working in RISC-V. > > > > With above issues fixed, added documentation on how to use pflash devices > > in RISC-V virt machine. > > > > This patch series is based on Alistair's riscv-to-apply.next branch. > > > > Changes since v3: > > 1) Converted single patch to a series with a cover letter since there are > > multiple patches now. > > 2) Added a new patch to enable pflash usage via -blockdev option. > > 3) Separated the documentation change into new patch and updated the > > documentation to mention only -blockdev option which seems to be the > > recommended way of using pflash. > > Success! \o/ > > With these patches applied, libvirt built from the master branch, > edk2 built from your branch and a JSON firmware descriptor for it > installed (attached), it's finally possible to boot an unmodified > openSUSE Tumbleweed RISC-V disk image by simply including > > <os firmware='efi'> Hi Andrea, I'm a bit concerned that we don't also need to add some XML in order to disable ACPI right now. RISC-V guest kernels will support ACPI in the near future. Ideally a default libvirt VM using edk2 will also use ACPI. Will there be a problem with changing that default later? If so, then I'd change it now and continue burdening developers a bit longer by requiring them to explicitly disable it. Thanks, drew
On Fri, May 26, 2023 at 08:39:07AM +0200, Andrew Jones wrote: > On Thu, May 25, 2023 at 11:03:52AM -0700, Andrea Bolognani wrote: > > With these patches applied, libvirt built from the master branch, > > edk2 built from your branch and a JSON firmware descriptor for it > > installed (attached), it's finally possible to boot an unmodified > > openSUSE Tumbleweed RISC-V disk image by simply including > > > > <os firmware='efi'> > > Hi Andrea, > > I'm a bit concerned that we don't also need to add some XML in order to > disable ACPI right now. RISC-V guest kernels will support ACPI in the > near future. Ideally a default libvirt VM using edk2 will also use ACPI. > Will there be a problem with changing that default later? If so, then > I'd change it now and continue burdening developers a bit longer by > requiring them to explicitly disable it. libvirt doesn't enable ACPI by default on any architecture, not even x86_64. virt-manager will enable it by default if it's advertised as available on the architecture in the capabilities XML. However, it looks like the corresponding code in libvirt is not as dynamic as I would have assumed: instead, we hardcode the list of architectures that advertise ACPI support available, and at the moment that list does *not* include RISC-V :) I think it would make sense to fix this, but I want to make sure I understand the impact. Is this just an UEFI thing? All my other RISC-V guests (Fedora, Ubuntu, FreeBSD) boot just fine when I turn ACPI on. In fact, even the openSUSE one works with ACPI on, as long as the UEFI implementation used is the U-Boot one rather than edk2. So, are edk2 users the only ones who would (temporarily) need to manually turn ACPI off if virt-manager started enabling it by default? -- Andrea Bolognani / Red Hat / Virtualization
On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > On Fri, May 26, 2023 at 08:39:07AM +0200, Andrew Jones wrote: > > On Thu, May 25, 2023 at 11:03:52AM -0700, Andrea Bolognani wrote: > > > With these patches applied, libvirt built from the master branch, > > > edk2 built from your branch and a JSON firmware descriptor for it > > > installed (attached), it's finally possible to boot an unmodified > > > openSUSE Tumbleweed RISC-V disk image by simply including > > > > > > <os firmware='efi'> > > > > Hi Andrea, > > > > I'm a bit concerned that we don't also need to add some XML in order to > > disable ACPI right now. RISC-V guest kernels will support ACPI in the > > near future. Ideally a default libvirt VM using edk2 will also use ACPI. > > Will there be a problem with changing that default later? If so, then > > I'd change it now and continue burdening developers a bit longer by > > requiring them to explicitly disable it. > > libvirt doesn't enable ACPI by default on any architecture, not even > x86_64. virt-manager will enable it by default if it's advertised as > available on the architecture in the capabilities XML. > > However, it looks like the corresponding code in libvirt is not as > dynamic as I would have assumed: instead, we hardcode the list of > architectures that advertise ACPI support available, and at the > moment that list does *not* include RISC-V :) > > I think it would make sense to fix this, but I want to make sure I > understand the impact. Is this just an UEFI thing? All my other > RISC-V guests (Fedora, Ubuntu, FreeBSD) boot just fine when I turn > ACPI on. In fact, even the openSUSE one works with ACPI on, as long > as the UEFI implementation used is the U-Boot one rather than edk2. > > So, are edk2 users the only ones who would (temporarily) need to > manually turn ACPI off if virt-manager started enabling it by > default? I assume so, but I'm not tracking firmware status. If the firmware doesn't extract the ACPI tables from QEMU and present them to the guest (afaik only edk2 does that), then the guest kernel falls back to DT, which is why it's working for you. I suppose we should wait until Linux merges the ACPI patches, before adding RISC-V to the libvirt capabilities ACPI list. Then, is it possible to use something like libosinfo to inform virt-manager when it should enable ACPI and when not? Later distro images, with later kernels, will want to use ACPI by default, but older images will still need to use DT. Thanks, drew
On Fri, May 26, 2023 at 10:34:36AM +0200, Andrew Jones wrote: > On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > > So, are edk2 users the only ones who would (temporarily) need to > > manually turn ACPI off if virt-manager started enabling it by > > default? > > I assume so, but I'm not tracking firmware status. If the firmware > doesn't extract the ACPI tables from QEMU and present them to the > guest (afaik only edk2 does that), then the guest kernel falls back > to DT, which is why it's working for you. > > I suppose we should wait until Linux merges the ACPI patches, before > adding RISC-V to the libvirt capabilities ACPI list. That sounds reasonable to me, but note that 1) the libvirt change might take a while to propagate to distros and 2) someone will have to remind me to prepare such a patch when the time comes ;) > Then, is it > possible to use something like libosinfo to inform virt-manager > when it should enable ACPI and when not? Later distro images, with > later kernels, will want to use ACPI by default, but older images > will still need to use DT. Something like that would definitely be possible, but I don't think the scaffolding for it exists at the moment, so someone would have to wire it up across the stack. Given how relatively immature the RISC-V distro ecosystem is at the moment, I think it's fine to do nothing and wait for the problem to go away on its own :) -- Andrea Bolognani / Red Hat / Virtualization
On Fri, May 26, 2023 at 04:42:57AM -0400, Andrea Bolognani wrote: > On Fri, May 26, 2023 at 10:34:36AM +0200, Andrew Jones wrote: > > On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > > > So, are edk2 users the only ones who would (temporarily) need to > > > manually turn ACPI off if virt-manager started enabling it by > > > default? > > > > I assume so, but I'm not tracking firmware status. If the firmware > > doesn't extract the ACPI tables from QEMU and present them to the > > guest (afaik only edk2 does that), then the guest kernel falls back > > to DT, which is why it's working for you. > > > > I suppose we should wait until Linux merges the ACPI patches, before > > adding RISC-V to the libvirt capabilities ACPI list. > > That sounds reasonable to me, but note that 1) the libvirt change > might take a while to propagate to distros and 2) someone will have > to remind me to prepare such a patch when the time comes ;) Initial ACPI support will probably be merged for 6.4. So maybe it is time to get the libvirt side of things going. > > > Then, is it > > possible to use something like libosinfo to inform virt-manager > > when it should enable ACPI and when not? Later distro images, with > > later kernels, will want to use ACPI by default, but older images > > will still need to use DT. > > Something like that would definitely be possible, but I don't think > the scaffolding for it exists at the moment, so someone would have to > wire it up across the stack. Given how relatively immature the RISC-V > distro ecosystem is at the moment, I think it's fine to do nothing > and wait for the problem to go away on its own :) WFM Thanks, drew
On Fri, May 26, 2023 at 11:10:12AM +0200, Andrew Jones wrote: > On Fri, May 26, 2023 at 04:42:57AM -0400, Andrea Bolognani wrote: > > On Fri, May 26, 2023 at 10:34:36AM +0200, Andrew Jones wrote: > > > On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > > > > So, are edk2 users the only ones who would (temporarily) need to > > > > manually turn ACPI off if virt-manager started enabling it by > > > > default? > > > > > > I assume so, but I'm not tracking firmware status. If the firmware > > > doesn't extract the ACPI tables from QEMU and present them to the > > > guest (afaik only edk2 does that), then the guest kernel falls back > > > to DT, which is why it's working for you. > > > > > > I suppose we should wait until Linux merges the ACPI patches, before > > > adding RISC-V to the libvirt capabilities ACPI list. > > > > That sounds reasonable to me, but note that 1) the libvirt change > > might take a while to propagate to distros and 2) someone will have > > to remind me to prepare such a patch when the time comes ;) > > Initial ACPI support will probably be merged for 6.4. So maybe it is > time to get the libvirt side of things going. Randomly remembered about this. Did ACPI support make it into 6.4 after all? Is now a good time to change libvirt? -- Andrea Bolognani / Red Hat / Virtualization
On Mon, Nov 20, 2023 at 02:29:28PM +0000, Andrea Bolognani wrote: > On Fri, May 26, 2023 at 11:10:12AM +0200, Andrew Jones wrote: > > On Fri, May 26, 2023 at 04:42:57AM -0400, Andrea Bolognani wrote: > > > On Fri, May 26, 2023 at 10:34:36AM +0200, Andrew Jones wrote: > > > > On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > > > > > So, are edk2 users the only ones who would (temporarily) need to > > > > > manually turn ACPI off if virt-manager started enabling it by > > > > > default? > > > > > > > > I assume so, but I'm not tracking firmware status. If the firmware > > > > doesn't extract the ACPI tables from QEMU and present them to the > > > > guest (afaik only edk2 does that), then the guest kernel falls back > > > > to DT, which is why it's working for you. > > > > > > > > I suppose we should wait until Linux merges the ACPI patches, before > > > > adding RISC-V to the libvirt capabilities ACPI list. > > > > > > That sounds reasonable to me, but note that 1) the libvirt change > > > might take a while to propagate to distros and 2) someone will have > > > to remind me to prepare such a patch when the time comes ;) > > > > Initial ACPI support will probably be merged for 6.4. So maybe it is > > time to get the libvirt side of things going. > > Randomly remembered about this. Did ACPI support make it into 6.4 > after all? Is now a good time to change libvirt? > Hi Andrea, Not yet. While basic ACPI changes are merged, the interrupt controller support is still going on. Looks like it will take few merge windows to get ACPI fully supported. So, we still need to wait for libvirt change. Thanks! Sunil
On Fri, May 26, 2023 at 03:49:11AM -0400, Andrea Bolognani wrote: > On Fri, May 26, 2023 at 08:39:07AM +0200, Andrew Jones wrote: > > On Thu, May 25, 2023 at 11:03:52AM -0700, Andrea Bolognani wrote: > > > With these patches applied, libvirt built from the master branch, > > > edk2 built from your branch and a JSON firmware descriptor for it > > > installed (attached), it's finally possible to boot an unmodified > > > openSUSE Tumbleweed RISC-V disk image by simply including > > > > > > <os firmware='efi'> > > > > Hi Andrea, > > > > I'm a bit concerned that we don't also need to add some XML in order to > > disable ACPI right now. RISC-V guest kernels will support ACPI in the > > near future. Ideally a default libvirt VM using edk2 will also use ACPI. > > Will there be a problem with changing that default later? If so, then > > I'd change it now and continue burdening developers a bit longer by > > requiring them to explicitly disable it. > > libvirt doesn't enable ACPI by default on any architecture, not even > x86_64. virt-manager will enable it by default if it's advertised as > available on the architecture in the capabilities XML. > > However, it looks like the corresponding code in libvirt is not as > dynamic as I would have assumed: instead, we hardcode the list of > architectures that advertise ACPI support available, and at the > moment that list does *not* include RISC-V :) > > I think it would make sense to fix this, but I want to make sure I > understand the impact. Is this just an UEFI thing? All my other > RISC-V guests (Fedora, Ubuntu, FreeBSD) boot just fine when I turn > ACPI on. In fact, even the openSUSE one works with ACPI on, as long > as the UEFI implementation used is the U-Boot one rather than edk2. > > So, are edk2 users the only ones who would (temporarily) need to > manually turn ACPI off if virt-manager started enabling it by > default? > Right. Currently only EDK2 supports passing ACPI information to the kernel in RISC-V. I think it is true even in aarch64. Hence, we need this temporary solution to turn acpi off only for EDK2 users. Is there an issue with delaying the fix in virt-manager to add RISC-V to ACPI supported list? I think there is no point enabling it until kernel also supports it. Thanks, Sunil
© 2016 - 2024 Red Hat, Inc.