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@xxxxxxxxxx> > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
