On Wed, Jan 31, 2024 at 11:20:41AM +0800, lixianglai wrote:
> > > 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@xxxxxxxxxx/
> > >
> > > "
> > >
> > > 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?
I thought that the second solution that you proposed above was the
same as other architectures, but reading again I think what you're
suggesting is that you'd have some logic in QEMU that ensures what
you ask to be loaded in pflash0 (CODE) would be loaded into ROM, and
what you ask to be loaded in pflash1 (VARS) would instead go into the
single pflash device for the machine?
If that's a correct understanding, my vote is emphatically against
that approach. The QEMU interface should be as "do exactly as I said"
as possible, with little to no cleverness to it. This is especially
true for a young architecture such as loongarch64, where you don't
need to be concerned about causing breakages for all the users
accumulated over decades.
> 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.
I think this is the way to go.
Note that changing this will likely requires adaptations in edk2 too.
That was the case when riscv64 made the same change.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
