[PATCH for-4.5] xen: Bump several interface versions in preparation for Xen-4.5

[PATCH for-4.5] xen: Bump several interface versions in preparation for Xen-4.5

[Andrew Cooper]

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4

Re: [PATCH for-4.5] xen: Bump several interface versions in preparation for Xen-4.5

[Andrew Cooper]

On 04/11/14 11:44, Andrew Cooper wrote:

Apologies - the subject is wrong, but content is correct. (I think,
having now checked the other interface versions).

> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
>
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
>
> As HVM ops have no specific interface version, the main Xen interface version
> needs to be bumped to compensate.
>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Tim Deegan <tim@xen.org>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
> ---
> This is a bugfix with regards to API versioning.  There is no risk whatsoever
> from taking it, but there is an outstanding API breakage which it fixes.
> ---
>  xen/include/public/xen-compat.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
> index 3eb80a0..c1d660d 100644
> --- a/xen/include/public/xen-compat.h
> +++ b/xen/include/public/xen-compat.h
> @@ -27,7 +27,7 @@
>  #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
>  #define __XEN_PUBLIC_XEN_COMPAT_H__
>  
> -#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
> +#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
>  
>  #if defined(__XEN__) || defined(__XEN_TOOLS__)
>  /* Xen is built with matching headers and implements the latest interface. */

[PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

[Andrew Cooper]

c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
structures associated with xen_hvm_{get,set}_mem_access from the Xen public
API.

While these were toolstack hypercalls and documented as liable to change in
the future, it causes build issues for certain tools (valgrind, strace).

As HVM ops have no specific interface version, the main Xen interface version
needs to be bumped to compensate.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

---
This is a bugfix with regards to API versioning.  There is no risk whatsoever
from taking it, but there is an outstanding API breakage which it fixes.

v2:
 * Correct patch subject
---
 xen/include/public/xen-compat.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/xen-compat.h b/xen/include/public/xen-compat.h
index 3eb80a0..c1d660d 100644
--- a/xen/include/public/xen-compat.h
+++ b/xen/include/public/xen-compat.h
@@ -27,7 +27,7 @@
 #ifndef __XEN_PUBLIC_XEN_COMPAT_H__
 #define __XEN_PUBLIC_XEN_COMPAT_H__
 
-#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040400
+#define __XEN_LATEST_INTERFACE_VERSION__ 0x00040500
 
 #if defined(__XEN__) || defined(__XEN_TOOLS__)
 /* Xen is built with matching headers and implements the latest interface. */
-- 
1.7.10.4

Re: [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

[Jan Beulich]

>>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).
> 
> As HVM ops have no specific interface version, the main Xen interface 
> version
> needs to be bumped to compensate.

Content-wise I don't really object to this patch, but I view it as
merely cosmetic rather than fixing anything: Tool stack interfaces
are declared to be volatile just because we want to avoid exactly
this need for bumping versions or anything when altering or
dropping them. If there are out of tree consumers of them, it is
their responsibility to keep up with our changes (or have their
own clones of the canonical headers).

Also we didn't bother incrementing the version just because of a
release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
shared interface versions, yet especially in the case of 4.1 I'm
pretty certain even without explicitly checking that there were
tool stack interface changes.

Jan

Re: [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

[Ian Campbell]

On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> > API.
> > 
> > While these were toolstack hypercalls and documented as liable to change in
> > the future, it causes build issues for certain tools (valgrind, strace).
> > 
> > As HVM ops have no specific interface version, the main Xen interface 
> > version
> > needs to be bumped to compensate.
> 
> Content-wise I don't really object to this patch, but I view it as
> merely cosmetic rather than fixing anything: Tool stack interfaces
> are declared to be volatile just because we want to avoid exactly
> this need for bumping versions or anything when altering or
> dropping them. If there are out of tree consumers of them, it is
> their responsibility to keep up with our changes (or have their
> own clones of the canonical headers).
> 
> Also we didn't bother incrementing the version just because of a
> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
> shared interface versions, yet especially in the case of 4.1 I'm
> pretty certain even without explicitly checking that there were
> tool stack interface changes.

I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
API rather than ABI, i.e. it gets used to revert
__HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
older consumers and things like that.

Ian.

Re: [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

[Jan Beulich]

>>> On 04.11.14 at 13:08, <Ian.Campbell@citrix.com> wrote:
> On Tue, 2014-11-04 at 12:00 +0000, Jan Beulich wrote:
>> >>> On 04.11.14 at 12:50, <andrew.cooper3@citrix.com> wrote:
>> > c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
>> > structures associated with xen_hvm_{get,set}_mem_access from the Xen public
>> > API.
>> > 
>> > While these were toolstack hypercalls and documented as liable to change in
>> > the future, it causes build issues for certain tools (valgrind, strace).
>> > 
>> > As HVM ops have no specific interface version, the main Xen interface 
>> > version
>> > needs to be bumped to compensate.
>> 
>> Content-wise I don't really object to this patch, but I view it as
>> merely cosmetic rather than fixing anything: Tool stack interfaces
>> are declared to be volatile just because we want to avoid exactly
>> this need for bumping versions or anything when altering or
>> dropping them. If there are out of tree consumers of them, it is
>> their responsibility to keep up with our changes (or have their
>> own clones of the canonical headers).
>> 
>> Also we didn't bother incrementing the version just because of a
>> release on earlier occasions: 3.3 and 3.4 as well as 4.0 and 4.1
>> shared interface versions, yet especially in the case of 4.1 I'm
>> pretty certain even without explicitly checking that there were
>> tool stack interface changes.
> 
> I always thought __XEN_(LATEST_)INTERFACE_VERSION__ were more to do with
> API rather than ABI, i.e. it gets used to revert
> __HYPERVISOR_sched_op_compat into providing __HYPERVISOR_sched_op for
> older consumers and things like that.

For __XEN_INTERFACE_VERSION__ - yes. But
__XEN_LATEST_INTERFACE_VERSION__ mainly announces
the version and is used to set the former if otherwise unset.

Jan

Re: [PATCH v2 for-4.5] xen: Bump Xen interface for Xen-4.5

[Ian Campbell]

On Tue, 2014-11-04 at 11:50 +0000, Andrew Cooper wrote:
> c/s fce5281c "x86/mem_access: Deprecate the HVM mem_access ops" removes the
> structures associated with xen_hvm_{get,set}_mem_access from the Xen public
> API.
> 
> While these were toolstack hypercalls and documented as liable to change in
> the future, it causes build issues for certain tools (valgrind, strace).

Valgrind has its own copy of the headers and needs to process old
hypercalls as well as new anyway, it will also DTRT with the ENOSYS
which results from a tool using an old interface on a new hypervisor.

Ian.