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 X-Spam-Level: X-Spam-Status: No, score=-16.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17248C433B4 for ; Mon, 26 Apr 2021 08:57:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CD8056117A for ; Mon, 26 Apr 2021 08:57:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232383AbhDZI6Z (ORCPT ); Mon, 26 Apr 2021 04:58:25 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20108 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232116AbhDZI6S (ORCPT ); Mon, 26 Apr 2021 04:58:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619427450; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xrtgnm/L0WtusbYF9SuDZ+pYt9hjB7RMvd0KmtVIh7o=; b=OtR+TGKCg4S/PVJ8lQwYlY2Sqd4gYCMUQxm7WJ+ReO3P5NMQGDfSjM7r/rP0JM9BpWW6Yp hsKn0jxcqVpd0wbBm1x7Aur2UfUQS2b+gmTg8TfDDXo/ucMCYDtrkYGkKImEwLMRMeFyUZ MS9kpfEG3Mug2vZzvNIn03UGEintzi8= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-603-cEPmFHbAMjq8giTK5dyVpA-1; Mon, 26 Apr 2021 04:57:28 -0400 X-MC-Unique: cEPmFHbAMjq8giTK5dyVpA-1 Received: by mail-ej1-f69.google.com with SMTP id p25-20020a1709061419b0290378364a6464so9917789ejc.15 for ; Mon, 26 Apr 2021 01:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=xrtgnm/L0WtusbYF9SuDZ+pYt9hjB7RMvd0KmtVIh7o=; b=gCrC7lmVHOkjdGMwXA1xL5L/qpx2qOF39YqbWzcefJB66O4y9s9DAIWMT/VuYEuFNZ xZcroWxeuNQdcvJ2fwDU4ubZ8/Y823Brmck6U37c2pFboH/wV2Jb+L110kTr1todm+8O TLAfLAnrKqLoDbceGd4Wb2aBiutHcVynczDvpmBcT9HO6lPQOkYWJ1TiX73CIJaqb6Rr xCnaivFqBAbqdCZPkeAJp8fYArSiAO1q5tRLj+J9//GeeLXa6l8UhCkiXLbCOrKC+3nA dx/BFoQa4DolH4XHX7oGhduvA5Lu5fiATXDG1AAfQ3HWUoJhAZyS3JWjCRCzLeyXM/QJ gbUw== X-Gm-Message-State: AOAM533JfhWR/bdQyL8lhx1n7yz/qOkPy/DFc+TZK24h9XgNsFtzixF6 dN8SgqScXJi2DuTa59+527Q6r3IQTcy4B+lqCrFuotG8YYMo53F5/F5huQzskTX3k6kudd1ruv6 kxemB9kZZ9YPHvBq1UVAzV7AE X-Received: by 2002:aa7:d3c2:: with SMTP id o2mr11080385edr.111.1619427447086; Mon, 26 Apr 2021 01:57:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy5MzhdKNnSR2VHJq899bCvKAXx3Od/AUHphWB11TckcK76RF4SdIk9cZ4VNU+wCPmi6XCfvA== X-Received: by 2002:aa7:d3c2:: with SMTP id o2mr11080371edr.111.1619427446916; Mon, 26 Apr 2021 01:57:26 -0700 (PDT) Received: from vitty.brq.redhat.com (g-server-2.ign.cz. [91.219.240.2]) by smtp.gmail.com with ESMTPSA id o8sm10956335ejm.18.2021.04.26.01.57.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Apr 2021 01:57:26 -0700 (PDT) From: Vitaly Kuznetsov To: Sean Christopherson , Paolo Bonzini Cc: Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Reiji Watanabe Subject: Re: [PATCH v3 2/4] KVM: SVM: Clear MSR_TSC_AUX[63:32] on write In-Reply-To: <20210423223404.3860547-3-seanjc@google.com> References: <20210423223404.3860547-1-seanjc@google.com> <20210423223404.3860547-3-seanjc@google.com> Date: Mon, 26 Apr 2021 10:57:26 +0200 Message-ID: <87k0opfmo9.fsf@vitty.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sean Christopherson writes: > Force clear bits 63:32 of MSR_TSC_AUX on write to emulate current AMD > CPUs, which completely ignore the upper 32 bits, including dropping them > on write. Emulating AMD hardware will also allow migrating a vCPU from > AMD hardware to Intel hardware without requiring userspace to manually > clear the upper bits, which are reserved on Intel hardware. > > Presumably, MSR_TSC_AUX[63:32] are intended to be reserved on AMD, but > sadly the APM doesn't say _anything_ about those bits in the context of > MSR access. The RDTSCP entry simply states that RCX contains bits 31:0 > of the MSR, zero extended. And even worse is that the RDPID description > implies that it can consume all 64 bits of the MSR: > > RDPID reads the value of TSC_AUX MSR used by the RDTSCP instruction > into the specified destination register. Normal operand size prefixes > do not apply and the update is either 32 bit or 64 bit based on the > current mode. > > Emulate current hardware behavior to give KVM the best odds of playing > nice with whatever the behavior of future AMD CPUs happens to be. > > Signed-off-by: Sean Christopherson > --- > arch/x86/kvm/svm/svm.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 9ed9c7bd7cfd..71d704f8d569 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -2904,8 +2904,17 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr) > * direct_access_msrs. Doing that would require a rdmsr in > * svm_vcpu_put. > */ > - svm->tsc_aux = data; > wrmsrl(MSR_TSC_AUX, svm->tsc_aux); Hm, shouldn't this be wrmsrl(MSR_TSC_AUX, data) or wrmsrl(MSR_TSC_AUX, (u32)data) then? As svm->tsc_aux wasn't updated yet. > + > + /* > + * Per Intel's SDM, bits 63:32 are reserved, but AMD's APM has > + * incomplete and conflicting architectural behavior. Current > + * AMD CPUs completely ignore bits 63:32, i.e. they aren't > + * reserved and always read as zeros. Emulate AMD CPU behavior > + * to avoid explosions if the vCPU is migrated from an AMD host > + * to an Intel host. > + */ > + svm->tsc_aux = (u32)data; Actually, shouldn't we just move wrmsrl() here? Assuming we're not sure how (and if) upper 32 bits are going to be used, it would probably make sense to not write them to the actual MSR... > break; > case MSR_IA32_DEBUGCTLMSR: > if (!boot_cpu_has(X86_FEATURE_LBRV)) { -- Vitaly