On Tue, Jan 9, 2018 at 9:33 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 09.01.18 at 18:23, <anth...@codemonkey.ws> wrote: >> On Tue, Jan 9, 2018 at 8:52 AM, Stefano Stabellini >> <sstabell...@kernel.org> wrote: >>> On Tue, 9 Jan 2018, George Dunlap wrote: >>>> On Mon, Jan 8, 2018 at 9:01 PM, Rich Persaud <pers...@gmail.com> wrote: >>>> > On a similarly pragmatic note: would a variation of Anthony's vixen patch >> series be suitable for pre-PVH Xen 4.6 - 4.9? These versions are currently >> documented as security-supported (Oct 2018 - July 2020). >>>> >>>> Hmm, Ian's mail seems to be focusing on the idea of checking in a >>>> non-polished series to 4.10, rather than exctly what the content of >>>> that series would be. >>>> >>>> In the IRL conversation that preceeded this mail, the new short-term >>>> target we discussed was: >>>> 1. A 4.10-based shim that could boot either under HVM or PVH >>>> 2. A script that would take an existing PV config, and spit out a) a >>>> bootable ISO with the shim & whatever was needed, and b) a new config >>>> that would boot the same VM, but in HVM mode with the shim >>>> >>>> The script + a 4.10 shim binary *should* allow most PV guests to boot >>>> without any changes whatsoever for most older versions of Xen. >>>> >>>> There are a number of people for whom this won't work; I think we also >>>> need to provide a way to transparently change PV guests into PVshim >>>> guests. But that will necessarily involve significant toolstack >>>> functionality, at which point you might as well backport PVH as well. >>> >>> Yes, there will be a number of people that won't be covered by this fix, >>> including those that can't use HVM/PVH mode because VT-x isn't available >>> at all in their environment. That is the only reason to run PV today. >>> Providing a way to transparently change PV guests into PVshim guests >>> won't cover any of these cases. A more complete workaround to SP3 is >>> along the lines of https://marc.info/?l=xen-devel&m=151509740625690. >>> >>> That said, I realize that we are only trying to do the best we can in a >>> very difficult situation, with very little time in our hands. I agree >>> with Ian that we should commit something unpolished and only partially >>> reviewed soon, even though it doesn't cover a good chunk of the userbase >>> for one reason or another. Even if migration doesn't work, it will still >>> help all that don't require it. It is only a partial fix by nature >>> anyway. >> >> Can people be a bit more explicit about what they think should be done here? >> >> I'm happy to redirect effort to PVH shim if that's what the solution >> is going to be. >> >> I obviously prefer the HVM approach as it works on a broad range of Xen >> versions >> without modification but I'm keen to get something done quickly and >> don't want to >> waste effort. > > From what I've read today, I have no reason to believe the PVH > shim won't work in HVM mode. How would the HVM-only approach > be better in that case?
PVShim doesn't work on HVM. I haven't debugged it but I get an early panic due when constructing dom0. There isn't adequate compatibility in the series too to support anything but very recent Xen versions (for event channels at least). The HVM-only approach is known to work on a wide set of Xen versions. Regards, Anthony Liguori > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
