[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <4E208162020000780004DA39@nat28.tlf.novell.com>
Date: Fri, 15 Jul 2011 17:05:22 +0100
From: "Jan Beulich" <JBeulich@...ell.com>
To: "Ian Campbell" <Ian.Campbell@...rix.com>,
"Konrad Rzeszutek Wilk" <konrad.wilk@...cle.com>,
"Keir Fraser" <keir@....org>
Cc: "Olaf Hering" <olaf@...fle.de>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on
resume
>>> On 13.07.11 at 11:12, Ian Campbell <Ian.Campbell@...rix.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists