Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp290011ybl; Tue, 13 Aug 2019 21:01:35 -0700 (PDT) X-Google-Smtp-Source: APXvYqw1QGfDGbnKdopr6KcynQt0q4p1oeqmAf3+ESTi7KYam4djajsDOzDDFsupILtg58MBBI6s X-Received: by 2002:a17:90a:cb12:: with SMTP id z18mr5014003pjt.82.1565755295137; Tue, 13 Aug 2019 21:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565755295; cv=none; d=google.com; s=arc-20160816; b=QX/Vz0/oeDsEHMy5Ce2zpqULQBbwEjqJg2BLN7hNRsRpRdT2rYCnn2xnfFm/8Sw9MC T7spF+ktjsjJ80ZCdAvd9t6vOAY2okGNkD0akWWvxpm3Ge6xP1hX4K1sevxAQAOiDpkt 2CYUyZL30VApNDYt4WYf1thx5MhWeyOaZNR9QVU6w8Fdk3AwDRSmPgYYBHyC74CYs4s9 8IIwzIoeKxG/mKPWTlGUO3X9yJHYafy6vbAhvxYeuKmxoKBJTiojdwp5vgNyfw8gYoQH Jl1tunpBtgomQY8TqP0vnpfvqy1AzFnw3QYfCyPBgRvyoPmFfRwsXz5MNXivRSSeDFtI HJ+A== 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:message-id:date :subject:cc:to:from; bh=33G6WnheyuacHp/SZe6EzpFwIV+zM9puskLH4+p/uMI=; b=GBR85iPqeZEJ7ts8o4bCbhANDa/IZV9moyWxl9GNdYCdOW2A8B/siQ3zsRRG08T5Aq rKtwb5e+Ot29npSH0xYmhwIRbLtlpdG3ldNU+JyRWsN+/6inoKZ7UhwtU1ZbG999PMJU 7lq4Z6OKxDy11PcpgXDTWEnzLk53CUJK+FvQOm6JgyHZrYayi8yKe6lstoCQL2L82dyl 501DBHbvA7dsLz//mYqCmbQ6e4V7BHXPY/UWI9WM6xcraOKoeonARM7cGAXynCAz+eyJ EhqsfQ94VkSarjpKBy28gL619zq/qoNlz1XAN28ms+EzJYmemGCs3XsKA+WSf2pEMm/m s7RQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si65478937pgg.334.2019.08.13.21.01.16; Tue, 13 Aug 2019 21:01:35 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725895AbfHNEAT (ORCPT + 99 others); Wed, 14 Aug 2019 00:00:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48074 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725262AbfHNEAS (ORCPT ); Wed, 14 Aug 2019 00:00:18 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A23CC30024C4; Wed, 14 Aug 2019 04:00:18 +0000 (UTC) Received: from gigantic.usersys.redhat.com (helium.bos.redhat.com [10.18.17.132]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0564727BAD; Wed, 14 Aug 2019 04:00:17 +0000 (UTC) From: Bandan Das To: Thomas Gleixner , Ingo Molnar , Borislav Petkov Cc: x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] x86/apic: reset LDR in clear_local_APIC Date: Wed, 14 Aug 2019 00:00:17 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 14 Aug 2019 04:00:18 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On a 32 bit RHEL6 guest with greater than 8 cpus, the kdump kernel hangs when calibrating apic. This happens because when apic initializes bigsmp, it also initializes LDR even though it probably wouldn't be used. When booting into kdump, KVM apic incorrectly reads the stale LDR values from the guest while building the logical destination map even for inactive vcpus. While KVM apic can be fixed to ignore apics that haven't been enabled, a simple guest only change can be to just clear out the LDR. Signed-off-by: Bandan Das --- arch/x86/kernel/apic/apic.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c index f5291362da1a..6b9511dc9157 100644 --- a/arch/x86/kernel/apic/apic.c +++ b/arch/x86/kernel/apic/apic.c @@ -1141,6 +1141,10 @@ void clear_local_APIC(void) apic_write(APIC_LVT0, v | APIC_LVT_MASKED); v = apic_read(APIC_LVT1); apic_write(APIC_LVT1, v | APIC_LVT_MASKED); + if (!x2apic_enabled()) { + v = apic_read(APIC_LDR) & ~APIC_LDR_MASK; + apic_write(APIC_LDR, v); + } if (maxlvt >= 4) { v = apic_read(APIC_LVTPC); apic_write(APIC_LVTPC, v | APIC_LVT_MASKED); -- 2.20.1