From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vitaly Kuznetsov Subject: Re: [PATCH v9 08/11] xen: arch-specific hooks for domain_soft_reset() Date: Fri, 24 Jul 2015 14:41:17 +0200 Message-ID: <874mktiv82.fsf@vitty.brq.redhat.com> References: <1437064046-12174-1-git-send-email-vkuznets@redhat.com> <1437064046-12174-9-git-send-email-vkuznets@redhat.com> <55B249A40200007800095277@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIcI3-0000NK-RR for xen-devel@lists.xenproject.org; Fri, 24 Jul 2015 12:41:27 +0000 In-Reply-To: <55B249A40200007800095277@prv-mh.provo.novell.com> (Jan Beulich's message of "Fri, 24 Jul 2015 06:20:20 -0600") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Olaf Hering , Wei Liu , Ian Campbell , Stefano Stabellini , Andrew Cooper , Julien Grall , Ian Jackson , Andrew Jones , Tim Deegan , David Vrabel , xen-devel@lists.xenproject.org, Daniel De Graaf , Keir Fraser List-Id: xen-devel@lists.xenproject.org "Jan Beulich" writes: >>>> On 16.07.15 at 18:27, wrote: >> --- a/xen/arch/x86/domain.c >> +++ b/xen/arch/x86/domain.c >> @@ -704,6 +704,90 @@ void arch_domain_unpause(struct domain *d) >> viridian_time_ref_count_thaw(d); >> } >> >> +int arch_domain_soft_reset(struct domain *d) >> +{ >> + struct page_info *page = virt_to_page(d->shared_info), *new_page; >> + int ret = 0; >> + struct domain *owner; >> + unsigned long mfn, mfn_new, gfn; >> + p2m_type_t p2mt; >> + unsigned int i; >> + >> + /* Soft reset is supported for HVM domains only. */ >> + if ( !is_hvm_domain(d) ) >> + return -EINVAL; > > This suggests that the whole function may better go somewhere in > hvm/. > > And is this intentionally excluding PVH? > Not really. As far as I understand the descision is to go for "HVM without dm" way for PVH in future? In that case, isn't is_hvm_domain() supposed to return true for it? I hope the selected approach to kexec should "just work" for such PVH guests. >... >> --- a/xen/common/domain.c >> +++ b/xen/common/domain.c >> @@ -1035,6 +1035,10 @@ int domain_soft_reset(struct domain *d) >> for_each_vcpu ( d, v ) >> unmap_vcpu_info(v); >> >> + rc = arch_domain_soft_reset(d); >> + if (rc) >> + return rc; > > I don't think this can be done this late, or else you'd need to have > a way to undo everything you've done earlier in the function. This > of course also applies to what's being done inside the function. Or > if undoing is - as it looks like - rather hard, perhaps the domain > would better be crashed than left in an inconsistent state? Crashing the domain seems reasonable. -- Vitaly