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

[Michael Roth]

Quoting Eduardo Habkost (2018-01-23 13:31:18)
> On Tue, Jan 23, 2018 at 12:15:27PM -0600, Michael Roth wrote:
> > Quoting Christian Borntraeger (2018-01-23 03:59:39)
> > > 
> > > 
> > > 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).
> > 
> > That's my plan as well, but IIUC the QEMU side of these patches rely on
> > a KVM flag that in turn relies on this series:
> > 
> >   https://lkml.org/lkml/2018/1/20/158
> 
> Actually it depends on:
> https://lkml.org/lkml/2018/1/9/329
> ([PATCH v2 0/8] KVM: x86: expose CVE-2017-5715 ("Spectre variant 2") 
> mitigations to guest)
> 
> The ability to expose IBRS to guests doesn't seem to depend on
> the host kernel using IBRS to protect itself.  But I guess it
> will be easier to merge that code after Linux developers decide
> what they'll do.  Paolo, what's your take on this?
> 
> Note that there are released OSes that use IBRS (Windows and
> RHEL), so even if upstream Linux decide to not rely on IBRS,
> users will probably want to expose IBRS to VMs as soon as KVM
> becomes able to do that.

I didn't really consider that angle, but I think anyone supporting such
guests will tend to be relying on their host distros for the fixes, and
distros will want their own guest types covered as well (looks like RHEL
already has its bases covered in this regard, maybe Hyper-V too WRT to
Windows guests..)

> 
> BUT:
> 
> > 
> > But that's still in RFC and Linus seems to have reservations with the
> > current code. Since coordinating these all this to users/downstreams is
> > somewhat of a mess I was thinking we should accompany the 2.11.1 release
> > with a blog post on the various options/backports/microcode needed 
> > throughout
> > the stack to enable the fixes, but until there's a stable patchset on
> > the linux side I'm not sure there's much worth in putting out the 2.11.1
> > release (if I'm missing something here please let me know).
> 
> I'm inclined to agree.  I merged the -IBRS CPU models expecting
> that the fixes would be included quickly in upstream Linux too,
> but it was not the case.
> 
> To be honest, I don't think adding new CPU models are the proper
> solution for the problem.  They are just a quick solution that
> doesn't require intrusive changes in the management stack.
> 
> Meltdown & Spectre made us painfully aware of limitations of
> management stacks out there (esp. OpenStack): they normally don't
> have an easy mechanism to enable CPU features that are not part
> of an existing CPU model name.  A good management stack would be
> able to use, e.g., "-cpu Westmere,+spec-ctrl" instead of
> "Westmere-IBRS" if it knows all the hosts on a given
> cluster/migration-set/whatever-it-is-called support the feature.
> The same applies to other flags like ibpb and pcid.
> 
> There's work being done on OpenStack to fix this,
> e.g.: https://review.openstack.org/#/c/534384/
> 
> 
> That said, we will probably want to include MSR code and the CPU
> feature flag names (spec-ctrl and ibpb) on the stable branch as
> soon as possible.  This way, people will have the option to
> manually enable those features (or make them automatically
> available using "-cpu host") before a decision is made regarding
> CPU model names.
> 
> I can send a patch series to -stable including only those
> patches, if it makes the work easier.

Will these proposed patches be dropping the model names introduced here
in favor of those flags, or introducing them alongside?

> 
> 
> > 
> > There's also the testing aspect of this, which I'd at least like to cover
> > on the x86 side. I've be doing some basic testing on top of early versions
> > of the IBRS patches and KVM patches, but I'd really like to make sure
> > everything is working on top of what's ultimately going upstream before
> > I commit the release.
> > 
> > In the meantime I've started a staging tree for 2.11.1 here:
> > 
> >   https://github.com/mdroth/qemu/commits/stable-2.11-staging
> > 
> > it doesn't have these patches yet, and given the above I'm not sure it
> > makes sense to try to set a release date yet, but I'll update the tree
> > as we go and post a call-for-patches within a day or so where we can
> > coordinate what else should go in for other archs.
> > 
> > > 
> > > Not sure about a 2.10.3?
> > > 
> > 
> > Out of support as far as stable releases go; will have to leave that one
> > up to the downstreams.
> 
> -- 
> Eduardo
>