From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
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 <andriy.shevchenko@linux.intel.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch
Date: Wed, 2 Mar 2016 20:40:06 +0100 [thread overview]
Message-ID: <20160302194006.GK25240@wotan.suse.de> (raw)
In-Reply-To: <20160302004342.GI25240@wotan.suse.de>
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
next prev parent reply other threads:[~2016-03-02 19:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 7:24 [PATCH v3 00/11] x86/init: replace paravirt_enabled() were possible Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 01/11] x86/boot: enumerate documentation for the x86 hardware_subarch Luis R. Rodriguez
2016-02-23 8:51 ` Ingo Molnar
2016-02-23 10:34 ` Luis R. Rodriguez
2016-02-23 20:41 ` Luis R. Rodriguez
2016-02-24 8:32 ` Ingo Molnar
2016-02-24 16:40 ` Andy Lutomirski
2016-02-25 1:18 ` Luis R. Rodriguez
2016-02-25 1:29 ` Andy Lutomirski
[not found] ` <CALCETrW=dia7QCDhJVF8rnaKGDx_NNYVZqUNZSs9R87_o=h6NQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-02-25 8:10 ` Ingo Molnar
2016-03-02 0:43 ` Luis R. Rodriguez
2016-03-02 19:40 ` Luis R. Rodriguez [this message]
2016-04-07 20:59 ` Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 02/11] tools/lguest: make lguest launcher use X86_SUBARCH_LGUEST explicitly Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 03/11] x86/xen: use X86_SUBARCH_XEN for PV guest boots Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 04/11] x86/init: make ebda depend on PC subarch Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 05/11] tools/lguest: force disable tboot and apm Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 06/11] apm32: remove paravirt_enabled() use Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 07/11] x86/tboot: remove paravirt_enabled() Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 08/11] x86/cpu/intel: replace paravirt_enabled() for f00f work around Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 09/11] x86/boot: add BIT() to boot/bitops.h Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 10/11] x86/rtc: replace paravirt rtc check with x86 specific solution Luis R. Rodriguez
2016-02-23 11:57 ` [Xen-devel] " David Vrabel
2016-02-23 18:10 ` Luis R. Rodriguez
2016-02-23 7:24 ` [PATCH v3 11/11] pnpbios: replace paravirt_enabled() check with subarch checks Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160302194006.GK25240@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=david.vrabel@citrix.com \
--cc=hpa@zytor.com \
--cc=konrad.wilk@oracle.com \
--cc=lguest@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).