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?
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).
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
