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/de...@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
