[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QEMU 6.0+ in 4.15 and 4.14 (Re: preparations for 4.15.1 and 4.13.4)


  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • From: Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Date: Fri, 27 Aug 2021 13:39:28 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Olaf Hering <olaf@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "George Dunlap" <george.dunlap@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Julien Grall <julien@xxxxxxx>
  • Delivery-date: Fri, 27 Aug 2021 12:39:39 +0000
  • Ironport-hdrordr: A9a23:OyGKc64WUb+NEtzTAwPXwAzXdLJyesId70hD6qkQc3Fom62j5q WTdZEgvyMc5wx/ZJhNo7690cq7MBHhHPxOgbX5VI3KNGXbUQOTR72KhrGSoAEIdReeygZcv5 0QCZSXCrfLfCVHZRCR2njFLz4iquP3j5xBnY3lvhNQpZkBUdAZ0+9+YDzrdXFedU19KrcSMo GT3cZDryrIQwVtUizqbkN1OdQqvrfw5evbXSI=
  • Ironport-sdr: cSuv7s1/V6AL/lsoTeijC4tfUux0hD0BlrHsDyfkDHS84dq3wFekXgy0ZvreG6RDj3Fci+/Wj7 Pjd30cu9WF0J1kxbGRBcu2DInPqLQzEHKesEq3E+NMO8IFWK/6HGek1tLvCOfaeQdw91HWH7Ff gv3gF/C+wnAXfGfHmffRw749G5ranm8hTa1kMAD8UvEIHCn1O5/teIN5HzIfShUQt/GolVn3o2 ExjJtZStRg5PQ+S5e7V8Y3YFH7bsRy+ZOrjmpXJWngM9ic83E0Ww81Kfx21DM8fc4fRLST0EAx qV1pJI3v0ouXVWhPbMdeGtxJ
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Thu, Aug 19, 2021 at 05:23:26PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: preparations for 4.15.1 and 4.13.4"):
> > Can we backport support of QEMU 6.0 to Xen 4.15? I'm pretty sure
> > distributions are going to want to use the latest QEMU and latest Xen,
> > without needed to build two different QEMU binaries.
> 
> I think this is appropriate.  Xen 4.15 is still now, and there was an
> unfortunate interaction between release dates.  Your argument makes
> sense.
> 
> > [XEN PATCH v2 0/8] Fix libxl with QEMU 6.0 + remove some more deprecated 
> > usages.
> > <20210511092810.13759-1-anthony.perard@xxxxxxxxxx>
> > Commits: d5f54009db^..fe6630ddc4
> > 
> > Some more QEMU 6.0 fixes
> > <20210628100157.5010-1-anthony.perard@xxxxxxxxxx>
> > Commits: 217eef30f7  3bc3be978f
> 
> So I have queued all these.
> 
> > Also, Olaf want them to be backported to 4.14, see
> >     <20210629095952.7b0b94c1.olaf@xxxxxxxxx>
> 
> I'm unsure about this.  The diff seems moderately large.  Also, are we
> sure that it wouldn't break anything other than very old qemu ?  OTOH
> compat problems with newer qemu are indeed a problem especially for
> distros.

I've check all commits, beside two commits they all have a fallback
mechanism so we still are compatible with old qemus.
There is these two commits
    libxl: Fix QEMU cmdline for scsi device
    libxl: Use -device for cd-rom drives
which replace command line arguments, but it is to use something that
has been available since QEMU 0.15, so before the first version that
libxl as evert supported.

So overall, I don't think we break compatibility with very old qemus. It
would take a couple more QMP command to run some feature as libxl would
try the new command first before falling back to previous ones.

> I'm currently leaning towards "no" but I am very open to being
> convinced this is a good idea.

I don't know if it is a good idea, but at least it doesn't seems to be a
bad one.

-- 
Anthony PERARD



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.