From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753843AbeARDA5 (ORCPT ); Wed, 17 Jan 2018 22:00:57 -0500 Received: from mga04.intel.com ([192.55.52.120]:50327 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753390AbeARDAu (ORCPT ); Wed, 17 Jan 2018 22:00:50 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,375,1511856000"; d="scan'208";a="196486705" Subject: Re: kexec reboot fails with extra wbinvd introduced for AME SME To: Linus Torvalds , Dave Young Cc: Yu Chen , Thomas Gleixner , Juergen Gross , Tony Luck , Boris Ostrovsky , Borislav Petkov , Rui Zhang , Dan Williams , Ingo Molnar , Kexec Mailing List , Linux Kernel Mailing List , ebiederm@redhat.com, Tom Lendacky , Baoquan He References: <20171213025256.GA1913@dhcp-128-65.nay.redhat.com> <20171213155746.GA29572@yu-chen.sh.intel.com> <20171214092429.GA2004@dhcp-128-65.nay.redhat.com> <20180104031537.GA1819@dhcp-128-65.nay.redhat.com> <20180117072123.GA1866@dhcp-128-65.nay.redhat.com> <20180118014705.GA1812@dhcp-128-65.nay.redhat.com> From: Arjan van de Ven Message-ID: <2f4f1e37-2be0-4609-0e7b-33d67815bd30@linux.intel.com> Date: Wed, 17 Jan 2018 19:00:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Does anybody have any other ideas? the only other weird case that comes to mind; what happens if there's a line dirty in the caches, but the memory is now mapped uncached. (Which could happen if kexec does muck with MTRRs, CR0 or other similar things in weird ways)... not sure what happens in CPU, a machine check for cache inclusion violations is not beyond the imagination and might be lethal this would explain a kexec specific angle versus general normal (but rare) use of wbinvd. other weird case could be cached mmio (not common, but some gpus and the like can do it) with iommu/VT-D in the middle, and during kexec VT-D shutting down the iommu before the wbinvd. This would be... highly odd... but this report already is in highly odd space.