> On Jul 2, 2019, at 10:24 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > On 02/07/19 18:43, Nadav Amit wrote: >>>> Remember that the output goes to the serial port. >>> >>> RAM size can use the multiboot info (see lib/x86/setup.c). >> >> The multiboot info, as provided by the boot-loader is not good enough as far >> as I remember. The info just defines where to kernel can be loaded, but does >> not say how big the memory is. For that, e820 decoding is needed, which I >> was too lazy to do. > > The multiboot info has both e801 memory size and e820 memory map info. > e801 is basically the first contiguous chunk of memory below 4GB, it > should be enough for kvm-unit-tests. It is not enough for some of the access/ept_access tests, and 1GB page allocation can fail on certain configurations. But anyhow I didn’t solve this problem (IIRC the allocator only allocates from addresses that are below 4GB). So, I can do that (using e801). >>> For the # of CPUs I'm not sure what you're supposed to do on bare metal >>> though. :) >> >> 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. [1] https://github.com/kernelslacker/x86info/blob/master/mptable.c [2] https://people.freebsd.org/~fsmp/SMP/mptable/mptable.c
