providers/libvirt: add support for aarch64 host

[xutao323]

Create domainXML for aarch64/arm64 arch in cloud-provider/libvirt, and check iommu=on for virtio device only in test.

This patch is similar to 63a002c, and ARM CCA CVM will be added later like 4422f14, when it's ready. This will initially support non-CCA workloads and eventually allow the creation of a Realm on a local/remote host.

go test on aarch64/arm64 host:

$ LIBVIRT_URI="qemu+ssh://[email protected]/system?no_verify=1" go test -v
=== RUN   TestCloudInit
temp file: /tmp/CloudInit-12504980.iso--- PASS: TestCloudInit (0.01s)
=== RUN   TestInMemoryCopier
--- PASS: TestInMemoryCopier (0.00s)
=== RUN   TestLibvirtConnection
2024/12/06 11:27:46 [adaptor/cloud/libvirt] Created libvirt connection
--- PASS: TestLibvirtConnection (0.64s)
=== RUN   TestGetArchitecture
2024/12/06 11:27:47 [adaptor/cloud/libvirt] Created libvirt connection
--- PASS: TestGetArchitecture (0.63s)
=== RUN   TestCreateDomainXMLs390x
2024/12/06 11:27:47 [adaptor/cloud/libvirt] Created libvirt connection
    libvirt_test.go:110: Skipping because architecture is [aarch64] and not [s390x].
--- SKIP: TestCreateDomainXMLs390x (0.61s)
=== RUN   TestCreateDomainXMLaarch64
2024/12/06 11:27:48 [adaptor/cloud/libvirt] Created libvirt connection
--- PASS: TestCreateDomainXMLaarch64 (0.60s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/src/cloud-providers/libvirt	2.590s

go test on x86_64/amd64 host:

$ LIBVIRT_URI="qemu+ssh://[email protected]/system?no_verify=1" go test -v
=== RUN   TestCloudInit
temp file: /tmp/CloudInit-2407912272.iso--- PASS: TestCloudInit (0.00s)
=== RUN   TestInMemoryCopier
--- PASS: TestInMemoryCopier (0.00s)
=== RUN   TestLibvirtConnection
2024/12/06 11:34:11 [adaptor/cloud/libvirt] Created libvirt connection
--- PASS: TestLibvirtConnection (0.60s)
=== RUN   TestGetArchitecture
2024/12/06 11:34:12 [adaptor/cloud/libvirt] Created libvirt connection
--- PASS: TestGetArchitecture (0.36s)
=== RUN   TestCreateDomainXMLs390x
2024/12/06 11:34:12 [adaptor/cloud/libvirt] Created libvirt connection
    libvirt_test.go:110: Skipping because architecture is [x86_64] and not [s390x].
--- SKIP: TestCreateDomainXMLs390x (0.28s)
=== RUN   TestCreateDomainXMLaarch64
2024/12/06 11:34:12 [adaptor/cloud/libvirt] Created libvirt connection
    libvirt_test.go:147: Skipping because architecture is [x86_64] and not [aarch64].
--- SKIP: TestCreateDomainXMLaarch64 (0.29s)
PASS
ok  	github.com/confidential-containers/cloud-api-adaptor/src/cloud-providers/libvirt	1.541s

libvirt E2E test needs additional changes in build scripts (operator and cloud-api-adaptor to build the new code) plus podvm to run on aarch64/arm64 machine. Those will be separated as they're more related to build.

E2E tests were done on aarch64/arm64 baremetal server to run demo peer-pods:
(based on v0.9.0 and v0.10.0 podvm, latest v0.11.0 podvm introduced cached artifacts in #2074).

$ kubectl get pods -o wide
NAME             READY   STATUS    RESTARTS   AGE     IP           NODE                 NOMINATED NODE   READINESS GATES
busybox-remote   1/1     Running   0          6m16s   10.244.1.8   peer-pods-worker-0   <none>           <none>

$ kubectl exec pods/busybox-remote -- uname -srim
Linux 5.4.0-136-generic aarch64 unknown

$ kcli list vm
+-------------------------------+--------+-----------------+------------+-----------+---------+
|              Name             | Status |        Ip       |   Source   |    Plan   | Profile |
+-------------------------------+--------+-----------------+------------+-----------+---------+
|      peer-pods-ctlplane-0     |   up   |  192.168.122.20 | ubuntu2204 | peer-pods |  kvirt  |
|       peer-pods-worker-0      |   up   | 192.168.122.199 | ubuntu2204 | peer-pods |  kvirt  |
| podvm-busybox-remote-62291ece |   up   | 192.168.122.237 |            |           |         |
+-------------------------------+--------+-----------------+------------+-----------+---------+

$ virsh list
 Id   Name                            State
-----------------------------------------------
 70   peer-pods-ctlplane-0            running
 71   peer-pods-worker-0              running
 72   podvm-busybox-remote-62291ece   running 

[stevenhorsman]

I think there is probably an opportunity to refactor the domainXML creation functions so there is less duplicated code, but I think that could be done as a later step, if necessary

[xutao323]

Thanks for the review. Agreed that domainXML creation can be refactored for those common configs, and it can be done separately before adding new CVM configs.

For the test failures, gofmt -s from golangci-lint is fixed. Latest tests hit #2179 and it shall be irrelevant.

[bpradipt]

/lgtm

[xutao323]

Thanks @stevenhorsman @bpradipt for reviewing the changes.