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

[Anthony PERARD <anthony.perard@citrix.com>]

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@citrix.com>
> > Commits: d5f54009db^..fe6630ddc4
> > 
> > Some more QEMU 6.0 fixes
> > <20210628100157.5010-1-anthony.perard@citrix.com>
> > Commits: 217eef30f7  3bc3be978f
> 
> So I have queued all these.
> 
> > Also, Olaf want them to be backported to 4.14, see
> >     <20210629095952.7b0b94c1.olaf@aepfle.de>
> 
> 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