[PATCH 17/21] qemuxml2(xml|argv)test: Test real state of things with 'x86-kvm-32-on-64'

Ján Tomko jtomko at redhat.com
Thu Jan 6 18:39:02 UTC 2022


On a Thursday in 2022, Peter Krempa wrote:
>As demonstrated by the qemuxml2xmltest DO_TEST_CAPS_LATEST data based on
>the 'x86-kvm-32-on-64' test case the post parse CPU selection code which
>fills in the CPU into the definition does not have exactly the same
>logic as we used to have when the cpu model was picked when formatting
>the commandline.
>
>Change the qemuxml2argv test to use DO_TEST_CAPS_LATEST too as it
>doesn't really make sense to test this on fake data.
>

Consider also adding a versioned test with QEMU 4.1.0 data which executes the
code path in qemuBuildCpuCommandLine that hardcodes qemu32 for i686
guests.

Ever since
commit 5e939cea896fb3373a6f68f86e325c657429ed3d
     qemu: Store default CPU in domain XML
we fill the default model in post-parse.

The qemuDomainDefSetDefaultCPU function is probably missing:

if (def->os.arch == VIR_ARCH_I686)
     virStringReplace(model, "64", "32");

>This possibly shows that there's a regression/change in behaviour which
>happened when the CPU code was changed.
>
>Signed-off-by: Peter Krempa <pkrempa at redhat.com>
>---
> ...gs => x86-kvm-32-on-64.x86_64-latest.args} | 14 +++++-----
> tests/qemuxml2argvtest.c                      |  2 +-
> .../x86-kvm-32-on-64.x86_64-latest.xml        | 27 +++++++++++++++++++
> tests/qemuxml2xmltest.c                       |  2 ++
> 4 files changed, 38 insertions(+), 7 deletions(-)
> rename tests/qemuxml2argvdata/{x86-kvm-32-on-64.args => x86-kvm-32-on-64.x86_64-latest.args} (53%)
> create mode 100644 tests/qemuxml2xmloutdata/x86-kvm-32-on-64.x86_64-latest.xml
>

Reviewed-by: Ján Tomko <jtomko at redhat.com>

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20220106/11c1b7fe/attachment-0001.sig>


More information about the libvir-list mailing list