Query regarding Windows on ARM64 ignoring TLFS "Relaxed Timing" (Bit 5) recommendation and subsequent Watchdog timeouts

Question

Query regarding Windows on ARM64 ignoring TLFS "Relaxed Timing" (Bit 5) recommendation and subsequent Watchdog timeouts

liye 20

Subject: Issue with Windows on ARM64 failing to honor TLFS "Relaxed Timing" (Bit 5) recommendation

Description:

Hello everyone, I am currently developing a virtualization solution based on the Hyper-V Top-Level Functional Specification (TLFS).

According to the TLFS, Bit 5 in 0x40000004 (Implementation Recommendations) suggests that the partition should use relaxed timing. It specifically states that the VM should disable any watchdog timeouts that rely on the timely delivery of external interrupts.

My Observations:

On x86/x64 platforms, Windows Guest OS correctly interprets this bit and adjusts or disables its internal watchdog mechanisms, preventing spurious crashes during host-side scheduling delays.

However, on ARM64, even when the hypervisor exposes this bit via the appropriate interface (e.g., virtual registers or HVC calls), the Windows Guest seems to ignore the recommendation. This leads to frequent Watchdog-related BSODs when the host experiences high load or scheduling latency.

Questions:

Does Windows on ARM64 fully support the "Relaxed Timing" recommendation defined in the TLFS?

Are there specific Enlightenments or configuration requirements unique to the ARM64 architecture needed to trigger this behavior?

For developers working on ARM64 virtualization, are there alternative mechanisms recommended by Microsoft to prevent watchdog timeouts caused by unavoidable host scheduling jitter?

Thank you for your time and assistance!

0 comments

Answer accepted by question author

2 additional answers

Your answer

Answer 1

Tan Vu 2,175 Independent Advisor

Hi liye,

Windows on ARM64 does support the TLFS "Relaxed Timing" recommendation, but only if it is exposed exactly according to the ARM64 TLFS interface.

A key difference from x86/x64 is that ARM64 does not use CPUID leaf 0x40000004 layout. Instead, the feature is exposed via HvRegisterFeaturesInfo (128-bit), and the "Relaxed Timing" flag is not at bit 5 of EAX like on x86. On ARM64 it is located in a different position (EBX bit 1 of the 128-bit feature register).

In practice, this means:

If you reuse the x86 bit layout, Windows ARM64 will silently ignore it
The value must be returned via the proper hypervisor register interface (e.g., HvCallGetVpRegisters) and available early at boot

So what you’re observing is usually not lack of support, but incorrect bit placement or exposure path.

Regarding alternatives: Microsoft doesn’t define a separate mechanism beyond this flag. The expected approach is still to:

Expose the relaxed timing recommendation correctly
Minimize interrupt latency (such as rely on architectural timers instead of external interrupts where possible)

If the bit is correctly exposed (including correct ARM64 bit position, register, and early boot visibility) and Windows still triggers watchdogs, then the likely causes are either incomplete Hv#1 interface exposure by the hypervisor, or a limitation/bug in the current Windows ARM64 implementation.

If this was helpful, please click "Accept Answer". If you have any further questions, you can leave a comment. I hope this helps and wish you success in resolving your issue. Have a great day!

TV

liye 20 Reputation points

2026-03-17T11:53:31.79+00:00

Thank you! This is a very insightful point. Could you please clarify the specific Register ID for HvRegisterFeaturesInfo on ARM64 and confirming if this bit mapping is documented in a specific version of the TLFS? I want to ensure my hypervisor's HvCallGetVpRegisters handler returns this bit in the exact expected position.

And I found HvRegisterFeaturesInfo on tlfs/feature-discovery, it seems that "Relaxed Timing" flag is on EAX 1 bit.
liye 20 Reputation points

2026-03-18T02:51:02.1666667+00:00

Subject: Windows Guest not sending HVC 0xC600FF01 on ARM64 StratoVirt

Hi,

I’m currently working on implementing Hyper-V Enlightenment (based on the Microsoft TLFS) within StratoVirt (a Rust-based VMM) on ARM64. My primary goal is to get the Windows Guest to recognize the underlying VMM as a Hyper-V-compatible interface so it can leverage optimized virtualization features.

However, I've hit a bit of a snag: during the Windows boot process, I’m unable to capture any Hypercalls with the Function ID 0xC600FF01 (which, from my understanding, is used for Feature and Interface Discovery on ARM64).

I suspect I might be missing some earlier "handshake" steps. What are the absolute minimum requirements—such as specific system registers (ID_AA64...) or mandatory HVC responses—that an ARM64 VMM must satisfy before Windows will even attempt that first TLFS discovery call?

Any pointers would be a huge help. Thanks again!
Tan Vu 2,175 Reputation points Independent Advisor

2026-03-18T05:02:09+00:00

Hi,

I believe the missing piece here is the initial hypervisor discovery step. On ARM64, Windows does not immediately issue TLFS hypercalls like 0xC600FF01.

Instead, it first performs hypervisor detection using the SMCCC interface (HVC/SMC), and only after successfully identifying a compatible Hyper-V interface (Hv#1), it proceeds with feature and register discovery.

You may find this section of the official TLFS documentation helpful, as it describes the ARM64 discovery flow in detail:

https://dotnet.territoriali.olinfo.it/en-us/virtualization/hyper-v-on-windows/tlfs/feature-discovery

So if you’re not seeing 0xC600FF01, it’s very likely that the earlier discovery/handshake step has not completed successfully.

Hope this helps.

Answer 2

Hi liye,

You are correct that in the TLFS documentation, the “Relaxed Timing” flag is defined as EAX bit 1 in HvRegisterFeaturesInfo. On ARM64, however, this register is returned as a 128-bit value via HvCallGetVpRegisters, where EAX/EBX/ECX/EDX are just logical 32-bit partitions of that value.

In practice:

EAX = bits 31:0

EBX = bits 63:32

ECX = bits 95:64

EDX = bits 127:96

So the "Relaxed Timing" flag is: bit 1 of EAX, i.e. bit 1 of the full 128-bit value

If the bit is placed in a different field (for example EBX), Windows will ignore it.

Answer 3

The TLFS defines the “relaxed timing” recommendation bit for both x64 and ARM64, but the provided material does not state any Windows‑on‑ARM64 behavior, requirements, or guarantees tied to that bit.

From the context:

On x64, bit 5 in the Feature and Interface Discovery leaf is defined as:
- “Recommend using relaxed timing for this partition. If used, the VM should disable any watchdog timeouts that rely on the timely delivery of external interrupts.”
On ARM64, the equivalent bit 1 is defined with the same semantics:
- “Recommend using relaxed timing for this partition. If used, the VM should disable any watchdog timeouts that rely on the timely delivery of external interrupts.”

The TLFS text only describes what the hypervisor exposes and what a guest should do for optimal behavior. It does not document:

Whether Windows guests on ARM64 currently implement this recommendation.
Any additional ARM64‑specific enlightenments, registry keys, or configuration needed to make Windows honor relaxed timing.
Any alternative, Microsoft‑recommended mechanism for suppressing watchdogs in Windows on ARM64 when the hypervisor sets this bit.

The other ARM64‑specific fields in the feature discovery and timer sections (e.g., UseHypercallForMmioAccess, UseGpaPinningHypercall, HvRegisterTimeRefCount, HvRegisterReferenceTsc) describe interfaces and capabilities, but do not mention watchdog behavior or relaxed‑timing handling by Windows.

Therefore, based only on the supplied material, the following can be stated:

The TLFS defines a relaxed‑timing recommendation bit for ARM64 with the same intended semantics as on x64.
The TLFS does not document any Windows‑on‑ARM64 implementation details or guarantees regarding that bit.
No ARM64‑specific configuration or alternative mechanism for watchdog suppression in Windows guests is described in the provided context.

For definitive answers about current Windows‑on‑ARM64 behavior and supported mitigations, this falls outside what is covered by the TLFS itself and would require product‑specific documentation or direct support channels, which are not included in the provided material.

References:

Share via

Query regarding Windows on ARM64 ignoring TLFS "Relaxed Timing" (Bit 5) recommendation and subsequent Watchdog timeouts

2 additional answers

Your answer