my123

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)

They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...

Was a research project gone out of hand, arm64 macOS wasn't on the radar and the IoT product it was released for didn't succeed.

I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).

sbtrans (for arm64) was static binary translation only. No JIT fallback whatsoever.

It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack,

The arm64 sbtrans-based version had that gone too, and it didn't have a nice engineering path towards supporting those. It'll come back later though I'm pretty sure, with using a more native arm64 version (or arm64EC which exists nowadays)

AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.

Yes that's used for dynamic query optimisation. It was disabled in Azure SQL Edge for arm64 as that was a JIT-less translated version.

Redacted

XNU has this oddity: https://github.com/apple-oss-distributions/xnu/blob/f6217f89...

Redacted from open source XNU, but exists in the closed source version

After Power9, IBM became uncompetitive multi-core performance against mainstream server CPUs - both x86 and Arm. They didn't keep up with the rise in core counts.

And the single thread side isn't that good either, but SMT8 is a quite nice software licensing trick

Xcode needs an Apple ID for download but the macOS SDK and toolchain does not.

Try to run any developer tool or "xcode-select install" and it'll download the command-line tools independently from Xcode.

(and then bring your own IDE)

There were two entirely separate DOS 4s

The multi-tasking DOS 4 that had its next release be branded as OS/2

and the other one, a conventional DOS stopgap product

Which vendors already support this?

One implementation I've seen in the wild is: https://docs.nvidia.com/jetson/archives/r36.4/DeveloperGuide...

Secure Boot is still supported in that configuration, but with PK/db/dbx being part of the firmware configuration and updating them requiring a UEFI capsule update.

Note that UEFI doesn't mean supporting most of those.

UEFI without runtime UEFI variable writes is a thing, and that configuration is incompatible with mokutil.

U-Boot nowadays speaks UEFI :) (and so does LK)

New Android devices all use a UEFI bootloader: https://source.android.com/docs/core/architecture/bootloader...

Side note: USB 3 Lightning did exist on iPad Pros.

SME2 is restricted in scope to matrix multiply workloads and isn't really designed for anything else.

The point of streaming SVE is to have a way to pre/post process data on the way in or out of a matrix multiply.

A list that I have around of chips which support various levels of SVE:

For SVE(1) deployment, chips that have it: - Fujitsu A64fx - AWS Graviton3

SVE2: - Snapdragon X2, 8/8 Elite Gen 5 and later - MediaTek Dimensity 9000 and later - NVIDIA Tegra Thor and later, NVIDIA "N1" or later (GB10 is an "N1x" SKU) - Samsung Exynos 2200 or later - AWS Graviton4, Microsoft Cobalt 100, Google Axion (and newer chips) - CIX P1

SME(1) instead of SME2:

- Snapdragon X2, 8/8 Elite Gen 5

SME2:

- Apple M4, A18 and later - Samsung Exynos 2600 - MediaTek Dimensity 9500

Note that the Snapdragon 8/8 Elite Gen 5 and X2 support sve2 but not svebitperm.

Qualcomm was odd like that for a long time yeah.

And yes the Gen 5 chips (8, 8 Elite and X2) do implement SVE2 and SME.

AmpereOne M with MTE is out nowadays

LPCAMM2 is more present on business/high end machines unfortunately. It's not an Intel restriction.

Google outright has worst in class SoCs on both CPU and GPU unfortunately.

If you want something more perf competitive, pick Dimensity, Exynos, or Snapdragon.

While the parent article shows AMD Zen 5 having significantly better results in floating-point SPEC CPU2017, these benchmark results are still misleading, because in properly optimized for AVX-512 applications the difference between Zen 5 and Cortex-X925 would be much greater. I have no idea how SPEC has been compiled by the author of the article, but the floating-point results are not consistent with programs optimized for Zen 5.

The arithmetic intensity of most SPECfp subtests is quite low. You see this wall because it ends up reaching bandwidth limitations long before running out of compute on cores with beefy SIMD.

It took until Alder Lake-N for the atom-grade stuff to have AVX2 across the board.

The Oryon 3rd gen in the Snapdragon X2 has SVE2 (as does NVIDIA N1x, currently pre-launched of sorts on the DGX Spark)

Section VII.3 has:

Libraries such as BLIS [19] lack SME support and are therefore excluded from comparison.