Re: [Xen-devel] Patches for stable

[Juergen Gross <jgross@xxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel