[libvirt] [PATCH 0/2] A couple of capabilities related adjustments

John Ferlan posted 2 patches 5 years, 3 months ago
Test syntax-check passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/libvirt tags/patchew/20190123205928.14800-1-jferlan@redhat.com
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%)
[libvirt] [PATCH 0/2] A couple of capabilities related adjustments
Posted by John Ferlan 5 years, 3 months ago
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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list