Mailing List Archive

On Thu, 4 Oct 2012, Ian Campbell wrote:
> This is now a xen_pfn_t.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> drivers/xen/balloon.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index 85ef7e7..4625560 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> EXPORT_SYMBOL_GPL(balloon_stats);
>
> /* We increase/decrease in batches which fit in a page */
> -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
>
> #ifdef CONFIG_HIGHMEM
> #define inc_totalhigh_pages() (totalhigh_pages++)

While I think is a good change, frame_list[i] is used as an argument to
set_phys_to_machine, that takes an unsigned long. Also unsigned long are
assigned to members of the array via page_to_pfn.
I think that we should take care of these cases, either introducing
explicit casts or changing the argument types.

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

On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote:
> On Thu, 4 Oct 2012, Ian Campbell wrote:
> > This is now a xen_pfn_t.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > ---
> > drivers/xen/balloon.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 85ef7e7..4625560 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> > EXPORT_SYMBOL_GPL(balloon_stats);
> >
> > /* We increase/decrease in batches which fit in a page */
> > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> >
> > #ifdef CONFIG_HIGHMEM
> > #define inc_totalhigh_pages() (totalhigh_pages++)
>
> While I think is a good change, frame_list[i] is used as an argument to
> set_phys_to_machine, that takes an unsigned long. Also unsigned long are
> assigned to members of the array via page_to_pfn.
> I think that we should take care of these cases, either introducing
> explicit casts or changing the argument types.

frame_list is used at the Xen interface, and so the pfn type has to be
sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those
unsigned longs are really "linux_pfn_t", that is they are the size of
the largest pfn the guest is itself prepared to deal with.

So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then
we are ok.

If and when Linux wants to use pfn's which are not unsigned longs then
the uses of unsigned long will need to be audited (globally, not just
here) to become whatever type Linux then defines to contain a pfn. In
the absence of that type being defined in the core Linux code I think it
is correct for us to keep using unsigned long in those contexts.

Konrad, now I think about it the same argument applies to the discussion
of fgmfn in <20121004155400.GA12128@phenom.dumpdata.com>. So I'll leave
that as unsigned long as well.

Ian.


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

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote:
> > On Thu, 4 Oct 2012, Ian Campbell wrote:
> > > This is now a xen_pfn_t.
> > >
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > ---
> > > drivers/xen/balloon.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > > index 85ef7e7..4625560 100644
> > > --- a/drivers/xen/balloon.c
> > > +++ b/drivers/xen/balloon.c
> > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> > > EXPORT_SYMBOL_GPL(balloon_stats);
> > >
> > > /* We increase/decrease in batches which fit in a page */
> > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > >
> > > #ifdef CONFIG_HIGHMEM
> > > #define inc_totalhigh_pages() (totalhigh_pages++)
> >
> > While I think is a good change, frame_list[i] is used as an argument to
> > set_phys_to_machine, that takes an unsigned long. Also unsigned long are
> > assigned to members of the array via page_to_pfn.
> > I think that we should take care of these cases, either introducing
> > explicit casts or changing the argument types.
>
> frame_list is used at the Xen interface, and so the pfn type has to be
> sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those
> unsigned longs are really "linux_pfn_t", that is they are the size of
> the largest pfn the guest is itself prepared to deal with.
>
> So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then
> we are ok.

I think that we are playing with fire here.

Let's imaging a future where physical addresses are actually 64 bit.
Let's imaging that Xen is supporting them perfectly fine and returns to
this balloon driver a pfn > ULONG_MAX (already possible on ARM).

That is a perfectly valid value for Xen to give us and we should be able
to handle it. If we are not we should return an error.
With this change we would trimmer the pfn returned by Xen to 32 bit so we
would actually have an incorrect behaviour instead.

If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a
macro like this:

#define LINUX_PFN_MAX ULONG_MAX
#define linux_pfn_t unsigned long
#define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;})

that is called in the right places.


> If and when Linux wants to use pfn's which are not unsigned longs then
> the uses of unsigned long will need to be audited (globally, not just
> here) to become whatever type Linux then defines to contain a pfn. In
> the absence of that type being defined in the core Linux code I think it
> is correct for us to keep using unsigned long in those contexts.

I think is OK using unsigned long for linux_pfn, the problem is the
conversion between what Xen gives us and linux_pfns.

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

On Fri, 2012-10-05 at 15:02 +0100, Stefano Stabellini wrote:
> On Fri, 5 Oct 2012, Ian Campbell wrote:
> > On Fri, 2012-10-05 at 12:48 +0100, Stefano Stabellini wrote:
> > > On Thu, 4 Oct 2012, Ian Campbell wrote:
> > > > This is now a xen_pfn_t.
> > > >
> > > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > > > ---
> > > > drivers/xen/balloon.c | 2 +-
> > > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > > > index 85ef7e7..4625560 100644
> > > > --- a/drivers/xen/balloon.c
> > > > +++ b/drivers/xen/balloon.c
> > > > @@ -87,7 +87,7 @@ struct balloon_stats balloon_stats;
> > > > EXPORT_SYMBOL_GPL(balloon_stats);
> > > >
> > > > /* We increase/decrease in batches which fit in a page */
> > > > -static unsigned long frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > > > +static xen_pfn_t frame_list[PAGE_SIZE / sizeof(unsigned long)];
> > > >
> > > > #ifdef CONFIG_HIGHMEM
> > > > #define inc_totalhigh_pages() (totalhigh_pages++)
> > >
> > > While I think is a good change, frame_list[i] is used as an argument to
> > > set_phys_to_machine, that takes an unsigned long. Also unsigned long are
> > > assigned to members of the array via page_to_pfn.
> > > I think that we should take care of these cases, either introducing
> > > explicit casts or changing the argument types.
> >
> > frame_list is used at the Xen interface, and so the pfn type has to be
> > sized for the largest pfn the hypervisor will use (aka xen_pfn_t). Those
> > unsigned longs are really "linux_pfn_t", that is they are the size of
> > the largest pfn the guest is itself prepared to deal with.
> >
> > So long as sizeof(unsigned long) <= sizeof(xen_pfn_t) (which it is) then
> > we are ok.
>
> I think that we are playing with fire here.
>
> Let's imaging a future where physical addresses are actually 64 bit.
> Let's imaging that Xen is supporting them perfectly fine and returns to
> this balloon driver a pfn > ULONG_MAX (already possible on ARM).

It might give us an *mfn* larger than ULONG_MAX but the guest would
never see that, because ARM guests (and x86 PVHVM, PVH ones etc) never
see real mfns, they are hypervisor internal with HAP and the interfaces
are all in terms of pfns.

The issue you describe could only happen for a 32 bit HAP guest if the
guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
explicitly trying to balloon memory over that limit, but in order for
that to even be possible it would already need to have made its concept
of a pfn larger than 32 bits.

In theory there might be a problem for a PV guest, but in the only case
which matters:
arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t;
and furthermore 32 bit PV guests are limited to 160G of MFN space (which
is less than 2^32) for other reasons already.

> That is a perfectly valid value for Xen to give us and we should be able
> to handle it. If we are not we should return an error.
> With this change we would trimmer the pfn returned by Xen to 32 bit so we
> would actually have an incorrect behaviour instead.
>
> If we assume sizeof(unsigned long) <= sizeof(xen_pfn_t), we only need a
> macro like this:
>
> #define LINUX_PFN_MAX ULONG_MAX
> #define linux_pfn_t unsigned long
> #define xen_pfn_to_linux_pfn(pfn) ({BUG_ON(pfn > LINUX_PFN_MAX); (linux_pfn_t)pfn;})
>
> that is called in the right places.
>
>
> > If and when Linux wants to use pfn's which are not unsigned longs then
> > the uses of unsigned long will need to be audited (globally, not just
> > here) to become whatever type Linux then defines to contain a pfn. In
> > the absence of that type being defined in the core Linux code I think it
> > is correct for us to keep using unsigned long in those contexts.
>
> I think is OK using unsigned long for linux_pfn, the problem is the
> conversion between what Xen gives us and linux_pfns.

Xen never gives us PFNs, they are always the guest's choice.

Ian.



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

On Fri, 5 Oct 2012, Ian Campbell wrote:
> In theory there might be a problem for a PV guest, but in the only case
> which matters:
> arch/x86/include/asm/xen/interface.h:typedef unsigned long xen_pfn_t;
> and furthermore 32 bit PV guests are limited to 160G of MFN space (which
> is less than 2^32) for other reasons already.

Well, we should at least write that in a comment

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

On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote:
> The issue you describe could only happen for a 32 bit HAP guest if the
> guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
> explicitly trying to balloon memory over that limit, but in order for
> that to even be possible it would already need to have made its concept
> of a pfn larger than 32 bits.

The one place this might matter is in the privcmd
IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small
dom0 needs to be able to build a big domU). Luckily that interface
already uses xen_pfn_t, we just need to be a bit careful in the
xen_remap_domain_mfn_range case, which Konrad tried to tell me already
and he was right...

On ARM that meant the following (built but not executed) patch, I
suspect the PVH variant needs similar treatment.

8<--------------------------

diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
index ae05e56..ad87917 100644
--- a/arch/arm/include/asm/xen/interface.h
+++ b/arch/arm/include/asm/xen/interface.h
@@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
DEFINE_GUEST_HANDLE(uint64_t);
DEFINE_GUEST_HANDLE(uint32_t);
DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);

/* Maximum number of virtual CPUs in multi-processor guests. */
#define MAX_VIRT_CPUS 1
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index a9946aa..1d64c02 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
.size = 1,
.space = XENMAPSPACE_gmfn_foreign,
};
- unsigned long idx = fgmfn;
+ xen_ulong_t idx = fgmfn;
xen_pfn_t gpfn = lpfn;

set_xen_guest_handle(xatp.idxs, &idx);
@@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
}

struct remap_data {
- unsigned long fgmfn; /* foreign domain's gmfn */
+ xen_pfn_t fgmfn; /* foreign domain's gmfn */
pgprot_t prot;
domid_t domid;
struct vm_area_struct *vma;
@@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,

int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long addr,
- unsigned long mfn, int nr,
+ xen_pfn_t mfn, int nr,
pgprot_t prot, unsigned domid,
struct xen_remap_mfn_info *info)
{
diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
index 250c254..d67f3c6 100644
--- a/arch/x86/include/asm/xen/interface.h
+++ b/arch/x86/include/asm/xen/interface.h
@@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
DEFINE_GUEST_HANDLE(uint64_t);
DEFINE_GUEST_HANDLE(uint32_t);
DEFINE_GUEST_HANDLE(xen_pfn_t);
+DEFINE_GUEST_HANDLE(xen_ulong_t);
#endif

#ifndef HYPERVISOR_VIRT_START
diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
index e5675bc..24e5731 100644
--- a/include/xen/interface/memory.h
+++ b/include/xen/interface/memory.h
@@ -199,7 +199,7 @@ struct xen_add_to_physmap_range {
domid_t foreign_domid; /* IFF gmfn_foreign */

/* Indexes into space being mapped. */
- GUEST_HANDLE(ulong) idxs;
+ GUEST_HANDLE(xen_ulong_t) idxs;

/* GPFN in domid where the source mapping page should appear. */
GUEST_HANDLE(xen_pfn_t) gpfns;
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 2f3cb06..59309f3 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -27,7 +27,7 @@ struct vm_area_struct;
struct xen_remap_mfn_info;
int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
unsigned long addr,
- unsigned long mfn, int nr,
+ xen_pfn_t mfn, int nr,
pgprot_t prot, unsigned domid,
struct xen_remap_mfn_info *pvhp);
int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,



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

On Fri, 2012-10-05 at 17:11 +0100, Ian Campbell wrote:
> On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote:
> > The issue you describe could only happen for a 32 bit HAP guest if the
> > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
> > explicitly trying to balloon memory over that limit, but in order for
> > that to even be possible it would already need to have made its concept
> > of a pfn larger than 32 bits.
>
> The one place this might matter is in the privcmd
> IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small
> dom0 needs to be able to build a big domU). Luckily that interface
> already uses xen_pfn_t, we just need to be a bit careful in the
> xen_remap_domain_mfn_range case, which Konrad tried to tell me already
> and he was right...
>
> On ARM that meant the following (built but not executed) patch, I
> suspect the PVH variant needs similar treatment.

NB, this is mostly just a bug fix to "arm: implement foreign mapping
using XENMEM_add_to_physmap_range" and/or "arm: implement remap
interfaces needed for privcmd mappings."

> 8<--------------------------
>
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..ad87917 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
> DEFINE_GUEST_HANDLE(uint64_t);
> DEFINE_GUEST_HANDLE(uint32_t);
> DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>
> /* Maximum number of virtual CPUs in multi-processor guests. */
> #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index a9946aa..1d64c02 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> .size = 1,
> .space = XENMAPSPACE_gmfn_foreign,
> };
> - unsigned long idx = fgmfn;
> + xen_ulong_t idx = fgmfn;
> xen_pfn_t gpfn = lpfn;
>
> set_xen_guest_handle(xatp.idxs, &idx);
> @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> }
>
> struct remap_data {
> - unsigned long fgmfn; /* foreign domain's gmfn */
> + xen_pfn_t fgmfn; /* foreign domain's gmfn */
> pgprot_t prot;
> domid_t domid;
> struct vm_area_struct *vma;
> @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
>
> int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> unsigned long addr,
> - unsigned long mfn, int nr,
> + xen_pfn_t mfn, int nr,
> pgprot_t prot, unsigned domid,
> struct xen_remap_mfn_info *info)
> {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 250c254..d67f3c6 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
> DEFINE_GUEST_HANDLE(uint64_t);
> DEFINE_GUEST_HANDLE(uint32_t);
> DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
> #endif
>
> #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index e5675bc..24e5731 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range {
> domid_t foreign_domid; /* IFF gmfn_foreign */
>
> /* Indexes into space being mapped. */
> - GUEST_HANDLE(ulong) idxs;
> + GUEST_HANDLE(xen_ulong_t) idxs;
>
> /* GPFN in domid where the source mapping page should appear. */
> GUEST_HANDLE(xen_pfn_t) gpfns;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 2f3cb06..59309f3 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,7 +27,7 @@ struct vm_area_struct;
> struct xen_remap_mfn_info;
> int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> unsigned long addr,
> - unsigned long mfn, int nr,
> + xen_pfn_t mfn, int nr,
> pgprot_t prot, unsigned domid,
> struct xen_remap_mfn_info *pvhp);
> int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
>
>
>
> _______________________________________________
> 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

On Fri, 5 Oct 2012, Ian Campbell wrote:
> On Fri, 2012-10-05 at 15:33 +0100, Ian Campbell wrote:
> > The issue you describe could only happen for a 32 bit HAP guest if the
> > guests was given > 16GB (2^(32+PAGE_SHIFT) bytes) of RAM and it was
> > explicitly trying to balloon memory over that limit, but in order for
> > that to even be possible it would already need to have made its concept
> > of a pfn larger than 32 bits.
>
> The one place this might matter is in the privcmd
> IOCTL_PRIVCMD_MMAPBATCH interface for the *foreign* pfn (since a small
> dom0 needs to be able to build a big domU). Luckily that interface
> already uses xen_pfn_t, we just need to be a bit careful in the
> xen_remap_domain_mfn_range case, which Konrad tried to tell me already
> and he was right...
>
> On ARM that meant the following (built but not executed) patch, I
> suspect the PVH variant needs similar treatment.

I think you are right


>
> diff --git a/arch/arm/include/asm/xen/interface.h b/arch/arm/include/asm/xen/interface.h
> index ae05e56..ad87917 100644
> --- a/arch/arm/include/asm/xen/interface.h
> +++ b/arch/arm/include/asm/xen/interface.h
> @@ -43,6 +43,7 @@ DEFINE_GUEST_HANDLE(void);
> DEFINE_GUEST_HANDLE(uint64_t);
> DEFINE_GUEST_HANDLE(uint32_t);
> DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
>
> /* Maximum number of virtual CPUs in multi-processor guests. */
> #define MAX_VIRT_CPUS 1
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index a9946aa..1d64c02 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -57,7 +57,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> .size = 1,
> .space = XENMAPSPACE_gmfn_foreign,
> };
> - unsigned long idx = fgmfn;
> + xen_ulong_t idx = fgmfn;
> xen_pfn_t gpfn = lpfn;
>
> set_xen_guest_handle(xatp.idxs, &idx);
> @@ -73,7 +73,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned long fgmfn,
> }
>
> struct remap_data {
> - unsigned long fgmfn; /* foreign domain's gmfn */
> + xen_pfn_t fgmfn; /* foreign domain's gmfn */
> pgprot_t prot;
> domid_t domid;
> struct vm_area_struct *vma;
> @@ -98,7 +98,7 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token, unsigned long addr,
>
> int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> unsigned long addr,
> - unsigned long mfn, int nr,
> + xen_pfn_t mfn, int nr,
> pgprot_t prot, unsigned domid,
> struct xen_remap_mfn_info *info)
> {
> diff --git a/arch/x86/include/asm/xen/interface.h b/arch/x86/include/asm/xen/interface.h
> index 250c254..d67f3c6 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -63,6 +63,7 @@ DEFINE_GUEST_HANDLE(void);
> DEFINE_GUEST_HANDLE(uint64_t);
> DEFINE_GUEST_HANDLE(uint32_t);
> DEFINE_GUEST_HANDLE(xen_pfn_t);
> +DEFINE_GUEST_HANDLE(xen_ulong_t);
> #endif
>
> #ifndef HYPERVISOR_VIRT_START
> diff --git a/include/xen/interface/memory.h b/include/xen/interface/memory.h
> index e5675bc..24e5731 100644
> --- a/include/xen/interface/memory.h
> +++ b/include/xen/interface/memory.h
> @@ -199,7 +199,7 @@ struct xen_add_to_physmap_range {
> domid_t foreign_domid; /* IFF gmfn_foreign */
>
> /* Indexes into space being mapped. */
> - GUEST_HANDLE(ulong) idxs;
> + GUEST_HANDLE(xen_ulong_t) idxs;
>
> /* GPFN in domid where the source mapping page should appear. */
> GUEST_HANDLE(xen_pfn_t) gpfns;
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 2f3cb06..59309f3 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -27,7 +27,7 @@ struct vm_area_struct;
> struct xen_remap_mfn_info;
> int xen_remap_domain_mfn_range(struct vm_area_struct *vma,
> unsigned long addr,
> - unsigned long mfn, int nr,
> + xen_pfn_t mfn, int nr,
> pgprot_t prot, unsigned domid,
> struct xen_remap_mfn_info *pvhp);
> int xen_unmap_domain_mfn_range(struct vm_area_struct *vma,
>
>
>

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