On Thu, Jul 26, 2012 at 04:34:02PM +0100, Stefano Stabellini wrote:
> Update struct xen_add_to_physmap to be in sync with Xen's version of the
> structure.
> The size field was introduced by:
>
> changeset: 24164:707d27fe03e7
> user: Jean Guyader <[email protected]>
> date: Fri Nov 18 13:42:08 2011 +0000
> summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range
>
> According to the comment:
>
> "This new field .size is located in the 16 bits padding between .domid
> and .space in struct xen_add_to_physmap to stay compatible with older
> versions."
>
> This is not true on ARM where there is not padding, but it is valid on
> X86, so introducing size is safe on X86 and it is going to fix the
> interace for ARM.
Has this been checked actually for backwards compatibility? It sounds
like it should work just fine with Xen 4.0 right?
I believe this also helps Mukesh's patches, so CC-ing him here for
his Ack.
I can put this in right now in tree if we are 100% sure its compatiblie with 4.0.
>
> Signed-off-by: Stefano Stabellini <[email protected]>
> ---
> include/xen/interface/memory.h | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index abbbff0..d8e33a9 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -163,6 +163,9 @@ struct xen_add_to_physmap {
> /* Which domain to change the mapping for. */
> domid_t domid;
>
> + /* Number of pages to go through for gmfn_range */
> + uint16_t size;
> +
> /* Source mapping space. */
> #define XENMAPSPACE_shared_info 0 /* shared info page */
> #define XENMAPSPACE_grant_table 1 /* grant table page */
> --
> 1.7.2.5
On Wed, 1 Aug 2012, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 26, 2012 at 04:34:02PM +0100, Stefano Stabellini wrote:
> > Update struct xen_add_to_physmap to be in sync with Xen's version of the
> > structure.
> > The size field was introduced by:
> >
> > changeset: 24164:707d27fe03e7
> > user: Jean Guyader <[email protected]>
> > date: Fri Nov 18 13:42:08 2011 +0000
> > summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range
> >
> > According to the comment:
> >
> > "This new field .size is located in the 16 bits padding between .domid
> > and .space in struct xen_add_to_physmap to stay compatible with older
> > versions."
> >
> > This is not true on ARM where there is not padding, but it is valid on
> > X86, so introducing size is safe on X86 and it is going to fix the
> > interace for ARM.
>
> Has this been checked actually for backwards compatibility? It sounds
> like it should work just fine with Xen 4.0 right?
>
> I believe this also helps Mukesh's patches, so CC-ing him here for
> his Ack.
>
> I can put this in right now in tree if we are 100% sure its compatiblie with 4.0.
Yes, it is: 4 bytes integers are 4-byte aligned on 32 bit and 64 bit
on x86.
On Wed, 1 Aug 2012 10:52:15 -0400
Konrad Rzeszutek Wilk <[email protected]> wrote:
> On Thu, Jul 26, 2012 at 04:34:02PM +0100, Stefano Stabellini wrote:
> > Update struct xen_add_to_physmap to be in sync with Xen's version
> > of the structure.
> > The size field was introduced by:
> >
> > changeset: 24164:707d27fe03e7
> > user: Jean Guyader <[email protected]>
> > date: Fri Nov 18 13:42:08 2011 +0000
> > summary: mm: New XENMEM space, XENMAPSPACE_gmfn_range
> >
> > According to the comment:
> >
> > "This new field .size is located in the 16 bits padding
> > between .domid and .space in struct xen_add_to_physmap to stay
> > compatible with older versions."
> >
> > This is not true on ARM where there is not padding, but it is valid
> > on X86, so introducing size is safe on X86 and it is going to fix
> > the interace for ARM.
>
> Has this been checked actually for backwards compatibility? It sounds
> like it should work just fine with Xen 4.0 right?
>
> I believe this also helps Mukesh's patches, so CC-ing him here for
> his Ack.
Yup, I already had that change in my tree.
thanks,
Mukesh