From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH v10 11/11] (lib)xl: soft reset support
Date: Tue, 01 Sep 2015 13:52:48 +0200
Message-ID: <87r3mie4q7.fsf@vitty.brq.redhat.com>
References: <1438090096-8297-1-git-send-email-vkuznets@redhat.com>
	<1438090096-8297-12-git-send-email-vkuznets@redhat.com>
	<20150831141417.GF22586@zion.uk.xensource.com>
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.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <vkuznets@redhat.com>) id 1ZWk7W-0003ES-M8
	for xen-devel@lists.xenproject.org; Tue, 01 Sep 2015 11:52:58 +0000
In-Reply-To: <20150831141417.GF22586@zion.uk.xensource.com> (Wei Liu's message
	of "Mon, 31 Aug 2015 15:14:17 +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: Wei Liu <wei.liu2@citrix.com>
Cc: Andrew Jones <drjones@redhat.com>, Julien Grall <julien.grall@linaro.org>, 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>, Olaf Hering <olaf@aepfle.de>, Tim Deegan <tim@xen.org>, David Vrabel <david.vrabel@citrix.com>, Jan Beulich <jbeulich@suse.com>, xen-devel@lists.xenproject.org, Daniel De Graaf <dgdegra@tycho.nsa.gov>
List-Id: xen-devel@lists.xenproject.org

Wei Liu <wei.liu2@citrix.com> writes:

[skip]

>>  
>> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>> index ff0d616..5f5559b 100644
>> --- a/tools/libxl/libxl.c
>> +++ b/tools/libxl/libxl.c
>> @@ -1478,6 +1478,7 @@ void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds)
>>          dds->stubdom.ao = ao;
>>          dds->stubdom.domid = stubdomid;
>>          dds->stubdom.callback = stubdom_destroy_callback;
>> +        dds->stubdom.soft_reset = false;
>>          libxl__destroy_domid(egc, &dds->stubdom);
>>      } else {
>>          dds->stubdom_finished = 1;
>> @@ -1486,6 +1487,7 @@ void libxl__domain_destroy(libxl__egc *egc, libxl__domain_destroy_state *dds)
>>      dds->domain.ao = ao;
>>      dds->domain.domid = dds->domid;
>>      dds->domain.callback = domain_destroy_callback;
>> +    dds->domain.soft_reset = dds->soft_reset;
>>      libxl__destroy_domid(egc, &dds->domain);
>>  }
>
> OOI have you tested stubdom case?
>

No, but ...

> Of course stubdom.soft_reset should be set to false, but do you really
> want to destroy stubdom?
>
> Sorry if my question is dumb or the answer is obvious. I expect stubdom
> QEMU would be rebuilt just like normal QEMU running in Dom0? From
> reading the code I think this is the case, but I prefer confirmation
> from you.

Yes, we need to restart domain's device model in all cases: 
1) We need it to release all memory mappings it has, and
2) XEN_DOMCTL_soft_reset will close all the existent event channels and
there is no way to ask QEMU to re-bind them.
Domain create path will re-launch QEMU and re-create stubdom if
required.

This actually resembles the migration case: we don't migrate stubdomains,
we re-create them.

>
> This is the only concern I have with this patch.
>

Thanks for the review! I'll fix all the issues you spotted and try to
test stubdomain case before sending out v11.

[skip]

-- 
  Vitaly