CC @dotnet/jit-contrib

Doesn't look like the bot notified anyone on this one. I couldn't get a clean CI run, but none of the failures are related.

We may assume that the presence of any Armv8.2 optional feature means we have at least Armv8.1. And because IsProcessorFeaturePresent does have a flag for the Armv8.2 DP optional extension, we may safely assume that its presence also implies RDM.

This is a reasonable assumption to make. However, I think you can go a bit further. This change will miss some cases - you'll disable RDM for any 8.2 or 8.3 without DP and all 8.1.

For that reason, I'd recommend you also enable RDM for PF_ARM_V81_ATOMIC_INSTRUCTIONS_AVAILABLE, PF_ARM_V83_JSCVT_INSTRUCTIONS_AVAILABLE, PF_ARM_V83_LRCPC_INSTRUCTIONS_AVAILABLE and PF_ARM_SVE_INSTRUCTIONS_AVAILABLE. All of these are post 8.1 features, and if available must mean that RDM is present.

You'll still miss some cases, but I think that's the best you can do given the available outputs in windows.

Actually, scratch that. For any given feature, it's possible that either now or in the future it is backported to an earlier architecture revision due to a particular customer requirement.

DP (or DotProd) is currently earliest in 8.2. However, it's possible this this could be backported to 8.1 or 8.0 in the future. This feels very unlikely, but it's possible. If that happened, then that's going to create all sorts of issues here.

For that reason, I'd recommend you also enable RDM for PF_ARM_V81_ATOMIC_INSTRUCTIONS_AVAILABLE, PF_ARM_V83_JSCVT_INSTRUCTIONS_AVAILABLE, PF_ARM_V83_LRCPC_INSTRUCTIONS_AVAILABLE and PF_ARM_SVE_INSTRUCTIONS_AVAILABLE. All of these are post 8.1 features, and if available must mean that RDM is present.

Definitely do not this this!

The correct and safe solution here is that the windows API needs expanding to include more features. The full list is much bigger and this issue is only going to occur again for other features.

DP (or DotProd) is currently earliest in 8.2. However, it's possible this this could be backported to 8.1 or 8.0 in the future. This feels very unlikely, but it's possible. If that happened, then that's going to create all sorts of issues here.

In the unlikely event this actually happened and such a device happened to run Windows and someone tried to run a .NET app using RDM on that device, we do still have the DOTNET_EnableArm64Rdm config knob as an escape hatch.

The correct and safe solution here is that the windows API needs expanding to include more features.

That would be ideal, but with no movement from the Windows side in over 4 years, I don't know what else we can do. This is broken on hardware (including Microsoft-branded) that exists and runs Windows today, so a workaround seems reasonable.

The main issue here is that the config knobs can disable an ISA but can't forcibly enable it, meaning there's no way to use the hardware we know is present.

That would be ideal, but with no movement from the Windows side in over 4 years, I don't know what else we can do

@jkotas, @kunalspathak. Anyone we can reach out to and ensure such config knobs are exposed? Unlike x64, there is no user-mode instruction (like CPUID) which allows querying of said support so we're reliant on the OS exposing the relevant queries.

we do still have the DOTNET_EnableArm64Rdm config knob as an escape hatch.

This isn't a knob that's really meant for use in production scenarios and certainly not by typical end users of applications. Rather its something that is primarily meant for testing scenarios, so that developers can validate their fallback paths instead.

I don't think any scenario where we emit invalid instructions by default for regular code is going to be viable for the shipping product.

@jkotas, @kunalspathak. Anyone we can reach out to and ensure such config knobs are exposed?

Done (both of you are on cc line)

but with no movement from the Windows side in over 4 years

If it helps, we might be able to provide some code could be used by the kernel to do the detection of all the features.

Had an internal conversation that basically boils down to Windows doesn't have any plans to expose a FEAT_RDM flag at this point in time.

Rather instead we can encode this essentially as if (OperatingSystem.IsWindowsVersionAtLeast(10, 0, 22000, 0)) { RdmSupported = true; }, effectively encoding that Windows 11 requires Armv8.1 or later (where AdvSimd support implies that RDM is provided)

This will exclude Windows 10, but that is going out of support next year in October 2025; prior to when .NET 10 will ship.

CC. @jkotas

More context: Rdm is supported on all Arm hardware supported by Windows 11 today and it is not expected to change in future.