Re: [PATCH] x86/cpuid: Clobber CPUID leaves 0x800000{1d..20}

From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH] x86/cpuid: Clobber CPUID leaves 0x800000{1d..20}
Date: Thu, 7 Apr 2022 16:27:11 +0200	[thread overview]
Message-ID: <4206733c-c4be-2e8d-7ea2-d145d3599e48@suse.com> (raw)
In-Reply-To: <20220407010121.11301-1-andrew.cooper3@citrix.com>

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