On 05/04/18 12:06, George Dunlap wrote:
On Thu, Apr 5, 2018 at 9:00 AM, Juergen Gross jgross@suse.com 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