[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] x86/amd: do not expose HWCR.TscFreqSel to guests
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Wed, 13 Sep 2023 08:18:57 +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=DKeRxAGAmMi/1vTc4qJyW5b1V/FPSZ/ubQxG9sGyjoc=; b=SKhYP/wMsbrQvAwlIix8+foXALXNsMSjSs0SmbAhOerMfrLDNsD6FutvUVINUUkXIbjiZRCUOG27tbNHNVSdeNrSZ2tyR5OsnWFKPqRHiYpMa59Hu2UwAQIDoZA774ypjMeT1nQWEMPHj08c/7H7XBBeP0/KT9Emw0atmRZuXU1Gen7WwK1sEVVvP+cipWgQTh/ZoC1pUnyzebLDBJDeFLQeNhd0Kbiz/22EAf99uAvJ8DBtDVQmWwB8sn59RkwKghS/+hidEIAQMHfkzKK438JJUKDflzteSlsBat16wNlTSGfFlnGH0IovA6gdFn8Ujp9I6SlYPpAoMNCOG3tilA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EY+6TRDF6Owg6aEfuR7bhvavtP0Tec5qx3nwey6gQ+GOiHARhM5jWyHMMIq8/hCfpC+DkI9cpIwAGdqaQBe8BGz2+2IkBUuIP5UtX0gEWW8+LuiogtwnRLkdrMQpUf178zR+3fEuIMhHT/gVHHwFFEQKLLvYN3+99x+yPjrvI0EEJbSLsF6oJUnM4uHb1w5cPCcDOlqQkOi2k7q31x38k3Ffwdd7fWQUzCBleITgmCQSj3/q/Y1y/iZB22BbPUyxtHlEu6x6pvcsaywPcUPjghRSDZ8r6Lzf9bUaETNjBNoGJUHFxhWKjdatfCgCf2JJP4o1+1SdtjigR3+0UzmDdQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Wei Liu <wl@xxxxxxx>, solene@xxxxxxxxxxx, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>, Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 13 Sep 2023 06:19:05 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 12.09.2023 18:35, Andrew Cooper wrote:
> On 12/09/2023 5:23 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/msr.c
>> +++ b/xen/arch/x86/msr.c
>> @@ -240,8 +240,12 @@ int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t
>> *val)
>> case MSR_K8_HWCR:
>> if ( !(cp->x86_vendor & (X86_VENDOR_AMD | X86_VENDOR_HYGON)) )
>> goto gp_fault;
>> - *val = get_cpu_family(cp->basic.raw_fms, NULL, NULL) >= 0x10
>> - ? K8_HWCR_TSC_FREQ_SEL : 0;
>> + /*
>> + * OpenBSD 7.3 accesses HWCR unconditionally if the TSC is reported
>> as
>> + * Invariant. Do not set TSC_FREQ_SEL as that would trigger
>> OpenBSD to
>> + * also poke at PSTATE0.
>> + */
>
> While this is true, the justification for removing this is because
> TSC_FREQ_SEL is a model specific bit, not an architectural bit in HWCR.
>
> Also because it's addition without writing into the migration stream was
> bogus irrespective of the specifics of the bit.
>
> I'm still of the opinion that it's buggy for OpenBSD to be looking at
> model specific bits when virtualised, but given my latest reading of the
> AMD manuals, I think OpenBSD *is* well behaved looking at PSTATE0 if it
> can see TSC_FREQ_SEL.
I'm afraid I'm still at a loss seeing what wording in which PPR makes you
see a connection. If there was a connection, I'd like to ask that we at
least properly consider exposing PSTATE0 (or if necessary all PSTATEn) as
well, with zero value (i.e. in particular with the valid bit clear),
rather than exposing a r/o bit with the wrong value, upsetting Linux.
Jan
|
