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

[George Dunlap <dunlapg@xxxxxxxxx>]

On Wed, May 16, 2018 at 3:01 PM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> 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.

I'm not sure exactly who you have in mind here; maybe you mean
downstreams like SuSE and XenServer that sell a product with Xen
inside.  Such companies certainly should have engineers whose job it
is to know the code to one of their key components.

I had in mind downstreams like Fedora, Debian, CentOS, ArchLinux,
XenMadeEasy, and so on; and/or end users who recompile their own
packages based on those; even small projects like QubesOS.  Most of
those people know C and can make a good stab at fixing a patch which
doesn't apply.  But it's not reasonable to expect volunteers
maintaining packages for free, or end users, to be experts in the
hypervisor -- each such port introduces a risk that there will be a
mistake.  And anyway, it seems like a waste of time to make each
downstream using (say) 4.8 duplicate their effort, instead of doing it
once and letting them all share the results.

Having xen packages available for end-users to use *does* contribute
back to the Xen project; and many of the downstreams do contribute
back in many ways, including actual code -- just typically not code in
the hypervisor.

>> 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.

If a security patch, when backported to 4.6, broke some fairly
critical bit of functionality (say,  openvswitch support), you would
oppose a subsequent patch which would fix that regression?

That doesn't seem very reasonable to me.  Users shouldn't have to
choose between being vulnerable to a security issue and losing
functionality which was working at the last release.  Otherwise,
what's the point of having "security supported" releases?

 -George

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