From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Jan Beulich" <JBeulich@novell.com>
Subject: Re: [PATCH]: Allow tools to map arbitrarily large
	machphys_mfn_list on 32bit dom0
Date: Mon, 14 Mar 2011 15:55:47 +0000
Message-ID: <4D7E489302000078000365B5@vpn.id2.novell.com>
References: <C9A026BF.14A37%keir.xen@gmail.com>
	<1300098009.17339.2110.camel@zakaz.uk.xensource.com>
	<1300115112.17229.78.camel@qabil.uk.xensource.com>
	<1300115469.17339.2188.camel@zakaz.uk.xensource.com>
	<1300115967.17229.82.camel@qabil.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <1300115967.17229.82.camel@qabil.uk.xensource.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Gianni Tedesco <gianni.tedesco@citrix.com>, Ian Campbell <Ian.Campbell@eu.citrix.com>
Cc: Keir@citrix.com, Tim Deegan <Tim.Deegan@eu.citrix.com>, Fraser <keir.fraser@xen.org>, Keir Fraser <keir.xen@gmail.com>, Xen Devel <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

>>> On 14.03.11 at 16:19, Gianni Tedesco <gianni.tedesco@citrix.com> =
wrote:
>=20
> 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.
>=20
> Suggested-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
>=20
> 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;
> =20
> -        limit =3D (unsigned long)(compat_machine_to_phys_mapping +
> -            min_t(unsigned long, max_page,
> -                  MACH2PHYS_COMPAT_NR_ENTRIES(current->domain)));
> +        limit =3D (unsigned long)(compat_machine_to_phys_mapping + =
max_page);

While doing this shouldn't hurt (except slightly for performance of
the hypercall), I don't see why it's useful: For slots past
MACH2PHYS_COMPAT_NR_ENTRIES(current->domain) you
wouldn't read non-null page table entries anyway (up to
RDWR_COMPAT_MPT_VIRT_END), so I don't see why the tools
couldn't equally well do with what we have currently (after all
they get told how many slots were filled).

Jan

>          if ( limit > RDWR_COMPAT_MPT_VIRT_END )
>              limit =3D RDWR_COMPAT_MPT_VIRT_END;
>          for ( i =3D 0, v =3D RDWR_COMPAT_MPT_VIRT_START, last_mfn =3D =
0;