Re: [PATCH v4 0/3] hw/riscv/virt: pflash improvements

[Andrea Bolognani]

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