Re: [Xen-devel] Patches for stable

[Juergen Gross <jgross@xxxxxxxx>]

On 05/04/18 09:14, Greg KH wrote:
> On Thu, Apr 05, 2018 at 09:02:27AM +0200, Juergen Gross wrote:
>> On 05/04/18 08:33, Greg KH wrote:
>>> On Wed, Apr 04, 2018 at 06:32:17PM +0200, Juergen Gross wrote:
>>>> 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.
>>>
>>> Xen doesn't support anything other than BSD, Linux, and Mini-OS? :)
>>
>> No other OS supports PVH mode so far.
>>
>>>>> 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?
>>>
>>> If a UEFI/BIOS update broken working systems, first we would go yell at
>>> the BIOS engineers for doing something foolish (like I am doing here...)
>>> Then we would grumble and go fix the issue in the latest kernel version
>>> and tell people to update to a new release and never buy from that
>>> vendor ever again as they obviously do not care about their users.
>>
>> Even if the kernel wasn't using the EFI interfaces correctly and just
>> worked by accident? Sorry, that's ridiculous.
>>
>>> So, I'll gladly tell everyone who hits this bug, to stop using Xen as
>>> they don't care about their users, and to work around it they have to
>>> use the 4.17 kernel release.
>>
>> The kernel is wrong here. You don't want to take the patches fixing the
>> issue.
> 
> These are not just "patches to fix the issue", they are "patches to add
> new features" that touch core acpi bits, right?  Support for new
> hardware and platforms and such are not normally part of the stable
> kernel patches at all (with the exceptions of tiny patches that add
> device ids and quirks.)

The way the patches are written are the result of requests of the
maintainers (x86, acpi). This way they don't break layering of the
components. I'd be happy to rewrite them for stable kernels if you
like that better.

> That's my main objection here, combined with the obvious one of "Xen
> does not care about their users".

Xen does care. PVH support in Linux is relatively new (the first working
kernel was 4.11), Xen has full PVH guest support since Xen 4.10.

For being able to replace PV mode it is mandatory for PVH to not add
unnecessary performance overhead, as performance is the main reason for
customers to run their guests in PV mode (yes, PV guests _are_ faster,
especially with many vcpus).

It was discovered that placing the RSDP table in low memory is bad for
performance as it adds more memory map holes than necessary. So moving
the RSDP to the same memory area as all other ACPI tables was the
right move and completely compliant to the specified interface. So in
order not to hit performance for future guests it was decided to write
patches for Linux to comply to the interface and move the RSDP. We
hoped to get those patches into stable kernels, too, but it seems we
were wrong.

>> That's rather sad as PVH mode was meant to replace PV in the
>> future, which will remove the need for most of the paravirt ops stuff.
>> You are just shifting that possibility some months further into the
>> future.
> 
> So if you run in PV mode, all is fine, right?  Great, then just use 4.17
> or newer for PVH, what's the issue?  Who cares about this for older
> kernel versions, those are all in running systems that would not be
> changing their version of Xen.

The idea was to be able to use kernel 4.14 or newer for PVH.

As you don't seem to take the patches it will be 4.17, of course.


Juergen

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