Commit d4005609 added "altered" capabilities replies output in order to fake a 'query-sev-capabilities' reply from QEMU. This worked fine for the 2.12 processing for qemuxml2argvtest until the next capabilities was generated and the output wasn't doctored. Thus commit 6c50cef8 used DO_TEST_CAPS_VER against 2.12.0 noting that the 2.12.0 capabilities were hand edited to add AMD specific output into an Intel capabilities reply. Instead of "altering" the output or running against a specific reply that we know was altered, let's instead use the mocking capabilities to check the return from a real call and mock up return data if we determine the returned real call doesn't support compiled-in SEV. This way the qemuxml2argvtest can use the DO_TEST_CAPS_LATEST which runs only for x86_64 to determine that noting in "latest" changes with respect to SEV and effectively fake things out to generate expected output ensuring that other changes to libvirt/qemu don't somehow affect SEV support. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- tests/qemucapsprobemock.c | 50 +++++++++++++++++++ ...=> launch-security-sev.x86_64-latest.args} | 0 tests/qemuxml2argvtest.c | 2 +- 3 files changed, 51 insertions(+), 1 deletion(-) rename tests/qemuxml2argvdata/{launch-security-sev.x86_64-2.12.0.args => launch-security-sev.x86_64-latest.args} (100%) diff --git a/tests/qemucapsprobemock.c b/tests/qemucapsprobemock.c index f3f17f2116..0351b946b2 100644 --- a/tests/qemucapsprobemock.c +++ b/tests/qemucapsprobemock.c @@ -22,9 +22,15 @@ #include "internal.h" #include "viralloc.h" #include "virjson.h" +#include "virlog.h" +#include "virstring.h" #include "qemu/qemu_monitor.h" #include "qemu/qemu_monitor_json.h" +#define VIR_FROM_THIS VIR_FROM_NONE + +VIR_LOG_INIT("tests.qemucapsprobemock"); + #define REAL_SYM(realFunc) \ do { \ if (!realFunc && !(realFunc = dlsym(RTLD_NEXT, __FUNCTION__))) { \ @@ -120,3 +126,47 @@ qemuMonitorJSONIOProcessLine(qemuMonitorPtr mon, virJSONValueFree(value); return ret; } + + +static int (*realQemuMonitorJSONGetSEVCapabilities)(qemuMonitorPtr mon, + virSEVCapability **capabilities); + +int +qemuMonitorJSONGetSEVCapabilities(qemuMonitorPtr mon, + virSEVCapability **capabilities) +{ + int ret = -1; + VIR_AUTOPTR(virSEVCapability) capability = NULL; + + VIR_DEBUG("mocked qemuMonitorJSONGetSEVCapabilities"); + + REAL_SYM(realQemuMonitorJSONGetSEVCapabilities); + + ret = realQemuMonitorJSONGetSEVCapabilities(mon, capabilities); + + if (ret == 0) { + /* QEMU has only compiled-in support of SEV in which case we + * can mock up a response instead since generation of SEV output + * is only possible on AMD hardware. Since the qemuxml2argvtest + * doesn't currently distinguish between AMD and Intel for x86_64 + * if we "alter" the pseudo failure we can at least allow the + * test to succeed using the latest replies rather than a specific + * version with altered reply data */ + if (VIR_ALLOC(capability) < 0) + return -1; + + if (VIR_STRDUP(capability->pdh, "Unchecked, but mocked pdh") < 0) + return -1; + + if (VIR_STRDUP(capability->cert_chain, "Mocked cert_chain too") < 0) + return -1; + + capability->cbitpos = 47; + capability->reduced_phys_bits = 1; + VIR_STEAL_PTR(*capabilities, capability); + + return 1; + } + + return ret; +} diff --git a/tests/qemuxml2argvdata/launch-security-sev.x86_64-2.12.0.args b/tests/qemuxml2argvdata/launch-security-sev.x86_64-latest.args similarity index 100% rename from tests/qemuxml2argvdata/launch-security-sev.x86_64-2.12.0.args rename to tests/qemuxml2argvdata/launch-security-sev.x86_64-latest.args diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index ba6fd4db35..c65f6f91ee 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -3068,7 +3068,7 @@ mymain(void) DO_TEST_CAPS_ARCH_LATEST("vhost-vsock-ccw", "s390x"); DO_TEST_CAPS_ARCH_LATEST("vhost-vsock-ccw-auto", "s390x"); - DO_TEST_CAPS_VER("launch-security-sev", "2.12.0"); + DO_TEST_CAPS_LATEST("launch-security-sev"); DO_TEST("riscv64-virt", QEMU_CAPS_DEVICE_VIRTIO_MMIO); -- 2.20.1

Add some comments to describe how to set up the QEMU environment prior to running the qemucapsprobe in order to allow for the creation of consistent results. Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- tests/qemucapabilitiestest.c | 34 ++++++++++++++++++++++++++++++++-- 1 file changed, 32 insertions(+), 2 deletions(-) diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c index 00137bb415..2b6291e99e 100644 --- a/tests/qemucapabilitiestest.c +++ b/tests/qemucapabilitiestest.c @@ -200,11 +200,41 @@ mymain(void) DO_TEST("riscv64", "caps_3.0.0"); /* + * Create a QEMU build environment using a checked out version + * of the release tag, such as: + * + * git checkout -b v3.0.0 v3.0.0 + * + * Be sure the build dependencies are up to date, such as via yum: + * + * yum builddep qemu + * + * Configure the environment, such as for x86_64: + * + * ./configure --target-list=x86_64-softmmu \ + * --disable-xen --disable-strip --disable-fdt \ + * --disable-werror --enable-debug \ + * --enable-system --enable-user --enable-linux-user \ + * --with-pkgversion=v3.0.0 + * + * Build the QEMU emulator binary. + * + * Then from a clean libvirt build: + * * Run "tests/qemucapsprobe /path/to/qemu/binary >foo.replies" - * to generate updated or new *.replies data files. + * to generate updated or new *.replies data files, such as: + * + * tests/qemucapsprobe /path/to/qemu/binary > \ + * tests/qemucapabilitiesdata/caps_3.0.0.x86_64.replies * - * If you manually edit replies files you can run + * If you needed to manually edit replies files you can run * "tests/qemucapsfixreplies foo.replies" to fix the replies ids. + * + * Run "VIR_TEST_REGENERATE_OUTPUT=1 tests/qemucapabilitiestest" to + * update the corresponding tests/qemucapabilitiesdata/caps_*.xml file. + * + * May also need to run "VIR_TEST_REGENERATE_OUTPUT=1 tests/domaincapstest" + * depending on what changed. */ qemuTestDriverFree(&data.driver); -- 2.20.1

On Wed, Feb 06, 2019 at 03:38:03PM -0500, Cole Robinson wrote: I agree that this looks weird. I was trying to figure out how to make sure that QEMU is compiled with the same configuration and relying on defaults with installing distribution build dependencies is not the answer. Sure, it helps a lot to install most of the dependencies but for example, if someone is using CentOS or older version of Fedora "yum/dnf builddep qemu" would not result in the same configuration. I was playing with an idea to create some script that would run './configure --help' to get all options, the script would have a list of options that should be ignored, enabled or disabled and all the other options would be automatically enabled. This would make sure that everything is explicitly enabled and ./configure would complain if there is any missing dependency and also it would cover all new dependencies. The rest of the documentation looks good. Pavel