All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: "Olaf Hering" <olaf@aepfle.de>
Cc: <Ian.Campbell@citrix.com>, <xen-devel@lists.xensource.com>,
	<konrad.wilk@oracle.com>, <linux-kernel@vger.kernel.org>,
	<keir@xen.org>
Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
Date: Fri, 15 Jul 2011 09:32:35 +0100	[thread overview]
Message-ID: <4E201743020000780004D8B8@nat28.tlf.novell.com> (raw)
In-Reply-To: <20110714102628.GA9157@aepfle.de>

>>> On 14.07.11 at 12:26, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Jul 13, Jan Beulich wrote:
> 
>> >>> Ian Campbell <Ian.Campbell@citrix.com> 07/13/11 11:12 AM >>>
>> >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?
>> 
>> Indeed - migration was completely beyond my consideration when
>> submitting this. A feature flag seems the right way to go to me.
> 
> I will prepare a patch for a new feature flag.

Let me fold this into the feature handling change patch I'm close
to submit - without those changes I don't think a guest kernel would
have a way to actually announce its capability.

Jan


WARNING: multiple messages have this Message-ID (diff)
From: "Jan Beulich" <JBeulich@novell.com>
To: Olaf Hering <olaf@aepfle.de>
Cc: Ian.Campbell@citrix.com, xen-devel@lists.xensource.com,
	konrad.wilk@oracle.com, linux-kernel@vger.kernel.org,
	keir@xen.org
Subject: Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume
Date: Fri, 15 Jul 2011 09:32:35 +0100	[thread overview]
Message-ID: <4E201743020000780004D8B8@nat28.tlf.novell.com> (raw)
In-Reply-To: <20110714102628.GA9157@aepfle.de>

>>> On 14.07.11 at 12:26, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Jul 13, Jan Beulich wrote:
> 
>> >>> Ian Campbell <Ian.Campbell@citrix.com> 07/13/11 11:12 AM >>>
>> >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?
>> 
>> Indeed - migration was completely beyond my consideration when
>> submitting this. A feature flag seems the right way to go to me.
> 
> I will prepare a patch for a new feature flag.

Let me fold this into the feature handling change patch I'm close
to submit - without those changes I don't think a guest kernel would
have a way to actually announce its capability.

Jan

  reply	other threads:[~2011-07-15  8:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-13 14:29 [PATCH] xen: update machine_to_phys_order on resume Jan Beulich
2011-07-14 10:26 ` [Xen-devel] " Olaf Hering
2011-07-15  8:32   ` Jan Beulich [this message]
2011-07-15  8:32     ` Jan Beulich
  -- strict thread matches above, loose matches on Subject: below --
2011-07-15 17:30 Jan Beulich
2011-07-15 18:23 ` [Xen-devel] " Keir Fraser
2011-07-18  7:05   ` Jan Beulich
2011-07-18  7:05     ` Jan Beulich
2011-07-18  7:27     ` Keir Fraser
2011-07-18  8:31       ` Ian Campbell
2011-07-18  8:47         ` Jan Beulich
2011-07-18  9:05           ` Ian Campbell
2011-07-18  9:50             ` Jan Beulich
2011-07-01 10:41 migration of pv guest fails from small to large host Olaf Hering
2011-07-12 16:43 ` [PATCH] xen: update machine_to_phys_order on resume Olaf Hering
2011-07-12 18:11   ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-07-13  9:12     ` Ian Campbell
2011-07-13 13:20       ` Konrad Rzeszutek Wilk
2011-07-15  8:56         ` Jan Beulich
2011-07-15 16:05       ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E201743020000780004D8B8@nat28.tlf.novell.com \
    --to=jbeulich@novell.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.