On Mon, 2011-03-14 at 16:22 +0000, Jan Beulich wrote:
> >>> 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}.
It's 1GB which is enough to cover 1TB of host memory, which AFAIK is all
we support these days. It certainly buys us time compared with currently
failing at 160GB.
> 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.
paging_init seems to do the right thing and setup the compat M2P up to a
maximum of RDWR_COMPAT_MPT_VIRT_END.
> 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).
That's another option I guess.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home