From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] xen: update machine_to_phys_order on resume Date: Fri, 15 Jul 2011 18:30:22 +0100 Message-ID: <4E20873F020000780007307B@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0793014041==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian.Campbell@citrix.com, konrad.wilk@oracle.com, keir@xen.org Cc: olaf@aepfle.de, xen-devel@lists.xensource.com, linux-kernel@vger.kernel.org List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --===============0793014041== Content-Type: multipart/alternative; boundary="=__Part416E223E.2__=" This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part416E223E.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> "Jan Beulich" 07/15/11 6:07 PM >>> >>>> On 13.07.11 at 11:12, Ian Campbell 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. Actually, one more thought: What's the purpose of this hypercall if it is set in stone what values it ought to return? Isn't a guest using it (supposed to be) advertising that it can deal with the values being variable (and it was just overlooked so far that this doesn't only include varying values from boot to boot, but also migration)? Or in other words, if we found a need to relocate the M2P table or grow its static maximum size, it would be impossible to migrate guests from an old to a new hypervisor. Jan --=__Part416E223E.2__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML >>> "Jan Beulich" <JBeulich@novell.com> = 07/15/11 6:07 PM >>>
>>>> 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
>not= e specified features of a DomU kernel. Passing this information
>down= from the tools or from the guest kernel itself otoh doesn't
>necessa= rily 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.
<= br>Actually, one more thought: What's the purpose of this hypercall = if
it is set in stone what values it ought to return? Isn't a guest = using
it (supposed to be) advertising that it can deal with the values = being
variable (and it was just overlooked so far that this doesn't = only
include varying values from boot to boot, but also migration)? Or = in
other words, if we found a need to relocate the M2P table or = grow
its static maximum size, it would be impossible to migrate = guests
from an old to a new hypervisor.

Jan
--=__Part416E223E.2__=-- --===============0793014041== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0793014041==--