| 2018-06-18 14:15:43 |
Kashyap Chamarthy |
bug |
|
|
added bug |
| 2018-06-18 14:16:27 |
Kashyap Chamarthy |
bug |
|
|
added subscriber Matthew Booth |
| 2018-06-18 14:22:28 |
Kashyap Chamarthy |
tags |
|
queens-backport-potential |
|
| 2018-06-18 14:25:06 |
Kashyap Chamarthy |
tags |
queens-backport-potential |
queens-backport-potential security |
|
| 2018-06-18 14:28:03 |
Kashyap Chamarthy |
tags |
queens-backport-potential security |
pike-backport-potential queens-backport-potential security |
|
| 2018-06-18 15:09:15 |
Kashyap Chamarthy |
description |
In addition to the existing 'virt-ssbd', future AMD CPUs will have _two_
ways to deal with SSBD (Speculative Store Bypass Disable). To that AMD
will be introducing two more[1][2] CPU flags:
amd-ssbd
amdb-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssbd', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssbd', if
available, in preference to 'virt-ssbd'."
- It safe to use 'amd-ssbd' (it is an architectural method for a guest
to do SSBD) in a guest which can be live migrated between different
generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
In addition to the existing 'virt-ssbd', future AMD CPUs will have
another (architectural) way to deal with SSBD (Speculative Store Bypass
Disable), via the CPU flag: 'amd-ssbd'.
Furthermore, future AMD CPUs also will expose a mechanism to tell the
guest that the "Speculative Store Bypass Disable" (SSBD) is not needed
and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb'
In summary, two new flags are[1][2]:
amd-ssbd
amdb-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssbd', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssbd', if
available, in preference to 'virt-ssbd'."
- It safe to use 'amd-ssbd' (it is an architectural method for a guest
to do SSBD) in a guest which can be live migrated between different
generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
nominated for series |
|
nova/ocata |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
bug task added |
|
nova/ocata |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
nominated for series |
|
nova/pike |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
bug task added |
|
nova/pike |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
nominated for series |
|
nova/queens |
|
| 2018-06-18 23:11:59 |
Matt Riedemann |
bug task added |
|
nova/queens |
|
| 2018-06-18 23:12:09 |
Matt Riedemann |
nova: status |
New |
Won't Fix |
|
| 2018-06-18 23:12:15 |
Matt Riedemann |
nova/pike: status |
New |
Confirmed |
|
| 2018-06-18 23:12:18 |
Matt Riedemann |
nova/queens: status |
New |
Confirmed |
|
| 2018-06-18 23:12:24 |
Matt Riedemann |
nova/pike: importance |
Undecided |
High |
|
| 2018-06-18 23:12:28 |
Matt Riedemann |
nova/queens: importance |
Undecided |
High |
|
| 2018-06-18 23:12:31 |
Matt Riedemann |
nova/queens: assignee |
|
Dan Smith (danms) |
|
| 2018-06-18 23:12:37 |
Matt Riedemann |
nova/ocata: status |
New |
Confirmed |
|
| 2018-06-18 23:12:40 |
Matt Riedemann |
nova/queens: status |
Confirmed |
In Progress |
|
| 2018-06-18 23:12:44 |
Matt Riedemann |
nova/ocata: importance |
Undecided |
High |
|
| 2018-06-19 07:50:49 |
Kashyap Chamarthy |
description |
In addition to the existing 'virt-ssbd', future AMD CPUs will have
another (architectural) way to deal with SSBD (Speculative Store Bypass
Disable), via the CPU flag: 'amd-ssbd'.
Furthermore, future AMD CPUs also will expose a mechanism to tell the
guest that the "Speculative Store Bypass Disable" (SSBD) is not needed
and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb'
In summary, two new flags are[1][2]:
amd-ssbd
amdb-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssbd', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssbd', if
available, in preference to 'virt-ssbd'."
- It safe to use 'amd-ssbd' (it is an architectural method for a guest
to do SSBD) in a guest which can be live migrated between different
generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
In addition to the existing 'virt-ssbd', future AMD CPUs will have
another (architectural) way to deal with SSBD (Speculative Store Bypass
Disable), via the CPU flag: 'amd-ssb'.
Furthermore, future AMD CPUs also will expose a mechanism to tell the
guest that the "Speculative Store Bypass Disable" (SSBD) is not needed
and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb'
In summary, two new flags are[1][2]:
amd-ssb
amdb-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssb', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssb' isn't present. The 'amd-ssb' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssb', if
available, in preference to 'virt-ssbd'."
- It safe to use 'amd-ssb' (it is an architectural method for a guest
to do SSBD) in a guest which can be live migrated between different
generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
|
| 2018-06-19 07:51:16 |
Kashyap Chamarthy |
summary |
Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd-no-ssb') |
Whitelist two more SSBD-related CPU flags for AMD ('amd-ssb', 'amd-no-ssb') |
|
| 2018-06-19 14:03:35 |
Kashyap Chamarthy |
summary |
Whitelist two more SSBD-related CPU flags for AMD ('amd-ssb', 'amd-no-ssb') |
Whitelist two more SSBD-related CPU flags for AMD ('amd-ssbd', 'amd-no-ssb') |
|
| 2018-06-19 14:08:14 |
Kashyap Chamarthy |
description |
In addition to the existing 'virt-ssbd', future AMD CPUs will have
another (architectural) way to deal with SSBD (Speculative Store Bypass
Disable), via the CPU flag: 'amd-ssb'.
Furthermore, future AMD CPUs also will expose a mechanism to tell the
guest that the "Speculative Store Bypass Disable" (SSBD) is not needed
and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb'
In summary, two new flags are[1][2]:
amd-ssb
amdb-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssb', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssb' isn't present. The 'amd-ssb' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssb', if
available, in preference to 'virt-ssbd'."
- It safe to use 'amd-ssb' (it is an architectural method for a guest
to do SSBD) in a guest which can be live migrated between different
generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
In addition to the existing 'virt-ssbd', future AMD CPUs will have
another (architectural) way to deal with SSBD (Speculative Store Bypass
Disable), via the CPU flag: 'amd-ssbd'.
Furthermore, future AMD CPUs also will expose a mechanism to tell the
guest that the "Speculative Store Bypass Disable" (SSBD) is not needed
and that the CPU is all good. This is via the CPU flag: 'amd-no-ssb'
In summary, two new flags are[1][2]:
amd-ssbd
amd-no-ssb
It is recommended to add the above two flags to the whitelist of Nova's
`cpu_model_extra_flags` config attribute -- for stable branches (Queens,
Pike and Ocata).
For Rocky and above release, no such white-listing is required, since we
allow free-form CPU flags[3].
* * *
Additional notes (from the QEMU mailing list thread[4]) related to
performance and live migration:
- tl;dr: On an AMD Compute node, a guest should be presented with
'amd-ssbd', if available, in preference to 'virt-ssbd'.
Details: Tom Lendacky from AMD writes[4] -- "The idea behind
'virt-ssbd' was to provide an architectural method for a guest to do
SSBD when 'amd-ssbd' isn't present. The 'amd-ssbd' feature will use
SPEC_CTRL which is intended to not be intercepted and will be fast.
The use of 'virt-ssbd' will always be intercepted and therefore will
not be as fast. So a guest should be presented with 'amd-ssbd', if
available, in preference to 'virt-ssbd'."
- It is safe to use 'amd-ssbd' (it is an architectural method for
guest to do SSBD) in a guest which can be live migrated between
different generations/families of AMD CPU.
[1] libvirt patch:
https://www.redhat.com/archives/libvir-list/2018-June/msg01111.html
[2] QEMU patch:
https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00222.html
[3] http://git.openstack.org/cgit/openstack/nova/commit/?id=cc27a20 --
libvirt: Lift the restriction of choices for `cpu_model_extra_flags`
[4] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg02301.html |
|
| 2018-06-22 20:14:24 |
OpenStack Infra |
nova/queens: status |
In Progress |
Fix Committed |
|
| 2018-06-22 20:24:58 |
OpenStack Infra |
nova/pike: status |
Confirmed |
In Progress |
|
| 2018-06-22 20:24:58 |
OpenStack Infra |
nova/pike: assignee |
|
Dan Smith (danms) |
|
| 2018-06-25 04:53:25 |
OpenStack Infra |
nova/pike: status |
In Progress |
Fix Committed |
|
| 2018-10-02 16:06:31 |
OpenStack Infra |
nova/ocata: status |
Confirmed |
In Progress |
|
| 2018-10-02 16:06:31 |
OpenStack Infra |
nova/ocata: assignee |
|
Elod Illes (elod-illes) |
|
| 2018-10-03 15:15:11 |
OpenStack Infra |
nova/ocata: status |
In Progress |
Fix Committed |
|
