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 "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. It's unfortunate that Linux 4.11 didn't follow the spec, but whose fault is that? 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? 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? -George