[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/11] x86 vendor check optimisations
- To: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Thu, 27 Nov 2025 22:11:39 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=cYDziWmpfg6jFIDyJg8fnIrPQbB102iQI0Syc2VeWWs=; b=x6MJvAkex3B3ic/DunkGsZW4E8If2PZyez++HazeLl/2iKqHOOqfZIudqTi7E1jBSeyenuDg4K4Ci6b5H78KC7PZT5Gmx2cH+BNKbwmygTfE8roTrWw9TzV+LcbxlmV1AWXfm7R2GAI4T2XvMhwrnH9jfI/A5ER5CK/AHNuXOfdAVba4CVKJtK3dSDACWDE7r9nky1cTSudsvB8DRvQGipTnYoIMK42mwQgyxiSBmCwRqUhhaoXzMc7lprS3XMBahUcQdHWL38b/qIpGkavJrOd6ZJ3gnn1HewyYGYc5ssWw5G8HK6T2WegPZTMsnSObuLq8vAepdcYj2odBK/QLEA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=yKSEuYZD2Q0kyuiDxsJx2wt+XjIhgDZ6kykg/pBcSn4UKIaGRj/qst9TxIOipUlUVHvE6sbWeXwAIexUUPBhKaZlx4FcCrDv3ilbf6zK2Q4qVMA26+v5Mm3PziMjY1aJQ2PNp/IdTPV+fU63fl4pWwBPcT/VhEX7Dz1Ox8Y1VoCrVkkytjvdDyjMo1zZ3muV3z7BoNHUjV+XKb02VXpYJ8Y+NKndaXQqCaYzckH6Qv2MsnrgUa4rl5Fm0zKMtAuwzKXA52tCebrelNunA9b37MRSmdwPYlPczZLr5Lz7Rz8Y17uoDuUphVNKONDXeqBPVASEnfOl1tcBN/1GWWYyrA==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: andrew.cooper3@xxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Xenia Ragiadakou <xenia.ragiadakou@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Thu, 27 Nov 2025 22:12:07 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26/11/2025 4:44 pm, Alejandro Vallejo wrote:
> Just knowing x86_vendor_is() is "good to have" is good enough as it enables
> our
> downstream to customise it with whatever optimisations we need.
>
> I also suspect other areas of the hypervisor could benefit from this meld of
> runtime+compiletime sort of checking, allowing transparent code removal.
>
> I'm thinking DOM0LESS_BOOT vs DOM0_BOOT vs PVSHIM_BOOT, or AMD_SVM vs
> INTEL_VMX
> in HVM-only builds, or family checks to have (i.e) a explicit "older-than-zen"
> Kconfig option with a similar approach on a family range check.
>
> This is maybe one of several such uses.
>
> So... thoughts? I'm definitely fond of the single-vendor bloat-o-meter output.
Having looked through the whole series, I'm not a massive fan of
converting the switch() statements, but it's the only way to do the
DCE. So be it.
I think x86_vendor_is(var, MASK) wants to become boot_vendor(MASK).
Most cases want the boot vendor, and those that appear to want something
else don't actually. When you disable the cross-vendor case (patch 2
pulled out ahead), then cp->vendor == boot_vendor and then you don't
need a variable to pass in.
This also reduces the verbosity of the new lines which is an improvement.
That said, this series also collides substantially with the Intel Fam
18/19 work, which is more urgent and needs backporting to 4.21. More
specifically, there are a bunch of changes which interfere with VFM
conversion, and for which I can't see an obvious DCE reason to have, so
I'm wondering if they were just part of "convert everything".
~Andrew
|
