Re: [Qemu-devel] [PULL 00/25] xen queue

[Peter Maydell]

On Fri, 11 Jan 2019 at 15:55, Anthony PERARD <address@hidden> wrote:
>
> On Fri, Jan 11, 2019 at 01:35:29PM +0000, Peter Maydell wrote:
> > On Thu, 10 Jan 2019 at 13:52, Anthony PERARD <address@hidden> wrote:
> > >
> > > The following changes since commit 
> > > 8ae951fbc1068308313b2c57a4fc3c68451641f4:
> > >
> > >   Merge remote-tracking branch 
> > > 'remotes/dgibson/tags/ppc-for-4.0-20190109' into staging (2019-01-09 
> > > 16:08:31 +0000)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git 
> > > tags/pull-xen-20190110
> > >
> > > for you to fetch changes up to 24edb91f5009fa941e1294aaf4bb2103d9ad077e:
> > >
> > >   xen-block: avoid repeated memory allocation (2019-01-10 11:25:17 +0000)
> > >
> > > ----------------------------------------------------------------
> > > xen queue
> > >
> > > * Xen PV backend 'qdevification'.
> > >   Starting with xen_disk.
> > > * Performance improvements for xen-block.
> > > * Remove of the Xen PV domain builder.
> > > * bug fixes.
> > >
> > > ----------------------------------------------------------------
> >
> > Hi. This fails to compile for me (x86-64 Linux host):
> >
> >   CC      hw/block/xen-block.o
> > In file included from
> > /home/petmay01/linaro/qemu-for-merges/include/hw/xen/xen-block.h:11:0,
> >                  from
> > /home/petmay01/linaro/qemu-for-merges/hw/block/xen-block.c:22:
> > /home/petmay01/linaro/qemu-for-merges/include/hw/xen/xen-bus.h:32:5:
> > error: unknown type name ‘xenevtchn_port_or_error_t’
> >      xenevtchn_port_or_error_t local_port;
> >      ^
> > /home/petmay01/linaro/qemu-for-merges/rules.mak:69: recipe for target
> > 'hw/block/xen-block.o' failed
> >
> > Probably the code is accidentally assuming a newer version
> > of the Xen headers than this system has installed? This
> > is Ubuntu 16.04.5 with libxen-dev  4.6.5-0ubuntu1.4.
>
> Sorry, I did stop build testing againt 4.6 as it went out of security
> support. Let me fix this and I'll resend a pull requests.

No problem. For fixing this pullreq a simple fix may be best,
but we should also consider dropping Xen 4.6 support from QEMU
if it's no longer within security support. We'd want to
make configure not enable Xen if the detected xenlibs are
too old (with the usual semantics for our configure of
silently just not building the Xen code by default but
failing with an error if the user explicitly asked for
Xen support to be enabled).

thanks
-- PMM