[libvirt] [PATCH] tests: reintroduce tests for libxl's legacy nested setting

Erik Skultety eskultet at redhat.com
Mon Oct 1 08:35:29 UTC 2018


On Mon, Oct 01, 2018 at 08:04:57AM +0200, Erik Skultety wrote:
> On Thu, Sep 27, 2018 at 08:25:53AM -0600, Jim Fehlig wrote:
> > On 9/27/18 3:29 AM, Erik Skultety wrote:
> > > On Wed, Sep 26, 2018 at 11:31:19AM -0600, Jim Fehlig wrote:
> > > > The preferred location for setting the nested CPU flag changed in
> > > > Xen 4.10 and is advertised via the LIBXL_HAVE_BUILDINFO_NESTED_HVM
> > > > define.  Commit 95d19cd0 changed libxl to use the new preferred
> > > > location but unconditionally changed the tests, causing 'make check'
> > > > failures against Xen < 4.10 that do not contain the new location.
> > > >
> > > > Commit e94415d5 fixed the failures by only running the tests when
> > > > LIBXL_HAVE_BUILDINFO_NESTED_HVM is defined. Since libvirt supports
> > > > several versions of Xen that use the old nested location, it is
> > > > prudent to test the flag is set correctly. This patch reintroduces
> > > > the tests for the legacy location of the nested setting.
> > > >
> > > > Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> > > > ---
> > > >
> > > > We could probably get by with one test for the old nested location,
> > > > in which case I'd drop vnuma-hvm-legacy-nest. Any opinions on that?
> > >
> > > I verified with a few different platforms. I don't have a better idea on what
> > > to do about the legacy tests, we either add more (even identical) test files
> > > or we figure out some black magic to do the same thing (not preferred).
> > > Anyway, to answer your question, even though it might be enough, I'd like to
> > > stay consistent and keep both, so that if one day someone is looking at the
> > > source they don't wonder why only one of them is being run in the legacy mode.
> > > I hope that makes sense.
> >
> > Yep, no problem. Should I push now or after release?
>
> Ah, sorry, we definitely want this in the release, so safe for freeze.

I went ahead and pushed the patch myself, since DV plans on doing the release
at some point during the day which might already by too late for you because of
a different timezone.

Erik




More information about the libvir-list mailing list