| Message ID | 20180118020157.25401-1-ehabkost@redhat.com |
|---|---|
| Headers | show |
| Series | x86 queue, 2018-01-17 | expand |
On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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
On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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/
On 01/23/2018 09:40 AM, Christian Ehrhardt wrote: > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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). Not sure about a 2.10.3?
On Tue, 23 Jan 2018 10:59:39 +0100 Christian Borntraeger <borntraeger@de.ibm.com> wrote: > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote: > > On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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 note that we will need a headers update for 2.11.1. > > Not sure about a 2.10.3? I'm not sure how far back we want to do stable changes (the further back, the more likely it is that the patches need some massaging). Also, I'm still not quite sure what the intended consumers are for our stable trees.
On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger <borntraeger@de.ibm.com> wrote: > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote: >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: >>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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. cu Christian
On Tue, 23 Jan 2018 11:34:18 +0100 Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger > <borntraeger@de.ibm.com> wrote: > > > > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote: > >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > >>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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.
On 23 January 2018 at 10:34, Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > 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 :-/ AIUI for Arm no QEMU changes should be required -- KVM VMs always use the same CPU type as the host, and the kernel always exposes the same MIDR (main ID register) value to the guest as the host has, and the guest kernel fixes will key off the MIDR. thanks -- PMM
On 23.01.2018 12:14, Peter Maydell wrote: > On 23 January 2018 at 10:34, Christian Ehrhardt > <christian.ehrhardt@canonical.com> wrote: >> 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 :-/ > > AIUI for Arm no QEMU changes should be required -- KVM VMs always > use the same CPU type as the host, and the kernel always exposes > the same MIDR (main ID register) value to the guest as the host has, > and the guest kernel fixes will key off the MIDR. Unrelated, but how can ARM make sure that migration back and forth works reliably? (e.g. from a system with spectre fixes to a system without spectre fixes) Thanks! > > thanks > -- PMM >
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 <peter.maydell@linaro.org> wrote: > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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 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). 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.
Quoting Cornelia Huck (2018-01-23 04:50:45) > On Tue, 23 Jan 2018 11:34:18 +0100 > Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote: > > > On Tue, Jan 23, 2018 at 10:59 AM, Christian Borntraeger > > <borntraeger@de.ibm.com> wrote: > > > > > > > > > On 01/23/2018 09:40 AM, Christian Ehrhardt wrote: > > >> On Thu, Jan 18, 2018 at 2:51 PM, Peter Maydell <peter.maydell@linaro.org> wrote: > > >>> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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.
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 <peter.maydell@linaro.org> wrote: > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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. 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. > > 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.
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 <peter.maydell@linaro.org> wrote: > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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 >
On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote: > 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 <peter.maydell@linaro.org> wrote: > > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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..) Well, who exactly is the audience for -stable? Doesn't it include people who run (or let their users run) Windows or RHEL 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? The flag names and MSR code (included in this pull request) are a requirement of the new CPU models. So it's possible to have just the flag names, or have both the flag names and the new CPU models. If people are able to edit the QEMU command-line or libvirt domain XML, they can enable the flags manually and this will be enough for them (so the new CPU models won't be a requirement). The difference is that picking a CPU model is easier than enabling CPU flags manually, and some management systems don't even allow users to configure individual CPU flags (that's why I included the -IBRS CPU models in the tree). > > > > > > > > > > > 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 > > >
Quoting Eduardo Habkost (2018-01-25 19:29:50) > On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote: > > 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 <peter.maydell@linaro.org> wrote: > > > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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..) > > Well, who exactly is the audience for -stable? Doesn't it > include people who run (or let their users run) Windows or RHEL > guests? Yes, I just think in most cases they'll likely be expecting an updated QEMU through their distro, and distros, outside of their own guest types (and even then), would probably prefer to roll it out once for everyone based on what will be landing upstream. > > > > > > > > > > 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? > > The flag names and MSR code (included in this pull request) are a > requirement of the new CPU models. So it's possible to have just > the flag names, or have both the flag names and the new CPU > models. > > If people are able to edit the QEMU command-line or libvirt > domain XML, they can enable the flags manually and this will be > enough for them (so the new CPU models won't be a requirement). > The difference is that picking a CPU model is easier than > enabling CPU flags manually, and some management systems don't > even allow users to configure individual CPU flags (that's why I > included the -IBRS CPU models in the tree). Ok, makes sense. From a stable perspective it seems reasonable to have both then. Is that where you're leaning on the upstream side? If so I'll go ahead and pull these in for stable and pull in your proposed changes when they become available (FWIW this series applies cleanly to current stable tree so not expecting much extra work there). > > > > > > > > > > > > > > > > > > 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 > > > > > > > -- > Eduardo >
On Fri, Jan 26, 2018 at 10:28:52AM -0600, Michael Roth wrote: > Quoting Eduardo Habkost (2018-01-25 19:29:50) > > On Tue, Jan 23, 2018 at 03:33:56PM -0600, Michael Roth wrote: > > > 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 <peter.maydell@linaro.org> wrote: > > > > > > >> On 18 January 2018 at 02:01, Eduardo Habkost <ehabkost@redhat.com> 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..) > > > > Well, who exactly is the audience for -stable? Doesn't it > > include people who run (or let their users run) Windows or RHEL > > guests? > > Yes, I just think in most cases they'll likely be expecting an updated > QEMU through their distro, and distros, outside of their own guest types > (and even then), would probably prefer to roll it out once for everyone > based on what will be landing upstream. > > > > > > > > > > > > > > > > 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? > > > > The flag names and MSR code (included in this pull request) are a > > requirement of the new CPU models. So it's possible to have just > > the flag names, or have both the flag names and the new CPU > > models. > > > > If people are able to edit the QEMU command-line or libvirt > > domain XML, they can enable the flags manually and this will be > > enough for them (so the new CPU models won't be a requirement). > > The difference is that picking a CPU model is easier than > > enabling CPU flags manually, and some management systems don't > > even allow users to configure individual CPU flags (that's why I > > included the -IBRS CPU models in the tree). > > Ok, makes sense. From a stable perspective it seems reasonable to have > both then. Is that where you're leaning on the upstream side? Yes. The -IBRS CPU models are nice to have even if it's just to avoid user confusion. > > If so I'll go ahead and pull these in for stable and pull in your > proposed changes when they become available (FWIW this series applies > cleanly to current stable tree so not expecting much extra work there). It looks like there's some confusion here: I don't have additional proposed changes; the flag names and MSR code I mentioned are already merged on master (through this pull request). > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > -- > > Eduardo > >
On 26 January 2018 at 18:08, Eduardo Habkost <ehabkost@redhat.com> wrote: [lots of quoted text] Could you folks try to trim down the quoted text when you're replying to this thread, please? Every time somebody replies to this thread and leaves the original pull request email quoted in it it flags the thread back up onto my "needs my attention" list... thanks -- PMM
Quoting Eduardo Habkost (2018-01-26 12:08:16) > It looks like there's some confusion here: I don't have > additional proposed changes; the flag names and MSR code I > mentioned are already merged on master (through this pull > request). Ah, my mistake, I thought the flags were being proposed as follow-up. Will pull these in as is then. Thanks! > > -- > Eduardo >