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/
Home Products Support Community News


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

To: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH]: Allow tools to map arbitrarily large machphys_mfn_list on 32bit dom0
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Mon, 14 Mar 2011 15:11:09 +0000
Cc: Tim Deegan <Tim.Deegan@xxxxxxxxxxxxx>, Keir, Fraser <keir.fraser@xxxxxxx>, Keir Fraser <keir.xen@xxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Mar 2011 08:11:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1300115112.17229.78.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <C9A026BF.14A37%keir.xen@xxxxxxxxx> <1300098009.17339.2110.camel@xxxxxxxxxxxxxxxxxxxxxx> <1300115112.17229.78.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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?


Xen-devel mailing list

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