Received: by 2002:a05:6a10:8395:0:0:0:0 with SMTP id n21csp605200pxh; Tue, 9 Nov 2021 16:03:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJyG1x7ryp+9O3XLrj3oAq4JuEzrTE7JfXg+9PkZZ5ynqwSO6kQRafHWY3sfSvLRVjfo7gNL X-Received: by 2002:a05:6e02:1c2d:: with SMTP id m13mr8843458ilh.26.1636502624643; Tue, 09 Nov 2021 16:03:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1636502624; cv=none; d=google.com; s=arc-20160816; b=lQ2sheA2VtXsIH7f/H/Rq/Iq1+cUg58vuCtVdCCCopxRr7PMxRmwZMyLoHYf0ExPPj sa9P1lGv26lA3zCOBxLkOTqeuuFjfrFEmPMvCkdQsjZdSQW1S3sN6YEdaJuy6QEB6gna 4FmM0fVmkzrwv/Y9094HWnZSz+VxmvOeWu+6+UiEIppr1+vEGsz4cHju9GdT+SIDBItw +lC3CDmy9OpQEqdJTA6tjyOovlUr0fw4TZw938T8No07oeeOqpEuiLmt9AaBFTQlGNfn ZG55Umb0PGF/g3VDLsv7DWuFIc3ZyCqqYKhgdB6S9/PMzWpPgO6Pt0zDfZG275ICv7ls LpZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:subject:from :references:cc:to; bh=tGN+U7/wJCKcyPwcqS9CWBJuR/jWeO2QUBQwVhkk6JM=; b=UryLqYeeQE4dtc8xLAELLl/X0394qiPAEOMze59rb+SL1bVyhh+HKvgIYEMszxdZpn FIzQ9WNpvbILYOt8YW1/6UZ0arr1rhwztvv2/68zUb+jnK2cnB3Im2dH9dHIAz7gTBYo xZrjGskX0QhWCbB+9dbpQCqGbTR30NWBbwgVQWYc1+y+Ddqn/WUrXvOT4NCMXAr8ZzH8 n9Kt0ZT0LynT5R1v0nsz7RxZwJZby2+FqALM6rpfoZn/sVEwz7oL/xUjPVpBGCZqivZ6 tGT0OTBVCZNT43oJD/HO1FojuG+zVB/0/jmx5zfmDdFDZNFVM+DK8iD3+DzEYrAnjg+y n3ng== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f1si14036237jaq.26.2021.11.09.16.03.31; Tue, 09 Nov 2021 16:03:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236519AbhKIPth convert rfc822-to-8bit (ORCPT + 97 others); Tue, 9 Nov 2021 10:49:37 -0500 Received: from ppsw-32.csi.cam.ac.uk ([131.111.8.132]:56550 "EHLO ppsw-32.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236482AbhKIPtg (ORCPT ); Tue, 9 Nov 2021 10:49:36 -0500 X-Greylist: delayed 1075 seconds by postgrey-1.27 at vger.kernel.org; Tue, 09 Nov 2021 10:49:35 EST X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: https://help.uis.cam.ac.uk/email-scanner-virus Received: from hades.srcf.societies.cam.ac.uk ([131.111.179.67]:39002) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1mkT33-000x3r-0M (Exim 4.95) (return-path ); Tue, 09 Nov 2021 15:28:33 +0000 Received: from [192.168.1.10] (host-92-12-61-86.as13285.net [92.12.61.86]) (Authenticated sender: amc96) by hades.srcf.societies.cam.ac.uk (Postfix) with ESMTPSA id C53601FBEE; Tue, 9 Nov 2021 15:28:32 +0000 (GMT) To: Peter Zijlstra , Boris Ostrovsky Cc: linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, jgross@suse.com References: <1635896196-18961-1-git-send-email-boris.ostrovsky@oracle.com> <48fb48fa-c65d-8e38-dabb-cf9be21365ca@oracle.com> From: Andrew Cooper Subject: Re: [PATCH] x86/smp: Factor out parts of native_smp_prepare_cpus() Message-ID: Date: Tue, 9 Nov 2021 15:28:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Content-Language: en-GB Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/11/2021 15:10, Peter Zijlstra wrote: > On Mon, Nov 08, 2021 at 12:20:26PM -0500, Boris Ostrovsky wrote: >>> But looking at those functions; there seems to be more spurious >>> differences. For example, the whole sched_topology thing. >> >> I did look at that and thought this should be benign given that Xen PV >> is not really topology-aware. I didn't see anything that would be a >> cause for concern but perhaps you can point me to things I missed. > And me not being Xen aware... What does Xen-PV guests see of the CPUID > topology fields? Does it fully sanitize the CPUID data, or is it a clean > pass-through from whatever CPU the vCPU happens to run on at the time? That depends on hardware support (CPUID Faulting or not), version of Xen (anything before Xen 4.7 is totally insane.  Anything more recent is only moderately insane), and whether the kernel asks via the enlightened CPUID path or not. On hardware lacking CPUID faulting, and for a kernel using native_cpuid() where it ought to be using the PVOP, it sees the real hardware value of the CPU it happens to be running on. ~Andrew