Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross <jgross@xxxxxxxx>]

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