From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:53150 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751979AbeDDQcU (ORCPT ); Wed, 4 Apr 2018 12:32:20 -0400 Subject: Re: Patches for stable To: Greg KH Cc: stable , Boris Ostrovsky , xen-devel References: <20180404142702.GA20460@kroah.com> <20180404144644.GA22656@kroah.com> <20180404154201.GA31981@kroah.com> From: Juergen Gross Message-ID: <9cd0be43-6380-f5a0-0427-7f75fca966a9@suse.com> Date: Wed, 4 Apr 2018 18:32:17 +0200 MIME-Version: 1.0 In-Reply-To: <20180404154201.GA31981@kroah.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 04/04/18 17:42, Greg KH wrote: > On Wed, Apr 04, 2018 at 05:12:32PM +0200, Juergen Gross wrote: >> On 04/04/18 16:46, Greg KH wrote: >>> On Wed, Apr 04, 2018 at 04:30:30PM +0200, Juergen Gross wrote: >>>> On 04/04/18 16:27, Greg KH wrote: >>>>> On Wed, Apr 04, 2018 at 12:38:43PM +0200, Juergen Gross wrote: >>>>>> Please add the patches: >>>>>> >>>>>> commit 038bac2b02989acf1fc938cedcb7944c02672b9f upstream >>>>>> commit dfc9327ab7c99bc13e12106448615efba833886b upstream >>>>>> commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 upstream >>>>>> >>>>>> to the 4.15 and 4.16 stable kernels. >>>>>> >>>>>> Those patches are needed to boot Linux as PVH guest on recent Xen. >>>>> >>>>> So a new feature? Why is that ok for stable kernels? >>>> >>>> It works for kernels since at least 4.11 on Xen 4.10. >>> >>> Great, so what commit caused this to fail? >>> >>> So far, in reading those commits, it sounds like they are "make Linux >>> work again due to changes in Xen". That sounds like a pretty bad thing >>> that Xen did, why do we have to fix up their mess? >> >> Xen did nothing bad. It was the "old" kernel implementation which relied >> on an assumption which happened to be true by accident. Xen had to be >> changed in order to enable grub2 to support PVH mode. >> >> The PVH interface specifies that the RSDP address is available via the >> start_info structure handed over to the PVH boot entry. The Linux kernel >> didn't look at that address, but used the legacy method scanning low >> memory for the RSDP table. As soon as Xen moved the RSDP to a higher >> address (which is covered by the PVH interface specification) the kernel >> could no longer be booted. >> >> So it was clearly a fault of the kernel not complying to the PVH >> specification. > > But it worked previously, so you can't fault Linux here :) > > How many other operating systems broke with this change? None. BSD did it correctly. I guess Mini-OS doesn't count, as it is mostly Xen-internal, but it was not hit by this change. > Not at all. We have a working kernel here. Xen changed and broke > working Linux systems. Now I understand the goal of wanting to also > change Linux to work properly, but these changes are really a new > feature addition if you read the patches. We have a working kernel just by luck. Would your reasoning be the same if the kernel would use an EFI runtime service wrong and an EFI update would lead to a crash? > So why can't Xen just tell all Linux users to update to a more modern > kernel, i.e. 4.17.y and newer, in order to run with the new Xen kernel > if they want to enforce this previously working behavior? Why does > Linux have to be the one to change here? I wanted to have those patches in 4.15, but problems with grub2 (not the upstream version, but multiple distro versions) and the Meltdown/Spectre desaster pushed them back to 4.17. Juergen