On 07.04.2022 03:01, Andrew Cooper wrote: > c/s 1a914256dca5 increased the AMD max leaf from 0x8000001c to 0x80000021, but > did not adjust anything in the calculate_*_policy() chain. As a result, on > hardware supporting these leaves, we read the real hardware values into the > raw policy, then copy into host, and all the way into the PV/HVM default > policies. > > All 4 of these leaves have enable bits (first two by TopoExt, next by SEV, > next by PQOS), so any software following the rules is fine and will leave them > alone. However, leaf 0x8000001d takes a subleaf input and at least two > userspace utilities have been observed to loop indefinitely under Xen (clearly > waiting for eax to report "no more cache levels"). > > Such userspace is buggy, but Xen's behaviour isn't great either.
Just another remark, since I stumbled across this again while preparing the backports: I'm not convinced such user space is to be called buggy. Generic CPUID dumping tools won't normally look for particular features. Their knowledge is usually limited to knowing where sub-leaves exist and how to determine how many of them there are. Anything beyond that would make a supposedly simple tool complicated. Jan
