Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965255Ab2JCRIA (ORCPT ); Wed, 3 Oct 2012 13:08:00 -0400 Received: from smtp.ctxuk.citrix.com ([62.200.22.115]:36037 "EHLO SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964890Ab2JCRH6 (ORCPT ); Wed, 3 Oct 2012 13:07:58 -0400 X-IronPort-AV: E=Sophos;i="4.80,528,1344211200"; d="scan'208";a="14921858" Date: Wed, 3 Oct 2012 18:06:56 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell CC: Stefano Stabellini , "xen-devel@lists.xensource.com" , "linux-kernel@vger.kernel.org" , Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH] xen: point xen_start_info to a dummy struct for PV on HVM guests In-Reply-To: <1349282492.650.185.camel@zakaz.uk.xensource.com> Message-ID: References: <1349272182.650.150.camel@zakaz.uk.xensource.com> <1349272482.650.151.camel@zakaz.uk.xensource.com> <20121003141116.GA10633@phenom.dumpdata.com> <1349276431.650.156.camel@zakaz.uk.xensource.com> <1349279862.650.171.camel@zakaz.uk.xensource.com> <1349280814.650.178.camel@zakaz.uk.xensource.com> <1349282492.650.185.camel@zakaz.uk.xensource.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5625 Lines: 124 On Wed, 3 Oct 2012, Ian Campbell wrote: > On Wed, 2012-10-03 at 17:13 +0100, Ian Campbell wrote: > > On Wed, 2012-10-03 at 17:05 +0100, Stefano Stabellini wrote: > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > On Wed, 2012-10-03 at 16:48 +0100, Stefano Stabellini wrote: > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > On Wed, 2012-10-03 at 15:11 +0100, Konrad Rzeszutek Wilk wrote: > > > > > > > On Wed, Oct 03, 2012 at 02:54:42PM +0100, Ian Campbell wrote: > > > > > > > > On Wed, 2012-10-03 at 14:51 +0100, Stefano Stabellini wrote: > > > > > > > > > On Wed, 3 Oct 2012, Ian Campbell wrote: > > > > > > > > > > On Wed, 2012-10-03 at 14:37 +0100, Stefano Stabellini wrote: > > > > > > > > > > > PV on HVM guests don't have a start_info page mapped by Xen, so > > > > > > > > > > > xen_start_info is just NULL for them. > > > > > > > > > > > That is problem because other parts of the code expect xen_start_info to > > > > > > > > > > > point to something valid, for example xen_initial_domain() is defined as > > > > > > > > > > > follow: > > > > > > > > > > > > > > > > > > > > > > #define xen_initial_domain() (xen_domain() && \ > > > > > > > > > > > xen_start_info->flags & SIF_INITDOMAIN) > > > > > > > > > > > > > > > > > > > > But anyone who calls this before xen_start_info is setup is going to get > > > > > > > > > > a bogus result, specifically in this case they will think they are domU > > > > > > > > > > when in reality they are dom0 -- wouldn't it be better to fix those > > > > > > > > > > callsites? > > > > > > > > > > > > > > > > > > That cannot be the case because setting up xen_start_info is the very > > > > > > > > > first thing that is done, before even calling to C. > > > > > > > > > > > > > > > > On PV, yes, but you are trying to fix PVHVM here, no? > > > > > > > > > > > > > > > > Otherwise if this is always set before calling into C then what is the > > > > > > > > purpose of this patch? > > > > > > > > > > > > > > to fix this - as PVHVM has it set to NULL and we end up de-referencing > > > > > > > the xen_start_info and crashing. As so:: > > > > > > > > > > > > > > > > > > > Right, so returning to my original point: The caller here is calling > > > > > > xen_initial_domain() *before* start info is setup. This is bogus and is > > > > > > your actual bug, all this patch does is hide that real issue. > > > > > > > > > > That is because xen_start_info wasn't setup at all for PV on HVM guests. > > > > > > > > > > The real reason is that PV on HVM guests don't have one, but that is > > > > > another matter. Until we get rid of all the references to xen_start_info > > > > > outside of PV specific code, we should just assume that there is one, > > > > > and that is already setup. > > > > > > > > > > One day not too far from now, we might refactor the code to never > > > > > reference xen_start_info directly, but I don't think that now is the > > > > > time for that. Also consider that this is the same thing we do on ARM. > > > > > > > > We actual fill in the dummy start info with valid information on ARM > > > > though, we don't just leave it full of zeroes. > > > > > > > > If we do start out with start_info pointing to an uninitialised > > > > start_info on ARM too then I would argue that this is also a mistake. > > > > > > Yes, we do point xen_start_info to an uninitialised start_info on ARM > > > too (I don't think is a mistake). Then when and if we have more > > > information we write them to start_info. > > > > So callers of xen_initial_domain in dom0 before xen_guest_init is called > > get the wrong result? > > > > That sounds like a mistake to me. > > How about (modulo my not having looked up the actual names of the > constants etc): > > #define xen_initial_domain() (xen_domain() && arch_is_initial_domain()) > > on x86: > int arch_is_initial_domain(void) > { > /* The initial domain is always PV and > * therefore start_info is always set for it. > */ > return start_info && start_info->flags & SIF_INITDOMAIN; > } > on ARM: > int arch_is_initial_domain(void) > { > static is_initial = -1; > if (is_initial == -1) > is_initial = HVM_param_get(HVMPARAM_DOM0) > return is_initial; > } What about the appended patch as a fix for the moment, then we can do the refactoring that you are suggesting, that is very similar to what I had in mind when I said that we shouldn't access xen_start_info directly. --- xen/xen_initial_domain: check that xen_start_info is initialized Since commit commit 4c071ee5268f7234c3d084b6093bebccc28cdcba ("arm: initial Xen support") PV on HVM guests can be xen_initial_domain. However PV on HVM guests might have an unitialized xen_start_info, so check before accessing its fields. Signed-off-by: Stefano Stabellini Reported-by: Konrad Rzeszutek Wilk diff --git a/include/xen/xen.h b/include/xen/xen.h index 9a39ca5..e7101bb 100644 --- a/include/xen/xen.h +++ b/include/xen/xen.h @@ -28,7 +28,7 @@ extern enum xen_domain_type xen_domain_type; #include #define xen_initial_domain() (xen_domain() && \ - xen_start_info->flags & SIF_INITDOMAIN) + xen_start_info && xen_start_info->flags & SIF_INITDOMAIN) #else /* !CONFIG_XEN_DOM0 */ #define xen_initial_domain() (0) #endif /* CONFIG_XEN_DOM0 */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/