From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Borislav Petkov <bp@alien8.de>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
X86 ML <x86@kernel.org>,
david.e.box@intel.com, Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Lv Zheng <lv.zheng@intel.com>, Jan Beulich <JBeulich@suse.com>,
"H. Peter Anvin" <hpa@zytor.com>,
qiuxishi@huawei.com, cocci@systeme.lip6.fr,
Xen Devel <xen-devel@lists.xensource.com>,
Joerg Roedel <joro@8bytes.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Robert Moore <robert.moore@intel.com>,
Ingo Molnar <mingo@redhat.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Thomas Gleixner <tglx@linutronix.de>,
mcb30@ipxe.org, Juergen Gross <jgross@suse.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
"Luis R. Rodriguez" <mcgrof@kernel.org>,
long.wanglo
Subject: Re: [Xen-devel] [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy
Date: Tue, 9 Feb 2016 07:22:37 +0100 [thread overview]
Message-ID: <20160209062237.GH25240@wotan.suse.de> (raw)
In-Reply-To: <56B8C7EC.3090403@citrix.com>
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
next prev parent reply other threads:[~2016-02-09 6:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-06 4:30 [PATCH v2 0/3] paravirt: rebrand paravirt_enabled as paravirt_legacy Luis R. Rodriguez
2016-02-06 4:30 ` [PATCH v2 1/3] paravirt: use bool for paravirt_enabled() and paravirt_has_feature() Luis R. Rodriguez
2016-02-06 4:30 ` [PATCH v2 2/3] paravirt: replace direct access to pv_info.paravirt_enabled Luis R. Rodriguez
2016-02-06 4:30 ` [PATCH v2 3/3] paravirt: rename paravirt_enabled to paravirt_legacy Luis R. Rodriguez
2016-02-06 7:11 ` Andy Lutomirski
2016-02-06 8:59 ` Luis R. Rodriguez
2016-02-06 20:05 ` Andy Lutomirski
2016-02-06 22:04 ` Borislav Petkov
2016-02-08 15:39 ` Boris Ostrovsky
2016-02-08 15:55 ` Borislav Petkov
2016-02-08 16:05 ` [Xen-devel] " Andrew Cooper
2016-02-08 16:12 ` Boris Ostrovsky
2016-02-08 16:26 ` Andrew Cooper
2016-02-08 16:31 ` Boris Ostrovsky
2016-02-08 16:32 ` Andrew Cooper
2016-02-08 16:35 ` Borislav Petkov
2016-02-08 16:38 ` Andrew Cooper
2016-02-08 16:45 ` Borislav Petkov
2016-02-08 16:52 ` Boris Ostrovsky
2016-02-08 20:45 ` Boris Ostrovsky
2016-02-08 21:06 ` Borislav Petkov
2016-02-08 16:53 ` Andrew Cooper
2016-02-08 17:13 ` Borislav Petkov
2016-02-09 6:22 ` Luis R. Rodriguez [this message]
2016-02-08 16:41 ` Boris Ostrovsky
2016-02-08 16:52 ` Borislav Petkov
2016-02-08 15:31 ` Boris Ostrovsky
2016-02-08 15:46 ` Borislav Petkov
2016-02-09 6:59 ` Luis R. Rodriguez
2016-02-08 21:04 ` Andy Lutomirski
2016-02-09 7:06 ` Luis R. Rodriguez
2016-02-17 20:07 ` Luis R. Rodriguez
2016-02-17 20:49 ` Borislav Petkov
2016-02-17 21:12 ` Luis R. Rodriguez
2016-02-17 21:21 ` Boris Ostrovsky
2016-02-17 22:03 ` Borislav Petkov
2016-02-17 22:18 ` Andy Lutomirski
2016-02-17 22:39 ` Boris Ostrovsky
2016-02-17 23:39 ` Borislav Petkov
2016-02-17 22:19 ` Boris Ostrovsky
2016-02-17 22:35 ` Luis R. Rodriguez
2016-02-09 6:41 ` Luis R. Rodriguez
2016-02-08 21:49 ` Boris Ostrovsky
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=20160209062237.GH25240@wotan.suse.de \
--to=mcgrof@suse.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=aryabinin@virtuozzo.com \
--cc=boris.ostrovsky@oracle.com \
--cc=bp@alien8.de \
--cc=cocci@systeme.lip6.fr \
--cc=david.e.box@intel.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=lv.zheng@intel.com \
--cc=mcb30@ipxe.org \
--cc=mcgrof@kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=mingo@redhat.com \
--cc=qiuxishi@huawei.com \
--cc=rafael.j.wysocki@intel.com \
--cc=robert.moore@intel.com \
--cc=rusty@rustcorp.com.au \
--cc=ryabinin.a.a@gmail.com \
--cc=tglx@linutronix.de \
--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).