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

[Laszlo Ersek <lersek@redhat.com>]

On 2/22/24 16:49, Andrea Bolognani wrote:
> 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.
> 

I'm surprised that the UEFI payload (?) on *physical* loongarch machines
is supposed (?) to launch from ROM. That means "no firmware updates",
which is quite unusual nowadays. Recent versions of the UEFI spec have
introduced a bunch of interfaces just for standardizing firmware
updates, meaning both add-on card firmware, and platform/system firmware.

(Unfortunately, I have nothing "constructive" to add; apologies.)

Laszlo