[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."
On 11/04/17 15:22, Boris Ostrovsky wrote: > > > On 04/11/2017 05:53 AM, Andrew Cooper wrote: >> On 10/04/17 19:48, Boris Ostrovsky wrote: >>>>> The following is meant as a real question without any >>>>> prejudice: >>>>> >>>>> How old a Xen version do we want to support in the Linux >>>>> kernel? >>>>> >>>>> - Only those being still maintained (meaning getting security >>>>> fixes) >>> Definitely not this. 4.4 is the oldest version receiving official >>> XSA patches and it's only 3 years old. >>> >>>>> - Versions max. X years after getting last security fixes >>>>> (what value of X?) - From version Y on (what value of Y?) - >>>>> All versions which we can think of >>>>> >>>>> I think we should answer this question in order to know what >>>>> we can remove in the Linux kernel without breaking >>>>> something. >>>> Ideally, "All versions which we can think of", unless it >>>> becomes too difficult. In that case, I would switch to "From >>>> version Y" where Y is not troublesome to support (and older >>>> than the oldest supported Xen release). >>> So Oracle, for example, officially supports its virtualization >>> product for 8 to 10 years. >>> >>> Which means that 10 years after a product is released it is >>> possible to see new version of Linux on such a product (although >>> realistically vendors may generally support more limited sets of >>> guests). >>> >>> If we are to follow this line of reasoning Xen 3.4 needs to be >>> supported --- it was released in 2009. >> >> Citrix XenServer is also 10 years. >> >> From what I understand, SUSE are still supporting Xen 3.2 based >> products, which is the same kind of vintage. > > > I think the right thing is indeed to revert 72a9b186292 (and > therefore da72ff5bfcb02). Any objections? For the end result: depends. Is there a real error or not? KarimAllah wrote that his concerns are of a theoretical nature as xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here? For just reverting the two commits: yes, as there would be conflicts with already applied patches, especially the pv isolation patches by Vitaly and pvh v1 removal. So in case we need a revert I'd ask KarimAllah to send a fixup patch restoring the state before 72a9b186292 while respecting the new structure to be found on the for-linus-4.12 branch of xen/tip. > The only possible remaining issue is that kernels not using vector > callbacks running on post-4.0 Xen won't work. But we always use > callbacks if they are available (and they are post 4.0). I guess this is a non-issue, as it worked until 4.9. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |