From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v4 08/31] libxc: rework BSP initialization Date: Fri, 7 Aug 2015 16:30:22 +0100 Message-ID: <55C4CF0E.50007@citrix.com> References: <1438942688-7610-1-git-send-email-roger.pau@citrix.com> <1438942688-7610-9-git-send-email-roger.pau@citrix.com> <20150807113143.GG6005@zion.uk.xensource.com> <55C49EC5.6090609@citrix.com> <20150807120614.GJ6005@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZNjbl-0005be-DD for xen-devel@lists.xenproject.org; Fri, 07 Aug 2015 15:30:57 +0000 In-Reply-To: <20150807120614.GJ6005@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu , =?windows-1252?Q?Roger_Pau_Monn=E9?= Cc: xen-devel@lists.xenproject.org, Ian Jackson , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On 07/08/15 13:06, Wei Liu wrote: > >>>> - ctxt = xc_hypercall_buffer_alloc(dom->xch, ctxt, sizeof(*ctxt)); >>>> - if ( ctxt == NULL ) >>>> - return -1; >>>> - >>>> DOMPRINTF_CALLED(dom->xch); >>>> >>>> /* misc stuff*/ >>>> @@ -259,13 +241,10 @@ int xc_dom_boot_image(struct xc_dom_image *dom) >>>> return rc; >>>> >>>> /* let the vm run */ >>>> - memset(ctxt, 0, sizeof(*ctxt)); >>>> - if ( (rc = dom->arch_hooks->vcpu(dom, ctxt)) != 0 ) >>>> + if ( (rc = dom->arch_hooks->vcpu(dom)) != 0 ) >>>> return rc; >>>> xc_dom_unmap_all(dom); >>> This is not your problem, but this xc_dom_unmap_all is really >>> suspicious. >> I agree, xc_dom_release already calls xc_dom_unmap_all. I guess it's not >> a big issue since xc_dom_boot_image is almost the last function called >> when doing domain creation, but I'm also not that familiar with libxc in >> order to figure out if there's a reason for calling xc_dom_unmap_all here. >> > Yeah, let's worry about that later. :) Make absolutely no assumptions about the correctness of the existing code. I got lead down several rabbit holes with migration v2 (one hole going back to 2002 and the bitkeeper source history). ~Andrew