Re: [libvirt PATCH V2 0/4] add loongarch support for libvirt

Hi Andrea:     I'm sorry for taking so long to reply you! Hi Philippe:     When developing libvirt on loongarch, we encountered some problems related to pflash. libvirt and qemu met some difficulties in the coordination of UEFI loading. I think we need your suggestions and opinions on the solution. Oh! Thanks! :) Don't mention it. All right, The loongarch support has been merged into upstream edk2 already. And you can see a detailed description of loongarch uefi in the link below: https://github.com/tianocore/edk2-platforms/blob/master/Platform/Loongson... this repository are just for convenience. :) In the qemu code, loongarch virt machine does only create a pflash, which is used for nvram, and uefi code is loaded by rom. In summary, loongarch virt machine can use nvram with the following command: ------------------------------------------------------------------------------------------------------- /qemu-system-loongarch64 \// //-m 8G \// //-smp 4 \// //-cpu la464   \// //-blockdev '{"driver":"file","filename":"./QEMU_VARS-pflash.raw","node-name":"libvirt-pflash0-storage","auto-read-only":false,"discard":"unmap"}' \// //-blockdev '{"node-name":"libvirt-pflash0-format","read-only":false,"driver":"raw","file":"libvirt-pflash0-storage"}' \// //-machine virt,pflash=libvirt-pflash0-format  \// //-snapshot \// //-bios ./QEMU_EFI.fd  \// //-serial stdio/ ------------------------------------------------------------------------------------------------------- This is really a big difference from the following boot method, and it still looks weird. ------------------------------------------------------------------------------------------------------- /-blockdev '{"driver":"file","filename":"/usr/share/edk2/loongarch64/QEMU_EFI.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' -blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/guest_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' -blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}'/ ------------------------------------------------------------------------------------------------------- However, during the development of qemu loongarch, we also used a RISCV-like solution to create two pflash, but the qemu community suggested that we put uefi code in rom for the following reasons: https://lore.kernel.org/qemu-devel/2f381d06-842f-ac8b-085c-0419675a4872@l... " Since you are starting a virtual machine from scratch, you should take the opportunity to learn from other early mistakes. X86 ended that way due to 1/ old firmwares back-compability and 2/ QEMU pflash block protections not being implemented. IIUC if we were starting with a UEFI firmware today, the layout design (still using QEMU) would be to map the CODE area in a dumb ROM device, and the VARSTORE area in a PFlash device. Since Virt machines don't need to use Capsule update, having the CODE area in ROM drastically simplifies the design and maintainance. " Well, anyway, now that we have an issue with qemu loongarch using nvram that is incompatible with libvirt, here I have come up with two solutions to solve this problem: Option 1: If the interface type "rom-uefi" is added and the device type "rom-flash" is added, the json file should be written like this: ------------------------------------------------------------------------------------------------------- /{// //   "interface-types": [// ////"rom-uefi"// //   ],// //   "mapping": {// ////"device": "rom-flash",// //     "executable": {// //       "filename": "/usr/share/edk2/loongarch64/QEMU_EFI.fd",// //       "format": "raw"// //     },// //     "nvram-template": {// //       "filename": "/usr/share/edk2/loongarch64/QEMU_VARS.fd",// //       "format": "raw"// //     }// //   },// //   "targets": [// //     {// //       "architecture": "loongarch64",// //       "machines": [// //         "virt",// //         "virt-*"// //       ]// //     }// //   ],// //   "features": [// //       "acpi"// //   ]/  ------------------------------------------------------------------------------------------------------- Then add the parsing of the new interface types in libvirt and load QEMU_CODE.fd as -bios and QEMU_VARS.fd as nvram when creating the command line, generating commands like the following:  ------------------------------------------------------------------------------------------------------- /qemu-system-loongarch64 \// //-m 8G \// //-smp 1 \// //-cpu la464   \// //-blockdev '{"driver":"file","filename":"////usr/share/edk2/loongarch64/QEMU_VARS.fd/","node-name":"libvirt-pflash0-storage","auto-read-only":false,"discard":"unmap"}' \// //-blockdev '{"node-name":"libvirt-pflash0-format","read-only":false,"driver":"raw","file":"libvirt-pflash0-storage"}' \// //-machine virt,pflash=libvirt-pflash0-format  \// //-snapshot \// //-bios /////usr/share/edk2/loongarch64///QEMU_EFI.fd \// //-serial stdio/ ------------------------------------------------------------------------------------------------------- Option 2: Solution 2 mainly starts from qemu. Now the rom that bios is loaded into is a memory region that cannot be configured with attributes, so we imagine abstracting rom as a device, creating it during machine initialization and setting "pflash0" attribute for it. Then create a pflash and set its property to "pflash1", so our startup command will look like this:  ------------------------------------------------------------------------------------------------------- /qemu-system-loongarch64 \// //-m 8G \// //-smp 1 \// //-cpu la464   \// //-blockdev '{"driver":"file","filename":"/usr/share/edk2/loongarch64/QEMU_EFI.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \// //-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \// //-blockdev '{"driver":"file","filename":"/usr/share/edk2/loongarch64/QEMU_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \// //-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"raw","file":"libvirt-pflash1-storage"}' \// //-machine virt,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format \// //-snapshot \// //-serial stdio/  ------------------------------------------------------------------------------------------------------- This way, without modifying libvirt, QEMU_CODE.fd can be loaded into the rom, but it is still a little strange that it is clearly rom but set a "pflash0" attribute, which can be confusing. Thank you very much for pointing out the problem, lxde iso is missing efiboot.img file so that the virtual machine UEFI can not recognize efi partition caused by the problem has been notified to the relevant personnel, I believe that the next version of libvirt patch will be shipped to use lxde iso. Thanks, Xianglai.