[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 7 Apr 2022 16:27:11 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vGzGK1vQdoVKXrrKQ2YHQsvPjrtBajn1TL0F4zIeRI4=; b=FjAzMIRz/iITky05rIsOk1Mokk3AUxkgW4hck5yvZwhA2TpJiBhO+ReSwh2N77NfElP7fLy6Jq29NImk+HoeDm2j8nHR/lRwSRLBS9OY8MLJhbdDsJVsRbN7IS8Vu/QPQqqiIm1eC/UV/25Wbzna0KVTJ/QjH6/ydcrCtg+0pailCnP3+2WhOEv28atDimUnsn1+3ebtpWt5GZivfjMzJ556aIhgyEFH08zo5bagR2eyx1HebrP9bQ/NEEJlNJp4dt4Y7R1VbgpwV/vXnv3ajftCblyhIs8VN5/2gzuLfoc3dHd5n/UlUFYWXgIlVgWv/ikq67O8Ex1Ac17PiDr5Ug==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XoCbh8HcwAybPnOU05Pf9dE/APzkvjuu9JFsD6NbAMDzQdd6G4lDlxgNrlbJWMLJqkObLsOZbYNQr9PHj0Z+sG0v/dpkqONz3V2kxTI1ztYPFEZc4bM+Ln/0Hf0TBoJ+ww2AgisAbgvCxyPgia7SUlHeSs65Bn3oXrHWbSmVDpWO8Abk4JS/DjdxhDeFF07E7hNFxROyHVG6gdE3Mk5D++83mPH0pPfjgoTOimCzOlgspqphaRDFBOCIUk9t5jdNUncjPHF3oWyMFofAYm3em99u8piJk41OwEu6veAtR8nDiR9XK+q5YAo31Y/AjaTCcwMnwMLKtR1AjTBpdGG4QA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 07 Apr 2022 14:27:39 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.