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

Re: [PATCH 1/3] x86/Intel: skip PLATFORM_INFO reads on family 0xf


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 11 Feb 2022 11:41:36 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=sfSqR2dH8GqQfY9mYwIKStsHGShHmQ34UwiEZAaj4zU=; b=J2Oozk3OL2lfNPJPIe02XzFaY8KmOeZd0LFX/HJ6s6h1wOtLPx5OT+yNQjFHDbPzrEur0ub7HH6kcryiORdtof7rPySJADYR1OZPSbvbCHvDgl3cWPcGfBO3RBGW2rcKn/8Ruz6SbHgKEYNjcCn0M1eGPDkQ6LDgvQy2JRR4SIb2mu9kYsM4E/n6eSvtwn9DAFN4QHPw60CQZ02iyqFKJPJFtO6tP0IrLbiXbquSKQ0RIpY2HXo5BK+372NJqqNlHAU0zhyxU/qmXmmX8reb0zbrWolvAIsuj1lA60WxcbrjjIjYTQ6r7nlkS+hJFtkrsfdLiEgjdYsQEvlZ7Fp3Yw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BS6x9Mq0xN/pR+9XGsqYDgX31BvmyMktVGmS8R6nmYY5J/es8qKH8jsqXsmCq5EWL8UvGx7rQp6xoPVSuSeIrN0QSLIMmyhB9XMmNzAX3P8Kg+at8IxirB+rGW+yLgxMTC6dAHjZi2cdyXTINy74XRqXYKAMXKF0ajOGtpYo9Rh0OTdKRHe4Z0+cMVgw2B+RWVrzUqw5nwNgzDOERDdspyzDEsGcOusgwvGZ49BJ8P/coKAhvijTKtY8BdgnVQIKpfDK1iTXOk7Vdj7Dax85uVQTIacVwD6WSRm9eYTkA6kYq6j/E/505NJLFelQKG/O3OmWudEDXqenqfuhHeGGgg==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Fri, 11 Feb 2022 10:42:10 +0000
  • Ironport-data: A9a23:RDGVfa3Ti0PxIoHXbvbD5QF2kn2cJEfYwER7XKvMYLTBsI5bp2ABx mMdXG2CPffca2T2fowjYYi0p0wPvMSEnYBnS1NopC1hF35El5HIVI+TRqvS04J+DSFhoGZPt Zh2hgzodZhsJpPkS5PE3oHJ9RGQ74nRLlbHILOCanAZqTNMEn9700o5wrdh2+aEvPDia++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFMZH4rHomjLmOQf2VhNrXSq 9Avbl2O1jixEx8FUrtJm1tgG6EAaua60QOm0hK6V0U+6/TrS+NbPqsTbZIhhUlrZzqhoo1c0 8tPs4OMawpyeYvPo+5MVzx8DHQrVUFG0OevzXmXtMWSywvNcmf2wuUoB0YzVWEa0r8pWycUr 6VecW1TKEDY7w616OvTpu1EnMMsIdOtJIoCknph0SvYHbAtRpWrr6Diu4EChmZu3JEm8fD2f 5taRBdVcTb8QRh0HUYUAcwgtdf1iSyqG9FfgA3M/vdmi4TJ9yRu1JD9PdyTfcaFLe1Fk0Ddq m/Y8mDRBhABKMfZ2TeD6mirhOLEgWX8Qo16PL+y++NugVaT7ncOExBQXly+ycRVkWbnBYgZc RZNvHNz8+5iryRHU+URQTWF/VOfoBwaROZyHrZ9zgK2wPvQxiKGUz1soiF6VPQqs8o/RDoP3 1CPns/0CTEHjIB5WU5x5Z/P82rsZHF9wXsqIHZdEFBbu4WLTJQb00qXJuuPBpJZmTEc9dvY5 zmR5BYziLwI5SLg//XqpAuX695AS3Wgc+LU2uk1dj/9hu+aTNT8D2BN1bQ9xawRRGp+ZgPf1 EXoY+DEsIgz4WilzURhutklErCz/OqiOzbBm1NpFJRJ323zpyL+J90Pv2sjfR8B3iM4ldnBO h67VeR5vsE7AZdXRfUvP9LZ5zoCkcAM6ugJptiLN4ETM/CdhSeM/T10ZF744oweuBNErE3LA r/CKZzEJS9DUcxPlWPqL89Age5D7n1vngv7GMGkpylLJJLDPRZ5v59eawDQBg34hYvZyDjoH yF3aZfUlUUFDbGWj+u+2dd7EG3m5EMTXPjeg8dWavSCMkxhHmQgAOXW2rQvZ8pumKE9qwsC1 ivVtpZwxAWtiHvZBx+Nb3w/OrrjUYwm9SAwPDA2PEbu0H8mON794KAafpoxXL8m6O08kqIkE 6hbI52NUqZVVzDK2zUBdp2h/oZsQwum2FCVNC2/bTlhI5M5H17V+sXpdxfE/TUVCnblrtM3p rCtj1uJQZcKSwl4ItzRbfajkwG4sXQHwbogVErUONhDPk7r9dEyeSD2i/Y2JeAKKAnCmWTGh 1rHX09AqLCU8YEv8dTPiaSVlKuTErNzThhAAm3WzbeqLi2GrGCt9pBNDbSTdjfHWWKqpKj7P bdJz+vxOeEslUpRt9YuCK5iyK8z6oe9p7JeyQg4TnzHY07yV+FlK3iCm8JOqrdM1vlSvg7vA hCD/dxTOLOoPsL5EQFOeFp5P7rbjfxEyCPP6fkVIVnh4H4l9bWKZkxeIh2QhXEPN7ByKo4kn b8stcN+B9ZTUfb23gJqVhxpylk=
  • Ironport-hdrordr: A9a23:IhuT9KPJmkHAXMBcT1n155DYdb4zR+YMi2TDiHofdfUFSKClfp 6V8cjztSWUtN4QMEtQ/uxoHJPwO080kqQFnLX5XI3SJzUO3VHHEGgM1/qB/9SNIVyaygcZ79 YdT0EcMqyAMbEZt7eC3ODQKb9Jq7PmgcOVbKXlvg9QpGlRGt9dBmxCe2Cm+yNNNW177c1TLu vi2iMLnUvqRV0nKuCAQlUVVenKoNPG0LrgfB49HhYirC2Dlymh5rLWGwWRmk52aUID/Z4StU z+1yDp7KSqtP+2jjfaym/o9pxT3P/s0MFKCsCggtUcbh/slgGrToJ8XKDqhkF+nMifrHIR1P XcqRYpOMp+r1vXY2GOuBPonzLt1T4/gkWSv2OwsD/Gm4jUVTg6A81OicZyaR3C8Xctu9l6ze Ziw3+Zn4A/N2KPoA3No/zzEz16nEu9pnQv1cQJiWZEbIcYYLhN6aQC4UJuFosaFi6S0vFpLA BXNrCd2B9qSyLYU5iA1VMfguBEH05DUitue3Jy+/B8iFNt7TVEJ0hx/r1pop5PzuN4d3B+3Z W2Dk1frsA7ciYnV9MMOA4/e7rENoXse2OEDIvAGyWuKEk4U0i93qIfpo9Fo92XRA==
  • Ironport-sdr: zgDg91yGhUWKo/WSY2E9zXDvXXhrdB9+L0HySU7w7V8jAqTGVpzlfpUNaqSoNJnsbTsZHGNvP+ XQmS9exfS4IbCm8jSDVGhdAKkUeb2FGmhBrL6Q1n5QBg56OVU9FHcUH+4KVbIdVHOiMRTwhkZJ uCNGygwU+BVKuMd9UxNOeiZbpGvPqt3Egx3njfJRVgeMNLBbwxe6Yzdy6iCIgjuAV8OvoVvqAg g23cOFwvHqotT+o3MXfm1O3JJFGcpBuGv9SjwKA/13EGg3B0n8vhyozOmVZh7+JEgLaOlpoMT/ pZxmG//u/XuQy4hoKoM4/Q9P
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Feb 11, 2022 at 10:59:10AM +0100, Jan Beulich wrote:
> On 11.02.2022 10:40, Roger Pau Monné wrote:
> > On Thu, Feb 10, 2022 at 03:55:52PM +0100, Jan Beulich wrote:
> >> This avoids unnecessary (and always somewhat scary) log messages for the
> >> recovered from #GP(0).
> > 
> > Could we maybe get rid of the #GP messages for cases like this where we
> > are explicitly probing for MSR presence? (ie: it's expected that we
> > can get a #GP)
> 
> This would mean some form of annotation of such RDMSR attempts (for
> the recovery code to recognize in order to skip the printk()). Not
> all rdmsr_safe() uses are, strictly speaking, probes, so I wouldn't
> want to put such in rdmsr_safe() itself.
> 
> In any event - quite a bit more work. Plus I'm not convinced it's a
> good idea to suppress any such log messages.
> 
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>

Acked-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> >> ---
> >> Perhaps even use "!= 6" in at least the CPUID-faulting family check?
> > 
> > Likely, or else you would also need to check for family 11 (Knights
> > Corner?) which doesn't seem to support PLATFORM_INFO either.
> 
> I don't think Xen is able to run on these (likewise for IA64, which
> iirc were surfacing as x86 model 7)? These are the co-processor ones,
> aren't they?

Right, Knights Corner uses a socket mount but it's still a
co-processor. It was Knights Landing the first one that could be used
as a host processor.

> My question was more towards whether we would (wrongly)
> exclude future processors when using != 6, if Intel decided to ever
> make new CPUs with a family other than 6.

In the case here I think we should only avoid the probe for family
0xf. Newer families (or even models on family 6 not supporting
PLATFORM_INFO) will just get a #GP message which is OK I think, we
could fix that in due time.

It's better to get a #GP message for probing than to just skip
detection of CPUID faulting on unknown newer families IMO.

Thanks, Roger.



 


Rackspace

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