On Mon, 2011-03-14 at 17:00 +0000, Jan Beulich wrote:
> >>> On 14.03.11 at 17:54, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> > On 14/03/2011 16:33, "Ian Campbell" <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> >
> >>> 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.
> >
> > It's not really an option for 4.1.0. Can we at least agree that this is an
> > improvement for now, and in time for 4.1.0?
>
> Yes, as long as the tools can handle the extended output.
It certainly seems to work for the domain suspend case, I'm not sure
where else it might fail but it-seems-to-me(tm) that tools should be
able to handle the output that they asked for.
Gianni
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home