Received: by 2002:a05:6358:16cc:b0:ea:6187:17c9 with SMTP id r12csp8022909rwl; Tue, 10 Jan 2023 08:09:19 -0800 (PST) X-Google-Smtp-Source: AMrXdXsj9JexpH8h+vL01RTF1sPDPS8YVct1DPnPHKg9HqahIJ+NuqXBPBMY8Y832q7dPNayOQBm X-Received: by 2002:a17:907:8c0c:b0:7fd:f1b5:7fd5 with SMTP id ta12-20020a1709078c0c00b007fdf1b57fd5mr62439123ejc.19.1673366958858; Tue, 10 Jan 2023 08:09:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673366958; cv=none; d=google.com; s=arc-20160816; b=Oofl+MxXvvG1JfI9km6kbEtAt0S2etpHbmNgHafyOwLxaQTfjBC2aRizlHWaqlJ1Ug XkHGf8qhd6Ts/etcLWZW+BzH/2Xusj3q/gW5KHlfrfRJs+bYWPiSmDy+4BqnSnEAibQ7 /ccQnEeZ4aQNi+Rivqd9Yo890f+JGVVuWV3BYQQKhA77grdP9o5MfpCp21PRjT0IQJ2H lmgG+a8MFTEB8805pddyhUnJ5f7dSQd/WQo8o8qF7EEwkEZRBxRocQV3YZFatI2sIi/E ZizzdOyObWyCY0+bdDzhJ4vU6tqnn4K7ZlYpUR9iSVI+4I3LLY1kHDpPYbW9hKcWoTP6 ci3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KoTc3COLjlM3JIN7L4+YuzmHqsIzPz2//77xFuiUH5g=; b=u8wg8IH642erPM9zvLBlF5e2FhaF7O+5d3aHs+z2U/CKtadBeavatayYbYiCXJ5eZi SrPmHsuo/wQH1s8PjuGXkNzXZVoGA6V2d7P1CrGpFX3or6lzAmjDSP00WnzdwZM5JuYJ kh43nz/TTo3Zpekn83MSGrh0aOyaOPIsaTWUbozmXtLM5hjJFqn6iIB2C0W1+x0jQYpK mdfzLFQ8WScubk3RxKSR+78N1HChq1Jlzv6a4vlZWJ0DdXc7PKdRm+sgo+afX63NGDfO R35hys28/+iPub6k3eapcvJKG247bydJXUskkrZvV2HNqEMKI7jRdWEzQXGgtMhHO6Kl Vx9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=n25yncwb; 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=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xg11-20020a170907320b00b007c122a681d7si12299316ejb.757.2023.01.10.08.09.05; Tue, 10 Jan 2023 08:09:18 -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=@alien8.de header.s=dkim header.b=n25yncwb; 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=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231963AbjAJQGH (ORCPT + 53 others); Tue, 10 Jan 2023 11:06:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231928AbjAJQFa (ORCPT ); Tue, 10 Jan 2023 11:05:30 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF685C4A; Tue, 10 Jan 2023 08:05:28 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 1D7DD1EC05F1; Tue, 10 Jan 2023 17:05:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1673366727; 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:in-reply-to:in-reply-to: references:references; bh=KoTc3COLjlM3JIN7L4+YuzmHqsIzPz2//77xFuiUH5g=; b=n25yncwbwSkh0JTwEymRYcujCpeAOpfD17Ih889ja8Ov/esVqiwFuK4iS7bvZGpaFuqKDS d1oOM6I3Xmd4gQdViKM2Tobq+XtW3v6DuD/uDQRIwBlmbhNtEAOZ8MhbAQca7rBBu595uv rS86SbyOR4y/LEYvaH3rwz7nwTvJnfI= Date: Tue, 10 Jan 2023 17:05:21 +0100 From: Borislav Petkov To: Alexey Kardashevskiy Cc: kvm@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, Venu Busireddy , Tony Luck , Tom Lendacky , Thomas Gleixner , Sean Christopherson , Sandipan Das , Peter Zijlstra , Pawan Gupta , Paolo Bonzini , Michael Roth , Mario Limonciello , Jan Kara , Ingo Molnar , Huang Rui , Dave Hansen , Daniel Sneddon , Brijesh Singh , Arnaldo Carvalho de Melo , Andrew Cooper , Alexander Shishkin , Adrian Hunter , "Jason A. Donenfeld" , "H. Peter Anvin" Subject: Re: [PATCH kernel v2 1/3] x86/amd: Cache values in percpu variables Message-ID: References: <20221209043804.942352-1-aik@amd.com> <20221209043804.942352-2-aik@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20221209043804.942352-2-aik@amd.com> X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS 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 Fri, Dec 09, 2022 at 03:38:02PM +1100, Alexey Kardashevskiy wrote: Make that Subject: "x86/amd: Cache debug register values in percpu variables" to make it less generic and more specific as to what you're doing. > Reading DR[0-3]_ADDR_MASK MSRs takes about 250 cycles which is going to > be noticeable with the AMD KVM SEV-ES DebugSwap feature enabled. > KVM is going to store host's DR[0-3] and DR[0-3]_ADDR_MASK before > switching to a guest; the hardware is going to swap these on VMRUN > and VMEXIT. > > Store MSR values passsed to set_dr_addr_mask() in percpu values s/values/variables/ Unknown word [passsed] in commit message. Use a spellchecker pls. > (when changed) and return them via new amd_get_dr_addr_mask(). > The gain here is about 10x. 10x when reading percpu vars vs MSR reads? Oh well. > As amd_set_dr_addr_mask() uses the array too, change the @dr type to > unsigned to avoid checking for <0. I feel ya but that function will warn once, return 0 when the @dr number is outta bounds and that 0 will still get used as an address mask. I think you really wanna return negative on error and the caller should not continue in that case. > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index c75d75b9f11a..9ac5a19f89b9 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -1158,24 +1158,41 @@ static bool cpu_has_amd_erratum(struct cpuinfo_x86 *cpu, const int *erratum) > return false; > } > > -void set_dr_addr_mask(unsigned long mask, int dr) > +DEFINE_PER_CPU_READ_MOSTLY(unsigned long[4], amd_dr_addr_mask); static > + > +static unsigned int amd_msr_dr_addr_masks[] = { > + MSR_F16H_DR0_ADDR_MASK, > + MSR_F16H_DR1_ADDR_MASK - 1 + 1, - 1 + 1 ? Why? Because of the DR0 and then DR1 being in a different MSR range? Who cares, make it simple: MSR_F16H_DR0_ADDR_MASK, MSR_F16H_DR1_ADDR_MASK, MSR_F16H_DR1_ADDR_MASK + 1, MSR_F16H_DR1_ADDR_MASK + 2 and add a comment if you want to denote the non-contiguous range but meh. > + MSR_F16H_DR1_ADDR_MASK - 1 + 2, > + MSR_F16H_DR1_ADDR_MASK - 1 + 3 > +}; > + > +void set_dr_addr_mask(unsigned long mask, unsigned int dr) > { > - if (!boot_cpu_has(X86_FEATURE_BPEXT)) > + if (!cpu_feature_enabled(X86_FEATURE_BPEXT)) > return; > > - switch (dr) { > - case 0: > - wrmsr(MSR_F16H_DR0_ADDR_MASK, mask, 0); > - break; > - case 1: > - case 2: > - case 3: > - wrmsr(MSR_F16H_DR1_ADDR_MASK - 1 + dr, mask, 0); > - break; > - default: > - break; > - } > + if (WARN_ON_ONCE(dr >= ARRAY_SIZE(amd_msr_dr_addr_masks))) > + return; > + > + if (per_cpu(amd_dr_addr_mask, smp_processor_id())[dr] == mask) Do that at function entry: int cpu = smp_processor_id(); and use cpu here. > + return; > + > + wrmsr(amd_msr_dr_addr_masks[dr], mask, 0); > + per_cpu(amd_dr_addr_mask, smp_processor_id())[dr] = mask; > +} Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette