Windows IA-64 guest support

[binarymaster]

I wonder if this software could support Windows for IA-64 as guest system one day, at least Windows XP 64-Bit Edition that targeted original Itanium / Merced processor.

Recently I also found out that HP-UX could run such guests virtualized: https://virtuallyfun.com/2024/09/23/windows-server-2008-ia64-guest-on-hp-integrity-vm-hp-ux/ - maybe this information could help achieve emulation of Windows for Itanium-based systems.

[trofi]

It's probably not easy to run windows as a guest. Today ski relies on a few things to get something running: modified guest kernel has to to pass data in and out for the console output (for example), to emulate block device (instead of simulating real bus like PCI), there is no real ACPI namespace exported to the guest. No video card support either.

[BHTY]

It could probably be more feasible to use Ski to run Win64/IA-64 applications while not actually booting IA-64 Windows, instead using the CPU emulator while thunking up API calls, in a similar manner to my EmuWOW project.

[sskras]

Some related project (of userland emulation) could be found here: @itanium64 | https://itanium64.github.io/

It lived through two rewrites: Go –> Rust –> C#, only to get abandoned, it seems.

[Vincent392]

It could probably be more feasible to use Ski to run Win64/IA-64 applications while not actually booting IA-64 Windows, instead using the CPU emulator while thunking up API calls, in a similar manner to my EmuWOW project.

By the time you would even be able to GET there, ski would probably be able to load the IA-64 NTOSKRNL anyways and boot the whole OS as making Ski into an app layer would require a whole rewrite.

[BHTY]

It could probably be more feasible to use Ski to run Win64/IA-64 applications while not actually booting IA-64 Windows, instead using the CPU emulator while thunking up API calls, in a similar manner to my EmuWOW project.

By the time you would even be able to GET there, ski would probably be able to load the IA-64 NTOSKRNL anyways and boot the whole OS as making Ski into an app layer would require a whole rewrite.

Making Ski into an app layer would not require a whole rewrite, it would just require only using the CPU emulation portion of Ski, which wouldn't need to be changed at all. Moreover, the level of CPU emulation needed to run some simple Windows apps is a lot simpler than what's needed to execute NTOSKRNL.

[NexusSfan]

You could try Simics if you don't mind Proprietary software

[binarymaster]

@NexusSfan just fyi, quoting Rairii (aka @Wack0) from BetaWiki:

Simics cannot run windows, fwiw
I have a bunch of versions of it
its ia64 emulation is an attempt at emulating Merced
and I really mean attempt here:

[binarymaster]

On that note, Simics uses its own ia64-fakeprom firmware - it's hard to say whether it's capable of booting Windows, given the base software limitations.

As I mentioned in the first post, HP Integrity VM (HP-UX) is a good candidate to look into, as it should have its own firmware implementation too, which boots Windows IA-64 guest.

---

86Box guys have preserved some IA-64 firmwares for Itanium and Itanium 2 based systems:

• Merced SDV firmware (from Tenox, discussion)
  • EFI 0.99 Debug SDV.bin
  • Unknown Ver EFI.bin
• HP i2000 (Merced / Intel 460GX / BIOS ID 63-0000-009999-00101111-071595-CAMINO / ACPI ID W460GXBS)
  • bios130.BIN (discussion 1, discussion 2)
  • HP_i2000_BIOS_Firmware_Update_v.117c.tar / bios117c.BIN (discussion)
• HP rx2600/zx2000/zx6000 (McKinley / HP zx1)
  • HP_ZX2000_IPF_Intel_28F640J3_00-7FFFFF.bin (discussion, mirror 1 / mirror 2)
• Supermicro MBD-i2DML-8G2-O (McKinley / i2DML-8G2 or i2DMR-iG2 / ACPI ID TIGER_2W or TIGER2W)
  • i2drb094.rom (discussion, mirror)

[Vincent392]

Returning to this, I tried for the hell of it to boot IA-64 Windows PE, and this returned

bski -forcesystem -stats -noconsole /media/random/WinGlass/InstallerIA64/WinGlassPE/IA64/setupldr.efi
Halting Simulation
119 insts (1 fault), 0.00 sec, 1166667 i/s, 31 cycles, 3.84 ipc

It DOES start very briefly from the seems of it, however it obviously wont work properly since it's using just the raw setupldr file, not an ISO.

It's not out of the question.

[BHTY]

@Vincent392 I'd be curious why it halts. An unimplemented instruction? It is also worth noting that if I understand the role of setupldr.efi correctly (I think it serves the role of NTLDR/SETUPLDR on x86 AT/BIOS systems of implementing an ARC bootloader layer and loading the COFF osloader.exe, which is the "actual" bootloader that is launched directly from ARC on RISC platforms and loads the kernel and everything) it shouldn't need to talk to the hardware directly and mostly just makes EFI calls, so if those are implemented right, it should be able to get through most of setupldr

[Vincent392]

@BHTY I assume it's because of the fact it's running right from the source folder and NOT the ISO the PE expects itself to be booting from.

That, or it's searching for TXTSETUP.SIF and the drivers and panicking because it can't.

[BHTY]

@BHTY I assume it's because of the fact it's running right from the source folder and NOT the ISO the PE expects itself to be booting from.

That, or it's searching for TXTSETUP.SIF and the drivers and panicking because it can't.

I find it incredibly unlikely that it faulted because of that. Only 119 instructions ran. If you can enable some kind of tracing capability within Ski, maybe you can see how it dies. It's more likely that some kind of processor exception (very likely an unimplemented instruction) executed.

[Vincent392]

There is also ski-efi, so I'll try that instead of bski as I'm booting a .efi file

[Vincent392]

That was a LONG compile process, not fun, trust me, had to go download toolchains from narnia only for them to fail and then realise dnf had what I needed this whole time.

Anyways, got ski-efi to compile and I ran the following:

bski -forcesystem -stats -noconsole ./ski-efi /media/random/WinGlass/InstallerIA64/WinGlassPE/IA64/setupldr.efi

It then returned with loading /media/random/WinGlass/InstallerIA64/WinGlassPE/IA64/setupldr.efi... before seemingly freezing on the frontend.

However, as one can see, it DOES do... something as seen in the screenshot, presumably it panics due to either a lack of instructions or a lack of drivers.

Hell, maybe it's even fully booted into the PE, but we don't know since there's no display for it to output to, so I did the next reasonable thing; I took the copy of Windows XP 64-Bit Edition Version 2003 that I extracted from an ISO I downloaded, only to have the EXACT same thing happen.

So, we need a display driver ASAP, and ideally the full IA-64 instruction set built into ski if we want a 100% chance of booting this, as ski doesn't have it yet.

Also, this glitch happens whenever I close bski while using ski-efi and it's loading an .efi file, :/