From: Andrew Jones <ajones@ventanamicro.com>
To: Andrea Bolognani <abologna@redhat.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>,
qemu-riscv@nongnu.org, qemu-devel@nongnu.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bin.meng@windriver.com>,
Weiwei Li <liweiwei@iscas.ac.cn>,
Daniel Henrique Barboza <dbarboza@ventanamicro.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>
Subject: Re: [PATCH v4 0/3] hw/riscv/virt: pflash improvements
Date: Fri, 26 May 2023 10:34:36 +0200 [thread overview]
Message-ID: <20230526-e398cfda73f326653323ea68@orel> (raw)
In-Reply-To: <CABJz62Nk-U+qHQjn6G2-bN8i9RcMEZWdYTyi7wqC=7BVjDSBWQ@mail.gmail.com>
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
next prev parent reply other threads:[~2023-05-26 8:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 16:48 [PATCH v4 0/3] hw/riscv/virt: pflash improvements Sunil V L
2023-05-25 16:48 ` [PATCH v4 1/3] hw/riscv: virt: Assume M-mode FW in pflash0 only when "-bios none" Sunil V L
2023-05-25 16:48 ` [PATCH v4 2/3] riscv/virt: Support using pflash via -blockdev option Sunil V L
2023-05-26 9:53 ` Philippe Mathieu-Daudé
2023-05-26 10:20 ` Sunil V L
2023-05-25 16:48 ` [PATCH v4 3/3] docs/system: riscv: Add pflash usage details Sunil V L
2023-05-26 9:48 ` Philippe Mathieu-Daudé
2023-05-25 18:03 ` [PATCH v4 0/3] hw/riscv/virt: pflash improvements Andrea Bolognani
2023-05-26 6:39 ` Andrew Jones
2023-05-26 7:49 ` Andrea Bolognani
2023-05-26 8:19 ` Sunil V L
2023-05-26 8:34 ` Andrew Jones [this message]
2023-05-26 8:42 ` Andrea Bolognani
2023-05-26 9:10 ` Andrew Jones
2023-11-20 14:29 ` Andrea Bolognani
2023-11-20 14:36 ` Sunil V L
2024-05-30 11:37 ` Andrea Bolognani
2024-05-31 13:18 ` Sunil V L
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230526-e398cfda73f326653323ea68@orel \
--to=ajones@ventanamicro.com \
--cc=abologna@redhat.com \
--cc=alistair.francis@wdc.com \
--cc=bin.meng@windriver.com \
--cc=dbarboza@ventanamicro.com \
--cc=liweiwei@iscas.ac.cn \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=sunilvl@ventanamicro.com \
--cc=zhiwei_liu@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).