On 05/04/18 12:06, George Dunlap wrote:
> On Thu, Apr 5, 2018 at 9:00 AM, Juergen Gross <jgross@xxxxxxxx> wrote:
>>> 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).
>
> I'm afraid I have to agree with Greg here regarding the meaning of
> "supported"; and I remember expressing a similar sentiment when I
> discovered that a recent Linux kernel wouldn't boot on the development
> version of Xen. Either we declare PVH in Linux 4.11-4.16 as
You finally said:
My subsequent response to Roger ("FWIW I can buy this argument") was
meant to indicate I didn't have any more objection to the approach you
guys were planning on taking.
> "supported", in which case we have to maintain backwards compatibility
> and attempt not to break it; or we declare PVH in Linux 4.11-4.16 as
> "tech preview" (retroactively), and Greg should feel free to ignore
> these backports.
I still believe he should take them, as they are correcting a bug in
the kernel.
> It's unfortunate that Linux 4.11 didn't follow the spec, but whose
> fault is that?
Linux? ;-)
I have no problem to admit that the patches adding PVH support to the
Linux kernel were wrong in this regard and I didn't detect that when
reviewing them.
> The fact is, that as it stands, a user could have a perfectly working
> system with Xen 4.10 and a load of PVH guests running stock Linux
> 4.15, and then upgrade to Xen 4.11 and have all those guests break for
> no apparent reason. That's a pretty obnoxious thing to do,
> particularly as we made such a fanfare about Xen 4.10 finally having
> PVH support, and encouraging everyone to go and use it. How are all
> of those users going to feel about Xen?
Point taken.
> Aren't there flags in the binary somewhere that could tell the
> toolstack / Xen whether the kernel in question needs the RSDP table in
> lowmem, or whether it can be put higher?
Not really. Analyzing the binary whether it accesses the rsdp_addr in
the start_info isn't the way to go, IMO.
I've sent a patch to xen-devel adding a quirk flag to the domain's
config to enable the admin special casing such an "old" kernel.
Juergen