Repository navigation
Arm64 minimum hardware requirements excludes some Windows 10 IoT supported CPUs #132340
Description
In the minimum hardware requirements documentation, it states:
For Windows, the baseline is updated to require the LSE instruction set. This is required by Windows 11 and by all Arm64 CPUs officially supported by Windows 10.
Windows 10 IoT 21H2 and 22H2 both support CPU's on Arm64 that don't have LSE extensions. The following CPUs do not support LSE extensions but are supported processors for Windows 10 IoT:
- NXP i.MX 8M Nano
- NXP i.MX 8M Mini
- NXP i.MX 8M Quad
- NXP i.MX 8M Plus
- NXP i.MX 8X QXP (looks to be a typo on the supported hardware page as it's listed as 8M)
Activity
tannergooding commentedon Aug 14, 2026
CC. @jkotas
We should still have all the support here, in part because Linux still target
armv8.0-aso flipping the JIT/AOT minimum for Windows back isn't difficult and I can get that up.We basically have the option to take this pre-emptively since Win10 IOT does have official A53 CPU support (contrary to our last discussion with the Windows team) -or- to wait for customer reports to come in and indicate its actually required. -- This support notably looks to extend until at least 2029, if not later.
I'm working on the fix locally anyways, but can stop that if we think this is unnecessary to handle pre-emptively.
mconnew commentedon Aug 14, 2026
If you wait for customer reports to come in, wouldn't you then have to ship a perf regression which could be significant for some applications?
tannergooding commentedon Aug 14, 2026
It likely depends, there are options available but I'm doubtful we'd want to exercise any of those "live" for .NET 11 (which is why I'm prepping the fix under the assumption we want to take it prior to GA).
Theoretically we could have the NAOT default be armv8.0-a+LSE and require no LSE to be opt-in, for example. In which case AOT apps don't work on those downlevel IOT devices without explicit opt-in, which may be acceptable given they are small form-factor IOT devices likely running AOT apps anyways.
Theoretically we could have two builds, one for Win10 one for Win11, and so on
-- Not saying any of these are "good" ideas, the best option (at least for .NET 11) is likely the simplest which is just all of Windows, except R2R, pessimizes to armv8.0-a again and it persists that way until said support is dropped.
EgorBo commentedon Aug 14, 2026
I would revert back to arm8.0 everywhere since there are still targets where we have to assume LSE might not present. What exactly bumping the baseline to 8.1 gives us?
The atomic are expected to be outlined for LSE in native code, JIT will re-jit to LSE anyway. We only need outlining in managed code - and we need to do it anyway, because otherwise NAOT on Linux-arm64 with the default CPU would be (currently is) terribly slow under high-load scenarios.
tannergooding commentedon Aug 14, 2026
We didn't bump to 8.1, we had bumped to
8.0 + lseas the minimum and it ensured that we got atomic support by default, the only ISA that had measured benefit from the investigations. -- The benefits it provides is notably also why it iss required on Win11 by the OS itself and the GC has explicit runtime checks to light it up. It makes a significant different to almost anything using locks and so is impactful to NAOT and other scenarios.Yes, that's what I'm working on doing, but wanted Jan's input on if the Win 10 IOT support is worth pessimizing everything else against.
EgorBo commentedon Aug 14, 2026
which wasn't enabled for native code anyway. My experience so far that outlined atomics are as fast as just LSE generally (and when there is a contention, the overhead from quick ISA check is around noise). We actually tested perf on various benchmarks like OrchardCMS for runtime compiled with mcpu=native vs default and were never able to detect any differences on arm64.
tannergooding commentedon Aug 14, 2026
Yes, but the point is that we don't have the NAOT (or even JIT/R2R for that matter) support for
if (Lse.IsSupported) { lse_ins } else { non_inlined_fallback(...); }. So this makes a significant different for that scenario and is a place where Windows and Linux are behind compared to OSX.EgorBo commentedon Aug 14, 2026
#129951 I think it's not too difficult to implement, too late for .NET 11 I presume.
jkotas commentedon Aug 15, 2026
Sounds good to me. It is a lot easier than trying to find out whether there are actually any Win10 IoT customers that run on Arm 8.0 w/o lse (and use .NET). The performance impact of flipping this back is not that significant.
Restore Windows Arm64 support for CPUs without LSE (#132345)