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