[libvirt] [PATCH v2 04/33] domaincapstest: Add test data for QEMU 2.9.0

Jiri Denemark jdenemar at redhat.com
Wed Feb 22 09:06:53 UTC 2017


On Tue, Feb 21, 2017 at 09:23:34 -0500, John Ferlan wrote:
> 
> 
> On 02/15/2017 11:44 AM, Jiri Denemark wrote:
> > Signed-off-by: Jiri Denemark <jdenemar at redhat.com>
> > ---
> > 
> > Notes:
> >     Version 2:
> >     - no change
> > 
> >  .../domaincapsschemadata/qemu_2.9.0-tcg.x86_64.xml | 116 +++++++++++++++++++++
> >  tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml   | 116 +++++++++++++++++++++
> >  tests/domaincapstest.c                             |   8 ++
> >  3 files changed, 240 insertions(+)
> >  create mode 100644 tests/domaincapsschemadata/qemu_2.9.0-tcg.x86_64.xml
> >  create mode 100644 tests/domaincapsschemadata/qemu_2.9.0.x86_64.xml
> > 
> 
> Will this "eventually" need an updated when qemu 2.9 is complete? Or is
> it "close enough"?

Probably not, but we can't tell until 2.9 is complete :-)

> > diff --git a/tests/domaincapstest.c b/tests/domaincapstest.c
> > index 28d8609ac..9b64f2c18 100644
> > --- a/tests/domaincapstest.c
> > +++ b/tests/domaincapstest.c
> > @@ -453,6 +453,14 @@ mymain(void)
> >                   "/usr/bin/qemu-system-x86_64", NULL,
> >                   "x86_64", VIR_DOMAIN_VIRT_QEMU);
> >  
> > +    DO_TEST_QEMU("2.9.0", "caps_2.9.0",
> > +                 "/usr/bin/qemu-system-x86_64", NULL,
> > +                 "x86_64", VIR_DOMAIN_VIRT_KVM);
> > +
> > +    DO_TEST_QEMU("2.9.0-tcg", "caps_2.9.0",
> > +                 "/usr/bin/qemu-system-x86_64", NULL,
> > +                 "x86_64", VIR_DOMAIN_VIRT_QEMU);
> > +
> >      DO_TEST_QEMU("2.7.0", "caps_2.7.0",
> >                   "/usr/bin/qemu-system-s390x", NULL,
> >                   "s390x", VIR_DOMAIN_VIRT_KVM);
> 
> What about "s390x" for 2.9.0?  Since later patches seem to make some
> alterations for s390...

s390 provides the required functionality since 2.8.0, thus we already
have the test data in place.

> Unrelated to this patch question - should these always be updated for
> each cpu type for each release?

I don't think we need to always update all of them at once. I tend to
add test data for things we want to test which are not present in
existing data sets.

Jirka




More information about the libvir-list mailing list