On Thu, Mar 30, 2023 at 10:40:37 +0100, Daniel P. Berrangé wrote:
On Tue, Mar 28, 2023 at 04:53:13PM +0200, Peter Krempa wrote:
On Tue, Mar 21, 2023 at 16:13:22 +0100, Martin Kletzander wrote:
On Thu, Mar 16, 2023 at 05:11:46PM +0100, Peter Krempa wrote:
The data is based on the generic variant of the 7.2.0 data on x86_64.
Only modification to the '.replies' file is that KVM is reported as unavailable/unsupported.
Ideally this will be replaced by a dump captured from a real system.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> --- .../qemu_7.2.0-hvf.x86_64+hvf.xml | 183 + .../qemu_7.2.0-tcg.x86_64+hvf.xml | 264 + .../caps_7.2.0_x86_64+hvf.replies | 39399 ++++++++++++++++ .../caps_7.2.0_x86_64+hvf.xml | 3250 ++ tests/qemucaps2xmloutdata/caps.x86_64+hvf.xml | 28 + 5 files changed, 43124 insertions(+) create mode 100644 tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml create mode 100644 tests/domaincapsdata/qemu_7.2.0-tcg.x86_64+hvf.xml create mode 100644 tests/qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.replies create mode 100644 tests/qemucapabilitiesdata/caps_7.2.0_x86_64+hvf.xml create mode 100644 tests/qemucaps2xmloutdata/caps.x86_64+hvf.xml
diff --git a/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml b/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml new file mode 100644 index 0000000000..d6dc93d957 --- /dev/null +++ b/tests/domaincapsdata/qemu_7.2.0-hvf.x86_64+hvf.xml @@ -0,0 +1,183 @@ +<domainCapabilities> + <path>/usr/bin/qemu-system-x86_64</path> + <domain>hvf</domain> + <machine>pc-i440fx-7.2</machine> + <arch>x86_64</arch>
Wow, x86_64 with ...
+ <iothreads supported='yes'/> + <os supported='yes'> + <enum name='firmware'> + <value>bios</value> + <value>efi</value> + </enum> + <loader supported='yes'> + <value>/usr/share/AAVMF/AAVMF_CODE.fd</value> + <value>/usr/share/AAVMF/AAVMF32_CODE.fd</value>
... AAVMF =)
Note that this is a real caps dump we have for 7.2. If you install qemu-system-aarch64 on your x86 box it comes with the firmware which we display here.
But this caps dump is referring to <path>/usr/bin/qemu-system-x86_64</path>, not qemu-system-aarch64, so the loader must be OVMF, not AAVMF.
This is an artifcat of how domaincapstest does stuff: 'fillQemuCaps' has: if (fillStringValues(&loader->values, "/usr/share/AAVMF/AAVMF_CODE.fd", "/usr/share/AAVMF/AAVMF32_CODE.fd", "/usr/share/OVMF/OVMF_CODE.fd", NULL) < 0) So the output files have this fake data without any consideration. Arguably it would be a better idea to simply fill this with obviously fake strings.