Re: [qemu-s390x] [Qemu-devel] [PULL 0/8] x86 queue, 2018-01-17

[Michael Roth]

Quoting Cornelia Huck (2018-01-23 04:50:45)
> On Tue, 23 Jan 2018 11:34:18 +0100
> Christian Ehrhardt <address@hidden> wrote:
> 
> > On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger
> > <address@hidden> wrote:
> > >
> > >
> > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote:  
> > >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <address@hidden> wrote:  
> > >>> On 18 January 2018 at 02:01, Eduardo Habkost <address@hidden> wrote:  
> > >>>> The following changes since commit 
> > >>>> 8e5dc9ba49743b46d955ec7dacb04e42ae7ada7c:
> > >>>>
> > >>>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20180116' 
> > >>>> into staging (2018-01-16 17:36:39 +0000)
> > >>>>
> > >>>> are available in the Git repository at:
> > >>>>
> > >>>>   git://github.com/ehabkost/qemu.git tags/x86-pull-request
> > >>>>
> > >>>> for you to fetch changes up to 
> > >>>> 6cfbc54e8903a9bcc0346119949162d040c144c1:
> > >>>>
> > >>>>   i386: Add EPYC-IBPB CPU model (2018-01-17 23:54:39 -0200)
> > >>>>
> > >>>> ----------------------------------------------------------------
> > >>>> x86 queue, 2018-01-17
> > >>>>
> > >>>> Highlight: new CPU models that expose CPU features that guests
> > >>>> can use to mitigate CVE-2017-5715 (Spectre variant #2).
> > >>>>  
> > >>>
> > >>> Applied, thanks.
> > >>>
> > >>> -- PMM
> > >>>  
> > >>
> > >> Hi,
> > >> I was kind of clinging to [1] so far and had the expectation that all
> > >> those would be wrapped up in 2.11.1 once ready.
> > >> I see that the s390x changes are targeted to qemu-stable (well to
> > >> admit I suggested so referring the article above).
> > >> So I'd expected to see this series to show up on qemu-stable as well
> > >> but haven't seen it so far.
> > >>
> > >> Therefore I wanted to ask if there was a change of plans in that
> > >> regard or if it needs just a few days more to see (part of) this
> > >> series on qemu-stable and on its way into 2.11.1?
> > >>
> > >> [1]: https://www.qemu.org/2018/01/04/spectre/  
> > >
> > > Adding Michael,
> > >
> > > Yes, I think it makes sense to have the guest enablement for the spectre
> > > mitigations available in 2.11.1 for all architectures that provide it.
> > > (this queue for x86, Connies pending S390 patches, whatever Power
> > > and arm will do).  
> > 
> > Also adding Suraj for a statement in this regard about his "[QEMU-PPC]
> > [PATCH V5 0/7] target/ppc: Rework spapr_caps" series which I think is
> > the PPC version of all of this right?
> > Not sure who to add for Arm :-/
> > 
> > @Cornelia - the consumers of these stable changes in particular IMHO
> > are Distributions for security updates.
> > Seeing at least one backport into 2.11.1 would be very helpful to
> > avoid issues that would not apply to a forward thinking 2.12 commit.
> > Such a (even short distance) backport being done by the Author would
> > have the lowest risk of such issues creeping in.
> > I'm not so sure on 2.(<11).x  - but one backport at least into the
> > latest release would be very nice to fulfill the [1] announcement
> > referenced above and provide a first release of these important
> > changes available earlier than full 2.12.
> 
> I agree that a backport unto 2.11.x is useful.
> 
> But I still think we should clarify the purpose of our stable tree --
> not necessarily in this thread, though.
> 

Generally the idea is a development cycle's worth of bug/security fixes
that a distro that bases on, say, 2.11, can pull in without any other
changes throughout their stack. Stuff like this is somewhat of an
exceptional case because it doesn't have any benefit to someone who
just drops it into their existing stack, but if it seems likely they'll
become reliant on it then it makes sense. We've done this in the past to
fix stuff like migration breakages that were discovered after release
and required new machine options. Certainly not an ideal situation
though.