From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:50205 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbeDEMTN (ORCPT ); Thu, 5 Apr 2018 08:19:13 -0400 Subject: Re: [Xen-devel] Patches for stable To: George Dunlap Cc: Greg KH , xen-devel , Boris Ostrovsky , stable References: <20180404142702.GA20460@kroah.com> <20180404144644.GA22656@kroah.com> <20180404154201.GA31981@kroah.com> <9cd0be43-6380-f5a0-0427-7f75fca966a9@suse.com> <20180405063314.GC5431@kroah.com> <20180405071448.GA9183@kroah.com> From: Juergen Gross Message-ID: <950f2f68-04ef-bf4d-fa61-afa9bdc918e4@suse.com> Date: Thu, 5 Apr 2018 14:19:10 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 05/04/18 12:06, George Dunlap wrote: > On Thu, Apr 5, 2018 at 9:00 AM, Juergen Gross 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