[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160209062237.GH25240@wotan.suse.de>
Date: Tue, 9 Feb 2016 07:22:37 +0100
From: "Luis R. Rodriguez" <mcgrof@...e.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: Borislav Petkov <bp@...en8.de>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
X86 ML <x86@...nel.org>, david.e.box@...el.com,
Andrey Ryabinin <ryabinin.a.a@...il.com>,
Lv Zheng <lv.zheng@...el.com>, Jan Beulich <JBeulich@...e.com>,
"H. Peter Anvin" <hpa@...or.com>, qiuxishi@...wei.com,
cocci@...teme.lip6.fr, Xen Devel <xen-devel@...ts.xensource.com>,
Joerg Roedel <joro@...tes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
Robert Moore <robert.moore@...el.com>,
Ingo Molnar <mingo@...hat.com>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Rusty Russell <rusty@...tcorp.com.au>,
Thomas Gleixner <tglx@...utronix.de>, mcb30@...e.org,
Juergen Gross <jgross@...e.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andy Lutomirski <luto@...capital.net>,
"Luis R. Rodriguez" <mcgrof@...nel.org>, long.wanglong@...wei.com,
Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to
paravirt_legacy
On Mon, Feb 08, 2016 at 04:53:00PM +0000, Andrew Cooper wrote:
> On 08/02/16 16:45, Borislav Petkov wrote:
> > On Mon, Feb 08, 2016 at 04:38:40PM +0000, Andrew Cooper wrote:
> >> Does the early loader have extable support? If so, this is fairly easy
> >> to fix. If not, we have a problem.
> > It doesn't and regardless, you want to have this CPUID querying as
> > simple as possible. No special handling, no special prefixes as it
> > should be able to run on other hypervisors too.
> >
> > If one can't execute a simple CPUID(0x4...) on a xen guest and get the
> > results back, then for early, we will have to do what we've done until
> > now and simply emulate the MSR accesses.
> >
> > Later code can use then xen_cpuid() and all is fine. We should still get
> > rid of paravirt_enabled() though.
> >
>
> The force emulation prefix starts with a ud2a instruction, so extable is
> to prevent it breaking on non-Xen systems. However, if extable isn't
> available, this point is moot.
>
> As an alternative check which should be doable this early on, peeking in
> the head of hypercall_page should work. If Linux was booted as a PV
> guest, the hypercall_page will have been constructed by the domain
> builder, and won't have 0x90's in it.
Most of the paravirt_enabled() checks can be replaced with a hardware_subarch
check once we modify the xen_start_kernel() to add that, today XEN is unused
even though it was added eons ago. Part of my work was to remove as many
paravirt_enabled() checks. I'll reply to Andy's original e-mail now indicating
which ones I could address, it sounds like with this nugget and some other
work we might be able to address all.
I should note, in the future the check for subarch would be an explicit part of
the x86 early init init routines to avoid further issues but only in between
x86_64_start_reservations() and setup_arch(). How *early* can such a hypercall
_page check be *safely* be called? I say safely here as if we're not on Xen are
we OK to muck around and check the same address space?
Provided we use the subarch for PV to remove a lot of the paravirt_enabled()
checks, is HVMLite still OK if it ends up using PC subarch and there not being
a paravirt_enabled() anyamore? Boris O's HVMLite series added paravirt_enabled
= 1 for the new HVMLite.
Luis
Powered by blists - more mailing lists