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