[Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Andrew Cooper]

  caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a

In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
but struct xen_add_to_physmap_batch has 'space' as a uint16_t.

By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
unsigned int to uint16_t, which changes the space switch()'d upon.

This wouldn't be noticed with any upstream code (of which I am aware), but was
discovered because of the XenServer support for legacy Windows PV drivers,
which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
The current Windows PV drivers don't do this any more, but we 'fix' Xen to
support running VMs with out-of-date tools.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>

---

As this breakage was caused between 4.4-rc1 and -rc2, I request a release ack
for the fix.

This was caught by a compile failure rather than a functional test.  I have
encountered a different compile error which turns out to be a bug in the cross
compiler we are currently using, so I need to fix that before I can
functionally test a 4.4-rc2 based XenServer.  (Which will be a rather better
test of whether the functionality of XENMEM_add_to_physmap is actually still
the same.  If anyone dares look,
https://github.com/xenserver/xen-4.3.pg/blob/master/xen-legacy-win-xenmapspace-quirks.patch
are the hacks required to make the legacy drivers work on modern Xen.)
---
 xen/arch/arm/mm.c    |    2 +-
 xen/arch/x86/mm.c    |    2 +-
 xen/include/xen/mm.h |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 293b6e2..127cce0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -970,7 +970,7 @@ void share_xen_page_with_privileged_guests(
 
 int xenmem_add_to_physmap_one(
     struct domain *d,
-    uint16_t space,
+    unsigned int space,
     domid_t foreign_domid,
     unsigned long idx,
     xen_pfn_t gpfn)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 32c0473..172c68c 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4522,7 +4522,7 @@ static int handle_iomem_range(unsigned long s, unsigned long e, void *p)
 
 int xenmem_add_to_physmap_one(
     struct domain *d,
-    uint16_t space,
+    unsigned int space,
     domid_t foreign_domid,
     unsigned long idx,
     xen_pfn_t gpfn)
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index f90ed74..b183189 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -356,7 +356,7 @@ static inline unsigned int get_order_from_pages(unsigned long nr_pages)
 
 void scrub_one_page(struct page_info *);
 
-int xenmem_add_to_physmap_one(struct domain *d, uint16_t space,
+int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
                               domid_t foreign_domid,
                               unsigned long idx, xen_pfn_t gpfn);
 
-- 
1.7.10.4

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Jan Beulich]

  >>> On 14.01.14 at 21:21, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
> 
> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned 
> int,
> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
> 
> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
> unsigned int to uint16_t, which changes the space switch()'d upon.
> 
> This wouldn't be noticed with any upstream code (of which I am aware), but 
> was
> discovered because of the XenServer support for legacy Windows PV drivers,
> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit 
> set.
> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
> support running VMs with out-of-date tools.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>

Reviewed-by: Jan Beulich <jbeulich@suse.com>

> ---
> 
> As this breakage was caused between 4.4-rc1 and -rc2, I request a release ack
> for the fix.

Seconded.

Jan

> This was caught by a compile failure rather than a functional test.  I have
> encountered a different compile error which turns out to be a bug in the 
> cross
> compiler we are currently using, so I need to fix that before I can
> functionally test a 4.4-rc2 based XenServer.  (Which will be a rather better
> test of whether the functionality of XENMEM_add_to_physmap is actually still
> the same.  If anyone dares look,
> https://github.com/xenserver/xen-4.3.pg/blob/master/xen-legacy-win-xenmapspace-qu 
> irks.patch
> are the hacks required to make the legacy drivers work on modern Xen.)
> ---
>  xen/arch/arm/mm.c    |    2 +-
>  xen/arch/x86/mm.c    |    2 +-
>  xen/include/xen/mm.h |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 293b6e2..127cce0 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -970,7 +970,7 @@ void share_xen_page_with_privileged_guests(
>  
>  int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    uint16_t space,
> +    unsigned int space,
>      domid_t foreign_domid,
>      unsigned long idx,
>      xen_pfn_t gpfn)
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 32c0473..172c68c 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4522,7 +4522,7 @@ static int handle_iomem_range(unsigned long s, unsigned 
> long e, void *p)
>  
>  int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    uint16_t space,
> +    unsigned int space,
>      domid_t foreign_domid,
>      unsigned long idx,
>      xen_pfn_t gpfn)
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index f90ed74..b183189 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -356,7 +356,7 @@ static inline unsigned int get_order_from_pages(unsigned 
> long nr_pages)
>  
>  void scrub_one_page(struct page_info *);
>  
> -int xenmem_add_to_physmap_one(struct domain *d, uint16_t space,
> +int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
>                                domid_t foreign_domid,
>                                unsigned long idx, xen_pfn_t gpfn);
>  
> -- 
> 1.7.10.4

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Ian Campbell]

On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
> 
> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
> 
> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
> unsigned int to uint16_t, which changes the space switch()'d upon.
> 
> This wouldn't be noticed with any upstream code (of which I am aware), but was
> discovered because of the XenServer support for legacy Windows PV drivers,
> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
> support running VMs with out-of-date tools.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> 
> ---
> 
> As this breakage was caused between 4.4-rc1 and -rc2,

That's certainly a good indicator, but you've not covered the actual
risks and rewards of making this change now:
http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze

Please can you do so.

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Andrew Cooper]

On 15/01/14 09:53, Ian Campbell wrote:
> On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
>>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
>>
>> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
>> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
>>
>> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
>> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
>> unsigned int to uint16_t, which changes the space switch()'d upon.
>>
>> This wouldn't be noticed with any upstream code (of which I am aware), but was
>> discovered because of the XenServer support for legacy Windows PV drivers,
>> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
>> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
>> support running VMs with out-of-date tools.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> CC: Keir Fraser <keir@xen.org>
>> CC: Jan Beulich <JBeulich@suse.com>
>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>>
>> ---
>>
>> As this breakage was caused between 4.4-rc1 and -rc2,
> That's certainly a good indicator, but you've not covered the actual
> risks and rewards of making this change now:
> http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze
>
> Please can you do so.
>
>

Contributes towards #1 "Bug-free release"

Risks:
 * We now know we have an ABI regression
 * It is a fairly obvious fix which is unlikely to have hidden issues
itself.

Rewards:
 * We keep the hypervisor ABI compatible with Xen 4.3

Alternatives:
 * Revert the patch which introduced the regression, but that is very
undesirable as it was fixing another long-running Xen operation, and
common-ifying some code between x86 and arm

~Andrew

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Ian Campbell]

On Wed, 2014-01-15 at 09:57 +0000, Andrew Cooper wrote:
> On 15/01/14 09:53, Ian Campbell wrote:
> > On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
> >>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
> >>
> >> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
> >> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
> >>
> >> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
> >> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
> >> unsigned int to uint16_t, which changes the space switch()'d upon.
> >>
> >> This wouldn't be noticed with any upstream code (of which I am aware), but was
> >> discovered because of the XenServer support for legacy Windows PV drivers,
> >> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
> >> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
> >> support running VMs with out-of-date tools.
> >>
> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> CC: Keir Fraser <keir@xen.org>
> >> CC: Jan Beulich <JBeulich@suse.com>
> >> CC: Ian Campbell <Ian.Campbell@citrix.com>
> >>
> >> ---
> >>
> >> As this breakage was caused between 4.4-rc1 and -rc2,
> > That's certainly a good indicator, but you've not covered the actual
> > risks and rewards of making this change now:
> > http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze
> >
> > Please can you do so.
> >
> >
> 
> Contributes towards #1 "Bug-free release"
> 
> Risks:
>  * We now know we have an ABI regression
>  * It is a fairly obvious fix which is unlikely to have hidden issues
> itself.
> 
> Rewards:
>  * We keep the hypervisor ABI compatible with Xen 4.3

IMHO it already is -- the 4.4 ABI is not broken because the truncated
bits are not used in the Xen ABI, 4.4 accepts everything which 4.3 does.
We still very much have the option of deferring this change to 4.5
and/or when the bits become used, with no risk to the Xen 4.4 release.

Please try and consider the guidelines exceptions with an unbiased eye,
rather than just as a mechanism for reconfirming your existing belief
that the patch should go in.

I was tempted to reject this patch just to make a point, but I think if
I'm being honest it probably should go in, so IFF Jan concurs with
"fairly obvious fix which is unlikely to have hidden issues":

Release-Ack: Ian Campbell

Next time I might be in a worse mood.

Ian.

> Alternatives:
>  * Revert the patch which introduced the regression, but that is very
> undesirable as it was fixing another long-running Xen operation, and
> common-ifying some code between x86 and arm
> 
> ~Andrew

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Jan Beulich]

>>> On 15.01.14 at 11:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Wed, 2014-01-15 at 09:57 +0000, Andrew Cooper wrote:
>> On 15/01/14 09:53, Ian Campbell wrote:
>> > On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
>> >>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
>> >>
>> >> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned 
> int,
>> >> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
>> >>
>> >> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
>> >> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
>> >> unsigned int to uint16_t, which changes the space switch()'d upon.
>> >>
>> >> This wouldn't be noticed with any upstream code (of which I am aware), but 
> was
>> >> discovered because of the XenServer support for legacy Windows PV drivers,
>> >> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit 
> set.
>> >> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
>> >> support running VMs with out-of-date tools.
>> >>
>> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>> >> CC: Keir Fraser <keir@xen.org>
>> >> CC: Jan Beulich <JBeulich@suse.com>
>> >> CC: Ian Campbell <Ian.Campbell@citrix.com>
>> >>
>> >> ---
>> >>
>> >> As this breakage was caused between 4.4-rc1 and -rc2,
>> > That's certainly a good indicator, but you've not covered the actual
>> > risks and rewards of making this change now:
>> > 
> http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_c 
> ode_freeze
>> >
>> > Please can you do so.
>> >
>> >
>> 
>> Contributes towards #1 "Bug-free release"
>> 
>> Risks:
>>  * We now know we have an ABI regression
>>  * It is a fairly obvious fix which is unlikely to have hidden issues
>> itself.
>> 
>> Rewards:
>>  * We keep the hypervisor ABI compatible with Xen 4.3
> 
> IMHO it already is -- the 4.4 ABI is not broken because the truncated
> bits are not used in the Xen ABI, 4.4 accepts everything which 4.3 does.

Not exactly: 4.4 now also accepts what 4.3 would reject.

> We still very much have the option of deferring this change to 4.5
> and/or when the bits become used, with no risk to the Xen 4.4 release.
> 
> Please try and consider the guidelines exceptions with an unbiased eye,
> rather than just as a mechanism for reconfirming your existing belief
> that the patch should go in.
> 
> I was tempted to reject this patch just to make a point, but I think if
> I'm being honest it probably should go in, so IFF Jan concurs with
> "fairly obvious fix which is unlikely to have hidden issues":

I already did in an earlier reply (or at least it was meant to be that
way).

> Release-Ack: Ian Campbell

Thanks.

> Next time I might be in a worse mood.

Hopefully not too much worse ;-)

Jan

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[David Vrabel]

On 15/01/14 10:35, Ian Campbell wrote:
> On Wed, 2014-01-15 at 09:57 +0000, Andrew Cooper wrote:
>> On 15/01/14 09:53, Ian Campbell wrote:
>>> On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
>>>>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
>>>>
>>>> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
>>>> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
>>>>
>>>> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
>>>> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
>>>> unsigned int to uint16_t, which changes the space switch()'d upon.
>>>>
>>>> This wouldn't be noticed with any upstream code (of which I am aware), but was
>>>> discovered because of the XenServer support for legacy Windows PV drivers,
>>>> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
>>>> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
>>>> support running VMs with out-of-date tools.
>>>>
>>>> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> CC: Keir Fraser <keir@xen.org>
>>>> CC: Jan Beulich <JBeulich@suse.com>
>>>> CC: Ian Campbell <Ian.Campbell@citrix.com>
>>>>
>>>> ---
>>>>
>>>> As this breakage was caused between 4.4-rc1 and -rc2,
>>> That's certainly a good indicator, but you've not covered the actual
>>> risks and rewards of making this change now:
>>> http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_code_freeze
>>>
>>> Please can you do so.
>>>
>>>
>>
>> Contributes towards #1 "Bug-free release"
>>
>> Risks:
>>  * We now know we have an ABI regression
>>  * It is a fairly obvious fix which is unlikely to have hidden issues
>> itself.
>>
>> Rewards:
>>  * We keep the hypervisor ABI compatible with Xen 4.3
> 
> IMHO it already is -- the 4.4 ABI is not broken because the truncated
> bits are not used in the Xen ABI, 4.4 accepts everything which 4.3 does.
> We still very much have the option of deferring this change to 4.5
> and/or when the bits become used, with no risk to the Xen 4.4 release.

It is a guest visible change as it changes the behaviour if the guest
supplies space >= 0x1000.  e.g., space == 0x1000 would be truncated and
it would operate on space == 0x0000 and (potentially) return sucesss
instead of an -EINVAL error.

David

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Ian Campbell]

On Wed, 2014-01-15 at 10:44 +0000, Jan Beulich wrote:
> >>> On 15.01.14 at 11:35, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > On Wed, 2014-01-15 at 09:57 +0000, Andrew Cooper wrote:
> >> On 15/01/14 09:53, Ian Campbell wrote:
> >> > On Tue, 2014-01-14 at 20:21 +0000, Andrew Cooper wrote:
> >> >>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
> >> >>
> >> >> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned 
> > int,
> >> >> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
> >> >>
> >> >> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
> >> >> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
> >> >> unsigned int to uint16_t, which changes the space switch()'d upon.
> >> >>
> >> >> This wouldn't be noticed with any upstream code (of which I am aware), but 
> > was
> >> >> discovered because of the XenServer support for legacy Windows PV drivers,
> >> >> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit 
> > set.
> >> >> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
> >> >> support running VMs with out-of-date tools.
> >> >>
> >> >> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> >> >> CC: Keir Fraser <keir@xen.org>
> >> >> CC: Jan Beulich <JBeulich@suse.com>
> >> >> CC: Ian Campbell <Ian.Campbell@citrix.com>
> >> >>
> >> >> ---
> >> >>
> >> >> As this breakage was caused between 4.4-rc1 and -rc2,
> >> > That's certainly a good indicator, but you've not covered the actual
> >> > risks and rewards of making this change now:
> >> > 
> > http://wiki.xen.org/wiki/Xen_Roadmap/4.4#Exception_guidelines_for_after_the_c 
> > ode_freeze
> >> >
> >> > Please can you do so.
> >> >
> >> >
> >> 
> >> Contributes towards #1 "Bug-free release"
> >> 
> >> Risks:
> >>  * We now know we have an ABI regression
> >>  * It is a fairly obvious fix which is unlikely to have hidden issues
> >> itself.
> >> 
> >> Rewards:
> >>  * We keep the hypervisor ABI compatible with Xen 4.3
> > 
> > IMHO it already is -- the 4.4 ABI is not broken because the truncated
> > bits are not used in the Xen ABI, 4.4 accepts everything which 4.3 does.
> 
> Not exactly: 4.4 now also accepts what 4.3 would reject.

That is a valid point, thanks. With that having been pointed out I think
it is pretty obvious that this should go in.

> I already did in an earlier reply (or at least it was meant to be that
> way).

I saw your reviewed by but didn't know if it applied to 4.4 or 4.5 so I
wanted check.

Ian.

Re: [Patch] common/memory: Fix ABI breakage for XENMEM_add_to_physmap

[Keir Fraser]

On 14/01/2014 20:21, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:

>   caused by c/s 4be86bb194e25e46b6cbee900601bfee76e8090a
> 
> In public/memory.h, struct xen_add_to_physmap has 'space' as an unsigned int,
> but struct xen_add_to_physmap_batch has 'space' as a uint16_t.
> 
> By defining xenmem_add_to_physmap_one() with space defined as uint16_t, the
> now-common xenmem_add_to_physmap() implicitly truncates xatp->space from
> unsigned int to uint16_t, which changes the space switch()'d upon.
> 
> This wouldn't be noticed with any upstream code (of which I am aware), but was
> discovered because of the XenServer support for legacy Windows PV drivers,
> which make XENMEM_add_to_physmap hypercalls using spaces with the top bit set.
> The current Windows PV drivers don't do this any more, but we 'fix' Xen to
> support running VMs with out-of-date tools.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Keir Fraser <keir@xen.org>
> CC: Jan Beulich <JBeulich@suse.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>

Acked-by: Keir Fraser <keir@xen.org>

> ---
> 
> As this breakage was caused between 4.4-rc1 and -rc2, I request a release ack
> for the fix.
> 
> This was caught by a compile failure rather than a functional test.  I have
> encountered a different compile error which turns out to be a bug in the cross
> compiler we are currently using, so I need to fix that before I can
> functionally test a 4.4-rc2 based XenServer.  (Which will be a rather better
> test of whether the functionality of XENMEM_add_to_physmap is actually still
> the same.  If anyone dares look,
> https://github.com/xenserver/xen-4.3.pg/blob/master/xen-legacy-win-xenmapspace
> -quirks.patch
> are the hacks required to make the legacy drivers work on modern Xen.)
> ---
>  xen/arch/arm/mm.c    |    2 +-
>  xen/arch/x86/mm.c    |    2 +-
>  xen/include/xen/mm.h |    2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 293b6e2..127cce0 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -970,7 +970,7 @@ void share_xen_page_with_privileged_guests(
>  
>  int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    uint16_t space,
> +    unsigned int space,
>      domid_t foreign_domid,
>      unsigned long idx,
>      xen_pfn_t gpfn)
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 32c0473..172c68c 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4522,7 +4522,7 @@ static int handle_iomem_range(unsigned long s, unsigned
> long e, void *p)
>  
>  int xenmem_add_to_physmap_one(
>      struct domain *d,
> -    uint16_t space,
> +    unsigned int space,
>      domid_t foreign_domid,
>      unsigned long idx,
>      xen_pfn_t gpfn)
> diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> index f90ed74..b183189 100644
> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -356,7 +356,7 @@ static inline unsigned int get_order_from_pages(unsigned
> long nr_pages)
>  
>  void scrub_one_page(struct page_info *);
>  
> -int xenmem_add_to_physmap_one(struct domain *d, uint16_t space,
> +int xenmem_add_to_physmap_one(struct domain *d, unsigned int space,
>                                domid_t foreign_domid,
>                                unsigned long idx, xen_pfn_t gpfn);
>