From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: "M. Vefa Bicakci" <m.v.b@runbox.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
"Charles (Chas) Williams" <ciwillia@brocade.com>,
"x86@kernel.org" <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
David Vrabel <david.vrabel@citrix.com>,
Juergen Gross <jgross@suse.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more
Date: Thu, 10 Nov 2016 13:01:10 -0500 [thread overview]
Message-ID: <3cdcf1fd-4aaf-7ef1-43f6-4454f1251e62@oracle.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1611101810250.3501@nanos>
On 11/10/2016 12:13 PM, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>> On 11/10/2016 10:12 AM, Thomas Gleixner wrote:
>>> On Thu, 10 Nov 2016, Boris Ostrovsky wrote:
>>>> By firmware you mean ACPI? It is most likely not available to PV guests.
>>> You either have to provide ACPI or MP tables. And either of those has to
>>> provide the intial APIC ids for the CPUs. They are supposed to match the
>>> IDs which are in the CPUID leafs.
>>>
>>>> How about returning cpu_data(cpu).initial_apicid?
>>> For a not yet brought up CPU. That's what the initial ACPI/MP table
>>> enumeration is for.
>> Unfortunately PV guests have neither. So we may need to emulate
>> something in xen_cpu_present_to_apicid().
> SFI does the same thing and according to the dmesg which was posted, this
> is using SFI. We also have devicetree based boot concept which provides the
> APICids in the CPU enumeration at boot time in a way which the whole x86
> machinery is expecting.
>
> So what kind of APICid is XEN handing in via SFI? None, or just an invalid
> one?
None, SFI is not used at all. Or device tree for that matter.
The (PV) guest currently assumes APIC ID (i.e. APIC[0x20]) to always be
zero (we just fixed a bug where CPUID may return an
inconsistent/non-zero initial APIC ID value, but that's a different
issue I think). There is no topology, really, everything is flat.
So this obviously is rather, ahem, fragile and we've been fixing bugs
there, especially with introduction of package map (a6a198bc60e6 that I
mentioned in the other message is one such example). There is work
scheduled on the hypervisor side to properly report initial APIC IDs in
CPUID and that may help with correctly dealing with this on Linux side.
(Longer term we would like to move to PVH where we will have "true" APIC
emulation, with ACPI, just like in HVM guests. You can do your part by
helping: http://marc.info/?l=linux-kernel&m=147791731414152&w=3 ;-))
-boris
prev parent reply other threads:[~2016-11-10 18:01 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-02 12:25 [RFC PATCH] perf/x86/intel/rapl: avoid access unallocate memory Sebastian Andrzej Siewior
2016-11-02 22:47 ` Charles (Chas) Williams
2016-11-03 17:47 ` Sebastian Andrzej Siewior
2016-11-04 12:20 ` Charles (Chas) Williams
2016-11-04 18:03 ` Sebastian Andrzej Siewior
2016-11-04 20:42 ` Charles (Chas) Williams
2016-11-04 20:57 ` Sebastian Andrzej Siewior
2016-11-07 16:19 ` Thomas Gleixner
2016-11-07 16:59 ` Charles (Chas) Williams
2016-11-07 20:20 ` Thomas Gleixner
2016-11-08 14:20 ` Charles (Chas) Williams
2016-11-08 14:31 ` Thomas Gleixner
2016-11-08 14:57 ` Charles (Chas) Williams
2016-11-08 16:22 ` Thomas Gleixner
2016-11-09 15:35 ` [PATCH] x86/cpuid: Deal with broken firmware once more Thomas Gleixner
2016-11-09 15:37 ` Thomas Gleixner
2016-11-09 16:03 ` Peter Zijlstra
2016-11-09 16:34 ` Charles (Chas) Williams
2016-11-09 18:37 ` Thomas Gleixner
2016-11-09 18:15 ` Charles (Chas) Williams
2016-11-09 20:27 ` [tip:x86/urgent] x86/cpu: Deal with broken firmware (VMWare/XEN) tip-bot for Thomas Gleixner
2016-11-11 5:49 ` Alok Kataria
2016-11-10 3:57 ` [PATCH] x86/cpuid: Deal with broken firmware once more M. Vefa Bicakci
2016-11-10 10:50 ` Charles (Chas) Williams
2016-11-10 11:14 ` Thomas Gleixner
2016-11-12 22:05 ` M. Vefa Bicakci
2016-11-10 11:13 ` Thomas Gleixner
2016-11-10 11:39 ` Peter Zijlstra
2016-11-10 14:02 ` Boris Ostrovsky
2016-11-10 15:05 ` Charles (Chas) Williams
2016-11-10 15:31 ` Boris Ostrovsky
2016-11-10 15:54 ` Sebastian Andrzej Siewior
2016-11-10 17:15 ` Thomas Gleixner
2016-11-12 22:05 ` M. Vefa Bicakci
2016-11-13 18:04 ` Boris Ostrovsky
2016-11-13 23:42 ` M. Vefa Bicakci
2016-11-15 1:21 ` Boris Ostrovsky
2016-11-18 11:16 ` Thomas Gleixner
2016-11-18 14:22 ` Boris Ostrovsky
2016-11-10 15:12 ` Thomas Gleixner
2016-11-10 15:38 ` Boris Ostrovsky
2016-11-10 17:13 ` Thomas Gleixner
2016-11-10 18:01 ` Boris Ostrovsky [this message]
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=3cdcf1fd-4aaf-7ef1-43f6-4454f1251e62@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=bigeasy@linutronix.de \
--cc=bp@alien8.de \
--cc=ciwillia@brocade.com \
--cc=david.vrabel@citrix.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.v.b@runbox.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xen.org \
/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
all inboxes | Powered by JetHome®