Re: [Xen-devel] backporting considerations (Re: [PATCH v9 0/9] xen/x86: various XPTI speedups)

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.05.18 at 15:18, <dunlapg@xxxxxxxxx> wrote:
> On Wed, May 16, 2018 at 10:06 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 26.04.18 at 13:33, <jgross@xxxxxxxx> wrote:
>>> Juergen Gross (9):
>>>   x86/xpti: avoid copying L4 page table contents when possible
>>>   xen/x86: add a function for modifying cr3
>>>   xen/x86: support per-domain flag for xpti
>>>   xen/x86: use invpcid for flushing the TLB
>>>   xen/x86: disable global pages for domains with XPTI active
>>>   xen/x86: use flag byte for decision whether xen_cr3 is valid
>>>   xen/x86: convert pv_guest_cr4_to_real_cr4() to a function
>>>   xen/x86: add some cr3 helpers
>>>   xen/x86: use PCID feature
>>
>> This being a performance improvement rather than a plain bug fix series,
>> I'm not entirely certain about backporting here. My current thinking is to
>> put this into 4.10 (Jürgen was kind enough to do the backporting work
>> already), but not into any older trees. Otoh at SUSE we already have
>> this in our 4.9-based branch as well, and if other consumers of that or
>> the 4.8 branch would mostly agree it should go there, I could certainly
>> be convinced.
> 
> Turning on XPTI causes a pretty large regression in performance; and
> these reduce that regression significantly.  I'm pretty sure that most
> downstreams will end up backporting these anyway (I'm sure CentOS
> will); it's much better to do it officially once, rather than have
> individual downstreams (most of whom do not have hypervisor developers
> maintaining packages) all do it separately.

Thanks, recorded as a data point. I don't, however, consider "do not
have hypervisor developers" as a valid excuse. Package maintainers
ought to be understanding their packages well enough to be capable of
doing such backports if they really think they need them. Basically this
goes back to there being (too many?) downstreams who don't care at
all to contribute anything back.

>> It is imo out of question of putting it into 4.7 or older.
> 
> Is that because of the complexity?  Or because 4.7 is in "security-only" 
> mode?

The latter.

> If the latter, I think the same argument applies: turning on XPTI is a
> requirement for many people, and thus represents a pretty hefty
> performance regression.  While we don't need to backport normal fixes
> to security-only releases, we should certainly try to avoid
> regressions.

I don't think we would have addressed non-security fallout (or other
than really severe regressions) from other security patches in the
past on security only branches. People caring about performance
should upgrade.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel