Xen devel - Aug 2005 - allocate_empty_lowmem_region hypervisor function

Hi,

Is there a reason that the allocate_empty_lowmem_region() function in
hypervisor.c is only available in Domain 0.  It is only included if
CONFIG_XEN_PHYSDEV_ACCESS is defined, however, when I remove this it seems to
work fine in DomUs.

Thanks,

Ross





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

> Is there a reason that the allocate_empty_lowmem_region() function in
> hypervisor.c is only available in Domain 0.  It is only included if
> CONFIG_XEN_PHYSDEV_ACCESS is defined, however, when I remove this it seems
> to work fine in DomUs.
It''s only used in the backend drivers, so I guess the build is trying
to omit
that as dead code as far as a domU is concerned.  IIRC the function is pure 
Linux-isms with no Xen-specifics, so it should be fine to build into a domU 
(or even x86 Linux).

Cheers,
Mark

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

> It''s only used in the backend drivers, so I guess the build is
trying to omit
> that as dead code as far as a domU is concerned.  
Could it be added to DomU, otherwise there is no way to map foreign
pages using the grant tables in unprivileged domains.  I thought the
point of grant tables was to allow inter domain communication between
non-privileged domains?  I could easily supply a patch if people think
this should be possible.
> IIRC the function is pure Linux-isms with no Xen-specifics, so it should be
fine to
> build into a domU (or even x86 Linux).
It uses the balloon driver and hypervisor calls, so I don''t think it
would work in x86 Linux, but it works fine in DomU.

Thanks,

Ross

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

> > It''s only used in the backend drivers, so I guess the build
is trying to
> > omit that as dead code as far as a domU is concerned.
>
> Could it be added to DomU, otherwise there is no way to map foreign
> pages using the grant tables in unprivileged domains.
> I thought the 
> point of grant tables was to allow inter domain communication between
> non-privileged domains?
Yep.  The existing uses of grant tables (Netif, XenFS) all used page exchange, 
so they would have had somewhere to map incoming pages (i.e. empty slots left 
by frames they''d flipped to the server).  If you''re running a
backend then
you really do need this function to make some space to map with.
> I could easily supply a patch if people think 
> this should be possible.
The lightest-weight solution (minimising dead code) would be to have this only 
built if you are building a backend driver.  Then again, building it 
unconditionally won''t add much code and is a rather smaller patch.

In any case, I think we should enable backends without physdev access so a 
patch would be good to see.
> > IIRC the function is pure Linux-isms with no Xen-specifics, so it
should
> > be fine to build into a domU (or even x86 Linux).
>
> It uses the balloon driver and hypervisor calls, so I don''t think
it
> would work in x86 Linux, but it works fine in DomU.
Oops, I was thinking of a different, related call in the backend :-)  But yes, 
allocate_empty_lowmem will work fine in domU.

Cheers,
Mark

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

Below is a patch to the enable allocate_empty_lowmem_region in
on-privileged domains, so that backend drivers can map granted foreign
pages even if they are running in an unprivileged domain. (as per the
"allocate_empty_lowmem_region hypervisor function" thread discussion)

Thanks

Ross


# HG changeset patch
# User rcmcilro@localhost.localdomain
# Node ID b235cde45efbb903d3e0e9626df6a90adde20577
# Parent  2f743309f21afdc6adaef01421da40f7ff1e8b0d
Add allocate_empty_lowmem_region() for unprivileged domains

diff -r 2f743309f21a -r b235cde45efb
linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c
--- a/linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c	Tue Aug  2
12:37:37 2005
+++ b/linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c	Tue Aug  2
13:58:30 2005
@@ -35,6 +35,7 @@
 #include <asm/pgtable.h>
 #include <asm-xen/hypervisor.h>
 #include <asm-xen/balloon.h>
+#include <linux/module.h>
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)
 #include <linux/percpu.h>
 #include <asm/tlbflush.h>
@@ -312,7 +313,6 @@
     balloon_unlock(flags);
 }
 
-#ifdef CONFIG_XEN_PHYSDEV_ACCESS
 
 unsigned long allocate_empty_lowmem_region(unsigned long pages)
 {
@@ -360,4 +360,4 @@
     return vstart;
 }
 
-#endif /* CONFIG_XEN_PHYSDEV_ACCESS */
+EXPORT_SYMBOL(allocate_empty_lowmem_region);
diff -r 2f743309f21a -r b235cde45efb
linux-2.6-xen-sparse/include/asm-xen/hypervisor.h
--- a/linux-2.6-xen-sparse/include/asm-xen/hypervisor.h	Tue Aug  2 12:37:37 2005
+++ b/linux-2.6-xen-sparse/include/asm-xen/hypervisor.h	Tue Aug  2 13:58:30 2005
@@ -136,10 +136,8 @@
 
 void xen_contig_memory(unsigned long vstart, unsigned int order);
 
-#ifdef CONFIG_XEN_PHYSDEV_ACCESS
 /* Allocate a contiguous empty region of low memory. Return virtual start. */
 unsigned long allocate_empty_lowmem_region(unsigned long pages);
-#endif
 
 #include <asm/hypercall.h>


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

> Below is a patch to the enable allocate_empty_lowmem_region in
> on-privileged domains, so that backend drivers can map granted foreign
> pages even if they are running in an unprivileged domain. (as per the
> "allocate_empty_lowmem_region hypervisor function" thread
discussion)
I see you''re adding an export so that it''s usable by modules;
I think that
makes sense.  Although the current backends must be statically compiled 
there''s no reason not to export this for other backends to use.  Harry
tells
me the 2.6 USB backend is fully modularised, for instance (he also pointed 
out there''s no way to deallocate the empty lowmem region on unload,
which''ll
need to be addressed at some stage).

I did wonder if we ought to tweak the name if we''re exporting to the
rest of
the kernel (e.g. prefix xen_) but I don''t think we have a convention
for
that.

Basically, +1 from me.  I like it.

Cheers,
Mark
> Thanks
>
> Ross
>
>
> # HG changeset patch
> # User rcmcilro@localhost.localdomain
> # Node ID b235cde45efbb903d3e0e9626df6a90adde20577
> # Parent  2f743309f21afdc6adaef01421da40f7ff1e8b0d
> Add allocate_empty_lowmem_region() for unprivileged domains
>
> diff -r 2f743309f21a -r b235cde45efb
> linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c
> --- a/linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c	Tue Aug  2
> 12:37:37 2005
> +++ b/linux-2.6-xen-sparse/arch/xen/i386/mm/hypervisor.c	Tue Aug  2
> 13:58:30 2005
> @@ -35,6 +35,7 @@
>  #include <asm/pgtable.h>
>  #include <asm-xen/hypervisor.h>
>  #include <asm-xen/balloon.h>
> +#include <linux/module.h>
>  #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0)
>  #include <linux/percpu.h>
>  #include <asm/tlbflush.h>
> @@ -312,7 +313,6 @@
>      balloon_unlock(flags);
>  }
>
> -#ifdef CONFIG_XEN_PHYSDEV_ACCESS
>
>  unsigned long allocate_empty_lowmem_region(unsigned long pages)
>  {
> @@ -360,4 +360,4 @@
>      return vstart;
>  }
>
> -#endif /* CONFIG_XEN_PHYSDEV_ACCESS */
> +EXPORT_SYMBOL(allocate_empty_lowmem_region);
> diff -r 2f743309f21a -r b235cde45efb
> linux-2.6-xen-sparse/include/asm-xen/hypervisor.h
> --- a/linux-2.6-xen-sparse/include/asm-xen/hypervisor.h	Tue Aug  2 12:37:37
> 2005 +++ b/linux-2.6-xen-sparse/include/asm-xen/hypervisor.h	Tue Aug  2
> 13:58:30 2005 @@ -136,10 +136,8 @@
>
>  void xen_contig_memory(unsigned long vstart, unsigned int order);
>
> -#ifdef CONFIG_XEN_PHYSDEV_ACCESS
>  /* Allocate a contiguous empty region of low memory. Return virtual start.
> */ unsigned long allocate_empty_lowmem_region(unsigned long pages);
> -#endif
>
>  #include <asm/hypercall.h>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel