When I set the C-state control to Disabled and the CFG Lock to Enabled in the UEFI Setup (so the Windows CPU-idle driver should not be able to re-enable any C-states) the CPU still seems to use C1 (basically clock gated HALT state) besides C0 (full clock operation). The same goes for Enabling C-state control (in the UEFI Setup) and setting everything to Disabled or the lowest state on the list (in practice that's a lot of "Disabled" and a single "C0/C1" for package C-states).
Before everybody starts picking on me with sane criticism, I am well aware that C1<->C0 is very fast and should never cause any significant/observable latency increase or performance decrease (and yes, I know, I should always be running with max power savings to save the holy humanity from extinction, blah, blah...). I am mostly just curious why it's not allowed and wish to play with it for testing (just because: why not...?).
I guess this might has something to do with HyperThreading and Turbo Boost compatibility because both take C-states (at least C1 but possibly deeper C-states as well) into account (at least on certain CPUs in certain situations). However, I don't have HT on the 8600K and Turbo is "unlocked" (the max turbo multiplier is not limited based on the number of active/inactive cores), so it should be fine to disable C1 (I think).
I couldn't find any Windows utilities for this. ThrottleStop can control C1E but that's not the same (C1 is not C1E, these are different). On Linux, the intel_idle driver allows me to force a POLL state (sometimes called MWAIT) which is basically C0 (if I am correct) by setting /dev/cpu_dma_latency to 0 (and keeping it open with a small program).
Would it be possible to include a switch in the UEFI Setup for C1 control? If not, is there any equivalent on Windows to Linux's intel_idle? Or does Windows still use ACPI for CPU-idle control on modern Intel CPUs (and is it missing the C1 control override)? (I think the Linux driver works starting from SandyBrige and up to CoffeeLake.)