| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 31 Jul 2023 16:10:11 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>
CC: LKML <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
Tom Lendacky <thomas.lendacky@....com>,
Andrew Cooper <andrew.cooper3@...rix.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
"James E.J. Bottomley" <jejb@...ux.ibm.com>,
Dick Kennedy <dick.kennedy@...adcom.com>,
James Smart <james.smart@...adcom.com>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
Guenter Roeck <linux@...ck-us.net>,
"linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
Jean Delvare <jdelvare@...e.com>,
Huang Rui <ray.huang@....com>, Juergen Gross <jgross@...e.com>,
Steve Wahl <steve.wahl@....com>,
Mike Travis <mike.travis@....com>,
Dimitri Sivanich <dimitri.sivanich@....com>,
Russ Anderson <russ.anderson@....com>
Subject: RE: [patch v2 21/38] x86/cpu: Provide cpu_init/parse_topology()
From: Thomas Gleixner <tglx@...utronix.de> Sent: Monday, July 31, 2023 8:38 AM
>
> On Mon, Jul 31 2023 at 15:27, Peter Zijlstra wrote:
> > On Mon, Jul 31, 2023 at 02:34:39PM +0200, Thomas Gleixner wrote:
> >> This collides massively with the other work I'm doing, which uses the
> >> MADT provided information to actually evaluate various topology related
> >> things upfront and later during bringup. Thats badly needed because lots
> >> of todays infrastructure is based on heuristics and guesswork.
> >>
> >> But it seems I wasted a month on reworking all of this just to be
> >> stopped cold in the tracks by completely undocumented and unnecessary
> >> hyper-v abuse.
> >>
> >> So if Hyper-V insists on abusing the initial APIC ID as read from CPUID
> >> for topology information related to L3, then hyper-v should override the
> >> cache topology mechanism and not impose this insanity on the basic
> >> topology evaluation infrastructure.
> >
> > So I'm very tempted to suggest you continue with the topology rewrite
> > and let Hyper-V keep the pieces. They're very clearly violating the SDM.
> >
> > Thing as they stand are untenable, the whole topology thing as it exists
> > today is an untenable shitshow.
> >
> > Michael, is there anything you can do early (as in MADT parse early) to
> > fix up the APIC-IDs?
>
> I don't think so.
>
> Michael, can you please provide me a table of:
>
> APICID (real/MADT) APICID (CPUID)
>
> from one of the tinker VMs please?
>
The VM is an F72s_v2 in Azure running your patch set. The VM has
72 vCPUs in two NUMA nodes across two physical Intel processors, with
36 vCPUs in each NUMA node.
The output is from /sys/kernel/debug/x86/topo/cpus, so the initial_apicid
is from CPUID, while the apicid is from read_apic_id() and matches the
MADT. As expected, the two values match for the first 36 vCPUs, but differ
by 28 (decimal) for the remaining 36.
initial_apicid: 0 apicid: 0
initial_apicid: 1 apicid: 1
initial_apicid: 2 apicid: 2
initial_apicid: 3 apicid: 3
initial_apicid: 4 apicid: 4
initial_apicid: 5 apicid: 5
initial_apicid: 6 apicid: 6
initial_apicid: 7 apicid: 7
initial_apicid: 8 apicid: 8
initial_apicid: 9 apicid: 9
initial_apicid: a apicid: a
initial_apicid: b apicid: b
initial_apicid: c apicid: c
initial_apicid: d apicid: d
initial_apicid: e apicid: e
initial_apicid: f apicid: f
initial_apicid: 10 apicid: 10
initial_apicid: 11 apicid: 11
initial_apicid: 12 apicid: 12
initial_apicid: 13 apicid: 13
initial_apicid: 14 apicid: 14
initial_apicid: 15 apicid: 15
initial_apicid: 16 apicid: 16
initial_apicid: 17 apicid: 17
initial_apicid: 18 apicid: 18
initial_apicid: 19 apicid: 19
initial_apicid: 1a apicid: 1a
initial_apicid: 1b apicid: 1b
initial_apicid: 1c apicid: 1c
initial_apicid: 1d apicid: 1d
initial_apicid: 1e apicid: 1e
initial_apicid: 1f apicid: 1f
initial_apicid: 20 apicid: 20
initial_apicid: 21 apicid: 21
initial_apicid: 22 apicid: 22
initial_apicid: 23 apicid: 23
initial_apicid: 40 apicid: 24
initial_apicid: 41 apicid: 25
initial_apicid: 42 apicid: 26
initial_apicid: 43 apicid: 27
initial_apicid: 44 apicid: 28
initial_apicid: 45 apicid: 29
initial_apicid: 46 apicid: 2a
initial_apicid: 47 apicid: 2b
initial_apicid: 48 apicid: 2c
initial_apicid: 49 apicid: 2d
initial_apicid: 4a apicid: 2e
initial_apicid: 4b apicid: 2f
initial_apicid: 4c apicid: 30
initial_apicid: 4d apicid: 31
initial_apicid: 4e apicid: 32
initial_apicid: 4f apicid: 33
initial_apicid: 50 apicid: 34
initial_apicid: 51 apicid: 35
initial_apicid: 52 apicid: 36
initial_apicid: 53 apicid: 37
initial_apicid: 54 apicid: 38
initial_apicid: 55 apicid: 39
initial_apicid: 56 apicid: 3a
initial_apicid: 57 apicid: 3b
initial_apicid: 58 apicid: 3c
initial_apicid: 59 apicid: 3d
initial_apicid: 5a apicid: 3e
initial_apicid: 5b apicid: 3f
initial_apicid: 5c apicid: 40
initial_apicid: 5d apicid: 41
initial_apicid: 5e apicid: 42
initial_apicid: 5f apicid: 43
initial_apicid: 60 apicid: 44
initial_apicid: 61 apicid: 45
initial_apicid: 62 apicid: 46
initial_apicid: 63 apicid: 47
Michael
Powered by blists - more mailing lists