[Xen-devel] Re: [PATCH]: Allow tools to map arbitrarily large machphys_mfn_list on 32bit dom0

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

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".

> 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?

Ian.



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