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;
Subject: Re: kexec reboot fails with extra wbinvd introduced for AME SME
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        Dave Young <dyoung@redhat.com>
Cc:     Yu Chen <yu.c.chen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Juergen Gross <jgross@suse.com>,
        Tony Luck <tony.luck@intel.com>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Borislav Petkov <bp@alien8.de>,
        Rui Zhang <rui.zhang@intel.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Ingo Molnar <mingo@kernel.org>,
        Kexec Mailing List <kexec@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        ebiederm@redhat.com, Tom Lendacky <thomas.lendacky@amd.com>,
        Baoquan He <bhe@redhat.com>
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>
 <CA+55aFxCuz2K_kE3Huu3Ar32LVmWav__2CPL_=zs2g0devx9-Q@mail.gmail.com>
 <20180118014705.GA1812@dhcp-128-65.nay.redhat.com>
 <CA+55aFzc9eXKOdhS-ygQPbr0_N84d8iE8WbSGOWmpJXr1rvDjQ@mail.gmail.com>
From:   Arjan van de Ven <arjan@linux.intel.com>
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: <CA+55aFzc9eXKOdhS-ygQPbr0_N84d8iE8WbSGOWmpJXr1rvDjQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> 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.