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

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.

> 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

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

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++

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)

Comments URL: https://news.ycombinator.com/item?id=48055273

Points: 2

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=47828536

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47756116

Points: 2

# Comments: 0

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

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

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)

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

and the other one, a conventional DOS stopgap product

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.

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

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