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/
Home Products Support Community News


Re: [Xen-devel] pv 2.6.31 (kernel.org) and save/migrate fails, domU BUG

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] pv 2.6.31 (kernel.org) and save/migrate fails, domU BUG
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Wed, 25 Nov 2009 12:32:24 -0800
Cc: "Rafael J. Wysocki" <rjw@xxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, "Xen-Devel \(E-mail\)" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Delivery-date: Wed, 25 Nov 2009 12:32:52 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1259179385.30589.0.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20091108154153.GM1434@xxxxxxxxxxx> <693ea516-aa5b-4f82-ad48-1bd51cfa3480@default> <20091108172747.GR1434@xxxxxxxxxxx> <20091110100806.GE16033@xxxxxxxxxxx> <4AFC9BFF.9030707@xxxxxxxx> <1259072824.7590.389.camel@xxxxxxxxxxxxxxxxxxxxxx> <1259158328.7590.539.camel@xxxxxxxxxxxxxxxxxxxxxx> <4B0D8554.3010103@xxxxxxxx> <1259179385.30589.0.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
On 11/25/09 12:03, Ian Campbell wrote:
>> Yep.  I wonder how it ever worked?  There's been a fair amount of change
>> in the PM code, so that could have changed things.  I don't know if
>> there's a deep reason for not calling tick_resume() on all processors.
>> Rafael, tglx: suspend/resume under Xen doesn't need to hot unplug all
>> the CPUs, so we don't; the hypervisor can manage the context
>> save/restore for all CPUs.  Is there a deep reason why
>> timekeeping_resume() can't call the CLOCK_EVT_NOTIFY_RESUME notifier on
>> all online CPUs?
> Interrupts are disabled at that point where it currently calls the
> notifier, so none of the SMP function call primitives work.

That does make it pretty awkward.


Xen-devel mailing list