> On Jul 2, 2019, at 4:39 PM, Nadav Amit <nadav.amit@xxxxxxxxx> wrote: > >> On Jul 2, 2019, at 11:28 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >> >> On 02/07/19 19:45, Nadav Amit wrote: >>>>> I know you are not “serious”, but I’ll use this opportunity for a small >>>>> clarification. You do need to provide the real number of CPUs as otherwise >>>>> things will fail. I do not use cpuid, as my machine, for example has two >>>>> sockets. Decoding the ACPI tables is the right way, but I was too lazy to >>>>> implement it. >>>> What about the mptables, too? >>> If you mean to reuse mptable.c from [1] or [2] - I can give it a shot. I am >>> not about to write my own parser. >> >> Sure. > > So mptable logic works on a couple of my machines, but not all. > > For instance, on my Dell R630, running x86info (which uses mptable.c), I > get: > > x86info v1.31pre Dave Jones 2001-2011 > Feedback to <davej@xxxxxxxxxx>. > > Found 48 identical CPUsMP Configuration Table Header MISSING! > > And this message (corrupted, but indicates what the code does), is since > apparently the "MP Floating Pointer Structure” holds a zeroed physical > address pointer. (The number 48 comes from sysconf, and clearly not usable > in kvm-unit-tests.) > > I also enable apic debugging and had a look on Linux's mpparse outputs. It > does not find the MPF either. > > So it seems to me that it is down to either doing a more comprehensive ACPI > table decoding or having a fallback in the form of a kernel parameter. I am > not really excited about implementing the ACPI option, since I am afraid a > basic implementation will encounter some issues on some machines, similarly > to mptable. The other option is having a fallback as a test parameter, but > if there is already a fallback, then using mptable becomes an enhancement, > and can be left out right now. > > What do you say? Never mind (for now). I’ll have a look at libacpi when I have time.
