>>> On 14.03.11 at 16:19, Gianni Tedesco <gianni.tedesco@xxxxxxxxxx> 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 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);
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 = 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
|
Home