[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/9] x86: Merge struct msr_policy into struct cpu_policy
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Thu, 30 Mar 2023 12:11:17 +0100
- 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=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=aud00+nPEs1KVI12TfTtFvGqSGn47so9rAPgY5V3avA=; b=ZXcfVCqEV3QiN7NYuYT+EjvUBcNfesiLzaOreJQhoIyMSqD06mMoE1zWQtFg1TTIzyJIDqPvNA1+NpZtNEhe3aN1Vtmcs30c2vU5wsZobiw2FY0sL1IgsbDhyk+q/JgviCt1YBwxSoD6TB/vAdxT1gdFVdWVvtNEMYgpmf2ecKiJJLxrE46gFaphzStadBuCrpBpOgbv/46aXYeIUuRaM/OvlqlRnMTVJYaWuApfWFTSJdi4aVM3VrY6XrPrcT3EcpHvl7xFf+j9v0T3jTWlWcYjpenajyoV9y6BWeSYhMTF/pD29da8bOMES+x0YlCdosBu7bJ0yAm2Kk6ElUytLQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=awpjTSvEAU10EmJMV9U0RrHvtCmM4nKuAz3yApJvzFqOVhjlBQpcH0n2Tc2qR1v0xa5MX9Ef77ybx1FvZhzkoMdgVyT2xMg+xT1TcZSTO/Q+E2GtUXoo8M7jKmtZYem2EjehNWdLR/5hQxae9/GRf4CDwt30tqKKb4rQoreHPQe6kx0C9ncJBcX8waRztb5JksPrK4gPFLunDTirEh7aFGFAyntV2AToM8HQsdgYhntNpyooDzXA5wY2/cX0BiQIb8jw4yFlb+6v5ZCJqVFtihh6bnwZlJoKuQidIZBn1H+Tn+07Q1xUeQ7/oUF9PGvTYpVgB4yopI9JZBV7hGEolQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
- Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Thu, 30 Mar 2023 11:11:30 +0000
- Ironport-data: A9a23:b4unfq/g9ojHu5J3ymtLDrUDrX+TJUtcMsCJ2f8bNWPcYEJGY0x3n TEWC27VOfyCNDTyLt11O9m3oEwH7ZDSxoBjTgFk+H88E34SpcT7XtnIdU2Y0wF+jCHgZBk+s 5hBMImowOQcFCK0SsKFa+C5xZVE/fjUAOG6UKicYXoZqTZMEE8JkQhkl/MynrlmiN24BxLlk d7pqojUNUTNNwRcawr40Ire7kI/1BjOkGlA5AdmPqsT5Aa2e0Q9V/rzG4ngdxMUfaEMdgKKb 76r5K20+Grf4yAsBruN+losWhRXKlJ6FVHmZkt+A8BOsDAbzsAB+v9T2M4nQVVWk120c+VZk 72hg3ASpTABZcUgkMxFO/VR/roX0aduoNcrKlDn2SCfItGvn9IBDJyCAWlvVbD09NqbDklNz qE7NQ5TNSqfqLqs/aK1F9ZBiOgaeZyD0IM34hmMzBn/JNN+HdXmfP+P4tVVmjAtmspJAPDSI dIDbiZiZwjBZBsJPUoLDJU5n6GjgXyXnz9w8QrJ4/ZopTeIilUujtABM/KMEjCObexTklyVu STt+GPhDwtBHNee1SCE4jSngeqncSbTAdpISOPkq6Yz6LGV7mEYLBtLDXmxmKGWpBSjVPFDJ HUT2yV7+MDe82TuFLERRSaQonSJoxodUNp4CPAh5UeGza+8yxmdLngJSHhGctNOnN87Q3km2 0GEm/vtBCdzq/uFRHSF7LCWoDiufy8PIgc/iTQsSAIE55zmv9s1hxeXEtJ7Svfq0JvyBC36x C2MoG4mnbIPgMUX1qK9u1fanzaroZuPRQkwjunKYl+YAspCTNbNT+SVBZLztJ6s8K7xooG9g UU5
- Ironport-hdrordr: A9a23:mU8kGai6n/RY5zsJL7kUrxXe43BQXrkji2hC6mlwRA09TyX4ra CTdZEgviMc5wx9ZJhNo7q90cq7IE80i6Qb3WB5B97LYOCMggeVxe9Zg7ff/w==
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 30/03/2023 10:30 am, Jan Beulich wrote:
> On 29.03.2023 22:51, Andrew Cooper wrote:
>> --- a/xen/include/xen/lib/x86/cpu-policy.h
>> +++ b/xen/include/xen/lib/x86/cpu-policy.h
>> @@ -3,7 +3,6 @@
>> #define XEN_LIB_X86_POLICIES_H
>>
>> #include <xen/lib/x86/cpuid-autogen.h>
>> -#include <xen/lib/x86/msr.h>
>>
>> #define FEATURESET_1d 0 /* 0x00000001.edx */
>> #define FEATURESET_1c 1 /* 0x00000001.ecx */
>> @@ -107,6 +106,9 @@ const char *x86_cpuid_vendor_to_str(unsigned int vendor);
>> CPUID_GUEST_NR_XSTATE - !!CPUID_GUEST_NR_XSTATE + \
>> CPUID_GUEST_NR_EXTD + 2 /* hv_limit and hv2_limit */ )
>>
>> +/* Maximum number of MSRs written when serialising msr_policy. */
>> +#define MSR_MAX_SERIALISED_ENTRIES 2
> The comment better wouldn't refer to msr_policy anymore, I think.
Ah yes. (There's so much comment and library cleanup still to do)
> I also
> wonder whether the comment wouldn't better move ...
>
>> @@ -324,6 +326,44 @@ struct cpu_policy
>> };
>> } extd;
>>
>> + /*
>> + * 0x000000ce - MSR_INTEL_PLATFORM_INFO
> ... e.g. above here, to increase the chance of it being spotted that
> it needs updating if another MSR is added here.
I'm not sure about that. In its current position, it's next to it's
CPUID partner.
The unit tests in test-cpu-policy cross-check that we never get -ENOBUFS
for a MSR_MAX_* sized destination, so I'm not worried about it actually
getting stale.
But, with the new merged policies, I need to change the serialising
behaviour anyway.
Right now we serialise everything unconditionally because that's the
only way that merging incremental deltas could be made to work, but now
the MSR enumeration bits are in the same structure we can use those
instead, along with the various "clear" passes we already have.
~Andrew
|
