[libvirt] [PATCH 0/2] A couple of capabilities related adjustments
Peeling the onion in my series to update the QEMU capabilites replies: https://www.redhat.com/archives/libvir-list/2019-January/msg00793.html resulted in consideration of a possible alternative to how the SEV capability checking "works". As it turns out, the initial changes "massaged" the .replies output to add a "fake" reply on an Intel CPU for what amounts to AMD specific output. This naturally resulted in a "problem" when the next batch of a capabilites was created and there was no sev output, so an adjustment was made to limit what was tested to one capabilities version. Since there isn't separate Intel/AMD x86_64 output, the first patch in the series will alter the return for virQEMUCapsProbeQMPSEVCapabilities so that 0 would "change" into 1 for the mocked environment and allow the sev-guest bit to be set which allows QEMU_CAPS_SEV_GUEST to be set for any x86_64 arch environment. This only affects how qemuxml2argvtest handles generation of DO_TEST_CAPS_LATEST for launch-security-sev. The XML generated isn't modified, nor is the reply output data since that's separate. The key is the "0" return meaning a GenericError which is assumed to be returned when compiled-in support for SEV isn't there, but *could* be if the underlying hardware arch supported it. For the test purpose we have, that doesn't matter unless someone wants to go through the trouble of separating the caps*.replies files into "Intel" and "AMD" specific output. So yes a "workaround" of sorts, but nonetheless an alternative to the current static checking of what's been deemed incorrect reply data. The second somewhat unrelated patch is fallout of the review discussion about having a consistent process. I suspect it's a "starting point" from which we can evolve to create a consistent/repeatable process to create caps*.replies. John Ferlan (2): tests: Add mocking for qemuMonitorJSONGetSEVCapabilities tests: Document procedure to build QEMU for *.replies generation tests/qemucapabilitiestest.c | 34 ++++++++++++- tests/qemucapsprobemock.c | 50 +++++++++++++++++++ ...=> launch-security-sev.x86_64-latest.args} | 0 tests/qemuxml2argvtest.c | 2 +- 4 files changed, 83 insertions(+), 3 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.x86_64-2.12.0.args => launch-security-sev.x86_64-latest.args} (100%) -- 2.20.1
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@redhat.com> --- 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
On 1/23/19 3:59 PM, John Ferlan wrote:
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.
Seems reasonable to me. This is an improvement over the current state that appears to implicitly require manually editing caps replies to list SEV support. The downside is that there's no way to test lack of SEV support now, but we weren't testing that anyways it seems. More complete solutions adding caps files for both intel and AMD sound nicer but are also a lot more work. Still it seems like it would be worthwhile to have actual AMD capabilities output in the test suite, even if it's just a single example. But I guess we would need to fine someone with the proper hardware and extend the macros in qemuxml2argv to handle it. Anyways...
Signed-off-by: John Ferlan <jferlan@redhat.com> --- 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 */
My brain kinda chokes on this comment. Maybe something like * QEMU only reports SEV support if it was compiled on appropriate AMD * hardware. Report SEV unconditionally here so we aren't dependent on * AMD specific output in our test capabilities .replies Or something like that. Reviewed-by: Cole Robinson <crobinso@redhat.com> - Cole
On Wed, Feb 06, 2019 at 03:32:44PM -0500, Cole Robinson wrote:
On 1/23/19 3:59 PM, John Ferlan wrote:
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.
Seems reasonable to me. This is an improvement over the current state that appears to implicitly require manually editing caps replies to list SEV support. The downside is that there's no way to test lack of SEV support now, but we weren't testing that anyways it seems. More complete solutions adding caps files for both intel and AMD sound nicer but are also a lot more work.
I've been working on this as a side project, like you said yourself - *lots* of work. At the moment, I don't see any other viable option that continue doing what we already do.
Still it seems like it would be worthwhile to have actual AMD capabilities output in the test suite, even if it's just a single example. But I guess we would need to fine someone with the proper hardware and extend the macros in qemuxml2argv to handle it. Anyways...
I contacted Yash about this as I'd like to move this whole process to Jenkins so we don't have to constantly trip over this with every new QEMU release, the question is whether ci.centos.org has an AMD HW available, especially EPYC-powered. Yash gave me a contact to a ci.centos.org guy and I need to carry on with the discussion. Regards, Erik
On 2/7/19 3:36 AM, Erik Skultety wrote:
On Wed, Feb 06, 2019 at 03:32:44PM -0500, Cole Robinson wrote:
On 1/23/19 3:59 PM, John Ferlan wrote:
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.
Seems reasonable to me. This is an improvement over the current state that appears to implicitly require manually editing caps replies to list SEV support. The downside is that there's no way to test lack of SEV support now, but we weren't testing that anyways it seems. More complete solutions adding caps files for both intel and AMD sound nicer but are also a lot more work.
I've been working on this as a side project, like you said yourself - *lots* of work. At the moment, I don't see any other viable option that continue doing what we already do.
What we "are" testing is that the doctored qemu 2.12 replies for an Intel machine work for this AMD environment. All the patch does is extend that slightly ;-) to starting with 2.12... Since we "fake" other things being available - it didn't seem to be too much of a reach for "just a test"... Part of my logic for taking this approach is I didn't want to make another freaking macro in the already overloaded DO_TEST_*CAPS* pile of macros that would be able to distinguish between Intel and AMD for x86_64. Additionally I never seem to be able to get generation of the capabilities output (tests/qemucapabilitiesdata/*) exactly like how any reviewer would accept, so I've just given up trying. I still dislike that some of the data doesn't come from a released version (see output grep package tests/qemucapabilitiesdata/*.xml | grep \>.*v or | grep \-, IOW: rc0, rc1, ###-g*).
Still it seems like it would be worthwhile to have actual AMD capabilities output in the test suite, even if it's just a single example. But I guess we would need to fine someone with the proper hardware and extend the macros in qemuxml2argv to handle it. Anyways...
I contacted Yash about this as I'd like to move this whole process to Jenkins so we don't have to constantly trip over this with every new QEMU release, the question is whether ci.centos.org has an AMD HW available, especially EPYC-powered. Yash gave me a contact to a ci.centos.org guy and I need to carry on with the discussion.
Automation of data that has to be reviewed and committed to git... unless I'm misunderstanding the intention. This one will perhaps sit on the shelf a bit to see if there's other comments, suggestions, ideas, or forgetaboutit's John
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@redhat.com> --- 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 1/23/19 3:59 PM, John Ferlan wrote:
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@redhat.com> --- 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 + *
AFAICT --enable-system/--enable-user/--enable-linux-user are all redundant if a manual --target-list is specified. I don't know why --disable-fdt matters, nor --enable-debug or --disable-strip. I figure less options the better, defaults should be fine
+ * 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. */
If we are getting this detailed, maybe also mention extending qemucaps2xmltest.c and qemucapabilitiestest.c for newly added capabilities files. Up to you Reviewed-by: Cole Robinson <crobinso@redhat.com> - Cole
On Wed, Feb 06, 2019 at 03:38:03PM -0500, Cole Robinson wrote:
On 1/23/19 3:59 PM, John Ferlan wrote:
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@redhat.com> --- 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 + *
AFAICT --enable-system/--enable-user/--enable-linux-user are all redundant if a manual --target-list is specified. I don't know why --disable-fdt matters, nor --enable-debug or --disable-strip. I figure less options the better, defaults should be fine
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
+ * 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. */
If we are getting this detailed, maybe also mention extending qemucaps2xmltest.c and qemucapabilitiestest.c for newly added capabilities files. Up to you
Reviewed-by: Cole Robinson <crobinso@redhat.com>
- Cole
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 2/7/19 3:28 AM, Pavel Hrdina wrote:
On Wed, Feb 06, 2019 at 03:38:03PM -0500, Cole Robinson wrote:
On 1/23/19 3:59 PM, John Ferlan wrote:
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@redhat.com> --- 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 + *
AFAICT --enable-system/--enable-user/--enable-linux-user are all redundant if a manual --target-list is specified. I don't know why --disable-fdt matters, nor --enable-debug or --disable-strip. I figure less options the better, defaults should be fine
I dunno - this was just the list I had come up with over time in a local "remind me how to do that again" file... I also peeked a bit at how Dan put together those virt-ark packages - it's a bit of digging and following links from: https://pagure.io/virt-ark or https://copr.fedorainfracloud.org/coprs/berrange/virt-ark/ to find https://pagure.io/virt-ark/blob/master/f/qemu-ark.spec.in that it seems the build uses: ./configure --prefix=/opt/qemu/%{version} \ + --target-list=x86_64-softmmu \ + --disable-xen \ + --disable-strip \ + --disable-fdt \ + --disable-werror
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.
Without a bunch of -devel packages installed - the qemu default seems to be fairly bare. As for yum/dnf - yeah that's obviously specific ;-). I recall using 'builddep' once and got an error about needing some other package installed type message, but I don't recall what it was now. But getting that led me to: dnf install $(grep ^BuildRequires libvirt.spec.in| \ cut -f2 -d' '|grep -v "\/usr/bin" | grep -v "\/usr/sbin") Unfortunately as time as gone on that isn't sufficient - I have a feeling checks in the m4 files haven't always translated into the spec.in file. Recently I had the need to try and enable as much as possible with a libvirt build and even after all the above I found I needed to : dnf install gettext-devel xhtml1-dtds libtool rpcgen gnutls-devel \ libnl3-devel cppi dnsmasq libxslt perl-XML-XPath just to get enough to allow ./autogen.sh to complete. Then if I wanted as much as possible, I had to (sorry for the line break stuff - email compose is less wide than my saved command): dnf install libblkid-devel libcap-devel libcurl-devel device-mapper-devel \ device-mapper-multipath-devel fuse-devel glusterfs-api-devel \ glusterfs-devel parted-devel python3-devel python2-devel \ libxml2-devel libssh-devel libpciaccess-devel dbus-devel \ libssh2-devel numactl-devel sanlock-devel libtirpc-devel \ yajl-devel libiscsi-devel libcap-ng-devel librados-devel zfs-fuse \ libpcap-devel iscsi-initiator-utils librbd-devel audit-libs-devel \ polkit-devel It's an interesting "exercise' to start from ground zero every once in a while. I'm sure the CI builds have a list of things that get installed for a more complete environment, but I didn't peek at that list.
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
+ * 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. */
If we are getting this detailed, maybe also mention extending qemucaps2xmltest.c and qemucapabilitiestest.c for newly added capabilities files. Up to you
Hmm... true, it's a complex and intertwined pile of files. Like 1/2 - I'll still hold on to this for a bit more - maybe more brilliant ideas will be generated ;-) John
Reviewed-by: Cole Robinson <crobinso@redhat.com>
- Cole
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Cole Robinson -
Erik Skultety -
John Ferlan -
Pavel Hrdina