From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755249AbcCBTkN (ORCPT ); Wed, 2 Mar 2016 14:40:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:58502 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755125AbcCBTkL (ORCPT ); Wed, 2 Mar 2016 14:40:11 -0500 Date: Wed, 2 Mar 2016 20:40:06 +0100 From: "Luis R. Rodriguez" To: "Luis R. Rodriguez" Cc: Ingo Molnar , bp@alien8.de, hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, rusty@rustcorp.com.au, x86@kernel.org, linux-kernel@vger.kernel.org, luto@amacapital.net, boris.ostrovsky@oracle.com, david.vrabel@citrix.com, konrad.wilk@oracle.com, xen-devel@lists.xensource.com, lguest@lists.ozlabs.org, Andy Shevchenko , Andrew Cooper , Linus Torvalds , Andrew Morton Subject: Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch Message-ID: <20160302194006.GK25240@wotan.suse.de> References: <1456212255-23959-1-git-send-email-mcgrof@kernel.org> <1456212255-23959-2-git-send-email-mcgrof@kernel.org> <20160223085119.GA10182@gmail.com> <20160223103409.GF25240@wotan.suse.de> <20160223204135.GH25240@wotan.suse.de> <20160224083259.GA20579@gmail.com> <20160302004342.GI25240@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160302004342.GI25240@wotan.suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 02, 2016 at 01:43:42AM +0100, Luis R. Rodriguez wrote: > On Wed, Feb 24, 2016 at 09:32:59AM +0100, Ingo Molnar wrote: > There's only one problem with this strategy I can think so far which differs > from my original approach, which is partly why I actually started looking at > this stuff: > > it doesn't help us pro-actively vet each early boot sequence > thrown at the x86 path well work on all required subarchs > > The quirks stuff / proactive solution should perhaps be considered orthogonal. > It just so happened that I was able to address some quirks with what I was Since it is orthogonal I'll simply work off on the paravirt_enabled() removal separately as its possible. Since the clarity on semantics will be needed for other work I'm doing (proactive solution to avoid issues on early boot) and since the proposed alternative still uses subarch for the quirks as you recommended I'll at least still push for documentation update on subarch use as well for now. After this, and then after sort a simple link table upstream I can then start focusing more on the proactive solution once again. That should help keep things separate and make it clearer what I'm trying to achieve later. Luis