v2: add info numa monitor command

Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

# HG changeset patch
# User Andre Przywara <[email protected]> # Date 1229430525 -3600
# Node ID 0f3054b66373c2a8b65a5be6d83af63f807dd88f # Parent a0a2e3026d4acffdce91b776d8c2d733767693c5 add info numa command to the monitor

diff -r a0a2e3026d4a -r 0f3054b66373 monitor.c
@@ -1281,6 +1281,20 @@ static void do_info_kvm(void)
 #endif
 }
 
+static void do_info_numa(void)
+{
+    int i, j;
+
+    term_printf("%d nodes\n", numnumanodes);
+    for (i = 0; i < numnumanodes; i++) {
+        term_printf("node %d cpus:", i);
+        for (j = 0; j < 64; j++)
+            if (node_to_cpus[i] & (1ULL << j)) term_printf(" %d", j);
+        term_printf("\n");
+        term_printf("node %d size: %" PRId64 " MB\n", i, node_mem[i] >> 20);
+    }
+}
+
 #ifdef CONFIG_PROFILER
 
 int64_t kqemu_time;

@@ -1538,6 +1552,8 @@ static const term_cmd_t info_cmds[] = {
       "", "show kqemu information", },
     { "kvm", "", do_info_kvm,
       "", "show kvm information", },
+    { "numa", "", do_info_numa,
+      "", "show NUMA information", },
     { "usb", "", usb_info,
       "", "show guest USB devices", },
     { "usbhost", "", usb_host_info,

I know, but I was hoping that a simpler patch would be easier to merge. So I am happy to fix it later and lift this restriction.
I searched for some kind of variable length bitmap type (like Linux' cpu_set_t) already being used in QEMU, but couldn't find anything appropriate. Do you know something? If you look at the glibc cpu_set_t implementation (in bits/sched.h), you surely want to make this a separate patch.

Ok, this could be a point, but is this BIOS FW interface really a stable interface we cannot change later easily? IMHO this is QEMU (and derived projects) only, which always provide a matching BIOS anyway.

What about if I prepare the BIOS FW interface for future expansion and stick to the current uint64_t type for now?

Regards,
Andre.

And by the way: 64 core machines are _not_ common today, especially not when hosting pure QEMU :-)

Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

I don't know that there's anything immediately obvious to use.

Please make the BIOS FW interface and the BIOS patch able to handle > 64 cpus. It's relatively painful to get stuff merged into Bochs and sync the BIOS. I don't want to have to go through that again in the near future once Jes gets wind of the fact that you're limiting us to 64 cpus ;-)

I can live with QEMU being limited to 64 cpus for now.

It all depends on your perspective. At any rate, the Core i7's reintroduce hyperthreading so you're looking at 16-way CPUs once the octal cores are released. I'm not sure the time frame, but I think 12-core CPUs are in the near future two from both Intel and AMD. A single 4-socket board will be 64-way. A multi-node system will easily be > 64-way. This isn't long term future things, this is stuff that'll be relatively common next year.

Regards,

Anthony Liguori