Re: [PATCH V2 1/1] loongarch: Change the UEFI loading mode to loongarch

[Andrea Bolognani <abologna@redhat.com>]

On Thu, Feb 22, 2024 at 04:10:20PM +0100, Philippe Mathieu-Daudé wrote:
> On 19/2/24 11:34, Xianglai Li wrote:
> > The UEFI loading mode in loongarch is very different
> > from that in other architectures:loongarch's UEFI code
> > is in rom, while other architectures' UEFI code is in flash.
> >
> > loongarch UEFI can be loaded as follows:
> > -machine virt,pflash=pflash0-format
> > -bios ./QEMU_EFI.fd
> >
> > Other architectures load UEFI using the following methods:
> > -machine virt,pflash0=pflash0-format,pflash1=pflash1-format
> >
> > loongarch's UEFI loading method makes qemu and libvirt incompatible
> > when using NVRAM, and the cost of loongarch's current loading method
> > far outweighs the benefits, so we decided to use the same UEFI loading
> > scheme as other architectures.
>
> This is unfortunate, since LoongArch was a fresh new target added,
> we had the possibility to make this right. Are you saying libvirt
> didn't accept to add support for the correct HW behavior which is
> to simply load a ROM instead of a PNOR flash device? Could you
> point me to the libvirt discussion please? libvirt is very good at
> supporting a broad range of legacy options, so I'm surprise 'Doing
> The Right Thing' is too costly.
>
> What is really the problem here, is it your use of the the -bios
> CLI option?

Hi Philippe,

the thread is here:

  https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/7PV3IXWNX3UXQN2BNV5UA5ASVXNVOQIF/

Unfortunately hyperkitty makes it impossible to link to a subthread
directly, so you're going to have to scroll around. The relevant part
of the discussion happens entirely as reply to the cover letter.

You were actually CC'd to that subthread right after my first reply,
so you should be able to find the relevant messages locally as well,
which is probably going to be more convenient.

In short, the discussion is similar to the one we had a while ago
about RISC-V, and my argument in favor of this change is largely the
same: barring exceptional circumstances, the overall (maintenance,
cognitive) cost of straying from the established norm, now spanning
three existing architectures, likely outweighs the benefits.

-- 
Andrea Bolognani / Red Hat / Virtualization