my123

Not an easily feasible option notably because the firmware ACPI tables are in part stubs - but work on hybrid ACPI/DT instead is possible.

One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.

Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.

_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.

It's worth more with business practices that the current owner wouldn't be willing to do.

Monaka-X will include SME2 but it didn't make the cut for first-gen Monaka

A big problem there is ensuring performance portability between different GPUs

> I am pretty sure VkImportSemaphoreFdInfoKHR, mentioned in https://github.com/ggml-org/llama.cpp/issues/22648, works across multiple AMD devices, but somehow doesn't work across multiple nvidia devices.

p2p is disabled on nvidia customer cards, vulkan device groups are shipped for the RTX 6000s

> Added support for creating Vulkan logical devices from multiple physical devices on select cards via VK_KHR_device_group_creation. This feature can be enabled by setting the environment variable __VK_ENABLE_DEVICE_GROUPS=1.

Eight Megabytes And Constantly Swapping

For reference: https://vulkan.org/user/pages/09.events/vulkanised-2025/T47-...

coopmat2 features will eventually be rolled elsewhere. coopmat also started as an NVIDIA extension.

The client use cases that coopmat was intended for are customer machines, not multi-GPU, which is broadly seen as a datacenter feature instead. That said coopmat orthogonal to this.

coopmat2 can be implemented by anybody non-nvidia. It's not EEE when the regular coopmat extension is not good enough to get good performance

Yeah talking about the (vendor-preferred) compute part here

Vulkan's SPIR-V dialect is substantially different from the OpenCL one, notably with the former having structured control flow. They're incompatible between each other.

oneAPI is effectively an Intel-only platform not a standard.

Yes they have implementations on top of CUDA but they're maintained by... Intel. They didn't get buy-in for cross-vendor collaboration

> Intel uses SPIRV iirc

They're migrating away from SPIR-V to their own, Intel PISA: https://discourse.llvm.org/t/rfc-upstreaming-the-pisa-backen...

> TSO

yeah that one is more messy on Windows, with extensive reliance on RCpc...

> and status flags

it's part of FEAT_FlagM(2) - has been there since the Snapdragon 8cx Gen 3 on the Windows side

it's available in retail (the foldable phone variant) in mainland China since today

It's an old comment.

iirc it's a documented feature now - FEAT_E2H0, https://support.arm.com/documentation/109697/2025_12/Feature...

And it was retroactively defined to be allowed starting from Armv8.0.

Apple designs pre-date the ID register bit for it being a thing so it takes a quirk there however.

Windows has a stable syscall ABI today officially, for supporting down-level containers:

> https://learn.microsoft.com/en-us/virtualization/windowscont...

> Decoupling the User/Kernel boundary in Windows is a monumental task and highly non-trivial, however, we have been working hard to stabilize this boundary across all of Windows to provide our customers the flexibility to run down-level containers. Starting with Windows 11 and Windows Server 2022 we are enabling the ability to run process-isolated WS2022 containers on Windows 11 hosts.

One thing in the story is that the SPU - the secure enclave on Qualcomm chips that is separate from just running on TrustZone on the main processor - is only available on Snapdragon 8 and X tier products. It's market segmented away from 7 series and below.

> Finally, we will continue to progressively open-source more of the Mojo language, as well as components in MAX that we have built with it. Our commitment remains unchanged – we will open source the Mojo compiler and toolchain in 2026.

Windows NT on PowerPC was an actual product, although running in 32-bit mode.

A big chunk of the problem is planning/political:

https://en.wikipedia.org/wiki/Purple_Line_(Maryland)

> A March 2025 report by the Maryland comptroller's office found that permitting and legal fees for the project, originally budgeted at $6 million, had actually consumed roughly $800 million, thanks to two lawsuits and the contract renegotiations

Better tech cannot solve that on its own, the problem is not even there.

And for the Jetsons btw still uses device tree with custom kernels but at least it's UEFI from Orin onwards.

For Jetson Orin and later:

You can download an ISO from https://developer.nvidia.com/embedded/jetpack/downloads and that'll work. Other distributions are still a bit of a mess though but Yocto is supported now.

No the Spark uses UEFI + ACPI

Regular Ubuntu or Fedora ISOs do work out of the box

Just needs the Nvidia GPU driver install afterwards

(And the realtek 10gbe module oot, or blocklist if not used)

It was true a long time ago for some particular cases, but is not true since quite some years now.

> but the only build targets are i386 and amd64

arm64 ReactOS boots all the way to desktop with it being on the way to upstream too.

NVIDIA's recent Nemotrons tend to be open training data and code.

Probably as a base to use by people buying NVIDIA hardware to train their own.

For the DGX Spark and OEM variants a big issue is that the ConnectX-7 is just not designed to have low power idle but instead to be efficient when loaded.

NVIDIA already lowered power draw at idle by 18W with a currently out of tree driver leveraging PCIe hotplug for the NIC earlier this year.

I think that quite a bit more people bought those to use them without the ConnectX than what NVIDIA expected.

Windows CE late in its lifetime (CE 6.0) had that go away with per-process address spaces.

Not much public yet about VRE virtualisation (which includes SEP) at this point.

> whose only purpose would be to capture those HVCs

quite expensive because you get to trap ~ all EL0 -> EL1 priv transitions through the virtualisation infrastructure as the sync handler has a lot going through it

> HCR_EL2.HCD

That's not ideal because of:

> Any resulting exception is taken to the Exception level at which the HVC instruction is executed.

instead of trapping to the hypervisor

> I've looked at how different hypervisors/VMMs handle this and, if this makes that patch set any less hacky, Virtualization.framework, QNX Hypervisor, and (I think) VMware all decode and emulate those instructions in software. Virtualization.framework is a remarkable spaghetti in this regard :)

And so does Hyper-V.

> It's not macOS triggering this in isolation either

There are some nightmare cases that SEPOS specifically triggers, such as doing isv=0 accesses to GICR... when using the Apple vGIC handling _that_ becomes truly bizarre.

> Simply ignoring the instruction, though, is not enough

Yeah that's not a great idea

It was a kernel panic for Tahoe. Anything between macOS 12 and 26 wasn't tested so releases in-between might have more issues.

The userspace reboot after FileVault password entry acts a bit oddly with QEMU input devices so you might need to attach a new USB tablet or kbd from the monitor.

> looks like there's a separate patch set for this

Yup and it's a bit of a problem to figure out the right thing to do for it on the upstreaming side as normal guests aren't supposed to do that.

> It's possible to patch out this functionality without special privileges or talk to the in-kernel hypervisor directly

Or pre-patch them all to HVC #1 works too. Patching the host Hypervisor.framework sounds quite brittle especially after they moved to a pile of C++

FYI: https://patchew.org/QEMU/20260324204855.29759-1-mohamed@unpr...

There's some randomness around Tahoe for FileVault and it crashing because Data is detected as not encrypted (and that's not OK on bare metal). If hitting that case you might need to enable FileVault inside the VM (and remember to sync aux storage afterwards if not done)