From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1EF36C433FE for ; Tue, 10 May 2022 23:46:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238564AbiEJXqA (ORCPT ); Tue, 10 May 2022 19:46:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35580 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238462AbiEJXp4 (ORCPT ); Tue, 10 May 2022 19:45:56 -0400 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CC27B28716 for ; Tue, 10 May 2022 16:45:55 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id w17-20020a17090a529100b001db302efed6so504651pjh.4 for ; Tue, 10 May 2022 16:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=QoqmhoJVijxJEwqA6DH3wPhDIm10VpX5UsNvXVMmXaw=; b=CZaKyY51AyEq0wEP49YMgPJQn7JQeY/jnsqcUl4i6IKFgfdtTE3Hn8aD+P3ovp1tKT Se7jJ6ELuMBQol0V8Y+hy5iia9eRuGm/BhbHPvqMJOhjmRf4PWDYPmnPyF/i5SlTU9o1 FgFS9q7alymdBOHPZ0025vQoTCX59MhS/gNrFwWM+KmWqgu/T/qjXTpgRRQc5TIn6oPc q4fhyzjwrnA8llH+ALICTvBIRmkT8EZja0ZAOLRyDbD36XpoHVbqfUN3HPhb8wCFmHi3 IgCA+9GBww59wUku55apPIa7HKFjCQAsfB2IsSBB4VG3IFZ9TgOp5Pi5g4PbsR7OLwBo FH3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=QoqmhoJVijxJEwqA6DH3wPhDIm10VpX5UsNvXVMmXaw=; b=K2IL+dc6/8u92jQJ9/YIKqnLG1SAoUecRkyl/Q3NWCkhdM5lhiWXb86TFKwkrTyeXx SAx+yJ3OWXPbjz3osyrqXyLntkj95+a/DRoBJ6pqOItHyM3JTmb2RgZewjEjlhSDda74 ej+Gx4DIt0v4NXwTG3gLFM/ZU5nDXaI/HYdR6BBdkf5erm9T/KzOx7FBQZwmSUpVUmMO ib//RQjHY39L/zpvctkt95jxRwfKi1bJKeL3LFmtorU86bByxa6JYlVRXYprAAOSjboe uOW78ucpvwzGP3FXFouT2i9mqR6FMVqeMgOSzUtiTR19MbPbWJh2RfJDqrnuW98eYqDB Ejig== X-Gm-Message-State: AOAM530EB1ia2ozDAd2VA6XWoxwwFlmKhpfW/w2YyEijs+lBfJxKm38m 3/NXBUaS5goP2n0meQNvq/b+BQ== X-Google-Smtp-Source: ABdhPJx/WVHQXojCsdNzfIEY9IGkVQnnK/pBHDnL2wt68lS7jDgOHsrhTO/9FLmQSAktIOY4VL0TPA== X-Received: by 2002:a17:902:864b:b0:15e:f9e0:20ca with SMTP id y11-20020a170902864b00b0015ef9e020camr16873731plt.122.1652226355057; Tue, 10 May 2022 16:45:55 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id d14-20020a621d0e000000b0050dc76281b0sm107617pfd.138.2022.05.10.16.45.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 16:45:54 -0700 (PDT) Date: Tue, 10 May 2022 23:45:51 +0000 From: Sean Christopherson To: Shannon Zhao Cc: kvm@vger.kernel.org, pbonzini@redhat.com, linux-kernel@vger.kernel.org, yijunzhu@linux.alibaba.com Subject: Re: [PATCH] KVM: SVM: Set HWCR[TscFreqSel] to host's value Message-ID: References: <1652169227-38383-1-git-send-email-shannon.zhao@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1652169227-38383-1-git-send-email-shannon.zhao@linux.alibaba.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 10, 2022, Shannon Zhao wrote: > KVM sets CPUID.80000007H:EDX[8] to 1, but not set HWCR[TscFreqSel]. > This will cause guest kernel printing below log on AMD platform even > though the hardware TSC exactly counts with P0 frequency. > "[Firmware Bug]: TSC doesn't count with P0 frequency!" > > Fix it by setting HWCR[TscFreqSel] to host's value to indicate whether > the TSC increments at the P0 frequency. I don't think this is safe. The APM says Some HWCR bits are implementation specific, and are described in the BIOS and Kernel Developer’s Guide (BKDG) or Processor Programming Reference Manual applicable to your product. Implementation specific HWCR bits are not listed below. and then omits bit 24. One thought to handle this would be to let userspace write all the non-architectural bits, then userspace can set the magic, non-architectural bits based on CPUID and vCPU FMS. > Signed-off-by: Shannon Zhao > --- > arch/x86/kvm/svm/svm.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7e45d03..fb4bb51 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -1139,6 +1139,11 @@ static void __svm_vcpu_reset(struct kvm_vcpu *vcpu) > svm_init_osvw(vcpu); > vcpu->arch.microcode_version = 0x01000065; > svm->tsc_ratio_msr = kvm_default_tsc_scaling_ratio; > + /* > + * TSC frequency select is HWCR[24], set it to host's value to indicate This really should get a #define in msr-index.h, but maybe that's "impossible" because it's not an architectural bit. > + * whether the TSC increments at the P0 frequency. > + */ > + vcpu->arch.msr_hwcr = native_read_msr(MSR_K7_HWCR) & BIT_ULL(24); This will break live save/restore, a.k.a. live migration. KVM doesn't allow writes to MSR_K7_HWCR to set anything other than bit 18, even if the write comes from userspace. > > if (sev_es_guest(vcpu->kvm)) > sev_es_vcpu_reset(svm); > -- > 1.8.3.1 >