From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v3 0/1] Introduce VCPUOP_reset_vcpu_info
Date: Wed, 20 Aug 2014 10:43:41 +0200
Message-ID: <877g23mtz6.fsf@vitty.brq.redhat.com>
References: <1408442683-12125-1-git-send-email-vkuznets@redhat.com>
	<53F39EA8.5020602@cantab.net>
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.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1XK1Uq-0008I1-Jq
	for xen-devel@lists.xenproject.org; Wed, 20 Aug 2014 08:43:56 +0000
In-Reply-To: <53F39EA8.5020602@cantab.net> (David Vrabel's message of "Tue, 19
	Aug 2014 19:59:52 +0100")
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: David Vrabel <dvrabel@cantab.net>
Cc: xen-devel@lists.xenproject.org, Andrew Jones <drjones@redhat.com>, David Vrabel <david.vrabel@citrix.com>, Jan Beulich <JBeulich@suse.com>
List-Id: xen-devel@lists.xenproject.org

David Vrabel <dvrabel@cantab.net> writes:

> On 19/08/14 11:04, Vitaly Kuznetsov wrote:
>> The patch and guest code are based on the prototype by Konrad Rzeszutek Wilk.
>>
>> VCPUOP_reset_vcpu_info is required to support kexec performed by smp pvhvm
>> guest. It was tested with the guest code listed below.
>
> Instead of having the guest teardown all these bits of  setup.  I
> think it would be preferable to have the toolstack build a new domain
> with the same memory contents from the original VM.  The toolstack
> would then start this new domain at the kexec entry point.
>
> The advantage of this is you don't need to add new hypercall sub-ops
> to teardown all bits and pieces, both for existing stuff and for
> anything new that might be added.

I agree this might be the more general approach to kexec. However, I
also think that having 'paired'  operations in hypervisor is a nice
thing to have: e.g. if we have EVTCHNOP_init_control that we need an op
to switch back, if there is VCPUOP_register_vcpu_info there should
be a sort of VCPUOP_reset_vcpu_info ...

The other question would be how can toolstack determine that hvm guest
is performing kexec/kdump? I can imaging some sort of a special
toolstack-handled call with new entry point as a parameter.. 

>
> David

-- 
  Vitaly