Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp1200635ybl; Wed, 21 Aug 2019 11:36:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqxajwEqigoIINzRlHg+iGpc9fQylRBkFvTs70rT92zv7D+r8Spxn5LTL/l+4ZAZzMxPfyN6 X-Received: by 2002:a17:902:1a4:: with SMTP id b33mr34262237plb.141.1566412579614; Wed, 21 Aug 2019 11:36:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566412579; cv=none; d=google.com; s=arc-20160816; b=AClKcYA2WYzrmn0wbR2hEp7BrfCyCn/mal+U74Wr7KSMsIJG6A+qgV9pl+NyeKSGDA auS+0EFMb0VUSLot2JXNRxOMAHxojk62p8J9wUZROUX1X8OrnZgcyUf8DCbPD5s0vJPu FVR2TOvgHRmayWb7QTIQnKymJwxJRJCgB8/jBMNGNL2EwH7+IzZz8A8GTp6erxVVFUj9 GdmIm4uzzFb6UZLcAhDg59xzBS0B44Osn9xQLncePYix2m5zB/e8q0AwWrboFC+QDpdT nLeVboxLlfmNrhJC3UPZeN4cil2w+iCEH+k4V+zDaBxcXcIWRBFIxLC/lf99Mvn8XD6M cXhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=U0j73cPVRh34Lrf0245wotOvdBLCQmW/De5ZrfHu33k=; b=zBXKbCJQvSBrp12q+iW1Am6gEiIL+2ODO3m4T+FqgNDV/RDOrnGMX4+JRla/vUO3jY 7ky6CyQ+oGQM0+7dOWMX3fada7II1kpBOFBRNn8JHVffruQrFx/O5X2MVpL4gjLXHEU3 QKrfohMysBsOpmEU7ZzN+SUgKjkZAwGJ77nhyoznQPmYWK7JLd4U3QetCAeSNsX0rUjS Av2hHaVhgjVnUumaq13n/A20QXgVd7eDeGvijAf0t4pT1DGmaCV45h/DpxkzLuoywIwO hYY+GptmzhOiiWVhWwB4WKaI0iACTPOq+GXIlBSKFLB643LIvvEx60ci97fGHzevr3ik Do9g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q11si496315pjv.95.2019.08.21.11.36.04; Wed, 21 Aug 2019 11:36:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728840AbfHUSWd (ORCPT + 99 others); Wed, 21 Aug 2019 14:22:33 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:56796 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726858AbfHUSWd (ORCPT ); Wed, 21 Aug 2019 14:22:33 -0400 Received: from p5de0b6c5.dip0.t-ipconnect.de ([93.224.182.197] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1i0VFb-00030J-3e; Wed, 21 Aug 2019 20:22:27 +0200 Date: Wed, 21 Aug 2019 20:22:21 +0200 (CEST) From: Thomas Gleixner To: Bandan Das cc: Ingo Molnar , Borislav Petkov , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/apic: reset LDR in clear_local_APIC In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bandan, On Wed, 21 Aug 2019, Bandan Das wrote: > Thomas Gleixner writes: > So, in KVM: if we make sure that the logical destination map isn't filled up if the virtual > apic is not enabled by software, it really doesn't matter whether the LDR for an inactive CPU > has a stale value. > > In x86/apic: if we make sure that the LDR is 0 or reset, > recalculate_apic_map() will never consider including this cpu in the > logical map. ? > In short, as I mentioned in the patch description, this is really a KVM > bug but it doesn't hurt to clear out the LDR in the guest and then, it > wouldn't need a hypervisor fix. I still needs a hypervisor fix. Taking disabled APICs into account is a bug which has also other consequeces than that particular one. So please don't claim that. It's wrong. If that prevents the APIC bug from triggering on unfixed hypervisors, then this is a nice side effect, but not a solution. > Is this better ? That's way better. So can you please create two patches: 1) Make that bogus bigsmp ldr init empty That one wants a changelog along these lines: - Setting LDR for physical destination mode is pointless - Setting multiple bits in the LDR is wrong Mention how this was discovered and caused the KVM APIC bug to be triggered. Also mention that the change is not there to paper over the KVM APIC bug. The change fixes a bug in the bigsmp APIC code. 2) Clear LDR in in that apic reset function That one wants a changelog along these lines: - Except for x2apic the LDR should be cleared as any other APIC register Mention how this was discovered. Again the change is not there to paper over the KVM APIC bug. It's for correctness sake and valid on its own. Thanks, tglx