WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] xen: update machine_to_phys_order on resume

>>> On 13.07.11 at 15:20, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> On Wed, Jul 13, 2011 at 10:12:44AM +0100, Ian Campbell wrote:
>> On Tue, 2011-07-12 at 19:11 +0100, Konrad Rzeszutek Wilk wrote:
>> > On Tue, Jul 12, 2011 at 06:43:42PM +0200, Olaf Hering wrote:
>> > > 
>> > > Migration of pv guests fails, the guest crashes on the target host once 
> the
>> > > guest is unpaused after transit. It happens when the guest is started on 
>> > > a
>> > > small systen, then migrated from that small system to a large system.
>> > > If the guest is started on a large system, then migrated to a small 
>> > > system 
> and
>> > > back to the large system, the migration will be successful.
>> > > 
>> > > The issue is that mfn_to_pfn() makes use of machine_to_phys_order, which
>> > > is only configured once early in the boot process. After migration to a
>> > > large host the mfns will exceed the order from the small system and a
>> > > wrong code path is taken.
>> > > 
>> > > Calling xen_setup_machphys_mapping() again in the resume path will avoid
>> > > the crash.
>> > 
>> > Oh, duh!
>> > 
>> > Let me queue that up for 3.0-rc7 unless there are objections?
>> 
>> 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?
> 
> Sounds reasonable to me.. I will wait (I can always submit it during 3.1 
> cycle
> and CC stable@xxxxxxxxxx to backport it to 3.0.1).
> 
> Jan, you are the one who came up with the c/s - what's your thought?
> How does your kernel handle the changing size of the M2P - like the patch 
> below?

As said in an earlier reply to Ian, I didn't pay attention to the
migration aspects and I'm in favor of introducing a feature flag
to control the behavior.

In the meantime, as an immediate fix, I just sent out a patch to
revert to original behavior for all but Dom0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel