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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 14.03.11 at 17:03, Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> On Mon, 2011-03-14 at 15:55 +0000, Jan Beulich wrote:
>> >>> 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).
> 
> In order to be able to migrate any guest the tools in domain 0 need to
> see the entire of host M2P, not just the subset which the kernel sees
> mapped into its hypervisor hole (which is what
> MACH2PHYS_COMPAT_NR_ENTRIES represents).
> 
> The hypercall reads from the global compat M2P mapping, not the guest
> kernel mapping of it, so it should read valid entries all the way up to
> RDWR_COMPAT_MPT_VIRT_END, AFAICT.

But RDWR_COMPAT_MPT_VIRT_END still doesn't necessarily
cover all of the memory the machine may have (after all the
range is way smaller than RDWR_MPT_VIRT_{START,END}.

If that's the goal, then the patch as presented isn't suitable,
as there's not event a compat table set up for all of the
memory. I'd say the tools then need to have access to the
native table, reading 64-bit MFNs from it (since, with MFN
compression, we can exceed 32-bits).

Jan




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