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

> > 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 \ > > -bios ./QEMU_EFI.fd > > > > ------------------------------------------------------------------------------------------------------- > > > > 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: > > > >  ------------------------------------------------------------------------------------------------------- > > > > -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 \ > > -bios /usr/share/edk2/loongarch64///QEMU_EFI.fd \ > > > > ------------------------------------------------------------------------------------------------------- > > > > 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: > > > >  ------------------------------------------------------------------------------------------------------- > > > > -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 \ > > > >  ------------------------------------------------------------------------------------------------------- > > > > 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. > > We recently had a very similar discussion regarding EFI booting on > RISC-V. > > Personally I would prefer to see the approach with two pflash > devices, one read-only and one read/write, adopted. This is pretty > much the de-facto standard across architectures: x86_64, aarch64 and > riscv64 all boot edk2 this way. > > I understand the desire to simplify things where possible, and I am > sympathetic towards it. If we could boot from just rom, without using > pflash at all, I would definitely see the appeal. However, as noted > earlier, in the case of EFI having some read/write storage space is > necessary to expose the full functionality, so going without it is > not really an option. > > With all the above in mind, the cost of loongarch64 doing things > differently from other architectures seems like it would outweight > the benefits, and I strongly advise against it. Hi Andrea :     So, just to be clear, you're not suggesting either of the options I suggested above,     are you? And still recommend that we use a two-piece pflash solution similar to other architectures,      right?

Hi Philippe :   I look forward to your reply and the comments of other members of the qemu community very much.  If everyone has no opinions, I will submit a patch to the community to change the loading mode of qemu under loongarch architecture to UEFI with two pieces of pflash.