Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1838702pxm; Thu, 24 Feb 2022 10:17:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJzy+tRLWk7IIyc3VrvG0T8Vy1S4LdicbAlPnIR1GsdKSzrRcd3QU7M2CAQ9VpUxgGrWPvOb X-Received: by 2002:a17:906:5a6e:b0:6d0:afaa:6ce9 with SMTP id my46-20020a1709065a6e00b006d0afaa6ce9mr3307533ejc.72.1645726621377; Thu, 24 Feb 2022 10:17:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645726621; cv=none; d=google.com; s=arc-20160816; b=c4vfKep+z8tM5SEJGpuBh08IhBP1w7/cpwYqj8dwMzuMEEwouFjnEJ3I6WC8dzP7Ge EJ0buxcrUe11aT8Ct2mm1LNukeDSMzJErv+tCeskNSXcFFxGA6f5H7PaMbmo7OB23T51 DNPL8D/vluXGdBBcF+CfnOT3qoSxwkHo6Ke0RQUcJMfyiz/Hb55yic9yAl63PxHHsjp0 YS7DHsve0cRFXrRcRIz5FlZ2wSbKffb+CUNwsAys7RpweBmDLPEGLMUIbT66Wa//mFxE suwYN7iI5p7wJIuOgbYoGOHJ26XttmnJ5HTpiZRdePKsMp1/uPKb+iQnzUR69Q+u0px+ Rglw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=70SduNrAiaotDuCIZO647ys8w2/fadsYzkVqmSb6sHw=; b=stKxRtFbWurLn2E79QrpnCY0tiZXVRLpNrWWxHdkZyw/sboga76E74sI7iquBRocKc wBsWn5tH4APeyxP8cZvziVcnk3sYUKICeBx7d2ZtbHlFI1WWJEsPWsUs/AbEmKjQ5xdB a+F0czsN/Kp3a3dO2y7d5PxJDfu5AY1M/TX/Lefke7/2W7KC8eWyCW8w4CQnjfEcMIN5 zrbs6ugX4gGG5bDacm+0who0ulpmpYkDyVf8TP8GMRiv6kfAcF0Y4lF8Gyag0ejfxn2S XEySfoEqmSMwo6GlfKEhVfsIiJCO7mshfH5BBd/MIklqLxPJ3I2he0cx2Pw5MY2mz+CS ziYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=d8JLEX6c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n19-20020a17090625d300b006d16268ca7dsi55128ejb.804.2022.02.24.10.16.36; Thu, 24 Feb 2022 10:17:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=d8JLEX6c; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232139AbiBXRly (ORCPT + 99 others); Thu, 24 Feb 2022 12:41:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229914AbiBXRlv (ORCPT ); Thu, 24 Feb 2022 12:41:51 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6F61F1C2F60 for ; Thu, 24 Feb 2022 09:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1645724480; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=70SduNrAiaotDuCIZO647ys8w2/fadsYzkVqmSb6sHw=; b=d8JLEX6cekXhQyxAoq/xEFYiIBvrdgF/V8DgqaNyQqLt99tMcRlpkq0qIOHnNqLEmLIoH4 XjxF/f29tw32RkTZ96pZwfaW88OSG17VOSeaylxo9CtKun1MuAbbiLkr0SWF3yHGsIXkgt 7fjuOOL/g+IRo2Nm/7p8j9OKEU9dfII= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-126-Wg3qdFI8OLuymlgHy0vicQ-1; Thu, 24 Feb 2022 12:41:17 -0500 X-MC-Unique: Wg3qdFI8OLuymlgHy0vicQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 70B5E80573C; Thu, 24 Feb 2022 17:41:14 +0000 (UTC) Received: from starship (unknown [10.40.195.190]) by smtp.corp.redhat.com (Postfix) with ESMTP id E50D51077CBF; Thu, 24 Feb 2022 17:41:11 +0000 (UTC) Message-ID: <55c391a51bf6b7d3927493ff56333e9846e04a4a.camel@redhat.com> Subject: Re: [RFC PATCH 08/13] KVM: SVM: Do not update logical APIC ID table when in x2APIC mode From: Maxim Levitsky To: Suravee Suthikulpanit , linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: pbonzini@redhat.com, seanjc@google.com, joro@8bytes.org, jon.grimm@amd.com, wei.huang2@amd.com, terry.bowman@amd.com Date: Thu, 24 Feb 2022 19:41:10 +0200 In-Reply-To: <20220221021922.733373-9-suravee.suthikulpanit@amd.com> References: <20220221021922.733373-1-suravee.suthikulpanit@amd.com> <20220221021922.733373-9-suravee.suthikulpanit@amd.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2022-02-20 at 20:19 -0600, Suravee Suthikulpanit wrote: > In X2APIC mode the Logical Destination Register is read-only, > which provides a fixed mapping between the logical and physical > APIC IDs. Therefore, there is no Logical APIC ID table in X2AVIC > and the processor uses the X2APIC ID in the backing page to create > a vCPU’s logical ID. > > Therefore, add logic to check x2APIC mode before updating logical > APIC ID table. > > Signed-off-by: Suravee Suthikulpanit > --- > arch/x86/kvm/svm/avic.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c > index 215d8a7dbc1d..55b3b703b93b 100644 > --- a/arch/x86/kvm/svm/avic.c > +++ b/arch/x86/kvm/svm/avic.c > @@ -417,6 +417,10 @@ static int avic_ldr_write(struct kvm_vcpu *vcpu, u8 g_physical_id, u32 ldr) > bool flat; > u32 *entry, new_entry; > > + /* Note: x2AVIC does not use logical APIC ID table */ > + if (apic_x2apic_mode(vcpu->arch.apic)) > + return 0; > + > flat = kvm_lapic_get_reg(vcpu->arch.apic, APIC_DFR) == APIC_DFR_FLAT; > entry = avic_get_logical_id_entry(vcpu, ldr, flat); > if (!entry) > @@ -435,8 +439,13 @@ static void avic_invalidate_logical_id_entry(struct kvm_vcpu *vcpu) > { > struct vcpu_svm *svm = to_svm(vcpu); > bool flat = svm->dfr_reg == APIC_DFR_FLAT; > - u32 *entry = avic_get_logical_id_entry(vcpu, svm->ldr_reg, flat); > + u32 *entry; > + > + /* Note: x2AVIC does not use logical APIC ID table */ > + if (apic_x2apic_mode(vcpu->arch.apic)) > + return; > > + entry = avic_get_logical_id_entry(vcpu, svm->ldr_reg, flat); > if (entry) > clear_bit(AVIC_LOGICAL_ID_ENTRY_VALID_BIT, (unsigned long *)entry); > } Here actually the good apic_x2apic_mode was used. However, shouldn't we inject #GP in avic_ldr_write to make this read realy read-only? It might be too late to do so here, since most AVIC writes are trap like. Thus we need to make the msr that corresponds to LDR to be write protected in the msr bitmap, and inject #GP when write it attempted. Then we can add WARN_ON in this function for this case instead. Best regards, Maxim Levitsky