Add loongarch cpu support for virt-manager

[lixianglai]

The virt-manager code is currently not perfect and lacks corresponding test cases. However, according to the suggestion, I first create a Pr for everyone to review. The following is a more detailed description：

#628

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.80%. Comparing base (eee8d09) to head (2eaa3aa).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #629   +/-   ##
=======================================
  Coverage   99.80%   99.80%           
=======================================
  Files          79       79           
  Lines       12431    12440    +9     
=======================================
+ Hits        12407    12416    +9     
  Misses         24       24           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[andreabolognani]

Oh and we're missing at least <rng> and <memballoon>. There's an allowlist deciding whether those are to be added by default, and it needs to be extended to include loongarch64 guests.

[lixianglai]

Oh and we're missing at least <rng> and <memballoon>. There's an allowlist deciding whether those are to be added by default, and it needs to be extended to include loongarch64 guests.

Thanks,I'll add them in the guest.

[andreabolognani]

@lixianglai no more comments from my side, everything looks good. Of course we want to get loongarch64 support merged into libvirt first.

[lixianglai]

@lixianglai no more comments from my side, everything looks good. Of course we want to get loongarch64 support merged into libvirt first.

Thank you very much！ I will be pushing a new version of libvirt patch this week.

[andreabolognani]

@crobinso libvirt support has now been merged, so as far as I'm concerned there are no longer any blockers to go ahead with this.

[lixianglai]

@crobinso Sorry to bother you, does this PR meet the entry requirements? Do I need to do anything?

[lixianglai]

@andreabolognani @crobinso
Hi Andrea and crobinso:
In this submission, I added a new patch, which adds optional bios type firmware for loongarch64 architecture, which essentially uses the -bios parameter to load QEMU_EFI.fd to achieve the purpose of using virt-manager internal snapshot.

I am not sure if this is within the norm, so I look forward to your comments and responses.

[andreabolognani]

@lixianglai thanks for updating the PR!

In this submission, I added a new patch, which adds optional bios type firmware for loongarch64 architecture, which essentially uses the -bios parameter to load QEMU_EFI.fd to achieve the purpose of using virt-manager internal snapshot.

This doesn't look right at all.

While it's true that the edk2 binary can be loaded using QEMU's -bios option, the firmware descriptor specification very clearly states that the "bios" interface type is intended for "Traditional x86 BIOS interface. For example, firmware built from the SeaBIOS project", and that's the meaning both libvirt and virt-manager assign to it.

It's unfortunate that virt-manger currently doesn't support internal snapshots of running VMs when using UEFI, but hacking around this limitation by having incorrect information presented to the user and passed to libvirt is not an acceptable way to address that. Please drop the new commit.

Everything else looks good to me.

Related to the overall effort, when you have a minute can you please weight in on this thread with information about support for TPM on loongarch64? That'd be very helpful. Thanks in advance!

[lixianglai]

@lixianglai thanks for updating the PR!

In this submission, I added a new patch, which adds optional bios type firmware for loongarch64 architecture, which essentially uses the -bios parameter to load QEMU_EFI.fd to achieve the purpose of using virt-manager internal snapshot.

This doesn't look right at all.

While it's true that the edk2 binary can be loaded using QEMU's -bios option, the firmware descriptor specification very clearly states that the "bios" interface type is intended for "Traditional x86 BIOS interface. For example, firmware built from the SeaBIOS project", and that's the meaning both libvirt and virt-manager assign to it.

It's unfortunate that virt-manger currently doesn't support internal snapshots of running VMs when using UEFI, but hacking around this limitation by having incorrect information presented to the user and passed to libvirt is not an acceptable way to address that. Please drop the new commit.

Oh, that's a shame. Does the community have any plans or ideas to solve the problem of not being able to create snapshots when using UEFI firmware? Since the variable storage is configured read-only when flashmode is stateless, there is no write security problem in this mode. Can we allow the creation of internal snapshots in this mode？

Everything else looks good to me.

Related to the overall effort, when you have a minute can you please weight in on this thread with information about support for TPM on loongarch64? That'd be very helpful. Thanks in advance!

Ok，I will reply to it as soon as possible。

[phrdina]

Just a note about snapshots to clarify current state.

When UEFI is used the issue with internal snapshots for running VM is that QEMU will try to store memory state in the varstore as that is the first storage where it can be saved. That's the reason why libvirt and because of that virt-manager don't support creating internal snapshot of running VM.

Upstream virt-manager (not part of any release yet) supports creating external snapshots that work with running VM with UEFI and that's what upstream virt-manager will prefer now if supported by libvirt.

[andreabolognani]

@phrdina thanks for providing this update! It's indeed amazing news. I've just tried it with my loongarch64 VM and it worked flawlessly :)

Do you think you could merge this PR now? AFAICT all of @crobinso's original feedback has been addressed, so I don't think it's necessary to wait for him to look at it again if me and you both are happy with the current version.

[phrdina]

Will look at it today and if I don't see anything will merge it as well.

[andreabolognani]

Thanks @phrdina! And thanks @lixianglai for your patience and excellent work both here and on the libvirt side :)

[lixianglai]

@andreabolognani @phrdina @crobinso Thank you very much for your help in reviewing the code and giving your opinions, and also thank you for your recognition of my work !!!