Re: [libvirt PATCH V2 0/4] add loongarch support for libvirt
Hi All,
Added my notes below.
Thanks,
Chao
On 2024/1/30 16:59, lixianglai wrote:
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.
On Fri, Jan 12, 2024 at 02:32:43PM +0800, Xianglai Li wrote:
Hello, Everyone:
This patch series adds libvirt support for loongarch.Although the bios
path and name has not been officially integrated into qemu and we think
there are still many shortcomings, we try to push a version of patch to
the community according to the opinions of the community, hoping to
listen to everyone's opinions. Anyway we have a version of libvirt that
supports loongarch.
You can also get libvirt's patch from the link below:
https://gitlab.com/lixianglai/libvirt
branch: loongarch
Since the patch associated with loongarch has not yet been submitted to
the virt-manager community, we are providing a temporary patch with
loongarch for the time being patch's virt-manager, the open source work
of virt-manager adding loongarch will be followed up later or
synchronized with the open source libvirt.
You can get the virt-manager code with loongarch patch from the link below:
https://github.com/lixianglai/virt-manager
branch: loongarch
It's really great that you're considering the entire stack, all the
way up to virt-manager, while working on this! :)
Oh! Thanks!
:)
loongarch's virtual machine bios is not yet available in qemu, so you can
get it from the following link
https://github.com/lixianglai/LoongarchVirtFirmware
(Note: You should clone the repository using git instead of downloading the
file via wget or you'll get xml)
We named the bios QEMU_EFI.fd, QEMU_VARS.fd is used to store pflash images of
non-volatile
variables.After installing qemu-system-loongarch64,You can install the
loongarch bios by executing the script
install-loongarch-virt-firmware.sh
To clarify, loongarch support has been merged into upstream edk2
already, right? And the contents of this repository are just for
convenience, since loongarch builds of edk2 have generally not made
it into distros yet? I think I might have asked about this already,
sorry O:-)
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/LoongArchQemuPkg/Readme.md
this repository are just for convenience. :)
BTW, LoongArchVirt under OvmfPkg is being committed to upstream, I guess
it will be merged before the stable202402, please refer to:
https://bugzilla.tianocore.org/show_bug.cgi?id=4584
https://edk2.groups.io/g/devel/message/114526
https://github.com/tianocore/edk2/pull/5208
Most maintainer have completed the review.
Anyway, I fetched and installed this. The firmware descriptor looks
like:
{
"interface-types": [
"uefi"
],
"mapping": {
"device": "memory",
"filename": "/usr/share/edk2/loongarch64/QEMU_EFI.fd"
},
"targets": [
{
"architecture": "loongarch64",
"machines": [
"virt",
"virt-*"
]
}
],
"features": [
"acpi"
]
}
This is not what I expected: specifically, it results in libvirt
generating
-bios /usr/share/edk2/loongarch64/QEMU_EFI.fd
So only one of the two files is used, in read-only mode, and there is
no persistent NVRAM storage that the guest can use.
This is what I expected instead:
{
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode": "split",
"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"
]
}
I've tried installing such a descriptor and libvirt picks it up,
resulting in the following guest configuration:
hvm
/usr/share/edk2/loongarch64/QEMU_EFI.fd
/var/lib/libvirt/qemu/nvram/guest_VARS.fd
which in turn produces the following QEMU command line options:
-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
'{"dri
Re: On integrating LoongArch EDK2 firmware into QEMU build process
Hi Xuerui, Sorry for late reply. In fact the EDK2 repo is ready for submit, in a few days I will commit the patch set in kilaterlee/edk2 repo and execute the EDK2 CI testing. I will notify some people to review them, you are also welcome to review the patch set. And then, I'll submit the formal version patch to the EDK2 devel community. Thanks, Chao 在 2023/10/1 04:16, WANG Xuerui 写道: On 3/31/23 08:54, maobibo wrote: Xuerui, Thanks for your mail, it is a good suggestion. Now we are planing to move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi bios supporting LoongArch can be auto compiled and uploaded to qemu repo. Only that process is somwhat slow since lacking of hands, however we are doing this. Pinging: a few months have passed, and it seems this work is stalled? Given the LoongArch Linux KVM support is about to land in v6.7, it may be time to prepare the firmware and QEMU side of things, so users would no longer have to manually acquire the firmware blobs whenever they fire up their VMs. Regards Bibo, Mao 在 2023/3/30 22:06, WANG Xuerui 写道: Hi, Recently there are reportedly increased general interest in trying out LoongArch on top of QEMU, among both end users and organizations; and the EDK2 firmware port is fully upstreamed since the stable202211 version, and a build suitable for QEMU is already possible with Platform/Loongson/LoongArchQemuPkg in edk2-platforms. I think providing pre-built LoongArch firmware would make it much easier to dabble in system emulation, helping those users. (They currently have to pull a blob from yangxiaojuan/qemu-binary, and remember to pair certain version of QEMU with certain revision of the firmware blob. I'm also one of the users who can't remember which version to use, but I can always build my own; imagine the difficulty an end user would face!) So I tried to add a LoongArch build to the list stored in roms/, but discovered that edk2-platforms seems not included, because all other platforms' EDK2 packages are directly under the main edk2 repo. The question is: is integrating a platform package from edk2-platforms okay under the current build system, so we can arrange to provide edk2-platforms also as a submodule and go ahead? Or do we (the LoongArch firmware community) have to change the code organization to make necessary parts available in the main edk2 repo? CC-ing target/loongarch maintainers from Loongson too as you may have more information.
Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process
在 2023/4/3 19:04, Gerd Hoffmann 写道: On Mon, Apr 03, 2023 at 10:29:52AM +, Michael Brown wrote: On 03/04/2023 11:13, Chao Li wrote: This problem is because the gcc-12 does not yet to support the option 'mno-explicit-reloc', this option is used to open the new reloaction type for LoongArch, this new feature is very important for LoongArch, because it can reduce the binary size and improve code execution efficiency, so we turn it on when submitting the code to the EDK2 repo. Is it possible to produce a _functional_ LoongArch64 EDK2 binary without this option, even if the resulting binary is less efficient? MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch relocation type only, which I expect being the new type. So I suspect the answer is "no" because the edk2 pe loader isn't able to handle the old relocation type(s). Yes, the answer is "no", but the opposite is ture, the MdePkg/Include/IndustryStandard/PeImage.h LoongArch relocation type is older, this type appears in this list for compatiblility with binaries using the old reloaction type. If you use this type, you have to turn on the option '-mla-global-with-abs' in gcc,all global symbols will be created as "mark la" type, PE loader will use this rule to handle them. This option is mutually exclusive with 'mno-explicit-reloc', new reloaction type(s) doesn't require special type(s) to be expressed in PeImage.h, PE loader doesn't need to do anything about relocation, all of reloaction process is done in BaseTools/Source/C/GenFw/Elf64Convert.c. Thanks, Chao 在 2023/4/3 19:04, Gerd Hoffmann 写道: On Mon, Apr 03, 2023 at 10:29:52AM +, Michael Brown wrote: On 03/04/2023 11:13, Chao Li wrote: This problem is because the gcc-12 does not yet to support the option 'mno-explicit-reloc', this option is used to open the new reloaction type for LoongArch, this new feature is very important for LoongArch, because it can reduce the binary size and improve code execution efficiency, so we turn it on when submitting the code to the EDK2 repo. Is it possible to produce a _functional_ LoongArch64 EDK2 binary without this option, even if the resulting binary is less efficient? MdePkg/Include/IndustryStandard/PeImage.h lists a single loongarch relocation type only, which I expect being the new type. So I suspect the answer is "no" because the edk2 pe loader isn't able to handle the old relocation type(s). take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102384):https://edk2.groups.io/g/devel/message/102384 Mute This Topic:https://groups.io/mt/98030924/6496846 Group Owner:devel+ow...@edk2.groups.io Unsubscribe:https://edk2.groups.io/g/devel/unsub [lic...@loongson.cn] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] On integrating LoongArch EDK2 firmware into QEMU build process
Hi Bibo, Thanks for Cc to me. Hi Gerd, This problem is because the gcc-12 does not yet to support the option 'mno-explicit-reloc', this option is used to open the new reloaction type for LoongArch, this new feature is very important for LoongArch, because it can reduce the binary size and improve code execution efficiency, so we turn it on when submitting the code to the EDK2 repo. gcc-13 will support this new feature, so we expect this issue to be resolved when using gcc-13, which may be released at this month. If Fedora38 does not plan to use gcc-13 now, I suggest that CI can download a LoongArch cross gcc-13 when creating a docker image, just like EDK2 CI process. You can refer following link for more information: https://github.com/tianocore/containers/blob/main/Fedora-37/Dockerfile . EDK2 CI uses Fedora35 and Fedora37 docker images for LoongArch, they will download a LoongArch cross gcc-13 when the CI targets is LoongArch. We are really sorry about that, I think this solution will make more work for you, but I think it is the best way for now, and I believe it will be solved when Fedora uses gcc-13 in the future. Thanks, Chao 在 2023/4/3 16:51, maobibo 写道: Cc to Chao Li who is maintainer of edk2 about LoongArch support. Hi Chao, Fedora38 is used to build edk2 binary in qemu CI, cross gcc-12 is integrated on Fedora38. There is one issue when gcc-12 is used to build edk2 loongarch like this: ... but when trying to use them to compile the loongarch firmware gcc throws errors: loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-reloc what is your option about this issue? Regards Bibo, Mao 在 2023/4/1 13:11, maobibo 写道: On 2023/3/31 20:12, Gerd Hoffmann wrote: On Fri, Mar 31, 2023 at 08:54:16AM +0800, maobibo wrote: Xuerui, Thanks for your mail, it is a good suggestion. Now we are planing to move LoongArch uefi bios from edk2-platform to edk2 repo, so that uefi bios supporting LoongArch can be auto compiled and uploaded to qemu repo. Only that process is somwhat slow since lacking of hands, however we are doing this. Good, so I think it makes sense for qemu to just wait for that to happen. Related question: What are the requirements to build the firmware? Fedora 38 ships cross compiler packages ... binutils-loongarch64-linux-gnu-2.39-3.fc38.x86_64 gcc-loongarch64-linux-gnu-12.2.1-5.fc38.x86_64 ... but when trying to use them to compile the loongarch firmware gcc throws errors: loongarch64-linux-gnu-gcc: error: unrecognized command-line option ‘-mno-explicit-relocs’ I suspect gcc-12 is just too old? There is a little different about relocation between gcc-12 and gcc-13 on LoongArch, gcc-13 is required for edk2 compiler now. However I think it is actually is one issue if gcc-12 can not be used and gcc-12 is popular latest compiler for all architectures. We will solve this problem. Regards Bibo, Mao take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#102377):https://edk2.groups.io/g/devel/message/102377 Mute This Topic:https://groups.io/mt/98030924/6496846 Group Owner:devel+ow...@edk2.groups.io Unsubscribe:https://edk2.groups.io/g/devel/unsub [lic...@loongson.cn] -=-=-=-=-=-=-=-=-=-=-=-
