VPMU backports for 4.6

VPMU backports for 4.6

[Boris Ostrovsky]

There two patches need to be backported to 4.6

fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
31af0d7 x86/VPMU: check more carefully which bits are allowed to be 
written to MSRs

(The second patch somewhat depends on
     00e248c x86/VPMU: support only versions 2 through 4 of 
architectural performance monitoring
so it may need to be backported as well).

-boris

Re: VPMU backports for 4.6

[Jan Beulich]

>>> On 20.01.16 at 17:12, <boris.ostrovsky@oracle.com> wrote:
> There two patches need to be backported to 4.6
> 
> fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
> 31af0d7 x86/VPMU: check more carefully which bits are allowed to be 
> written to MSRs

"Need to be" is pretty strong for an unsupported subsystem. In fact
I had already considered those and then decided not to take them.
So with you asking for them I'm not really sure what to do...

Jan

Re: VPMU backports for 4.6

[Boris Ostrovsky]

On 01/20/2016 12:13 PM, Jan Beulich wrote:
>>>> On 20.01.16 at 17:12, <boris.ostrovsky@oracle.com> wrote:
>> There two patches need to be backported to 4.6
>>
>> fb424bf x86/VPMU: don't allow any non-zero writes to MSR_IA32_PEBS_ENABLE
>> 31af0d7 x86/VPMU: check more carefully which bits are allowed to be
>> written to MSRs
> "Need to be" is pretty strong for an unsupported subsystem. In fact
> I had already considered those and then decided not to take them.
> So with you asking for them I'm not really sure what to do...

"Need to" may indeed have been a bit too much.

Since there is a potential for crashing the hypervisor I think we should 
have those two in 4.6, even if we don't officially support VPMU.

(As a side --- XSA-163 says that VPMU is "unsupported security-wise". Do 
we make any distinction between a feature being generally or 
security-wise unsupported?)

-boris

Re: VPMU backports for 4.6

[Jan Beulich]

>>> On 20.01.16 at 18:36, <boris.ostrovsky@oracle.com> wrote:
> (As a side --- XSA-163 says that VPMU is "unsupported security-wise". Do 
> we make any distinction between a feature being generally or 
> security-wise unsupported?)

Not sure; considering stable tree maintenance one might imply
general support to be a superset of security support. But I can
easily see other views on that being equally possible/legitimate.

Jan

Re: VPMU backports for 4.6

[Ian Campbell]

On Thu, 2016-01-21 at 00:35 -0700, Jan Beulich wrote:
> > > > On 20.01.16 at 18:36, <boris.ostrovsky@oracle.com> wrote:
> > (As a side --- XSA-163 says that VPMU is "unsupported security-wise".
> > Do 
> > we make any distinction between a feature being generally or 
> > security-wise unsupported?)
> 
> Not sure; considering stable tree maintenance one might imply
> general support to be a superset of security support. But I can
> easily see other views on that being equally possible/legitimate.

I think I would take the view that if it is Unsupported then it is
Unsupported until we explicitly say otherwise.

That doesn't mean we can't backport fixes for issues which people
(presumably those who are working on taking the feature from Unsupported to
Supported in unstable) identify and would like fixed, assuming they don't
impact other Supported features.

I think it is OK for folks working on a currently unsupported feature in
unstable to want to fix known issues even in stable releases, particularly
(although not exclusively) those which would block people from doing
further testing.

Fixing those issues expands the amount of feedback which can be gathered
from users who might be willing to test the feature, but not use a
development version, which helps the developers find the next bug after the
one which was fixed, which will help to move that feature forwards in the
development branch too.

It's also possible that a feature might improve sufficiently that we would
consider it supported from a particular point release. We've done so n the
past, I think, although not always successfully, I'm thinking xsave in and
around the 4.0.x releases.

Ian.