> 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?
