[libvirt] [PATCH v1 6/7] tests: Update qemucapabilitiesdata

Michal Privoznik mprivozn at redhat.com
Tue Apr 17 08:52:40 UTC 2018


On 04/17/2018 10:39 AM, Peter Krempa wrote:
> On Thu, Apr 12, 2018 at 18:39:51 +0200, Michal Privoznik wrote:
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> 
> So this really needs to be squashed into the previous commit. Also It
> would help if you'd describe what you are doing since it does not seem
> to be the classic churn from just updating the ordering of
> capabilities.
> 
> Also I'd suggest to not add a sign-off to patches which you don't intend
> to push, since the commit hook will save you from doing a mistake.
> 
>> ---
> 
> [...]
> 
>> diff --git a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> index ca98ee14db..bc82624335 100644
>> --- a/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> +++ b/tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml
>> @@ -160,7 +160,7 @@
>>    <flag name='isa-serial'/>
>>    <version>2001001</version>
>>    <kvmVersion>0</kvmVersion>
>> -  <microcodeVersion>58992</microcodeVersion>
>> +  <microcodeVersion>59147</microcodeVersion>
> 
> I think this change is not warranted here. If you regenerated the
> capabilities, you need to make sure that the emulators you use have the
> same config, so that we don't change anything that's not necessary.
> 
> There are a few other examples here, e.g. with the cpu flags.
> 
> It's a shame though that object-add QMP command is not introspectable
> via the QMP schema. It would quite simplify this series.
> 
> NACK to change to data which is not relevant to the capability you are
> introducing.
> 

In fact it is. In the tests, microcode version is just the file length
of input .replies file. It doesn't reflect any real microcode version.
Just look at testQemuCaps() from tests/qemucapabilitiestest.c.

Michal




More information about the libvir-list mailing list