lkml.org 
[lkml]   [2011]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
>>> On 13.07.11 at 11:12, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> It's not so much an objection to this patch but this issue seems to have
> been caused by Xen cset 20892:d311d1efc25e which looks to me like a
> subtle ABI breakage for guests. Perhaps we should introduce a feature
> flag to indicate that a guest can cope with the m2p changing size over
> migration like this?

That's actually not strait forward, as the hypervisor can't see the ELF
note specified features of a DomU kernel. Passing this information
down from the tools or from the guest kernel itself otoh doesn't
necessarily seem worth it. Instead a guest that can deal with the
upper bound of the M2P table changing can easily obtain the
desired information through XENMEM_maximum_ram_page. So I
think on the hypervisor side we're good with the patch I sent
earlier today.

Now - does anyone remember why machine_to_phys_order got
introduced in the first place (rather than doing a precise upper
bound check using the maximum number the hypervisor returned)?
I really can't see any benefit in calculating and using the much
more coarse order only.

Jan




\
 
 \ /
  Last update: 2011-07-15 18:07    [W:0.055 / U:2.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site