From mboxrd@z Thu Jan  1 00:00:00 1970
From: David Vrabel <david.vrabel@citrix.com>
Subject: Re: [PATCH v4 0/9] toolstack-based approach to pvhvm
 guest kexec
Date: Thu, 11 Dec 2014 15:24:17 +0000
Message-ID: <5489B721.6010504@citrix.com>
References: <1417626981-8432-1-git-send-email-vkuznets@redhat.com>
	<20141211142428.GA19820@aepfle.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta14.messagelabs.com ([193.109.254.103])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <david.vrabel@citrix.com>) id 1Xz5bp-0006HW-Ic
	for xen-devel@lists.xenproject.org; Thu, 11 Dec 2014 15:24:53 +0000
In-Reply-To: <20141211142428.GA19820@aepfle.de>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Olaf Hering <olaf@aepfle.de>, Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Keir Fraser <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org, Wei Liu <wei.liu2@citrix.com>
List-Id: xen-devel@lists.xenproject.org

On 11/12/14 14:24, Olaf Hering wrote:
> On Wed, Dec 03, Vitaly Kuznetsov wrote:
> 
>> When a PVHVM linux guest performs kexec there are lots of things which
>> require taking care of:
>> - shared info, vcpu_info
>> - grants
>> - event channels
>> - ...
>> Instead of taking care of all these things we can rebuild the domain
>> performing kexec from scratch doing so-called soft-reboot.
> 
> How does this approach handle ballooned pages?
>>>From the guests point of view they are always there, just claimed by the
> balloon driver. The new kernel does not have that driver nor does its
> driver have the knowledge which pages the old kernel gave back to Xen.
> 
> After a brief look none of the patches seem to deal with that.

Nothing special needs to be done with ballooned pages.  If frames are
not populated in the original domain, they will be unpopulated in the
new domain.

It's the responsibility of the guest to ensure it either doesn't kexec
when it is ballooned or that the kexec kernel can handle this (e.g., by
using a crash region that is never ballooned out).

David