On Tue, 2018-03-27 at 09:26 -0500, Brijesh Singh wrote: > > You're going to have to either fetch capabilities from your own > > QEMU 2.12 binary or hack it up by adding the return data in the > > right spot and call tests/qemucapsfixreplies to re-align the ids. > > Right, running the tests/qemucapsprobe on my system I see that > query-sev-capabilities command returns a valid data. In my local branch, > I updated the caps_2.12.0.x86_64.replies with response. With those > changes I no longer get the internal error but > tests/qemucapabilitiestest still fails for me with below error message: > > 29) caps_2.12.0(x86_64) ... > In > '/home/amd/workdir/upstream/libvirt/tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml': > Offset 7143 > Expect [060] > Actual [306] > > It is basically pointing to microcode version change, do I need to > update the cap with new version ? After you've tweaked the .replies file, you can just run $ VIR_TEST_REGENERATE_OUTPUT=1 make check and the .xml file will be refreshed, microcode version and all. > > I think you can get away with the latter, as we're going to want > > to refresh the replies files once 2.12 is released anyway. > > I am not able to follow this comment, let me explain the situation. > The QEMU_CAPS_SEV flag was set to indicate QEMU supports the > 'query-sev-capabilities' QMP command and sev-guest object. That merely > indicates that command exist but does not means that command will always > execute successfully. e.g If hypervisor does not support the SEV feature > then query-sev-capabilities will return error. That means if > tests/qemucapsprobe is used to generate the replies on non-SEV capable > system then .replies will not contain output of query-sev-capabilities > command. Will this be an issue ? Not at all. That's already the case for a lot of features. My comment was merely pointing out that the capabilities data we have in the tree right now is for QEMU 2.12.0-rc0, and once QEMU 2.12 is officially released we will want to collect it again. It's not something you need to worry about, really :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
