Memory map and processor id updates

[johnny-mnemonic]

No description provided.

[johnny-mnemonic]

Update memory map for Ski

In v5.3 (last mainline version before Ski support was removed from Linux) the memory map (which is part of the ski-bootloader) was still configured as follows:

	/* simulate free memory at physical address zero */
	MAKE_MD(EFI_BOOT_SERVICES_DATA,		EFI_MEMORY_WB,    0*MB,    1*MB);
	MAKE_MD(EFI_PAL_CODE,			EFI_MEMORY_WB,    1*MB,    2*MB);
	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB,    2*MB,  130*MB);
	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB, 4096*MB, 4128*MB);

This is from https://github.com/torvalds/linux/blob/v5.3/arch/ia64/hp/sim/boot/fw-emu.c#L336 and was like that at least since v4.19.y - the last stable kernel which still had Ski support when I started to restore it for later kernels - see https://github.com/torvalds/linux/blob/v4.19/arch/ia64/hp/sim/boot/fw-emu.c#L336 .

That would be:

1. a 128 MiB block starting at 2 MiB

2. a 32 MiB block starting at 4096 MiB

..., making 160 MiB in total, but with a larger than 1 GiB hole between these blocks.

Here an example with v4.19.325 and extended memory map of the stock ski-bootloader of the upstream Ski repo, which has:

	/* simulate free memory at physical address zero */
	MAKE_MD(EFI_BOOT_SERVICES_DATA,		EFI_MEMORY_WB,    0*MB,    1*MB);
	/* bootloader.lds targets this space */
	MAKE_MD(EFI_PAL_CODE,			EFI_MEMORY_WB,    1*MB,    2*MB);
	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB,    2*MB,  130*MB);
	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB, 4096*MB, 6144*MB);

..., see https://github.com/trofi/ski/blob/master/ski-bootloader/fw-emu.c#L315.

Interestingly when running Linux inside Ski with such a memmap it considers this to be one large block:

root@darkstar:/$ uname -a
Linux darkstar 4.19.325-a67e7cdde-ia64-ski #1 SMP PREEMPT Sat Apr 12 18:09:08 CEST 2025 ia64 31 HP Ski Simulator GNU/Linux

root@darkstar:/$ free -m
               total        used        free      shared  buff/cache   available
Mem:            6110          72        6053           0          29        6038
Swap:              0           0           0

The used kernel is configured with:

CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y

...as per the corresponding /proc/config.gz, which is a little strange considering the differences between these (see for example Memory: the flat, the discontiguous, and the sparse).

For later kernels there are changes in regard to flat, discontiguous and sparse mem, e.g. since at least v6.6 we have:

config IA64
[...]
	select NUMA if !FLATMEM

..., from https://github.com/torvalds/linux/blob/v6.6/arch/ia64/Kconfig#L66 and at the same time we have - since at least v4.19.y for kernel sources with Ski support:

config NUMA
	bool "NUMA support"
	depends on !IA64_HP_SIM && !FLATMEM

..., from https://github.com/torvalds/linux/blob/v4.19/arch/ia64/Kconfig#L392C1-L394C37 . Which means we can effectively only use flat mem for a Ski enabled kernel*. But since v5.11-rc1 (specifically since torvalds/linux@ea34f78) the currently used memory map is no longer allowed with flat mem:

static void __init verify_gap_absence(void)
{
	unsigned long max_gap;

	/* Forbid FLATMEM if hole is > than 1G */
	efi_memmap_walk(find_largest_hole, (u64 *)&max_gap);
	if (max_gap >= SZ_1G)
		panic("Cannot use FLATMEM with %ldMB hole\n"
		      "Please switch over to SPARSEMEM\n",
		      (max_gap >> 20));
}

..., see https://github.com/torvalds/linux/blob/v6.6/arch/ia64/mm/contig.c#L177C1-L187C2 . Which is why I deactivated that check in the Ski/HP-Sim restoration patches since v5.15.y.

A solution to this problem w/o touching the Linux kernel code is the first commit in this PR. @mikpe in early 2014 extended the upper end of the first EFI_CONVENTIONAL_MEMORY block of the - back then - memory map to 2048 MiB:

diff -rupN linux-3.13/arch/ia64/hp/sim/boot/fw-emu.c linux-3.13.ia64-hpsim-2GB-RAM/arch/ia64/hp/sim/boot/fw-emu.c
--- linux-3.13/arch/ia64/hp/sim/boot/fw-emu.c	2013-09-03 19:06:28.000000000 +0200
+++ linux-3.13.ia64-hpsim-2GB-RAM/arch/ia64/hp/sim/boot/fw-emu.c	2014-01-25 11:24:01.703718921 +0100
@@ -336,7 +336,7 @@ sys_fw_init (const char *args, int argle
 	/* simulate free memory at physical address zero */
 	MAKE_MD(EFI_BOOT_SERVICES_DATA,		EFI_MEMORY_WB,    0*MB,    1*MB);
 	MAKE_MD(EFI_PAL_CODE,			EFI_MEMORY_WB,    1*MB,    2*MB);
-	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB,    2*MB,  130*MB);
+	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB,    2*MB, 2048*MB);
 	MAKE_MD(EFI_CONVENTIONAL_MEMORY,	EFI_MEMORY_WB, 4096*MB, 4128*MB);
 #else
 	MAKE_MD( 4,		   0x9, 0x0000000000000000, 0x0000000000001000);

..., from https://user.it.uu.se/~mpe22148/linux/patches/ia64/linux-3.13/linux-3.13-ia64-hpsim-2GB-RAM.patch .

I extended that to 3 GiB (actually 3172 MiB, see below) and also dropped the second EFI_CONVENTIONAL_MEMORY block to avoid a gap. Also considering that Linux so far assumed the whole space betwen the start of the first block and the end of the second block was available memory, which can't be right as there was/would be a gap between the two blocks, like if there was no memory installed in this gap.
I didn't go to 4096 MiB as I don't know if there might have been a reason why the second block started at 4096 MiB. E.g. for old PCs the PCI address space is between 3.5 GiB and 4 GiB and as Ski also can emulate and run i386 code and the ski-bootloader has code to handle SAL_PCI_CONFIG_READ and SAL_PCI_CONFIG_WRITE (though only for CONFIG_PCI) I'd rather stay away from that part of memory.
Also 3 GiB ought to be enough for everybody ;-), no, really, during my distcc cluster testing 3 GiB (I accidently tested with 3172 MiB as upper end as I just found out, but a few extra MiBs didn't hurt) for each Ski instance was more than enough for the tested compilations. And the best thing is, I never saw any crashes.

We can change that to something more usual of course, but 2 MiB to 3172 MiB can be considered tested and working.

---

*) Unless we would make Ski "support" NUMA, either for real or just pretend it would support it in the kernel config. I can imagine that both would require a considerable effort. IMHO a better use of our efforts would be to implement the missing syscalls to allow userland emulation to work with modern software, either by doing it ourselves or by trying to utilize an AI for that.

[johnny-mnemonic]

Introduce own processor type for Ski

So far this was configured as McKinley, but the exposed processor features (branchlong and 16-byte atomic ops):

root@darkstar:/$ cat /proc/cpuinfo 
processor  : 0
vendor     : HP Ski Simulator
arch       : IA-64
family     : 31
model      : 0
model name : McKinley
revision   : 0
archrev    : 0
features   : branchlong, 16-byte atomic ops
cpu number : 0
cpu regs   : 4
cpu MHz    : 2.000
itc MHz    : 2.000000
BogoMIPS   : 164.36
siblings   : 1

...are actually on par with a Montecito (see e.g. http://epic-linux.org/#!machines/rx2620/index.md#Hardware_details) and exceed even those of a Madison (see http://epic-linux.org/#!machines/rx4640/index.md#Hardware_details). Montecito is actually a family 32 processor and usually a dual-core with two hardware threads per core, though single-core (most likely with one deactivated core) models w/a single hardware thread per core do exist (Itanium 2 9010). As the processor simulated in Ski is a single-core single-thread one, I configured the processor as a - non-existing in reality - family 31/model 3 processor, e.g. close to Montecito but not the same. Also I didn't find any code in Linux that handles Montecito processor family and model, maybe this is directly read from the processor.

I carry an extra patch for the Ski/HP-Sim patches for Linux to handle this:

processor  : 0
vendor     : HP Ski Simulator
arch       : IA-64
family     : 31
model      : 3
model name : MonteSkito
revision   : 0
archrev    : 0
features   : branchlong, 16-byte atomic ops
cpu number : 0
cpu regs   : 4
cpu MHz    : 2.000
itc MHz    : 2.000000
BogoMIPS   : 172.88
siblings   : 1

As it is not a Montecito - but close - I called it the "MonteSkito".