WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH]: Allow tools to map arbitrarily large machphys_m

On Mon, 2011-03-14 at 15:11 +0000, Ian Campbell wrote:
> On Mon, 2011-03-14 at 15:05 +0000, Gianni Tedesco wrote:
> > This permits suspend/resume to work with 32bit dom0/tools. AFAICT the
> > limit to MACH2PHYS_COMPAT_NR_ENTRIES is redundant since that refers to a
> > limit in kernel mappings under 32bit hypervisors,
> 
> 32 bit guest on 64 bit h/v, but yes, it refers only to the size of the
> mapping of the compat M2P which the hypervisor provides for the guest in
> the "hypervisor hole".

Ah, thanks for clarification.

> > not userspace where
> > there may be gigabytes of useful virtual space for this.
> 
> Agreed, and in any case if the guest/tools wants to ask for more
> mappings than it can cope with, that's its own problem...
> 
> > Suggested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
> > Signed-off-by: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
> > 
> > diff -r cf558cb8b92b xen/arch/x86/x86_64/compat/mm.c
> > --- a/xen/arch/x86/x86_64/compat/mm.c       Mon Mar 07 17:52:44 2011 +0000
> > +++ b/xen/arch/x86/x86_64/compat/mm.c       Mon Mar 14 14:58:04 2011 +0000
> > @@ -162,8 +162,7 @@ int compat_arch_memory_op(int op, XEN_GU
> >              return -EFAULT;
> >  
> >          limit = (unsigned long)(compat_machine_to_phys_mapping +
> > -            min_t(unsigned long, max_page,
> > -                  MACH2PHYS_COMPAT_NR_ENTRIES(current->domain)));
> > +                    (unsigned long)max_page);
> 
> max_page is already unsigned long, so only the overall expression needs
> casting (since compat_machine_to_phys_mapping is an int *), right?

Right you are:

--

This permits suspend/resume to work with 32bit dom0/tools. AFAICT the
limit to MACH2PHYS_COMPAT_NR_ENTRIES is redundant since that refers to a
limit in 32bit guest compat mappings under 64bit hypervisors, not
userspace where there may be gigabytes of useful virtual space available
for this.

Suggested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Signed-off-by: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>

diff -r 8b5cbccbc654 xen/arch/x86/x86_64/compat/mm.c
--- a/xen/arch/x86/x86_64/compat/mm.c   Mon Mar 14 14:59:27 2011 +0000
+++ b/xen/arch/x86/x86_64/compat/mm.c   Mon Mar 14 15:17:59 2011 +0000
@@ -161,9 +161,7 @@ int compat_arch_memory_op(int op, XEN_GU
         if ( copy_from_guest(&xmml, arg, 1) )
             return -EFAULT;
 
-        limit = (unsigned long)(compat_machine_to_phys_mapping +
-            min_t(unsigned long, max_page,
-                  MACH2PHYS_COMPAT_NR_ENTRIES(current->domain)));
+        limit = (unsigned long)(compat_machine_to_phys_mapping + max_page);
         if ( limit > RDWR_COMPAT_MPT_VIRT_END )
             limit = RDWR_COMPAT_MPT_VIRT_END;
         for ( i = 0, v = RDWR_COMPAT_MPT_VIRT_START, last_mfn = 0;




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

<Prev in Thread] Current Thread [Next in Thread>