Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Fri, 25 Sep 2015, Ian Campbell wrote:
> On Thu, 2015-09-24 at 23:19 +0100, Stefano Stabellini wrote:
> > On Thu, 24 Sep 2015, Ian Campbell wrote:
> > > On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> > > > On Thu, 24 Sep 2015, Ian Campbell wrote:
> > > > > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > > > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > > > > > The oldest Xen version I build-test for every pull request is
> > > > Xen 4.0.0,
> > > > > 
> > > > > I setup a build trees for 4.0 thru 4.6 yesterday to test this, what
> > > > a
> > > > > pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer
> > > > compiler
> > > > > warnings and mostly, but not all, fixes which I could just backport
> > > > > from newer Xen, the exceptions were a couple of things which were
> > > > > removed before they needed to be fixed)
> > > > > 
> > > > > > > > I think it is very reasonable to remove anything older than
> > > > that.
> > > > > > > > I am OK with removing Xen 4.0.0 too, but I would like a
> > > > warning to be
> > > > > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > > > > 
> > > > > > > There is not much point in removing <=3.4 support and keeping
> > > > 4.0, since
> > > > > > > 4.0.0 was the last one which used a plain int as a handle,
> > > > anything older
> > > > > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > > > > 
> > > > > > > One approach I am considering in order to keep 4.0.0 support
> > > > and earlier
> > > > > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> > > > open
> > > > > > > wrapper do malloc(sizeof int) and the using wrappers do
> > > > xc_foo(*handle).
> > > > > > > 
> > > > > > > This way all the different variants take pointers and we have
> > > > less hoops to
> > > > > > > jump through to typedef everything in the correct way for each
> > > > variant.
> > > > > > > 
> > > > > > > If you would rather avoid doing that then I think dropping
> > > > 4.0.0 support
> > > > > > > would be the way to go and I'll send a mail to qemu-devel.
> > > > > >  
> > > > > > I would rather drop 4.0 support.
> > > > > 
> > > > > Supporting 4.0 didn't turn out quite as ugly as I had feared.
> > > > > 
> > > > > So before I send an email to qemu-devel to propose dropping 4.0
> > > > what do
> > > > > you think of the following which handles the evtchn case, there is
> > > > a
> > > > > similar patch for gnttab and a (yet to be written) patch for the
> > > > > foreign memory mapping case.
> > > > > 
> > > > > The relevant bit for this discussion is the 4.0.0 definition of
> > > > > xenevtchn_open in xen_common.h, the rest is just adjusting it to
> > > > use
> > > > > the API of the new library (for reasons explained in the commit
> > > > > message).
> > > > 
> > > > I think that it is OK in principle.
> > > > 
> > > > 
> > > > > diff --git a/include/hw/xen/xen_common.h
> > > > b/include/hw/xen/xen_common.h
> > > > > index 5923290..5700c1b 100644
> > > > > --- a/include/hw/xen/xen_common.h
> > > > > +++ b/include/hw/xen/xen_common.h
> > > > > @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int
> > > > xc_handle, uint32_t dom, int prot,
> > > > >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
> > > > >  
> > > > >  typedef int XenXC;
> > > > > -typedef int XenEvtchn;
> > > > > +typedef int xenevtchn_handle;
> > > > >  typedef int XenGnttab;
> > > >  
> > > > ...
> > > > 
> > > > > @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle
> > > > *xsh)
> > > > >  #else
> > > > >  
> > > > >  typedef xc_interface *XenXC;
> > > > > -typedef xc_evtchn *XenEvtchn;
> > > > > +typedef xc_evtchn xenevtchn_handle;
> > > > >  typedef xc_gnttab *XenGnttab;
> > > > >  
> > > > 
> > > > There is no reasons why we couldn't have a small compat shim on Xen >
> > > > 4.6 too, so I would change the definition of XenEvtchn for newer
> > > > versions of Xen and avoid some of the renaming in this patch to
> > > > reduce
> > > > the changes.
> > > > 
> > > > For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen >
> > > > 4.6?
> > > > So that we don't need to go and rename all the call sites?
> > > 
> > > The idea was that the code would use the new stable API names from the
> > > stable libraries going forward, rather than using a shim to turn the
> > > stable APIs back into the old ones.
> > 
> > I don't think that is very important from QEMU's point of view, using a
> > shim is just fine, especially if it reduces the patch size to 5 lines of
> > code :-)
> 
> Is patch size really the major consideration here? IMHO it is simply less
> confusing to have no shim (since one doesn't need to translate the names
> when reading differing code bases) and with time the shim layers can drop
> away leading to less complexity.
>
> Also, I've already written all the patches, the renamings were very
> mechanical and at this 

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Thu, 2015-09-24 at 23:19 +0100, Stefano Stabellini wrote:
> On Thu, 24 Sep 2015, Ian Campbell wrote:
> > On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> > > On Thu, 24 Sep 2015, Ian Campbell wrote:
> > > > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > > > > The oldest Xen version I build-test for every pull request is
> > > Xen 4.0.0,
> > > > 
> > > > I setup a build trees for 4.0 thru 4.6 yesterday to test this, what
> > > a
> > > > pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer
> > > compiler
> > > > warnings and mostly, but not all, fixes which I could just backport
> > > > from newer Xen, the exceptions were a couple of things which were
> > > > removed before they needed to be fixed)
> > > > 
> > > > > > > I think it is very reasonable to remove anything older than
> > > that.
> > > > > > > I am OK with removing Xen 4.0.0 too, but I would like a
> > > warning to be
> > > > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > > > 
> > > > > > There is not much point in removing <=3.4 support and keeping
> > > 4.0, since
> > > > > > 4.0.0 was the last one which used a plain int as a handle,
> > > anything older
> > > > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > > > 
> > > > > > One approach I am considering in order to keep 4.0.0 support
> > > and earlier
> > > > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> > > open
> > > > > > wrapper do malloc(sizeof int) and the using wrappers do
> > > xc_foo(*handle).
> > > > > > 
> > > > > > This way all the different variants take pointers and we have
> > > less hoops to
> > > > > > jump through to typedef everything in the correct way for each
> > > variant.
> > > > > > 
> > > > > > If you would rather avoid doing that then I think dropping
> > > 4.0.0 support
> > > > > > would be the way to go and I'll send a mail to qemu-devel.
> > > > >  
> > > > > I would rather drop 4.0 support.
> > > > 
> > > > Supporting 4.0 didn't turn out quite as ugly as I had feared.
> > > > 
> > > > So before I send an email to qemu-devel to propose dropping 4.0
> > > what do
> > > > you think of the following which handles the evtchn case, there is
> > > a
> > > > similar patch for gnttab and a (yet to be written) patch for the
> > > > foreign memory mapping case.
> > > > 
> > > > The relevant bit for this discussion is the 4.0.0 definition of
> > > > xenevtchn_open in xen_common.h, the rest is just adjusting it to
> > > use
> > > > the API of the new library (for reasons explained in the commit
> > > > message).
> > > 
> > > I think that it is OK in principle.
> > > 
> > > 
> > > > diff --git a/include/hw/xen/xen_common.h
> > > b/include/hw/xen/xen_common.h
> > > > index 5923290..5700c1b 100644
> > > > --- a/include/hw/xen/xen_common.h
> > > > +++ b/include/hw/xen/xen_common.h
> > > > @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int
> > > xc_handle, uint32_t dom, int prot,
> > > >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
> > > >  
> > > >  typedef int XenXC;
> > > > -typedef int XenEvtchn;
> > > > +typedef int xenevtchn_handle;
> > > >  typedef int XenGnttab;
> > >  
> > > ...
> > > 
> > > > @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle
> > > *xsh)
> > > >  #else
> > > >  
> > > >  typedef xc_interface *XenXC;
> > > > -typedef xc_evtchn *XenEvtchn;
> > > > +typedef xc_evtchn xenevtchn_handle;
> > > >  typedef xc_gnttab *XenGnttab;
> > > >  
> > > 
> > > There is no reasons why we couldn't have a small compat shim on Xen >
> > > 4.6 too, so I would change the definition of XenEvtchn for newer
> > > versions of Xen and avoid some of the renaming in this patch to
> > > reduce
> > > the changes.
> > > 
> > > For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen >
> > > 4.6?
> > > So that we don't need to go and rename all the call sites?
> > 
> > The idea was that the code would use the new stable API names from the
> > stable libraries going forward, rather than using a shim to turn the
> > stable APIs back into the old ones.
> 
> I don't think that is very important from QEMU's point of view, using a
> shim is just fine, especially if it reduces the patch size to 5 lines of
> code :-)

Is patch size really the major consideration here? IMHO it is simply less
confusing to have no shim (since one doesn't need to translate the names
when reading differing code bases) and with time the shim layers can drop
away leading to less complexity.

Also, I've already written all the patches, the renamings were very
mechanical and at this point it would actually take me longer to undo them.

I'll do that if you insist, but I think the justification for sticking with
a shim is very flimsy.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> On Wed, 23 Sep 2015, Ian Campbell wrote:
> > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > The oldest Xen version I build-test for every pull request is Xen 4.0.0,

I setup a build trees for 4.0 thru 4.6 yesterday to test this, what a
pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer compiler
warnings and mostly, but not all, fixes which I could just backport
from newer Xen, the exceptions were a couple of things which were
removed before they needed to be fixed)

> > > I think it is very reasonable to remove anything older than that.
> > > I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> > > sent ahead of time to qemu-devel to see if anybody complains.
> > 
> > There is not much point in removing <=3.4 support and keeping 4.0, since
> > 4.0.0 was the last one which used a plain int as a handle, anything older
> > than 4.0.0 is trivial if 4.0.0 is supported.
> > 
> > One approach I am considering in order to keep 4.0.0 support and earlier
> > was to turn the "int fd" for <=4.0 into a pointer by having the open
> > wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> > 
> > This way all the different variants take pointers and we have less hoops to
> > jump through to typedef everything in the correct way for each variant.
> > 
> > If you would rather avoid doing that then I think dropping 4.0.0 support
> > would be the way to go and I'll send a mail to qemu-devel.
>  
> I would rather drop 4.0 support.

Supporting 4.0 didn't turn out quite as ugly as I had feared.

So before I send an email to qemu-devel to propose dropping 4.0 what do
you think of the following which handles the evtchn case, there is a
similar patch for gnttab and a (yet to be written) patch for the
foreign memory mapping case.

The relevant bit for this discussion is the 4.0.0 definition of
xenevtchn_open in xen_common.h, the rest is just adjusting it to use
the API of the new library (for reasons explained in the commit
message).

commit d97f6bb5045685d766d85b8cd004ce007fe29120
Author: Ian Campbell 
Date:   Wed Sep 23 17:30:15 2015 +0100

xen: Switch to libxenevtchn interface for compat shims.

In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenevtchn which provides access to event
channels.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Build tested with 4.1 and 4.5.

Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.

Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.

Signed-off-by: Ian Campbell 

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..1fd8e01 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
 xen_be_printf(NULL, 0, "can't open evtchn device\n");
 g_free(xendev);
 return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
 xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
 if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
 xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
 g_free(xendev);
 return NULL;
 }
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
 g_free(xendev->fe);
 }
 
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
 }
 if (xendev->gnttabdev != 

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Fabio Fantoni]

Il 24/09/2015 09:15, Ian Campbell ha scritto:

On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:

On Wed, 23 Sep 2015, Ian Campbell wrote:

On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote:

The oldest Xen version I build-test for every pull request is Xen 4.0.0,

I setup a build trees for 4.0 thru 4.6 yesterday to test this, what a
pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer compiler
warnings and mostly, but not all, fixes which I could just backport
from newer Xen, the exceptions were a couple of things which were
removed before they needed to be fixed)


I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.

There is not much point in removing <=3.4 support and keeping 4.0, since
4.0.0 was the last one which used a plain int as a handle, anything older
than 4.0.0 is trivial if 4.0.0 is supported.

One approach I am considering in order to keep 4.0.0 support and earlier
was to turn the "int fd" for <=4.0 into a pointer by having the open
wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).

This way all the different variants take pointers and we have less hoops to
jump through to typedef everything in the correct way for each variant.

If you would rather avoid doing that then I think dropping 4.0.0 support
would be the way to go and I'll send a mail to qemu-devel.
  
I would rather drop 4.0 support.

Supporting 4.0 didn't turn out quite as ugly as I had feared.


Even if seems that major of distro use newer qemu version instead older 
with xen seems that keep updated also xen to latest stable version (or 
at least previous) and the cases where can uses next qemu version with 
very old xen I think is at least very rare.
Another thing is that upstream qemu on older xen not had good support 
(at least for hvm domUs) and when I started to use it some years ago 
seems that was with too very few users.

There are also some problem, for example this:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=2e814a017155b885e4d4b5a88dc05e7367a9722a
without hvm domUs with emulated vga don't start with qemu>=1.4, applied 
to xen 4.3 and backported only in stable-4.2
Therefore excluded recent unexpected that I not know for a working 
support of hvm domUsat least xen 4.2 is needed.
In my cases I had saw good hvm domUs support with upstream qemu for 
production use only starting from xen 4.3.
I think is good know if older xen is really used with newer (more 
exactly next for these changes) qemu instead wasting time supporting and 
testing also many older xen versions.

In any cases thanks to all for any xen and qemu improvements.

Sorry for my bad english.



So before I send an email to qemu-devel to propose dropping 4.0 what do
you think of the following which handles the evtchn case, there is a
similar patch for gnttab and a (yet to be written) patch for the
foreign memory mapping case.

The relevant bit for this discussion is the 4.0.0 definition of
xenevtchn_open in xen_common.h, the rest is just adjusting it to use
the API of the new library (for reasons explained in the commit
message).

commit d97f6bb5045685d766d85b8cd004ce007fe29120
Author: Ian Campbell 
Date:   Wed Sep 23 17:30:15 2015 +0100

 xen: Switch to libxenevtchn interface for compat shims.
 
 In Xen 4.7 we are refactoring parts libxenctrl into a number of

 separate libraries which will provide backward and forward API and ABI
 compatiblity.
 
 One such library will be libxenevtchn which provides access to event

 channels.
 
 In preparation for this switch the compatibility layer in xen_common.h

 (which support building with older versions of Xen) to use what will
 be the new library API. This means that the evtchn shim will disappear
 for versions of Xen which include libxenevtchn.
 
 To simplify things for the <= 4.0.0 support we wrap the int fd in a

 malloc(sizeof int) such that the handle is always a pointer. This
 leads to less typedef headaches and the need for
 XC_HANDLER_INITIAL_VALUE etc for these interfaces.
 
 Build tested with 4.1 and 4.5.
 
 Note that this patch does not add any support for actually using

 libxenevtchn, it just adjusts the existing shims.
 
 Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,

 since that functionality is not exposed by /dev/xen/evtchn.
 
 Signed-off-by: Ian Campbell 


diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index b2cb22b..1fd8e01 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
  xendev->debug  = debug;
  xendev->local_port = -1;
  
-xendev->evtchndev = 

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> On Thu, 24 Sep 2015, Ian Campbell wrote:
> > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > > The oldest Xen version I build-test for every pull request is
> Xen 4.0.0,
> > 
> > I setup a build trees for 4.0 thru 4.6 yesterday to test this, what
> a
> > pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer
> compiler
> > warnings and mostly, but not all, fixes which I could just backport
> > from newer Xen, the exceptions were a couple of things which were
> > removed before they needed to be fixed)
> > 
> > > > > I think it is very reasonable to remove anything older than
> that.
> > > > > I am OK with removing Xen 4.0.0 too, but I would like a
> warning to be
> > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > 
> > > > There is not much point in removing <=3.4 support and keeping
> 4.0, since
> > > > 4.0.0 was the last one which used a plain int as a handle,
> anything older
> > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > 
> > > > One approach I am considering in order to keep 4.0.0 support
> and earlier
> > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> open
> > > > wrapper do malloc(sizeof int) and the using wrappers do
> xc_foo(*handle).
> > > > 
> > > > This way all the different variants take pointers and we have
> less hoops to
> > > > jump through to typedef everything in the correct way for each
> variant.
> > > > 
> > > > If you would rather avoid doing that then I think dropping
> 4.0.0 support
> > > > would be the way to go and I'll send a mail to qemu-devel.
> > >  
> > > I would rather drop 4.0 support.
> > 
> > Supporting 4.0 didn't turn out quite as ugly as I had feared.
> > 
> > So before I send an email to qemu-devel to propose dropping 4.0
> what do
> > you think of the following which handles the evtchn case, there is
> a
> > similar patch for gnttab and a (yet to be written) patch for the
> > foreign memory mapping case.
> > 
> > The relevant bit for this discussion is the 4.0.0 definition of
> > xenevtchn_open in xen_common.h, the rest is just adjusting it to
> use
> > the API of the new library (for reasons explained in the commit
> > message).
> 
> I think that it is OK in principle.
> 
> 
> > diff --git a/include/hw/xen/xen_common.h
> b/include/hw/xen/xen_common.h
> > index 5923290..5700c1b 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int
> xc_handle, uint32_t dom, int prot,
> >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
> >  
> >  typedef int XenXC;
> > -typedef int XenEvtchn;
> > +typedef int xenevtchn_handle;
> >  typedef int XenGnttab;
>  
> ...
> 
> > @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle
> *xsh)
> >  #else
> >  
> >  typedef xc_interface *XenXC;
> > -typedef xc_evtchn *XenEvtchn;
> > +typedef xc_evtchn xenevtchn_handle;
> >  typedef xc_gnttab *XenGnttab;
> >  
> 
> There is no reasons why we couldn't have a small compat shim on Xen >
> 4.6 too, so I would change the definition of XenEvtchn for newer
> versions of Xen and avoid some of the renaming in this patch to reduce
> the changes.
> 
> For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen > 4.6?
> So that we don't need to go and rename all the call sites?

The idea was that the code would use the new stable API names from the
stable libraries going forward, rather than using a shim to turn the
stable APIs back into the old ones.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Thu, 24 Sep 2015, Ian Campbell wrote:
> On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > The oldest Xen version I build-test for every pull request is Xen 4.0.0,
> 
> I setup a build trees for 4.0 thru 4.6 yesterday to test this, what a
> pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer compiler
> warnings and mostly, but not all, fixes which I could just backport
> from newer Xen, the exceptions were a couple of things which were
> removed before they needed to be fixed)
> 
> > > > I think it is very reasonable to remove anything older than that.
> > > > I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > 
> > > There is not much point in removing <=3.4 support and keeping 4.0, since
> > > 4.0.0 was the last one which used a plain int as a handle, anything older
> > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > 
> > > One approach I am considering in order to keep 4.0.0 support and earlier
> > > was to turn the "int fd" for <=4.0 into a pointer by having the open
> > > wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> > > 
> > > This way all the different variants take pointers and we have less hoops 
> > > to
> > > jump through to typedef everything in the correct way for each variant.
> > > 
> > > If you would rather avoid doing that then I think dropping 4.0.0 support
> > > would be the way to go and I'll send a mail to qemu-devel.
> >  
> > I would rather drop 4.0 support.
> 
> Supporting 4.0 didn't turn out quite as ugly as I had feared.
> 
> So before I send an email to qemu-devel to propose dropping 4.0 what do
> you think of the following which handles the evtchn case, there is a
> similar patch for gnttab and a (yet to be written) patch for the
> foreign memory mapping case.
> 
> The relevant bit for this discussion is the 4.0.0 definition of
> xenevtchn_open in xen_common.h, the rest is just adjusting it to use
> the API of the new library (for reasons explained in the commit
> message).

I think that it is OK in principle.


> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 5923290..5700c1b 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int xc_handle, 
> uint32_t dom, int prot,
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
>  
>  typedef int XenXC;
> -typedef int XenEvtchn;
> +typedef int xenevtchn_handle;
>  typedef int XenGnttab;
 
...

> @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle *xsh)
>  #else
>  
>  typedef xc_interface *XenXC;
> -typedef xc_evtchn *XenEvtchn;
> +typedef xc_evtchn xenevtchn_handle;
>  typedef xc_gnttab *XenGnttab;
>  

There is no reasons why we couldn't have a small compat shim on Xen >
4.6 too, so I would change the definition of XenEvtchn for newer
versions of Xen and avoid some of the renaming in this patch to reduce
the changes.

For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen > 4.6?
So that we don't need to go and rename all the call sites?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Thu, 24 Sep 2015, Ian Campbell wrote:
> On Thu, 2015-09-24 at 20:33 +0100, Stefano Stabellini wrote:
> > On Thu, 24 Sep 2015, Ian Campbell wrote:
> > > On Wed, 2015-09-23 at 18:36 +0100, Stefano Stabellini wrote:
> > > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > > > > > The oldest Xen version I build-test for every pull request is
> > Xen 4.0.0,
> > > 
> > > I setup a build trees for 4.0 thru 4.6 yesterday to test this, what
> > a
> > > pain 4.1 and 4.0 are to build with a modern gcc! (Mostly newer
> > compiler
> > > warnings and mostly, but not all, fixes which I could just backport
> > > from newer Xen, the exceptions were a couple of things which were
> > > removed before they needed to be fixed)
> > > 
> > > > > > I think it is very reasonable to remove anything older than
> > that.
> > > > > > I am OK with removing Xen 4.0.0 too, but I would like a
> > warning to be
> > > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > > 
> > > > > There is not much point in removing <=3.4 support and keeping
> > 4.0, since
> > > > > 4.0.0 was the last one which used a plain int as a handle,
> > anything older
> > > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > > 
> > > > > One approach I am considering in order to keep 4.0.0 support
> > and earlier
> > > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> > open
> > > > > wrapper do malloc(sizeof int) and the using wrappers do
> > xc_foo(*handle).
> > > > > 
> > > > > This way all the different variants take pointers and we have
> > less hoops to
> > > > > jump through to typedef everything in the correct way for each
> > variant.
> > > > > 
> > > > > If you would rather avoid doing that then I think dropping
> > 4.0.0 support
> > > > > would be the way to go and I'll send a mail to qemu-devel.
> > > >  
> > > > I would rather drop 4.0 support.
> > > 
> > > Supporting 4.0 didn't turn out quite as ugly as I had feared.
> > > 
> > > So before I send an email to qemu-devel to propose dropping 4.0
> > what do
> > > you think of the following which handles the evtchn case, there is
> > a
> > > similar patch for gnttab and a (yet to be written) patch for the
> > > foreign memory mapping case.
> > > 
> > > The relevant bit for this discussion is the 4.0.0 definition of
> > > xenevtchn_open in xen_common.h, the rest is just adjusting it to
> > use
> > > the API of the new library (for reasons explained in the commit
> > > message).
> > 
> > I think that it is OK in principle.
> > 
> > 
> > > diff --git a/include/hw/xen/xen_common.h
> > b/include/hw/xen/xen_common.h
> > > index 5923290..5700c1b 100644
> > > --- a/include/hw/xen/xen_common.h
> > > +++ b/include/hw/xen/xen_common.h
> > > @@ -39,17 +39,37 @@ static inline void *xc_map_foreign_bulk(int
> > xc_handle, uint32_t dom, int prot,
> > >  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 410
> > >  
> > >  typedef int XenXC;
> > > -typedef int XenEvtchn;
> > > +typedef int xenevtchn_handle;
> > >  typedef int XenGnttab;
> >  
> > ...
> > 
> > > @@ -108,17 +128,20 @@ static inline void xs_close(struct xs_handle
> > *xsh)
> > >  #else
> > >  
> > >  typedef xc_interface *XenXC;
> > > -typedef xc_evtchn *XenEvtchn;
> > > +typedef xc_evtchn xenevtchn_handle;
> > >  typedef xc_gnttab *XenGnttab;
> > >  
> > 
> > There is no reasons why we couldn't have a small compat shim on Xen >
> > 4.6 too, so I would change the definition of XenEvtchn for newer
> > versions of Xen and avoid some of the renaming in this patch to reduce
> > the changes.
> > 
> > For example, why not define xc_evtchn_fd as xenevtchn_fd for Xen > 4.6?
> > So that we don't need to go and rename all the call sites?
> 
> The idea was that the code would use the new stable API names from the
> stable libraries going forward, rather than using a shim to turn the
> stable APIs back into the old ones.

I don't think that is very important from QEMU's point of view, using a
shim is just fine, especially if it reduces the patch size to 5 lines of
code :-)

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Konrad Rzeszutek Wilk]

On Wed, Sep 23, 2015 at 09:29:10AM +0100, Ian Campbell wrote:
> On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > The oldest Xen version I build-test for every pull request is Xen 4.0.0,
> > I think it is very reasonable to remove anything older than that.
> > I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> > sent ahead of time to qemu-devel to see if anybody complains.
> 
> There is not much point in removing <=3.4 support and keeping 4.0, since
> 4.0.0 was the last one which used a plain int as a handle, anything older
> than 4.0.0 is trivial if 4.0.0 is supported.
> 
> One approach I am considering in order to keep 4.0.0 support and earlier
> was to turn the "int fd" for <=4.0 into a pointer by having the open
> wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> 
> This way all the different variants take pointers and we have less hoops to
> jump through to typedef everything in the correct way for each variant.
> 
> If you would rather avoid doing that then I think dropping 4.0.0 support
> would be the way to go and I'll send a mail to qemu-devel.

Perhaps to help in killing the 4.0.0 support - Linux pvops can't work
with Xen 4.0.0 - sadly I don't recall the details but I think it was missing
an hypercall.
> 
> Ian.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Juergen Gross]

On 09/23/2015 04:09 PM, Konrad Rzeszutek Wilk wrote:

On Wed, Sep 23, 2015 at 09:29:10AM +0100, Ian Campbell wrote:

On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote:

The oldest Xen version I build-test for every pull request is Xen 4.0.0,
I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.


There is not much point in removing <=3.4 support and keeping 4.0, since
4.0.0 was the last one which used a plain int as a handle, anything older
than 4.0.0 is trivial if 4.0.0 is supported.

One approach I am considering in order to keep 4.0.0 support and earlier
was to turn the "int fd" for <=4.0 into a pointer by having the open
wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).

This way all the different variants take pointers and we have less hoops to
jump through to typedef everything in the correct way for each variant.

If you would rather avoid doing that then I think dropping 4.0.0 support
would be the way to go and I'll send a mail to qemu-devel.


Perhaps to help in killing the 4.0.0 support - Linux pvops can't work
with Xen 4.0.0 - sadly I don't recall the details but I think it was missing
an hypercall.


Are you sure? On the Xen developer summit this year I asked a guy from
Amazon whether they are testing upstream pvops kernels on all Xen
versions they support, and he confirmed that. And they do support Xen
4.0 and older.


Juergen


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Konrad Rzeszutek Wilk]

On Wed, Sep 23, 2015 at 04:17:05PM +0200, Juergen Gross wrote:
> On 09/23/2015 04:09 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Sep 23, 2015 at 09:29:10AM +0100, Ian Campbell wrote:
> >>On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote:
> >>>The oldest Xen version I build-test for every pull request is Xen 4.0.0,
> >>>I think it is very reasonable to remove anything older than that.
> >>>I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> >>>sent ahead of time to qemu-devel to see if anybody complains.
> >>
> >>There is not much point in removing <=3.4 support and keeping 4.0, since
> >>4.0.0 was the last one which used a plain int as a handle, anything older
> >>than 4.0.0 is trivial if 4.0.0 is supported.
> >>
> >>One approach I am considering in order to keep 4.0.0 support and earlier
> >>was to turn the "int fd" for <=4.0 into a pointer by having the open
> >>wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> >>
> >>This way all the different variants take pointers and we have less hoops to
> >>jump through to typedef everything in the correct way for each variant.
> >>
> >>If you would rather avoid doing that then I think dropping 4.0.0 support
> >>would be the way to go and I'll send a mail to qemu-devel.
> >
> >Perhaps to help in killing the 4.0.0 support - Linux pvops can't work
> >with Xen 4.0.0 - sadly I don't recall the details but I think it was missing
> >an hypercall.
> 
> Are you sure? On the Xen developer summit this year I asked a guy from

And I am incorrect (from http://wiki.xen.org/wiki/Dom0_Kernels_for_Xen):

"Q: I've seen mentions of 'pv_ops' and 'xenlinux' kernels. Which one
should I choose?

Simple answer: pv_ops. Xen Project 4.0 switched to using Linux pv_ops
based dom0 kernel as a default.."

> Amazon whether they are testing upstream pvops kernels on all Xen
> versions they support, and he confirmed that. And they do support Xen
> 4.0 and older.

Oh gosh, older than 4.0? Ugh.

> 
> 
> Juergen
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Wed, 2015-09-23 at 10:21 -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 23, 2015 at 04:17:05PM +0200, Juergen Gross wrote:
> > On 09/23/2015 04:09 PM, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Sep 23, 2015 at 09:29:10AM +0100, Ian Campbell wrote:
> > > > On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote:
> > > > > The oldest Xen version I build-test for every pull request is Xen
> > > > > 4.0.0,
> > > > > I think it is very reasonable to remove anything older than that.
> > > > > I am OK with removing Xen 4.0.0 too, but I would like a warning
> > > > > to be
> > > > > sent ahead of time to qemu-devel to see if anybody complains.
> > > > 
> > > > There is not much point in removing <=3.4 support and keeping 4.0,
> > > > since
> > > > 4.0.0 was the last one which used a plain int as a handle, anything
> > > > older
> > > > than 4.0.0 is trivial if 4.0.0 is supported.
> > > > 
> > > > One approach I am considering in order to keep 4.0.0 support and
> > > > earlier
> > > > was to turn the "int fd" for <=4.0 into a pointer by having the
> > > > open
> > > > wrapper do malloc(sizeof int) and the using wrappers do
> > > > xc_foo(*handle).
> > > > 
> > > > This way all the different variants take pointers and we have less
> > > > hoops to
> > > > jump through to typedef everything in the correct way for each
> > > > variant.
> > > > 
> > > > If you would rather avoid doing that then I think dropping 4.0.0
> > > > support
> > > > would be the way to go and I'll send a mail to qemu-devel.
> > > 
> > > Perhaps to help in killing the 4.0.0 support - Linux pvops can't work
> > > with Xen 4.0.0 - sadly I don't recall the details but I think it was
> > > missing
> > > an hypercall.
> > 
> > Are you sure? On the Xen developer summit this year I asked a guy from
> 
> And I am incorrect (from http://wiki.xen.org/wiki/Dom0_Kernels_for_Xen):
> 
>   "Q: I've seen mentions of 'pv_ops' and 'xenlinux' kernels. Which
> one
>   should I choose?
> 
>   Simple answer: pv_ops. Xen Project 4.0 switched to using Linux
> pv_ops
>   based dom0 kernel as a default.."

This contracts your hypothesis, it says that Xen 4.0 is expected to work
with a pvops dom0 (or else we wouldn't have switched to it by default).

I think the cut off you are thinking of was a bit older, e.g. 3.4 or so.

> 
> > Amazon whether they are testing upstream pvops kernels on all Xen
> > versions they support, and he confirmed that. And they do support Xen
> > 4.0 and older.

NB they presumably care about domU only for this testing, whereas whatever
the incompatibility is it was to do with dom0 only, since domU interface
has been stable since 3.0.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Wed, 23 Sep 2015, Ian Campbell wrote:
> On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> > The oldest Xen version I build-test for every pull request is Xen 4.0.0,
> > I think it is very reasonable to remove anything older than that.
> > I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> > sent ahead of time to qemu-devel to see if anybody complains.
> 
> There is not much point in removing <=3.4 support and keeping 4.0, since
> 4.0.0 was the last one which used a plain int as a handle, anything older
> than 4.0.0 is trivial if 4.0.0 is supported.
> 
> One approach I am considering in order to keep 4.0.0 support and earlier
> was to turn the "int fd" for <=4.0 into a pointer by having the open
> wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).
> 
> This way all the different variants take pointers and we have less hoops to
> jump through to typedef everything in the correct way for each variant.
> 
> If you would rather avoid doing that then I think dropping 4.0.0 support
> would be the way to go and I'll send a mail to qemu-devel.
 
I would rather drop 4.0 support.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

On Tue, 2015-09-22 at 22:31 +0100, Stefano Stabellini wrote: 
> The oldest Xen version I build-test for every pull request is Xen 4.0.0,
> I think it is very reasonable to remove anything older than that.
> I am OK with removing Xen 4.0.0 too, but I would like a warning to be
> sent ahead of time to qemu-devel to see if anybody complains.

There is not much point in removing <=3.4 support and keeping 4.0, since
4.0.0 was the last one which used a plain int as a handle, anything older
than 4.0.0 is trivial if 4.0.0 is supported.

One approach I am considering in order to keep 4.0.0 support and earlier
was to turn the "int fd" for <=4.0 into a pointer by having the open
wrapper do malloc(sizeof int) and the using wrappers do xc_foo(*handle).

This way all the different variants take pointers and we have less hoops to
jump through to typedef everything in the correct way for each variant.

If you would rather avoid doing that then I think dropping 4.0.0 support
would be the way to go and I'll send a mail to qemu-devel.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Stefano Stabellini]

On Tue, 22 Sep 2015, Ian Campbell wrote:
> (dropping minios-devel)
> 
> Stefano,
> 
> On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> > 
> > There are 3 series, against xen.git (15 patches), mini-os.git (5
> > patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> > point to the patches in the other two trees via instructions to update
> > the relevant Config.mk field. The perils of changing unstable
> > interfaces!
> 
> I started looking into making the appropriate changes to QEMU upstream to
> use the new libraries directly.
> 
> QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl
> versions back as far as 3.3.0.
> 
> The main distinction is between pre-4.1.0 and 4.1.0 and later, since
> various handles switching from int's to opaque pointers at that point,
> meaning there are some typedefs and wrappers for things.
> 
> My plan was to rework the QEMU code to use only the new library function
> names for everything such that this becomes the default case (which makes
> sense given these libraries are intended to be long term stable) and to
> update the code in xen_common.h to bridge the gap to 4.6 and earlier.
> 
> But I'm having to jump through some hoops in order to support the pre-4.1.0
> version of things. It's not impossible to support it, I'm sure, but things
> would be a lot easier if we could just drop that support code.
> 
> Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU
> at this point?
> 
> Some data: Xen 4.0.0 was released in April 2010, the last point release was
> 4.0.4 in August 2012 and we no longer do security support for it (for a
> year or two now, I think).
 
The oldest Xen version I build-test for every pull request is Xen 4.0.0,
I think it is very reasonable to remove anything older than that.
I am OK with removing Xen 4.0.0 too, but I would like a warning to be
sent ahead of time to qemu-devel to see if anybody complains.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Oldest supported Xen version in upstream QEMU (Was: Re: [Minios-devel] [PATCH v2 0/15+5+5] Begin to disentangle libxenctrl and provide some stable libraries)

[Ian Campbell]

(dropping minios-devel)

Stefano,

On Wed, 2015-07-15 at 16:46 +0100, Ian Campbell wrote:
> 
> There are 3 series, against xen.git (15 patches), mini-os.git (5
> patches) and qemu-xen-trad.git (5 patches). The patches against xen.git
> point to the patches in the other two trees via instructions to update
> the relevant Config.mk field. The perils of changing unstable
> interfaces!

I started looking into making the appropriate changes to QEMU upstream to
use the new libraries directly.

QEMU (in include/hw/xen/xen_common.h) includes compat shims for libxenctrl
versions back as far as 3.3.0.

The main distinction is between pre-4.1.0 and 4.1.0 and later, since
various handles switching from int's to opaque pointers at that point,
meaning there are some typedefs and wrappers for things.

My plan was to rework the QEMU code to use only the new library function
names for everything such that this becomes the default case (which makes
sense given these libraries are intended to be long term stable) and to
update the code in xen_common.h to bridge the gap to 4.6 and earlier.

But I'm having to jump through some hoops in order to support the pre-4.1.0
version of things. It's not impossible to support it, I'm sure, but things
would be a lot easier if we could just drop that support code.

Can we consider dropping support for Xen 4.0 and earlier from upstream QEMU
at this point?

Some data: Xen 4.0.0 was released in April 2010, the last point release was
4.0.4 in August 2012 and we no longer do security support for it (for a
year or two now, I think).

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel