[libvirt PATCH v3 5/5] Add second qom-list-types call to test data.

Peter Krempa pkrempa at redhat.com
Wed Apr 22 06:43:21 UTC 2020


On Tue, Apr 21, 2020 at 16:43:47 -0400, tobin wrote:
> On 2020-04-21 04:50, Peter Krempa wrote:
> > On Mon, Apr 20, 2020 at 15:25:10 -0400, Tobin Feldman-Fitzthum wrote:
> > > We make an additional call to qom-list-types. Adjust
> > > qemucapabilitiesdata accordingly.
> > > 
> > > Signed-off-by: Tobin Feldman-Fitzthum <tobin at linux.vnet.ibm.com>
> > > ---
> > >  .../caps_2.10.0.aarch64.replies               |  2699 ++-
> > >  .../caps_2.10.0.ppc64.replies                 |  2799 +++-
> > >  .../caps_2.10.0.s390x.replies                 |  1027 +-
> > >  .../caps_2.10.0.x86_64.replies                |  1708 +-
> > >  .../caps_2.11.0.s390x.replies                 |  1063 +-
> > >  .../caps_2.11.0.x86_64.replies                |  1692 +-
> > >  .../caps_2.12.0.aarch64.replies               |  2912 +++-
> > >  .../caps_2.12.0.ppc64.replies                 |  2947 +++-
> > >  .../caps_2.12.0.s390x.replies                 |  1087 +-
> > >  .../caps_2.12.0.x86_64.replies                |  1767 +-
> > >  .../caps_3.0.0.ppc64.replies                  |  2979 +++-
> > >  .../caps_3.0.0.s390x.replies                  |  1117 +-
> > >  .../caps_3.0.0.x86_64.replies                 |  1783 +-
> > >  .../caps_3.1.0.ppc64.replies                  |  2999 +++-
> > >  .../caps_3.1.0.x86_64.replies                 |  1803 +-
> > >  .../caps_4.0.0.aarch64.replies                |  3175 +++-
> > >  .../caps_4.0.0.ppc64.replies                  |  3171 +++-
> > >  .../caps_4.0.0.s390x.replies                  |  1259 +-
> > >  .../caps_4.0.0.x86_64.replies                 |  1915 ++-
> > >  .../caps_4.1.0.x86_64.replies                 |  2155 ++-
> > >  .../caps_4.2.0.aarch64.replies                |  3355 +++-
> > >  .../caps_4.2.0.ppc64.replies                  |  3208 +++-
> > >  .../caps_4.2.0.s390x.replies                  |  1264 +-
> > >  .../caps_4.2.0.x86_64.replies                 |  2244 ++-
> > >  .../caps_5.0.0.aarch64.replies                |  3391 +++-
> > >  .../caps_5.0.0.ppc64.replies                  | 13986
> > > +++++++++-------
> > >  .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml |  1214 +-
> > >  .../caps_5.0.0.x86_64.replies                 |  2267 ++-
> > >  28 files changed, 64830 insertions(+), 8156 deletions(-)
> > 
> > Note that these changes must be part of the commit which actually addss
> > the calls
> > 
> 
> Got it. My bad.
> 
> > > 
> > > diff --git a/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
> > > b/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
> > > index c75d4ab8a7..a9587e24ed 100644
> > > --- a/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
> > > +++ b/tests/qemucapabilitiesdata/caps_2.10.0.aarch64.replies
> > > @@ -3078,12 +3078,2587 @@
> > >    "id": "libvirt-6"
> > >  }
> > > 
> > > +{
> > > +  "execute": "qom-list-types",
> > > +  "id": "libvirt-7"
> > > +}
> > 
> > We already do call 'qom-list-types' once visible as command libvirt-6
> > above. You really should re-use the data rather than calling it again.
> 
> My thinking was that the check for TCG should mimic the checks for KVM.
> Given that it is an accelerator rather than a device, it didn't seem
> right to put it in the virQEMUCapsProbeQMPDevices function, although

In that case you can extract the call does the QMP query and reuse data
across two function calls with data as argument, but in the end I don't
think it's really necessary.

> I agree that it is inelegant to make an extra QMP query.
> 
> Since the capability is added only when accel-tcg is not present in
> the output of qom-list-types, it can't be set via the array
> like the other devices are. I could move virQEMUCapsProbeQMPTCGState to
> be inside of virQEMUCapsProbeQMPDevices and use the same values. Perhaps
> that would be best? I will prepare update soon.

Yes you'll need to add special code for it. At that point IMO
virQEMUCapsProbeQMPDevices should be renamed to ...ProbeQMPTypes or
something like that to match.




More information about the libvir-list mailing list