* [PATCH 1/3] stackdepot: check depot_index before accessing the stack slab
From: glider @ 2020-02-20 14:19 UTC (permalink / raw)
To: dvyukov, andreyknvl, aryabinin, akpm
Cc: sergey.senozhatsky, arnd, linux-mm, vegard.nossum, elver,
Alexander Potapenko
Avoid crashes on corrupted stack ids.
Despite stack ID corruption may indicate other bugs in the program, we'd
better fail gracefully on such IDs instead of crashing the kernel.
This patch has been previously mailed as part of KMSAN RFC patch series.
Signed-off-by: Alexander Potapenko <glider@google.com>
To: Alexander Potapenko <glider@google.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: linux-mm@kvack.org
---
lib/stackdepot.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index 81c69c08d1d15..a2f6cb900db80 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -202,9 +202,22 @@ unsigned int stack_depot_fetch(depot_stack_handle_t handle,
unsigned long **entries)
{
union handle_parts parts = { .handle = handle };
- void *slab = stack_slabs[parts.slabindex];
+ void *slab;
size_t offset = parts.offset << STACK_ALLOC_ALIGN;
- struct stack_record *stack = slab + offset;
+ struct stack_record *stack;
+
+ if (parts.slabindex > depot_index) {
+ WARN(1, "slab index %d out of bounds (%d) for stack id %08x\n",
+ parts.slabindex, depot_index, handle);
+ *entries = NULL;
+ return 0;
+ }
+ slab = stack_slabs[parts.slabindex];
+ stack = slab + offset;
+ if (!stack) {
+ *entries = NULL;
+ return 0;
+ }
*entries = stack->entries;
return stack->size;
--
2.25.0.265.gbab2e86ba0-goog
^ permalink raw reply related
* [PATCH 2/3] stackdepot: build with -fno-builtin
From: glider @ 2020-02-20 14:19 UTC (permalink / raw)
To: dvyukov, andreyknvl, aryabinin, akpm
Cc: sergey.senozhatsky, arnd, linux-mm, vegard.nossum, elver,
Alexander Potapenko
In-Reply-To: <20200220141916.55455-1-glider@google.com>
Clang may replace stackdepot_memcmp() with a call to instrumented bcmp(),
which is exactly what we wanted to avoid creating stackdepot_memcmp().
Building the file with -fno-builtin prevents such optimizations.
This patch has been previously mailed as part of KMSAN RFC patch series.
Signed-off-by: Alexander Potapenko <glider@google.com>
To: Alexander Potapenko <glider@google.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: linux-mm@kvack.org
---
lib/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/Makefile b/lib/Makefile
index 23ca78d43d247..390e90d2ee88b 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -220,6 +220,10 @@ obj-$(CONFIG_MEMREGION) += memregion.o
obj-$(CONFIG_STMP_DEVICE) += stmp_device.o
obj-$(CONFIG_IRQ_POLL) += irq_poll.o
+# stackdepot.c should not be instrumented or call instrumented functions.
+# Prevent the compiler from calling builtins like memcmp() or bcmp() from this
+# file.
+CFLAGS_stackdepot.o += -fno-builtin
obj-$(CONFIG_STACKDEPOT) += stackdepot.o
KASAN_SANITIZE_stackdepot.o := n
KCOV_INSTRUMENT_stackdepot.o := n
--
2.25.0.265.gbab2e86ba0-goog
^ permalink raw reply related
* [PATCH 3/3] kasan: stackdepot: move filter_irq_stacks() to stackdepot.c
From: glider @ 2020-02-20 14:19 UTC (permalink / raw)
To: dvyukov, andreyknvl, aryabinin, akpm
Cc: sergey.senozhatsky, arnd, linux-mm, vegard.nossum, elver,
Alexander Potapenko
In-Reply-To: <20200220141916.55455-1-glider@google.com>
filter_irq_stacks() can be used by other tools (e.g. KMSAN), so it needs
to be moved to a common location.
lib/stackdepot.c seems a good place, as filter_irq_stacks() is usually
applied to the output of stack_trace_save().
This patch has been previously mailed as part of KMSAN RFC patch series.
Signed-off-by: Alexander Potapenko <glider@google.com>
To: Alexander Potapenko <glider@google.com>
Cc: Vegard Nossum <vegard.nossum@oracle.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Marco Elver <elver@google.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: linux-mm@kvack.org
---
include/linux/stackdepot.h | 2 ++
lib/stackdepot.c | 24 ++++++++++++++++++++++++
mm/kasan/common.c | 23 -----------------------
3 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/include/linux/stackdepot.h b/include/linux/stackdepot.h
index 3efa97d482cbe..24d49c732341a 100644
--- a/include/linux/stackdepot.h
+++ b/include/linux/stackdepot.h
@@ -19,4 +19,6 @@ depot_stack_handle_t stack_depot_save(unsigned long *entries,
unsigned int stack_depot_fetch(depot_stack_handle_t handle,
unsigned long **entries);
+unsigned int filter_irq_stacks(unsigned long *entries, unsigned int nr_entries);
+
#endif
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
index a2f6cb900db80..da5d1880bf343 100644
--- a/lib/stackdepot.c
+++ b/lib/stackdepot.c
@@ -20,6 +20,7 @@
*/
#include <linux/gfp.h>
+#include <linux/interrupt.h>
#include <linux/jhash.h>
#include <linux/kernel.h>
#include <linux/mm.h>
@@ -318,3 +319,26 @@ depot_stack_handle_t stack_depot_save(unsigned long *entries,
return retval;
}
EXPORT_SYMBOL_GPL(stack_depot_save);
+
+static inline int in_irqentry_text(unsigned long ptr)
+{
+ return (ptr >= (unsigned long)&__irqentry_text_start &&
+ ptr < (unsigned long)&__irqentry_text_end) ||
+ (ptr >= (unsigned long)&__softirqentry_text_start &&
+ ptr < (unsigned long)&__softirqentry_text_end);
+}
+
+unsigned int filter_irq_stacks(unsigned long *entries,
+ unsigned int nr_entries)
+{
+ unsigned int i;
+
+ for (i = 0; i < nr_entries; i++) {
+ if (in_irqentry_text(entries[i])) {
+ /* Include the irqentry function into the stack. */
+ return i + 1;
+ }
+ }
+ return nr_entries;
+}
+EXPORT_SYMBOL_GPL(filter_irq_stacks);
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 6aa51723b92b9..92815ef9c80d3 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -15,7 +15,6 @@
*/
#include <linux/export.h>
-#include <linux/interrupt.h>
#include <linux/init.h>
#include <linux/kasan.h>
#include <linux/kernel.h>
@@ -42,28 +41,6 @@
#include "kasan.h"
#include "../slab.h"
-static inline int in_irqentry_text(unsigned long ptr)
-{
- return (ptr >= (unsigned long)&__irqentry_text_start &&
- ptr < (unsigned long)&__irqentry_text_end) ||
- (ptr >= (unsigned long)&__softirqentry_text_start &&
- ptr < (unsigned long)&__softirqentry_text_end);
-}
-
-static inline unsigned int filter_irq_stacks(unsigned long *entries,
- unsigned int nr_entries)
-{
- unsigned int i;
-
- for (i = 0; i < nr_entries; i++) {
- if (in_irqentry_text(entries[i])) {
- /* Include the irqentry function into the stack. */
- return i + 1;
- }
- }
- return nr_entries;
-}
-
static inline depot_stack_handle_t save_stack(gfp_t flags)
{
unsigned long entries[KASAN_STACK_DEPTH];
--
2.25.0.265.gbab2e86ba0-goog
^ permalink raw reply related
* [PATCH v3 0/2] qemu-cpu-models: Convert to rST; document other MSR bits
From: Kashyap Chamarthy @ 2020-02-20 14:19 UTC (permalink / raw)
To: qemu-devel
Cc: peter.maydell, berrange, Eduardo Habkost, kchamart, Paolo Bonzini,
Richard Henderson
In v3:
- Address the comments from Peter Maydell, from here:
https://lists.nongnu.org/archive/html/qemu-devel/2020-02/msg05155.html
This small series does two things:
(1) Convert the original qemu-cpu-models.texi to rST
(2) In a separate patch, incorporate the additional new content from
this:
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg06455.html
([PATCH v3] qemu-cpu-models: Document -noTSX, mds-no, taa-no, and
tsx-ctrl)
Sphinx rendering of the converted doc is here:
https://kashyapc.fedorapeople.org/QEMU_v4.2.0-1301-gb082353c5e_docs/system/qemu-cpu-models.html
Kashyap Chamarthy (2):
docs: Convert qemu-cpu-models.texi to rST
qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl
MAINTAINERS | 2 +-
Makefile | 10 +-
docs/qemu-cpu-models.texi | 677 --------------------------------
docs/system/conf.py | 3 +
docs/system/index.rst | 1 +
docs/system/qemu-cpu-models.rst | 571 +++++++++++++++++++++++++++
qemu-doc.texi | 5 -
7 files changed, 581 insertions(+), 688 deletions(-)
delete mode 100644 docs/qemu-cpu-models.texi
create mode 100644 docs/system/qemu-cpu-models.rst
--
2.21.0
^ permalink raw reply
* [PATCH v3 2/2] qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl
From: Kashyap Chamarthy @ 2020-02-20 14:20 UTC (permalink / raw)
To: qemu-devel
Cc: peter.maydell, berrange, Eduardo Habkost, kchamart, Paolo Bonzini,
Richard Henderson
In-Reply-To: <20200220142001.20774-1-kchamart@redhat.com>
- Add the '-noTSX' variants for CascadeLake and SkyLake.
- Document the three MSR bits: 'mds-no', 'taa-no', and 'tsx-ctrl'
Two confusing things about 'mds-no' (and the first point applies to
the other two MSRs too):
(1) The 'mds-no' bit will _not_ show up in the guest's /proc/cpuinfo.
Rather it is used to fill in the guest's sysfs:
/sys/devices/system/cpu/vulnerabilities/mds:Not affected
Paolo confirmed on IRC as such.
(2) There are _three_ variants[+] of CascadeLake CPUs, with different
stepping levels: 5, 6, and 7. To quote wikichip.org[*]:
"note that while steppings 6 & 7 are fully mitigated, earlier
stepping 5 is not protected against MSBDS, MLPDS, nor MDSUM"
The above is also indicated in the Intel's document[+], as
indicated by "No" under the three columns of MFBDS, MSBDS, and
MLPDS.
I've expressed this in the docs without belabouring the details.
[+] https://software.intel.com/security-software-guidance/insights/processors-affected-microarchitectural-data-sampling
[*] https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake#Key_changes_from_Skylake
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
---
[Retaining parts of the change-log from the Texinfo-variant of this patch,
which is now no-longer needed:
https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg06455.html]
v3:
- Makefile, Sphinx and related fixes (Peter Maydell)
- Address feedback from Paolo
- Add URL to the deep-dive on Intel's MDS
v2:
- Address feedback from DanPB
- Add sections on 'taa-no' and 'tsx-ctrl'
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
docs/system/qemu-cpu-models.rst | 57 +++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/docs/system/qemu-cpu-models.rst b/docs/system/qemu-cpu-models.rst
index a189d6a9da..946e90e1dc 100644
--- a/docs/system/qemu-cpu-models.rst
+++ b/docs/system/qemu-cpu-models.rst
@@ -61,15 +61,24 @@ mixture of host CPU models between machines, if live migration
compatibility is required, use the newest CPU model that is compatible
across all desired hosts.
+* Intel Xeon Processor (Cascade Lake, 2019), with "stepping" levels 6 or
+ 7 only. (The Cascade Lake Xeon processor with *stepping 5 is
+ vulnerable to MDS variants*.)
+
+ * ``Cascadelake-Server``
+ * ``Cascadelake-Server-noTSX``
+
* Intel Xeon Processor (Skylake, 2016)
* ``Skylake-Server``
* ``Skylake-Server-IBRS``
+ * ``Skylake-Server-IBRS-noTSX``
* Intel Core Processor (Skylake, 2015)
* ``Skylake-Client``
* ``Skylake-Client-IBRS``
+ * ``Skylake-Client-noTSX-IBRS}``
* Intel Core Processor (Broadwell, 2014)
@@ -182,6 +191,54 @@ features are included if using "Host passthrough" or "Host model".
Requires the host CPU microcode to support this feature before it
can be used for guest CPUs.
+``mds-no``
+ Recommended to inform the guest OS that the host is *not* vulnerable
+ to any of the MDS variants ([MFBDS] CVE-2018-12130, [MLPDS]
+ CVE-2018-12127, [MSBDS] CVE-2018-12126).
+
+ This is an MSR (Model-Specific Register) feature rather than a CPUID feature,
+ so it will not appear in the Linux ``/proc/cpuinfo`` in the host or
+ guest. Instead, the host kernel uses it to populate the MDS
+ vulnerability file in ``sysfs``.
+
+ So it should only be enabled for VMs if the host reports @code{Not
+ affected} in the ``/sys/devices/system/cpu/vulnerabilities/mds`` file.
+
+``taa-no``
+ Recommended to inform that the guest that the host is ``not``
+ vulnerable to CVE-2019-11135, TSX Asynchronous Abort (TAA).
+
+ This too is an MSR feature, so it does not show up in the Linux
+ ``/proc/cpuinfo`` in the host or guest.
+
+ It should only be enabled for VMs if the host reports ``Not affected``
+ in the ``/sys/devices/system/cpu/vulnerabilities/tsx_async_abort``
+ file.
+
+``tsx-ctrl``
+ Recommended to inform the guest that it can disable the Intel TSX
+ (Transactional Synchronization Extensions) feature; or, if the
+ processor is vulnerable, use the Intel VERW instruction (a
+ processor-level instruction that performs checks on memory access) as
+ a mitigation for the TAA vulnerability. (For details, refer to this
+ `Intel's deep-dive into
+ MDS <https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling>`_.)
+
+ Expose this to the guest OS if and only if: (a) the host has TSX
+ enabled; *and* (b) the guest has ``rtm`` CPU flag enabled.
+
+ By disabling TSX, KVM-based guests can avoid paying the price of
+ mitigting TSX-based attacks.
+
+ Note that ``tsx-ctrl`` too is an MSR feature, so it does not show
+ up in the Linux ``/proc/cpuinfo`` in the host or guest.
+
+ To validate that Intel TSX is indeed disabled for the guest, there are
+ two ways: (a) check for the *absence* of ``rtm`` in the guest's
+ ``/proc/cpuinfo``; or (b) the
+ ``/sys/devices/system/cpu/vulnerabilities/tsx_async_abort`` file in
+ the guest should report ``Mitigation: TSX disabled``.
+
Preferred CPU models for AMD x86 hosts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.21.0
^ permalink raw reply related
* [PATCH v3 1/2] docs: Convert qemu-cpu-models.texi to rST
From: Kashyap Chamarthy @ 2020-02-20 14:20 UTC (permalink / raw)
To: qemu-devel
Cc: peter.maydell, berrange, Eduardo Habkost, kchamart, Paolo Bonzini,
Richard Henderson
In-Reply-To: <20200220142001.20774-1-kchamart@redhat.com>
This doc was originally written by Daniel P. Berrangé
<berrange@redhat.com>, introduced via commit[1]: 2544e9e4aa (docs: add
guidance on configuring CPU models for x86, 2018-06-27).
In this patch:
- 1-1 conversion of Texinfo to rST, besides a couple of minor
tweaks that are too trivial to mention. (Thanks to Stephen
Finucane on IRC for the suggestion to use rST "definition lists"
instead of bullets in some places.)
Further modifications will be done via a separate patch.
- rST and related infra changes: for building the manual page,
Makefile fixes, clean up references to qemu-cpu-models.texi, etc.
[1] https://git.qemu.org/?p=qemu.git;a=commit;h=2544e9e4aa
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
---
v2: Fix rST conversion, man page creation, Makefile changes, et al
(thanks, Peter Maydell)
---
MAINTAINERS | 2 +-
Makefile | 10 +-
docs/qemu-cpu-models.texi | 677 --------------------------------
docs/system/conf.py | 3 +
docs/system/index.rst | 1 +
docs/system/qemu-cpu-models.rst | 514 ++++++++++++++++++++++++
qemu-doc.texi | 5 -
7 files changed, 524 insertions(+), 688 deletions(-)
delete mode 100644 docs/qemu-cpu-models.texi
create mode 100644 docs/system/qemu-cpu-models.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index e72b5e5f69..38bb821034 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -319,7 +319,7 @@ F: tests/tcg/i386/
F: tests/tcg/x86_64/
F: hw/i386/
F: disas/i386.c
-F: docs/qemu-cpu-models.texi
+F: docs/system/qemu-cpu-models.rst
T: git https://github.com/ehabkost/qemu.git x86-next
Xtensa TCG CPUs
diff --git a/Makefile b/Makefile
index 461d40bea6..5377a30d88 100644
--- a/Makefile
+++ b/Makefile
@@ -349,9 +349,9 @@ DOCS+=$(MANUAL_BUILDDIR)/interop/qemu-img.1
DOCS+=$(MANUAL_BUILDDIR)/interop/qemu-nbd.8
DOCS+=$(MANUAL_BUILDDIR)/interop/qemu-ga.8
DOCS+=$(MANUAL_BUILDDIR)/system/qemu-block-drivers.7
+DOCS+=$(MANUAL_BUILDDIR)/system/qemu-cpu-models.7
DOCS+=docs/interop/qemu-qmp-ref.html docs/interop/qemu-qmp-ref.txt docs/interop/qemu-qmp-ref.7
DOCS+=docs/interop/qemu-ga-ref.html docs/interop/qemu-ga-ref.txt docs/interop/qemu-ga-ref.7
-DOCS+=docs/qemu-cpu-models.7
DOCS+=$(MANUAL_BUILDDIR)/index.html
ifdef CONFIG_VIRTFS
DOCS+=$(MANUAL_BUILDDIR)/interop/virtfs-proxy-helper.1
@@ -764,7 +764,6 @@ distclean: clean
rm -f docs/interop/qemu-qmp-ref.txt docs/interop/qemu-ga-ref.txt
rm -f docs/interop/qemu-qmp-ref.pdf docs/interop/qemu-ga-ref.pdf
rm -f docs/interop/qemu-qmp-ref.html docs/interop/qemu-ga-ref.html
- rm -f docs/qemu-cpu-models.7
rm -rf .doctrees
$(call clean-manual,devel)
$(call clean-manual,interop)
@@ -841,7 +840,7 @@ ifdef CONFIG_POSIX
$(INSTALL_DIR) "$(DESTDIR)$(mandir)/man7"
$(INSTALL_DATA) docs/interop/qemu-qmp-ref.7 "$(DESTDIR)$(mandir)/man7"
$(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-block-drivers.7 "$(DESTDIR)$(mandir)/man7"
- $(INSTALL_DATA) docs/qemu-cpu-models.7 "$(DESTDIR)$(mandir)/man7"
+ $(INSTALL_DATA) $(MANUAL_BUILDDIR)/system/qemu-cpu-models.7 "$(DESTDIR)$(mandir)/man7"
ifeq ($(CONFIG_TOOLS),y)
$(INSTALL_DATA) $(MANUAL_BUILDDIR)/interop/qemu-img.1 "$(DESTDIR)$(mandir)/man1"
$(INSTALL_DIR) "$(DESTDIR)$(mandir)/man8"
@@ -1056,6 +1055,8 @@ $(call define-manpage-rule,interop,\
$(call define-manpage-rule,system,qemu-block-drivers.7)
+$(call define-manpage-rule,system,qemu-cpu-models.7)
+
$(MANUAL_BUILDDIR)/index.html: $(SRC_PATH)/docs/index.html.in qemu-version.h
@mkdir -p "$(MANUAL_BUILDDIR)"
$(call quiet-command, sed "s|@@VERSION@@|${VERSION}|g" $< >$@, \
@@ -1078,7 +1079,6 @@ docs/interop/qemu-ga-qapi.texi: qga/qapi-generated/qga-qapi-doc.texi
qemu.1: qemu-doc.texi qemu-options.texi qemu-monitor.texi qemu-monitor-info.texi
qemu.1: qemu-option-trace.texi
-docs/qemu-cpu-models.7: docs/qemu-cpu-models.texi
html: qemu-doc.html docs/interop/qemu-qmp-ref.html docs/interop/qemu-ga-ref.html sphinxdocs
info: qemu-doc.info docs/interop/qemu-qmp-ref.info docs/interop/qemu-ga-ref.info
@@ -1090,7 +1090,7 @@ qemu-doc.html qemu-doc.info qemu-doc.pdf qemu-doc.txt: \
qemu-tech.texi qemu-option-trace.texi \
qemu-deprecated.texi qemu-monitor.texi \
qemu-monitor-info.texi \
- docs/qemu-cpu-models.texi docs/security.texi
+ docs/security.texi
docs/interop/qemu-ga-ref.dvi docs/interop/qemu-ga-ref.html \
docs/interop/qemu-ga-ref.info docs/interop/qemu-ga-ref.pdf \
diff --git a/docs/qemu-cpu-models.texi b/docs/qemu-cpu-models.texi
deleted file mode 100644
index f88a1def0d..0000000000
--- a/docs/qemu-cpu-models.texi
+++ /dev/null
@@ -1,677 +0,0 @@
-@c man begin SYNOPSIS
-QEMU / KVM CPU model configuration
-@c man end
-
-@set qemu_system_x86 qemu-system-x86_64
-
-@c man begin DESCRIPTION
-
-@menu
-* recommendations_cpu_models_x86:: Recommendations for KVM CPU model configuration on x86 hosts
-* recommendations_cpu_models_MIPS:: Supported CPU model configurations on MIPS hosts
-* cpu_model_syntax_apps:: Syntax for configuring CPU models
-@end menu
-
-QEMU / KVM virtualization supports two ways to configure CPU models
-
-@table @option
-
-@item Host passthrough
-
-This passes the host CPU model features, model, stepping, exactly to the
-guest. Note that KVM may filter out some host CPU model features if they
-cannot be supported with virtualization. Live migration is unsafe when
-this mode is used as libvirt / QEMU cannot guarantee a stable CPU is
-exposed to the guest across hosts. This is the recommended CPU to use,
-provided live migration is not required.
-
-@item Named model
-
-QEMU comes with a number of predefined named CPU models, that typically
-refer to specific generations of hardware released by Intel and AMD.
-These allow the guest VMs to have a degree of isolation from the host CPU,
-allowing greater flexibility in live migrating between hosts with differing
-hardware.
-@end table
-
-In both cases, it is possible to optionally add or remove individual CPU
-features, to alter what is presented to the guest by default.
-
-Libvirt supports a third way to configure CPU models known as "Host model".
-This uses the QEMU "Named model" feature, automatically picking a CPU model
-that is similar the host CPU, and then adding extra features to approximate
-the host model as closely as possible. This does not guarantee the CPU family,
-stepping, etc will precisely match the host CPU, as they would with "Host
-passthrough", but gives much of the benefit of passthrough, while making
-live migration safe.
-
-@node recommendations_cpu_models_x86
-@subsection Recommendations for KVM CPU model configuration on x86 hosts
-
-The information that follows provides recommendations for configuring
-CPU models on x86 hosts. The goals are to maximise performance, while
-protecting guest OS against various CPU hardware flaws, and optionally
-enabling live migration between hosts with heterogeneous CPU models.
-
-@menu
-* preferred_cpu_models_intel_x86:: Preferred CPU models for Intel x86 hosts
-* important_cpu_features_intel_x86:: Important CPU features for Intel x86 hosts
-* preferred_cpu_models_amd_x86:: Preferred CPU models for AMD x86 hosts
-* important_cpu_features_amd_x86:: Important CPU features for AMD x86 hosts
-* default_cpu_models_x86:: Default x86 CPU models
-* other_non_recommended_cpu_models_x86:: Other non-recommended x86 CPUs
-@end menu
-
-@node preferred_cpu_models_intel_x86
-@subsubsection Preferred CPU models for Intel x86 hosts
-
-The following CPU models are preferred for use on Intel hosts. Administrators /
-applications are recommended to use the CPU model that matches the generation
-of the host CPUs in use. In a deployment with a mixture of host CPU models
-between machines, if live migration compatibility is required, use the newest
-CPU model that is compatible across all desired hosts.
-
-@table @option
-@item @code{Skylake-Server}
-@item @code{Skylake-Server-IBRS}
-
-Intel Xeon Processor (Skylake, 2016)
-
-
-@item @code{Skylake-Client}
-@item @code{Skylake-Client-IBRS}
-
-Intel Core Processor (Skylake, 2015)
-
-
-@item @code{Broadwell}
-@item @code{Broadwell-IBRS}
-@item @code{Broadwell-noTSX}
-@item @code{Broadwell-noTSX-IBRS}
-
-Intel Core Processor (Broadwell, 2014)
-
-
-@item @code{Haswell}
-@item @code{Haswell-IBRS}
-@item @code{Haswell-noTSX}
-@item @code{Haswell-noTSX-IBRS}
-
-Intel Core Processor (Haswell, 2013)
-
-
-@item @code{IvyBridge}
-@item @code{IvyBridge-IBRS}
-
-Intel Xeon E3-12xx v2 (Ivy Bridge, 2012)
-
-
-@item @code{SandyBridge}
-@item @code{SandyBridge-IBRS}
-
-Intel Xeon E312xx (Sandy Bridge, 2011)
-
-
-@item @code{Westmere}
-@item @code{Westmere-IBRS}
-
-Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010)
-
-
-@item @code{Nehalem}
-@item @code{Nehalem-IBRS}
-
-Intel Core i7 9xx (Nehalem Class Core i7, 2008)
-
-
-@item @code{Penryn}
-
-Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007)
-
-
-@item @code{Conroe}
-
-Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006)
-
-@end table
-
-@node important_cpu_features_intel_x86
-@subsubsection Important CPU features for Intel x86 hosts
-
-The following are important CPU features that should be used on Intel x86
-hosts, when available in the host CPU. Some of them require explicit
-configuration to enable, as they are not included by default in some, or all,
-of the named CPU models listed above. In general all of these features are
-included if using "Host passthrough" or "Host model".
-
-
-@table @option
-
-@item @code{pcid}
-
-Recommended to mitigate the cost of the Meltdown (CVE-2017-5754) fix
-
-Included by default in Haswell, Broadwell & Skylake Intel CPU models.
-
-Should be explicitly turned on for Westmere, SandyBridge, and IvyBridge
-Intel CPU models. Note that some desktop/mobile Westmere CPUs cannot
-support this feature.
-
-
-@item @code{spec-ctrl}
-
-Required to enable the Spectre v2 (CVE-2017-5715) fix.
-
-Included by default in Intel CPU models with -IBRS suffix.
-
-Must be explicitly turned on for Intel CPU models without -IBRS suffix.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-
-
-@item @code{stibp}
-
-Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
-operating systems.
-
-Must be explicitly turned on for all Intel CPU models.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-
-
-@item @code{ssbd}
-
-Required to enable the CVE-2018-3639 fix
-
-Not included by default in any Intel CPU model.
-
-Must be explicitly turned on for all Intel CPU models.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-
-
-@item @code{pdpe1gb}
-
-Recommended to allow guest OS to use 1GB size pages
-
-Not included by default in any Intel CPU model.
-
-Should be explicitly turned on for all Intel CPU models.
-
-Note that not all CPU hardware will support this feature.
-
-@item @code{md-clear}
-
-Required to confirm the MDS (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130,
-CVE-2019-11091) fixes.
-
-Not included by default in any Intel CPU model.
-
-Must be explicitly turned on for all Intel CPU models.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-@end table
-
-
-@node preferred_cpu_models_amd_x86
-@subsubsection Preferred CPU models for AMD x86 hosts
-
-The following CPU models are preferred for use on Intel hosts. Administrators /
-applications are recommended to use the CPU model that matches the generation
-of the host CPUs in use. In a deployment with a mixture of host CPU models
-between machines, if live migration compatibility is required, use the newest
-CPU model that is compatible across all desired hosts.
-
-@table @option
-
-@item @code{EPYC}
-@item @code{EPYC-IBPB}
-
-AMD EPYC Processor (2017)
-
-
-@item @code{Opteron_G5}
-
-AMD Opteron 63xx class CPU (2012)
-
-
-@item @code{Opteron_G4}
-
-AMD Opteron 62xx class CPU (2011)
-
-
-@item @code{Opteron_G3}
-
-AMD Opteron 23xx (Gen 3 Class Opteron, 2009)
-
-
-@item @code{Opteron_G2}
-
-AMD Opteron 22xx (Gen 2 Class Opteron, 2006)
-
-
-@item @code{Opteron_G1}
-
-AMD Opteron 240 (Gen 1 Class Opteron, 2004)
-@end table
-
-@node important_cpu_features_amd_x86
-@subsubsection Important CPU features for AMD x86 hosts
-
-The following are important CPU features that should be used on AMD x86
-hosts, when available in the host CPU. Some of them require explicit
-configuration to enable, as they are not included by default in some, or all,
-of the named CPU models listed above. In general all of these features are
-included if using "Host passthrough" or "Host model".
-
-
-@table @option
-
-@item @code{ibpb}
-
-Required to enable the Spectre v2 (CVE-2017-5715) fix.
-
-Included by default in AMD CPU models with -IBPB suffix.
-
-Must be explicitly turned on for AMD CPU models without -IBPB suffix.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-
-
-@item @code{stibp}
-
-Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
-operating systems.
-
-Must be explicitly turned on for all AMD CPU models.
-
-Requires the host CPU microcode to support this feature before it
-can be used for guest CPUs.
-
-
-@item @code{virt-ssbd}
-
-Required to enable the CVE-2018-3639 fix
-
-Not included by default in any AMD CPU model.
-
-Must be explicitly turned on for all AMD CPU models.
-
-This should be provided to guests, even if amd-ssbd is also
-provided, for maximum guest compatibility.
-
-Note for some QEMU / libvirt versions, this must be force enabled
-when when using "Host model", because this is a virtual feature
-that doesn't exist in the physical host CPUs.
-
-
-@item @code{amd-ssbd}
-
-Required to enable the CVE-2018-3639 fix
-
-Not included by default in any AMD CPU model.
-
-Must be explicitly turned on for all AMD CPU models.
-
-This provides higher performance than virt-ssbd so should be
-exposed to guests whenever available in the host. virt-ssbd
-should none the less also be exposed for maximum guest
-compatibility as some kernels only know about virt-ssbd.
-
-
-@item @code{amd-no-ssb}
-
-Recommended to indicate the host is not vulnerable CVE-2018-3639
-
-Not included by default in any AMD CPU model.
-
-Future hardware generations of CPU will not be vulnerable to
-CVE-2018-3639, and thus the guest should be told not to enable
-its mitigations, by exposing amd-no-ssb. This is mutually
-exclusive with virt-ssbd and amd-ssbd.
-
-
-@item @code{pdpe1gb}
-
-Recommended to allow guest OS to use 1GB size pages
-
-Not included by default in any AMD CPU model.
-
-Should be explicitly turned on for all AMD CPU models.
-
-Note that not all CPU hardware will support this feature.
-@end table
-
-
-@node default_cpu_models_x86
-@subsubsection Default x86 CPU models
-
-The default QEMU CPU models are designed such that they can run on all hosts.
-If an application does not wish to do perform any host compatibility checks
-before launching guests, the default is guaranteed to work.
-
-The default CPU models will, however, leave the guest OS vulnerable to various
-CPU hardware flaws, so their use is strongly discouraged. Applications should
-follow the earlier guidance to setup a better CPU configuration, with host
-passthrough recommended if live migration is not needed.
-
-@table @option
-@item @code{qemu32}
-@item @code{qemu64}
-
-QEMU Virtual CPU version 2.5+ (32 & 64 bit variants)
-
-qemu64 is used for x86_64 guests and qemu32 is used for i686 guests, when no
--cpu argument is given to QEMU, or no <cpu> is provided in libvirt XML.
-@end table
-
-
-@node other_non_recommended_cpu_models_x86
-@subsubsection Other non-recommended x86 CPUs
-
-The following CPUs models are compatible with most AMD and Intel x86 hosts, but
-their usage is discouraged, as they expose a very limited featureset, which
-prevents guests having optimal performance.
-
-@table @option
-
-@item @code{kvm32}
-@item @code{kvm64}
-
-Common KVM processor (32 & 64 bit variants)
-
-Legacy models just for historical compatibility with ancient QEMU versions.
-
-
-@item @code{486}
-@item @code{athlon}
-@item @code{phenom}
-@item @code{coreduo}
-@item @code{core2duo}
-@item @code{n270}
-@item @code{pentium}
-@item @code{pentium2}
-@item @code{pentium3}
-
-Various very old x86 CPU models, mostly predating the introduction of
-hardware assisted virtualization, that should thus not be required for
-running virtual machines.
-@end table
-
-@node recommendations_cpu_models_MIPS
-@subsection Supported CPU model configurations on MIPS hosts
-
-QEMU supports variety of MIPS CPU models:
-
-@menu
-* cpu_models_MIPS32:: Supported CPU models for MIPS32 hosts
-* cpu_models_MIPS64:: Supported CPU models for MIPS64 hosts
-* cpu_models_nanoMIPS:: Supported CPU models for nanoMIPS hosts
-* preferred_cpu_models_MIPS:: Preferred CPU models for MIPS hosts
-@end menu
-
-@node cpu_models_MIPS32
-@subsubsection Supported CPU models for MIPS32 hosts
-
-The following CPU models are supported for use on MIPS32 hosts. Administrators /
-applications are recommended to use the CPU model that matches the generation
-of the host CPUs in use. In a deployment with a mixture of host CPU models
-between machines, if live migration compatibility is required, use the newest
-CPU model that is compatible across all desired hosts.
-
-@table @option
-@item @code{mips32r6-generic}
-
-MIPS32 Processor (Release 6, 2015)
-
-
-@item @code{P5600}
-
-MIPS32 Processor (P5600, 2014)
-
-
-@item @code{M14K}
-@item @code{M14Kc}
-
-MIPS32 Processor (M14K, 2009)
-
-
-@item @code{74Kf}
-
-MIPS32 Processor (74K, 2007)
-
-
-@item @code{34Kf}
-
-MIPS32 Processor (34K, 2006)
-
-
-@item @code{24Kc}
-@item @code{24KEc}
-@item @code{24Kf}
-
-MIPS32 Processor (24K, 2003)
-
-
-@item @code{4Kc}
-@item @code{4Km}
-@item @code{4KEcR1}
-@item @code{4KEmR1}
-@item @code{4KEc}
-@item @code{4KEm}
-
-MIPS32 Processor (4K, 1999)
-@end table
-
-@node cpu_models_MIPS64
-@subsubsection Supported CPU models for MIPS64 hosts
-
-The following CPU models are supported for use on MIPS64 hosts. Administrators /
-applications are recommended to use the CPU model that matches the generation
-of the host CPUs in use. In a deployment with a mixture of host CPU models
-between machines, if live migration compatibility is required, use the newest
-CPU model that is compatible across all desired hosts.
-
-@table @option
-@item @code{I6400}
-
-MIPS64 Processor (Release 6, 2014)
-
-
-@item @code{Loongson-2F}
-
-MIPS64 Processor (Loongson 2, 2008)
-
-
-@item @code{Loongson-2E}
-
-MIPS64 Processor (Loongson 2, 2006)
-
-
-@item @code{mips64dspr2}
-
-MIPS64 Processor (Release 2, 2006)
-
-
-@item @code{MIPS64R2-generic}
-@item @code{5KEc}
-@item @code{5KEf}
-
-MIPS64 Processor (Release 2, 2002)
-
-
-@item @code{20Kc}
-
-MIPS64 Processor (20K, 2000)
-
-
-@item @code{5Kc}
-@item @code{5Kf}
-
-MIPS64 Processor (5K, 1999)
-
-
-@item @code{VR5432}
-
-MIPS64 Processor (VR, 1998)
-
-
-@item @code{R4000}
-
-MIPS64 Processor (MIPS III, 1991)
-@end table
-
-@node cpu_models_nanoMIPS
-@subsubsection Supported CPU models for nanoMIPS hosts
-
-The following CPU models are supported for use on nanoMIPS hosts. Administrators /
-applications are recommended to use the CPU model that matches the generation
-of the host CPUs in use. In a deployment with a mixture of host CPU models
-between machines, if live migration compatibility is required, use the newest
-CPU model that is compatible across all desired hosts.
-
-@table @option
-@item @code{I7200}
-
-MIPS I7200 (nanoMIPS, 2018)
-
-@end table
-
-@node preferred_cpu_models_MIPS
-@subsubsection Preferred CPU models for MIPS hosts
-
-The following CPU models are preferred for use on different MIPS hosts:
-
-@table @option
-@item @code{MIPS III}
-R4000
-
-@item @code{MIPS32R2}
-34Kf
-
-@item @code{MIPS64R6}
-I6400
-
-@item @code{nanoMIPS}
-I7200
-@end table
-
-@node cpu_model_syntax_apps
-@subsection Syntax for configuring CPU models
-
-The example below illustrate the approach to configuring the various
-CPU models / features in QEMU and libvirt
-
-@menu
-* cpu_model_syntax_qemu:: QEMU command line
-* cpu_model_syntax_libvirt:: Libvirt guest XML
-@end menu
-
-@node cpu_model_syntax_qemu
-@subsubsection QEMU command line
-
-@table @option
-
-@item Host passthrough
-
-@example
- $ @value{qemu_system_x86} -cpu host
-@end example
-
-With feature customization:
-
-@example
- $ @value{qemu_system_x86} -cpu host,-vmx,...
-@end example
-
-@item Named CPU models
-
-@example
- $ @value{qemu_system_x86} -cpu Westmere
-@end example
-
-With feature customization:
-
-@example
- $ @value{qemu_system_x86} -cpu Westmere,+pcid,...
-@end example
-
-@end table
-
-@node cpu_model_syntax_libvirt
-@subsubsection Libvirt guest XML
-
-@table @option
-
-@item Host passthrough
-
-@example
- <cpu mode='host-passthrough'/>
-@end example
-
-With feature customization:
-
-@example
- <cpu mode='host-passthrough'>
- <feature name="vmx" policy="disable"/>
- ...
- </cpu>
-@end example
-
-@item Host model
-
-@example
- <cpu mode='host-model'/>
-@end example
-
-With feature customization:
-
-@example
- <cpu mode='host-model'>
- <feature name="vmx" policy="disable"/>
- ...
- </cpu>
-@end example
-
-@item Named model
-
-@example
- <cpu mode='custom'>
- <model name="Westmere"/>
- </cpu>
-@end example
-
-With feature customization:
-
-@example
- <cpu mode='custom'>
- <model name="Westmere"/>
- <feature name="pcid" policy="require"/>
- ...
- </cpu>
-@end example
-
-@end table
-
-@c man end
-
-@ignore
-
-@setfilename qemu-cpu-models
-@settitle QEMU / KVM CPU model configuration
-
-@c man begin SEEALSO
-The HTML documentation of QEMU for more precise information and Linux
-user mode emulator invocation.
-@c man end
-
-@c man begin AUTHOR
-Daniel P. Berrange
-@c man end
-
-@end ignore
diff --git a/docs/system/conf.py b/docs/system/conf.py
index 7ca115f5e0..7cc9da9508 100644
--- a/docs/system/conf.py
+++ b/docs/system/conf.py
@@ -18,5 +18,8 @@ html_theme_options['description'] = u'System Emulation User''s Guide'
man_pages = [
('qemu-block-drivers', 'qemu-block-drivers',
u'QEMU block drivers reference',
+ ['Fabrice Bellard and the QEMU Project developers'], 7),
+ ('qemu-cpu-models', 'qemu-cpu-models',
+ u'QEMU CPU Models',
['Fabrice Bellard and the QEMU Project developers'], 7)
]
diff --git a/docs/system/index.rst b/docs/system/index.rst
index f66e6ea585..849dcd8cb8 100644
--- a/docs/system/index.rst
+++ b/docs/system/index.rst
@@ -15,3 +15,4 @@ Contents:
:maxdepth: 2
qemu-block-drivers
+ qemu-cpu-models
diff --git a/docs/system/qemu-cpu-models.rst b/docs/system/qemu-cpu-models.rst
new file mode 100644
index 0000000000..a189d6a9da
--- /dev/null
+++ b/docs/system/qemu-cpu-models.rst
@@ -0,0 +1,514 @@
+QEMU / KVM CPU model configuration
+==================================
+
+.. |qemu_system| replace:: qemu-system-x86_64
+
+.. only:: man
+
+ Synopsis
+ --------
+
+ QEMU CPU Modelling Infrastructure manual
+
+Two ways to configure CPU models with QEMU / KVM
+------------------------------------------------
+
+(1) **Host passthrough**
+
+ This passes the host CPU model features, model, stepping, exactly to
+ the guest. Note that KVM may filter out some host CPU model features
+ if they cannot be supported with virtualization. Live migration is
+ unsafe when this mode is used as libvirt / QEMU cannot guarantee a
+ stable CPU is exposed to the guest across hosts. This is the
+ recommended CPU to use, provided live migration is not required.
+
+(2) **Named model**
+
+ QEMU comes with a number of predefined named CPU models, that
+ typically refer to specific generations of hardware released by
+ Intel and AMD. These allow the guest VMs to have a degree of
+ isolation from the host CPU, allowing greater flexibility in live
+ migrating between hosts with differing hardware. @end table
+
+In both cases, it is possible to optionally add or remove individual CPU
+features, to alter what is presented to the guest by default.
+
+Libvirt supports a third way to configure CPU models known as "Host
+model". This uses the QEMU "Named model" feature, automatically picking
+a CPU model that is similar the host CPU, and then adding extra features
+to approximate the host model as closely as possible. This does not
+guarantee the CPU family, stepping, etc will precisely match the host
+CPU, as they would with "Host passthrough", but gives much of the
+benefit of passthrough, while making live migration safe.
+
+
+Recommendations for KVM CPU model configuration on x86 hosts
+------------------------------------------------------------
+
+The information that follows provides recommendations for configuring
+CPU models on x86 hosts. The goals are to maximise performance, while
+protecting guest OS against various CPU hardware flaws, and optionally
+enabling live migration between hosts with heterogeneous CPU models.
+
+
+Preferred CPU models for Intel x86 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are preferred for use on Intel hosts.
+Administrators / applications are recommended to use the CPU model that
+matches the generation of the host CPUs in use. In a deployment with a
+mixture of host CPU models between machines, if live migration
+compatibility is required, use the newest CPU model that is compatible
+across all desired hosts.
+
+* Intel Xeon Processor (Skylake, 2016)
+
+ * ``Skylake-Server``
+ * ``Skylake-Server-IBRS``
+
+* Intel Core Processor (Skylake, 2015)
+
+ * ``Skylake-Client``
+ * ``Skylake-Client-IBRS``
+
+* Intel Core Processor (Broadwell, 2014)
+
+ * ``Broadwell``
+ * ``Broadwell-IBRS``
+ * ``Broadwell-noTSX``
+ * ``Broadwell-noTSX-IBRS``
+
+* Intel Core Processor (Haswell, 2013)
+
+ * ``Haswell``
+ * ``Haswell-IBRS``
+ * ``Haswell-noTSX``
+ * ``Haswell-noTSX-IBRS``
+
+* Intel Xeon E3-12xx v2 (Ivy Bridge, 2012)
+
+ * ``IvyBridge``
+ * ``IvyBridge-IBR``
+
+* Intel Xeon E312xx (Sandy Bridge, 2011)
+
+ * ``SandyBridge``
+ * ``SandyBridge-IBRS``
+
+* Westmere E56xx/L56xx/X56xx (Nehalem-C, 2010)
+
+ * ``Westmere``
+ * ``Westmere-IBRS``
+
+* Intel Core i7 9xx (Nehalem Class Core i7, 2008)
+
+ * ``Nehalem``
+ * ``Nehalem-IBRS``
+
+* Intel Core 2 Duo P9xxx (Penryn Class Core 2, 2007)
+
+ * ``Penryn``
+
+* Intel Celeron_4x0 (Conroe/Merom Class Core 2, 2006)
+
+ * ``Conroe``
+
+
+Important CPU features for Intel x86 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are important CPU features that should be used on Intel
+x86 hosts, when available in the host CPU. Some of them require explicit
+configuration to enable, as they are not included by default in some, or
+all, of the named CPU models listed above. In general all of these
+features are included if using "Host passthrough" or "Host model".
+
+``pcid``
+ Recommended to mitigate the cost of the Meltdown (CVE-2017-5754) fix.
+
+ Included by default in Haswell, Broadwell & Skylake Intel CPU models.
+
+ Should be explicitly turned on for Westmere, SandyBridge, and
+ IvyBridge Intel CPU models. Note that some desktop/mobile Westmere
+ CPUs cannot support this feature.
+
+``spec-ctrl``
+ Required to enable the Spectre v2 (CVE-2017-5715) fix.
+
+ Included by default in Intel CPU models with -IBRS suffix.
+
+ Must be explicitly turned on for Intel CPU models without -IBRS
+ suffix.
+
+ Requires the host CPU microcode to support this feature before it
+ can be used for guest CPUs.
+
+``stibp``
+ Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
+ operating systems.
+
+ Must be explicitly turned on for all Intel CPU models.
+
+ Requires the host CPU microcode to support this feature before it can
+ be used for guest CPUs.
+
+``ssbd``
+ Required to enable the CVE-2018-3639 fix.
+
+ Not included by default in any Intel CPU model.
+
+ Must be explicitly turned on for all Intel CPU models.
+
+ Requires the host CPU microcode to support this feature before it
+ can be used for guest CPUs.
+
+``pdpe1gb``
+ Recommended to allow guest OS to use 1GB size pages.
+
+ Not included by default in any Intel CPU model.
+
+ Should be explicitly turned on for all Intel CPU models.
+
+ Note that not all CPU hardware will support this feature.
+
+``md-clear``
+ Required to confirm the MDS (CVE-2018-12126, CVE-2018-12127,
+ CVE-2018-12130, CVE-2019-11091) fixes.
+
+ Not included by default in any Intel CPU model.
+
+ Must be explicitly turned on for all Intel CPU models.
+
+ Requires the host CPU microcode to support this feature before it
+ can be used for guest CPUs.
+
+
+Preferred CPU models for AMD x86 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are preferred for use on Intel hosts.
+Administrators / applications are recommended to use the CPU model that
+matches the generation of the host CPUs in use. In a deployment with a
+mixture of host CPU models between machines, if live migration
+compatibility is required, use the newest CPU model that is compatible
+across all desired hosts.
+
+* AMD EPYC Processor (2017)
+
+ * ``EPYC``
+ * ``EPYC-IBPB``
+
+* ``Opteron_G5`` – AMD Opteron 63xx class CPU (2012)
+
+* ``Opteron_G4`` – AMD Opteron 62xx class CPU (2011)
+
+* ``Opteron_G3`` – AMD Opteron 23xx (Gen 3 Class Opteron, 2009)
+
+* ``Opteron_G2`` – AMD Opteron 22xx (Gen 2 Class Opteron, 2006)
+
+* ``Opteron_G1`` – AMD Opteron 240 (Gen 1 Class Opteron, 2004)
+
+
+Important CPU features for AMD x86 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following are important CPU features that should be used on AMD x86
+hosts, when available in the host CPU. Some of them require explicit
+configuration to enable, as they are not included by default in some, or
+all, of the named CPU models listed above. In general all of these
+features are included if using "Host passthrough" or "Host model".
+
+``ibpb``
+ Required to enable the Spectre v2 (CVE-2017-5715) fix.
+
+ Included by default in AMD CPU models with -IBPB suffix.
+
+ Must be explicitly turned on for AMD CPU models without -IBPB suffix.
+
+ Requires the host CPU microcode to support this feature before it
+ can be used for guest CPUs.
+
+``stibp``
+ Required to enable stronger Spectre v2 (CVE-2017-5715) fixes in some
+ operating systems.
+
+ Must be explicitly turned on for all AMD CPU models.
+
+ Requires the host CPU microcode to support this feature before it
+ can be used for guest CPUs.
+
+``virt-ssbd``
+ Required to enable the CVE-2018-3639 fix
+
+ Not included by default in any AMD CPU model.
+
+ Must be explicitly turned on for all AMD CPU models.
+
+ This should be provided to guests, even if amd-ssbd is also provided,
+ for maximum guest compatibility.
+
+ Note for some QEMU / libvirt versions, this must be force enabled when
+ when using "Host model", because this is a virtual feature that
+ doesn't exist in the physical host CPUs.
+
+``amd-ssbd``
+ Required to enable the CVE-2018-3639 fix
+
+ Not included by default in any AMD CPU model.
+
+ Must be explicitly turned on for all AMD CPU models.
+
+ This provides higher performance than ``virt-ssbd`` so should be
+ exposed to guests whenever available in the host. ``virt-ssbd`` should
+ none the less also be exposed for maximum guest compatibility as some
+ kernels only know about ``virt-ssbd``.
+
+``amd-no-ssb``
+ Recommended to indicate the host is not vulnerable CVE-2018-3639
+
+ Not included by default in any AMD CPU model.
+
+ Future hardware generations of CPU will not be vulnerable to
+ CVE-2018-3639, and thus the guest should be told not to enable
+ its mitigations, by exposing amd-no-ssb. This is mutually
+ exclusive with virt-ssbd and amd-ssbd.
+
+``pdpe1gb``
+ Recommended to allow guest OS to use 1GB size pages
+
+ Not included by default in any AMD CPU model.
+
+ Should be explicitly turned on for all AMD CPU models.
+
+ Note that not all CPU hardware will support this feature.
+
+
+Default x86 CPU models
+----------------------
+
+The default QEMU CPU models are designed such that they can run on all
+hosts. If an application does not wish to do perform any host
+compatibility checks before launching guests, the default is guaranteed
+to work.
+
+The default CPU models will, however, leave the guest OS vulnerable to
+various CPU hardware flaws, so their use is strongly discouraged.
+Applications should follow the earlier guidance to setup a better CPU
+configuration, with host passthrough recommended if live migration is
+not needed.
+
+* QEMU Virtual CPU version 2.5+ (32 & 64 bit variants)
+
+ * ``qemu32``
+ * ``qemu64``
+
+ ``qemu64`` is used for x86_64 guests and ``qemu32`` is used for i686
+ guests, when no ``-cpu`` argument is given to QEMU, or no ``<cpu>`` is
+ provided in libvirt XML.
+
+Other non-recommended x86 CPUs
+------------------------------
+
+The following CPUs models are compatible with most AMD and Intel x86
+hosts, but their usage is discouraged, as they expose a very limited
+featureset, which prevents guests having optimal performance.
+
+* Common KVM processor (32 & 64 bit variants):
+
+ * ``kvm32``
+ * ``kvm64``
+
+ Legacy models just for historical compatibility with ancient QEMU
+ versions.
+
+* Various very old x86 CPU models, mostly predating the introduction of
+ hardware assisted virtualization, that should thus not be required for
+ running virtual machines.
+
+ * ``486``
+ * ``athlon``
+ * ``phenom``
+ * ``coreduo``
+ * ``core2duo``
+ * ``n270``
+ * ``pentium``
+ * ``pentium2``
+ * ``pentium3``
+
+
+Supported CPU model configurations on MIPS hosts
+------------------------------------------------
+
+QEMU supports variety of MIPS CPU models:
+
+Supported CPU models for MIPS32 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are supported for use on MIPS32 hosts.
+Administrators / applications are recommended to use the CPU model that
+matches the generation of the host CPUs in use. In a deployment with a
+mixture of host CPU models between machines, if live migration
+compatibility is required, use the newest CPU model that is compatible
+across all desired hosts.
+
+* ``mips32r6-generic`` – MIPS32 Processor (Release 6, 2015)
+
+* ``P5600`` – MIPS32 Processor (P5600, 2014)
+
+* MIPS32 Processor (M14K, 2009)
+
+ * ``M14K``
+ * ``M14Kc``
+
+* ``74Kf`` – MIPS32 Processor (74K, 2007)
+
+* ``34Kf`` – MIPS32 Processor (34K, 2006)
+
+* MIPS32 Processor (24K, 2003)
+
+ * ``24Kc``
+ * ``24KEc``
+ * ``24Kf``
+
+* MIPS32 Processor (4K, 1999)
+
+ * ``4Kc``
+ * ``4Km``
+ * ``4KEcR1``
+ * ``4KEmR1``
+ * ``4KEc``
+ * ``4KEm``
+
+
+Supported CPU models for MIPS64 hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are supported for use on MIPS64 hosts.
+Administrators / applications are recommended to use the CPU model that
+matches the generation of the host CPUs in use. In a deployment with a
+mixture of host CPU models between machines, if live migration
+compatibility is required, use the newest CPU model that is compatible
+across all desired hosts.
+
+* ``I6400`` – MIPS64 Processor (Release 6, 2014)
+
+* ``Loongson-2F`` – MIPS64 Processor (Loongson 2, 2008)
+
+* ``Loongson-2E`` – MIPS64 Processor (Loongson 2, 2006)
+
+* ``mips64dspr2`` – MIPS64 Processor (Release 2, 2006)
+
+* MIPS64 Processor (Release 2, 2002)
+
+ * ``MIPS64R2-generic``
+ * ``5KEc``
+ * ``5KEf``
+
+* ``20Kc`` – MIPS64 Processor (20K, 2000
+
+* MIPS64 Processor (5K, 1999)
+
+ * ``5Kc``
+ * ``5Kf``
+
+* ``VR5432`` – MIPS64 Processor (VR, 1998)
+
+* ``R4000`` – MIPS64 Processor (MIPS III, 1991)
+
+
+Supported CPU models for nanoMIPS hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are supported for use on nanoMIPS hosts.
+Administrators / applications are recommended to use the CPU model that
+matches the generation of the host CPUs in use. In a deployment with a
+mixture of host CPU models between machines, if live migration
+compatibility is required, use the newest CPU model that is compatible
+across all desired hosts.
+
+* ``I7200`` – MIPS I7200 (nanoMIPS, 2018)
+
+Preferred CPU models for MIPS hosts
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following CPU models are preferred for use on different MIPS hosts:
+
+* ``MIPS III`` – R4000
+
+* ``MIPS32R2`` – 34Kf
+
+* ``MIPS64R6`` – I6400
+
+* ``nanoMIPS`` – I7200
+
+Syntax for configuring CPU models
+---------------------------------
+
+The examples below illustrate the approach to configuring the various
+CPU models / features in QEMU and libvirt.
+
+QEMU command line
+~~~~~~~~~~~~~~~~~
+
+Host passthrough:
+
+.. parsed-literal::
+
+ |qemu_system| -cpu host
+
+Host passthrough with feature customization:
+
+.. parsed-literal::
+
+ |qemu_system| -cpu host,-vmx,...
+
+Named CPU models:
+
+.. parsed-literal::
+
+ |qemu_system| -cpu Westmere
+
+Named CPU models with feature customization:
+
+.. parsed-literal::
+
+ |qemu_system| -cpu Westmere,+pcid,...
+
+Libvirt guest XML
+~~~~~~~~~~~~~~~~~
+
+Host passthrough::
+
+ <cpu mode='host-passthrough'/>
+
+Host passthrough with feature customization::
+
+ <cpu mode='host-passthrough'>
+ <feature name="vmx" policy="disable"/>
+ ...
+ </cpu>
+
+Host model::
+
+ <cpu mode='host-model'/>
+
+Host model with feature customization::
+
+ <cpu mode='host-model'>
+ <feature name="vmx" policy="disable"/>
+ ...
+ </cpu>
+
+Named model::
+
+ <cpu mode='custom'>
+ <model name="Westmere"/>
+ </cpu>
+
+Named model with feature customization::
+
+ <cpu mode='custom'>
+ <model name="Westmere"/>
+ <feature name="pcid" policy="require"/>
+ ...
+ </cpu>
diff --git a/qemu-doc.texi b/qemu-doc.texi
index a1ef6b6484..c6a74877d6 100644
--- a/qemu-doc.texi
+++ b/qemu-doc.texi
@@ -616,11 +616,6 @@ The monitor understands integers expressions for every integer
argument. You can use register names to get the value of specifics
CPU registers by prefixing them with @emph{$}.
-@node cpu_models
-@section CPU models
-
-@include docs/qemu-cpu-models.texi
-
@node disk_images
@section Disk Images
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 14:21 UTC (permalink / raw)
To: minyard
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, Corey Minyard,
linux-kernel
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
On 2020-02-19 15:24, minyard@acm.org wrote:
> From: Corey Minyard <cminyard@mvista.com>
[...]
> After studying the EL0 handling for this, I realized an issue with
> using
> MDSCR to check if single step is enabled: it can be expensive on a VM.
> So check the task flag first to see if single step is enabled. Then
> check MDSCR if the task flag is set.
Very tangential remark: I'd really like people *not* to try and optimize
Linux based on the behaviour of a hypervisor. In general, reading a
system register is fast, and the fact that it traps on a given
hypervisor
at some point may not be true in the future, nor be a valid assumption
across hypervisors.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 14:21 UTC (permalink / raw)
To: minyard
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
On 2020-02-19 15:24, minyard@acm.org wrote:
> From: Corey Minyard <cminyard@mvista.com>
[...]
> After studying the EL0 handling for this, I realized an issue with
> using
> MDSCR to check if single step is enabled: it can be expensive on a VM.
> So check the task flag first to see if single step is enabled. Then
> check MDSCR if the task flag is set.
Very tangential remark: I'd really like people *not* to try and optimize
Linux based on the behaviour of a hypervisor. In general, reading a
system register is fast, and the fact that it traps on a given
hypervisor
at some point may not be true in the future, nor be a valid assumption
across hypervisors.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/5] env/fat.c: remove private CMD_SAVEENV logic
From: Rasmus Villemoes @ 2020-02-20 14:22 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200219132715.1F81A240036@gemini.denx.de>
On 19/02/2020 14.27, Wolfgang Denk wrote:
> Dear Rasmus,
>
> In message <20200219094726.26798-4-rasmus.villemoes@prevas.dk> you wrote:
>> Always compile the env_fat_save() function, and let
>> CONFIG_IS_ENABLED(SAVEENV) (via the ENV_SAVE_PTR macro) decide whether
>> it actually ends up being compiled in.
>
> Have you tested that this works? How do the sizes of the
> images differe before and after applying your changes?
With or without these patches, I get
$ size u-boot spl/u-boot-spl
text data bss dec hex filename
407173 45308 98352 550833 867b1 u-boot
52403 3360 276 56039 dae7 spl/u-boot-spl
$ nm spl/u-boot-spl | grep env_fat
0090c5e8 t env_fat_load
$ nm u-boot | grep env_fat
17826cb4 t env_fat_load
17826c10 t env_fat_save
for a wandboard_defconfig modified by
-CONFIG_SPL_FS_EXT4=y
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_ENV_IS_IN_FAT=y
So in the "read-only environment access in SPL" case, everything is the
same before and after.
Now also enable CONFIG_SPL_SAVEENV and SPL_FAT_WRITE, then with my
patches we get
$ size u-boot spl/u-boot-spl
text data bss dec hex filename
407173 45308 98352 550833 867b1 u-boot
58298 3360 65860 127518 1f21e spl/u-boot-spl
$ nm spl/u-boot-spl | grep env_fat
0090c6e0 t env_fat_load
0090c63c t env_fat_save
but without,
$ size u-boot spl/u-boot-spl
text data bss dec hex filename
407173 45308 98352 550833 867b1 u-boot
52659 3360 280 56299 dbeb spl/u-boot-spl
$ nm spl/u-boot-spl | grep env_fat
0090c5e8 t env_fat_load
So without the fat.c patch, CONFIG_SPL_SAVEENV is effectively ignored.
> [Same question for ext4]
Actually, the situation for ext4 is even worse than indicated.
Just from reading code in ext4.c, env_ext4_save gets built into the SPL
if CONFIG_CMD_SAVEENV, whether or not CONFIG_SPL_SAVEENV is set. So I
expected my patch to simply reduce the spl image size in the
CONFIG_SPL_SAVEENV=n case. But one cannot compare - currently building with
CONFIG_CMD_SAVEENV=y
CONFIG_SPL_ENV_IS_IN_EXT4=y
CONFIG_SPL_SAVEENV=n
simply fails the SPL build because env_ext4_save refers to hexport_r,
which is only compiled if
!(defined(CONFIG_SPL_BUILD) && !defined(CONFIG_SPL_SAVEENV))
- which took me a while to read, it's a little easier if spelled
!defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_SAVEENV)
Anyway, a side-effect of my ext4 patch is that the above combination
actually builds, because env_ext4_save is not linked in, so hexport_r
isn't needed. And turning on SPL_SAVEENV also works as expected.
Rasmus
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Will Deacon @ 2020-02-20 14:22 UTC (permalink / raw)
To: minyard; +Cc: Catalin Marinas, linux-arm-kernel, linux-kernel, Corey Minyard
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
On Wed, Feb 19, 2020 at 09:24:03AM -0600, minyard@acm.org wrote:
> From: Corey Minyard <cminyard@mvista.com>
>
> I was working on a single-step bug on kgdb on an ARM64 system, and I saw
> this scenario:
>
> * A single step is setup to return to el1
> * The ERET return to el1
> * An interrupt is pending and runs before the instruction
> * As soon as PSTATE.D (the debug disable bit) is cleared, the single
> step happens in that location, not where it should have.
>
> This appears to be due to PSTATE.SS not being cleared when the exception
> happens. Per section D.2.12.5 of the ARMv8 reference manual, that
> appears to be incorrect, it says "As part of exception entry, the PE
> does all of the following: ... Sets PSTATE.SS to 0."
Sorry, but I don't follow you here. If PSTATE.SS is not cleared, why would
you take the step exception?
> However, I appear to not be the first person who has noticed this. In
> the el0-only portion of the kernel_entry macro in entry.S, I found the
> following comment: "Ensure MDSCR_EL1.SS is clear, since we can unmask
> debug exceptions when scheduling." Exactly the same scenario, except
> coming from a userland single step, not a kernel one.
No, I think you might be conflating PSTATE.SS and MDSCR_EL1.SS.
> As I was studying this, though, I realized that the following scenario
> had an issue:
>
> * Kernel enables MDSCR.SS, MDSCR.KDE, MDSCR.MDE (unnecessary), and
> PSTATE.SS to enable a single step in el1, for kgdb or kprobes,
> on the current CPU's MDSCR register and the process' PSTATE.SS
> register.
> * Kernel returns from the exception with ERET.
> * An interrupt or page fault happens on the instruction, causing the
> instruction to not be run, but the exception handler runs.
> * The exception causes the task to migrate to a new core.
> * The return from the exception runs on a different processor now,
> where the MDSCR values are not set up for a single step.
> * The single step fails to happen.
>
> This is bad for kgdb, of course, but it seems really bad for kprobes if
> this happens.
I don't see how this can happen for kprobes. Have you managed to reproduce
the failure?
> To fix both these problems, rework the handling of single steps to clear
> things out upon entry to the kernel from el1, and then to set up single
> step when returning to el1, and not do the setup in debug-monitors.c.
> This means that single stepping does not use
> enable/disable_debug_monitors(); it is no longer necessary to track
> those flags for single stepping. This is much like single stepping is
> handled for el0. A new flag is added in pt_regs to enable single
> stepping from el1. Unfortunately, the old value of PSTATE.SS cannot be
> used for this because of the hardware bug mentioned earlier.
I don't think there's a hardware bug.
It sound like you're trying to make kernel debugging per-task instead
of per-cpu, but I don't think that's the right thing to do. What if I /want/
to debug an interrupt handler? For example, I might have a watchpoint on
something accessed by timer interrupt.
> As part of this, there is an interaction between single stepping and the
> other users of debug monitors with the MDSCR.KDE bit. That bit has to
> be set for both hardware breakpoints at el1 and single stepping at el1.
> A new variable was created to store the cpu-wide value of MDSCR.KDE; the
> single stepping code makes sure not to clear that bit on kernel entry if
> it's set in the per-cpu variable.
>
> After fixing this and doing some more testing, I ran into another issue:
>
> * Kernel enables the pt_regs single step
> * Kernel returns from the exception with ERET.
> * An interrupt or page fault happens on the instruction, causing the
> instruction to not be run, but the exception handler runs.
This sounds like you've broken debug; we should take the step exception
in the exception handler. That's the way this is supposed to work.
> There's no easy way to find the pt_regs that has the single step flag
> set. So a thread info flag was added so that the single step could be
> disabled in this case. Both that flag and the flag in pt_regs must be
> set to enable a single step.
Honestly, I get the feeling that you don't really understand the code
you're changing here and it's a tonne of effort to try to untangle what
you're doing. That's not necessarily your fault because the debug
architecture is a nightmare to comprehend, but I'm not keen to change it
unless we have a really good justification. I'm sure kgdb is riddled with
bugs but, as I said before, the fixes should be in kgdb, not by tearing
up the low-level debug code (which has the potential to break other users).
Maybe it would be easier if you tried to fix one problem per patch,
preferably with a way to reproduce the issue you're seeing each time?
Will
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Will Deacon @ 2020-02-20 14:22 UTC (permalink / raw)
To: minyard; +Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Corey Minyard
In-Reply-To: <20200219152403.3495-1-minyard@acm.org>
On Wed, Feb 19, 2020 at 09:24:03AM -0600, minyard@acm.org wrote:
> From: Corey Minyard <cminyard@mvista.com>
>
> I was working on a single-step bug on kgdb on an ARM64 system, and I saw
> this scenario:
>
> * A single step is setup to return to el1
> * The ERET return to el1
> * An interrupt is pending and runs before the instruction
> * As soon as PSTATE.D (the debug disable bit) is cleared, the single
> step happens in that location, not where it should have.
>
> This appears to be due to PSTATE.SS not being cleared when the exception
> happens. Per section D.2.12.5 of the ARMv8 reference manual, that
> appears to be incorrect, it says "As part of exception entry, the PE
> does all of the following: ... Sets PSTATE.SS to 0."
Sorry, but I don't follow you here. If PSTATE.SS is not cleared, why would
you take the step exception?
> However, I appear to not be the first person who has noticed this. In
> the el0-only portion of the kernel_entry macro in entry.S, I found the
> following comment: "Ensure MDSCR_EL1.SS is clear, since we can unmask
> debug exceptions when scheduling." Exactly the same scenario, except
> coming from a userland single step, not a kernel one.
No, I think you might be conflating PSTATE.SS and MDSCR_EL1.SS.
> As I was studying this, though, I realized that the following scenario
> had an issue:
>
> * Kernel enables MDSCR.SS, MDSCR.KDE, MDSCR.MDE (unnecessary), and
> PSTATE.SS to enable a single step in el1, for kgdb or kprobes,
> on the current CPU's MDSCR register and the process' PSTATE.SS
> register.
> * Kernel returns from the exception with ERET.
> * An interrupt or page fault happens on the instruction, causing the
> instruction to not be run, but the exception handler runs.
> * The exception causes the task to migrate to a new core.
> * The return from the exception runs on a different processor now,
> where the MDSCR values are not set up for a single step.
> * The single step fails to happen.
>
> This is bad for kgdb, of course, but it seems really bad for kprobes if
> this happens.
I don't see how this can happen for kprobes. Have you managed to reproduce
the failure?
> To fix both these problems, rework the handling of single steps to clear
> things out upon entry to the kernel from el1, and then to set up single
> step when returning to el1, and not do the setup in debug-monitors.c.
> This means that single stepping does not use
> enable/disable_debug_monitors(); it is no longer necessary to track
> those flags for single stepping. This is much like single stepping is
> handled for el0. A new flag is added in pt_regs to enable single
> stepping from el1. Unfortunately, the old value of PSTATE.SS cannot be
> used for this because of the hardware bug mentioned earlier.
I don't think there's a hardware bug.
It sound like you're trying to make kernel debugging per-task instead
of per-cpu, but I don't think that's the right thing to do. What if I /want/
to debug an interrupt handler? For example, I might have a watchpoint on
something accessed by timer interrupt.
> As part of this, there is an interaction between single stepping and the
> other users of debug monitors with the MDSCR.KDE bit. That bit has to
> be set for both hardware breakpoints at el1 and single stepping at el1.
> A new variable was created to store the cpu-wide value of MDSCR.KDE; the
> single stepping code makes sure not to clear that bit on kernel entry if
> it's set in the per-cpu variable.
>
> After fixing this and doing some more testing, I ran into another issue:
>
> * Kernel enables the pt_regs single step
> * Kernel returns from the exception with ERET.
> * An interrupt or page fault happens on the instruction, causing the
> instruction to not be run, but the exception handler runs.
This sounds like you've broken debug; we should take the step exception
in the exception handler. That's the way this is supposed to work.
> There's no easy way to find the pt_regs that has the single step flag
> set. So a thread info flag was added so that the single step could be
> disabled in this case. Both that flag and the flag in pt_regs must be
> set to enable a single step.
Honestly, I get the feeling that you don't really understand the code
you're changing here and it's a tonne of effort to try to untangle what
you're doing. That's not necessarily your fault because the debug
architecture is a nightmare to comprehend, but I'm not keen to change it
unless we have a really good justification. I'm sure kgdb is riddled with
bugs but, as I said before, the fixes should be in kgdb, not by tearing
up the low-level debug code (which has the potential to break other users).
Maybe it would be easier if you tried to fix one problem per patch,
preferably with a way to reproduce the issue you're seeing each time?
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Questions about logic_pio
From: John Garry @ 2020-02-20 14:23 UTC (permalink / raw)
To: Jiaxun Yang
Cc: Wei Xu, bhelgaas, andyshevchenko, Arnd Bergmann, linux-kernel,
Linux Mips
In-Reply-To: <17062738bc0.c380503c6222.6801557833645076299@flygoat.com>
> Also Cc MIPS list to check other's opinions.
>
> Hi John.
>
Hi Jiaxun Yang,
> Thanks for your kind explanation, however, I think this way is
> violating how I/O ports supposed to work, at least in MIPS world.
For a bit more history, please understand that the core PCI code was
managing non-native IO port space in the same way before we added the
logic PIO framework. The only real functional change here was that we
introduced the indirect-io region within the IO port space, under
CONFIG_INDIRECT_PIO.
>
> > >>
> > >> After dig into logic pio logic, I found that logic pio is trying to "allocate" an io_start
> > >> for MMIO ranges, the allocation starts from 0x0. And later the io_start is used to calculate
> > >> cpu_address. In my opinion, for direct MMIO access, logic_pio address should always
> > >> equal to hw address,
> >
> > I'm not sure what you mean by simply the hw address.
> >
>
> I meant hw_start should always equal to io_start.
>
>
> MIPS have their own wrapped inl/outl functions,
Can you please point me to these? I could not find them in arch/mips
I will also note that arch/mips/include/asm/io.h does not include
asm-generic io.h today
doing the samething with
> PCI_IOBASE enabled one. I was just trying to use PCI_IOBASE instead.
>
> Originally, the I/O ports layout seems like this:
>
> 00000020-00000021 : pic1
> 00000060-0000006f : i8042
> 00000070-00000077 : rtc0
> 000000a0-000000a1 : pic2
> 00000170-00000177 : pata_atiixp
> 000001f0-000001f7 : pata_atiixp
> 00000376-00000376 : pata_atiixp
> 000003f6-000003f6 : pata_atiixp
> 00000800-000008ff : acpi
> 00001000-00001008 : piix4_smbus
> 00004000-0003ffff : pci io space
> 00004000-00004fff : PCI Bus 0000:01
> 00004000-000040ff : 0000:01:05.0
> 00005000-00005fff : PCI Bus 0000:03
> 00005000-0000501f : 0000:03:00.0
>
> But with PCI_IOBASE defined, I got this:
>
> host bridge /bus@10000000/pci@10000000 ranges:
> MEM 0x0040000000..0x007fffffff -> 0x0040000000
> IO 0x0000004000..0x0000007fff -> 0x0000004000
> resource collision: [io 0x0000-0x3fff] conflicts with pic1 [io 0x0020-0x0021]
>
> Because io_start was allocated to 0x0 by Logic PIO.
>
> There are a lot of devices that have fixed ioports thanks to x86's legacy.
Well, yes, I'm not so surprised.
So if MIPS does not have native IO port access, then surely you need
some host bridge to translate host CPU MMIO accesses to port I/O
accesses, right? Where are these CPU addresses defined?
> For example, in my hardware, ioports for RTC, PIC, I8042 are unmoveable,
> and they can't be managed by logic pio subsystem. > Also, the PCI Hostbridge got implied by DeviceTree that it's I/O range
> started from 0x4000 in bus side
which bus is this?
, but then, Logic PIO remapped to PCI_IOBASE + 0x0.
> The real address should be PCI_IOBASE + 0x4000,
You seem to be using two methods to manage IO port space, and they seem
to be conflicting.
> hardware never got correctly informed about that. And there is still no way to
> transform to correct address as it's inside the MMIO_LIMIT.
>
> So the question comes to why we're allocating io_start for MMIO PCI_IOBASE
> rather than just check the range provided doesn't overlap each other or exceed
> the MMIO_LIMIT.
When PCI_IOBASE is defined, we work on the basis that any IO port range
in the system is registered for a logical PIO region, which manages the
actual IO port addresses - see logic_pio_trans_cpuaddr().
Thanks,
John
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Jürgen Groß @ 2020-02-20 14:23 UTC (permalink / raw)
To: Roger Pau Monné, Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, xen-devel
In-Reply-To: <20200220141117.GK4679@Air-de-Roger>
On 20.02.20 15:11, Roger Pau Monné wrote:
> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
>> On 20.02.2020 13:02, Roger Pau Monne wrote:
>>> I've done some testing and at least the CPU down case is fixed now.
>>> Posting early in order to get feedback on the approach taken.
>>
>> Looks good, thanks, just a question and two comments:
>>
>>> --- a/xen/include/xen/rwlock.h
>>> +++ b/xen/include/xen/rwlock.h
>>> @@ -20,21 +20,30 @@ typedef struct {
>>> #define DEFINE_RWLOCK(l) rwlock_t l = RW_LOCK_UNLOCKED
>>> #define rwlock_init(l) (*(l) = (rwlock_t)RW_LOCK_UNLOCKED)
>>>
>>> -/*
>>> - * Writer states & reader shift and bias.
>>> - *
>>> - * Writer field is 8 bit to allow for potential optimisation, see
>>> - * _write_unlock().
>>> - */
>>> -#define _QW_WAITING 1 /* A writer is waiting */
>>> -#define _QW_LOCKED 0xff /* A writer holds the lock */
>>> -#define _QW_WMASK 0xff /* Writer mask.*/
>>> -#define _QR_SHIFT 8 /* Reader count shift */
>>> +/* Writer states & reader shift and bias. */
>>> +#define _QW_WAITING 1 /* A writer is waiting */
>>> +#define _QW_LOCKED 3 /* A writer holds the lock */
>>
>> Aiui things would work equally well if 2 was used here?
>
> I think so, I left it as 3 because previously LOCKED would also
> include WAITING, and I didn't want to change it in case I've missed
> some code path that was relying on that.
>
>>
>>> +#define _QW_WMASK 3 /* Writer mask */
>>> +#define _QW_CPUSHIFT 2 /* Writer CPU shift */
>>> +#define _QW_CPUMASK 0x3ffc /* Writer CPU mask */
>>
>> At least on x86, the shift involved here is quite certainly
>> more expensive than using wider immediates on AND and CMP
>> resulting from the _QW_MASK-based comparisons. I'd therefore
>> like to suggest to put the CPU in the low 12 bits.
>
> Hm right. The LOCKED and WAITING bits don't need shifting anyway.
>
>>
>> Another option is to use the recurse_cpu field of the
>> associated spin lock: The field is used for recursive locks
>> only, and hence the only conflict would be with
>> _spin_is_locked(), which we don't (and in the future then
>> also shouldn't) use on this lock.
>
> I looked into that also, but things get more complicated AFAICT, as it's
> not possible to atomically fetch the state of the lock and the owner
> CPU at the same time. Neither you could set the LOCKED bit and the CPU
> at the same time.
>
>>
>>> @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
>>> * If the writer field is atomic, it can be cleared directly.
>>> * Otherwise, an atomic subtraction will be used to clear it.
>>> */
>>> - atomic_sub(_QW_LOCKED, &lock->cnts);
>>> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
>>> + atomic_sub(_write_lock_val(), &lock->cnts);
>>
>> I think this would be more efficient with atomic_and(), not
>> the least because of the then avoided smp_processor_id().
>> Whether to mask off just _QW_WMASK or also the CPU number of
>> the last write owner would need to be determined. But with
>> using subtraction, in case of problems it'll likely be
>> harder to understand what actually went on, from looking at
>> the resulting state of the lock (this is in part a pre-
>> existing problem, but gets worse with subtraction of CPU
>> numbers).
>
> Right, a mask would be better. Right now both need to be cleared (the
> LOCKED and the CPU fields) as there's code that relies on !lock->cnts
> as a way to determine that the lock is not read or write locked. If we
> left the CPU lying around those checks would need to be adjusted.
In case you make _QR_SHIFT 16 it is possible to just write a 2-byte zero
value for write_unlock() (like its possible to do so today using a
single byte write).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: NVMe/IB support
From: Christoph Hellwig @ 2020-02-20 14:25 UTC (permalink / raw)
To: Max Gurtovoy; +Cc: Christoph Hellwig, Talker Alex, linux-nvme
In-Reply-To: <e2f116a2-ee5a-ee53-32c2-1f1e8d998567@mellanox.com>
On Thu, Feb 20, 2020 at 04:13:07PM +0200, Max Gurtovoy wrote:
>
> On 2/19/2020 5:20 PM, Christoph Hellwig wrote:
> > On Fri, Feb 07, 2020 at 03:43:22PM +0300, Talker Alex wrote:
> > > Hi,
> > >
> > > is there really exist NVMe/IB solutions?
> > All the original NVMeoF development was done on IB, just using the
> > RDMA/CM IP based addressing.
>
> I guess we can consider adding this code one day, for users that can't use
> RDMA/CM (SRP supports both options).
The NVMeOF RDMA transport requires RDMA/CM. But RDMA/CM can also use
IB addressing, which should be easy enough to implement if someone
cares.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: Modern uses of CONFIG_XFS_RT
From: Brian Foster @ 2020-02-20 14:25 UTC (permalink / raw)
To: Dave Chinner
Cc: Luis Chamberlain, Richard Wareing, linux-xfs, Anthony Iliopoulos
In-Reply-To: <20200220034106.GO10776@dread.disaster.area>
On Thu, Feb 20, 2020 at 02:41:06PM +1100, Dave Chinner wrote:
> On Wed, Feb 19, 2020 at 01:57:15PM +0000, Luis Chamberlain wrote:
> > I hear some folks still use CONFIG_XFS_RT, I was curious what was the
> > actual modern typical use case for it. I thought this was somewhat
> > realted to DAX use but upon a quick code inspection I see direct
> > realtionship.
>
> Facebook use it in production systems to separate large file data
> from metadata and small files. i.e. they use a small SSD based
> partition for the filesytem metadata and a spinning disk for
> the large scale data storage. Essentially simple teired storage.
>
Didn't this involve custom functionality? I thought they had posted
something at one point that wasn't seen through to merge, but I could be
misremembering (or maybe that was something else RT related). It doesn't
matter that much as there are probably other users out there, but I'm
not sure this serves as a great example use case if it did require
downstream customizations that aren't going to be generalized/supported
for the community.. Richard..?
Brian
> It's also commonly still used in multi-stream DVRs (think
> multi-camera security systems), and other similar sequential access
> data applications...
>
> That's just a couple off the top of my head...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>
^ permalink raw reply
* Re: [PATCH v3 09/25] fs: add is_userns_visible() helper
From: Serge E. Hallyn @ 2020-02-20 14:26 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Christian Brauner, Serge E. Hallyn, Stéphane Graber,
Eric W. Biederman, Aleksa Sarai, Jann Horn, smbarber,
Seth Forshee, Alexander Viro, Alexey Dobriyan, James Morris,
Kees Cook, Jonathan Corbet, Phil Estes, LKML, Linux FS Devel,
Linux Containers, LSM List, Linux API
In-Reply-To: <CALCETrW-XPkBMs30vk+Aiv+jA5i7TjHOYCgz0Ud6d0geaYte=g@mail.gmail.com>
On Wed, Feb 19, 2020 at 09:18:51AM -0800, Andy Lutomirski wrote:
> On Wed, Feb 19, 2020 at 4:06 AM Christian Brauner
> <christian.brauner@ubuntu.com> wrote:
> >
> > On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote:
> > > On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
> > > > Introduce a helper which makes it possible to detect fileystems whose
> > > > superblock is visible in multiple user namespace. This currently only
> > > > means proc and sys. Such filesystems usually have special semantics so their
> > > > behavior will not be changed with the introduction of fsid mappings.
> > >
> > > Hi,
> > >
> > > I'm afraid I've got a bit of a hangup about the terminology here. I
> > > *think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
> > > always translated per the id mappings, not fsid mappings. But when I see
> >
> > Correct!
> >
> > > the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
> > > be seen by other namespaces at all.
> > >
> > > Am I right in my first interpretation? If so, can we talk about the
> > > naming?
> >
> > Yep, your first interpretation is right. What about: wants_idmaps()
>
> Maybe fsidmap_exempt()?
Yeah, and maybe SB_USERNS_FSID_EXEMPT ?
> I still haven't convinced myself that any of the above is actually
> correct behavior, especially when people do things like creating
> setuid binaries.
The only place that would be a problem is if the child userns has an
fsidmapping from X to 0 in the parent userns, right? Yeah I'm sure
many people would ignore all advice to the contrary and do this anyway,
but I would try hard to suggest that people use an intermediary userns
for storing filesystems for the "docker share" case. So the host fsid
range would start at say 200000. So a setuid binary would just be
setuid-200000.
^ permalink raw reply
* [Bug 1857811] Re: qemu user static binary seems to lack support for network namespace.
From: Laurent Vivier @ 2020-02-20 14:13 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <157762661516.5433.16221584605990009162.malonedeb@gac.canonical.com>
I need the strace result of _configure_loopback_interface in a qemu-
aarch64 chroot.
But as strace cannot be started in the chroot you must strace the
"chroot" command and its children.
So something like "sudo strace -yyy chroot <your chroot directory> <your
test path>"
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1857811
Title:
qemu user static binary seems to lack support for network namespace.
Status in QEMU:
New
Bug description:
Whenever I execute emerge in gentoo linux in qemu-aarch64 chroot, I
see the following error message.
Unable to configure loopback interface: Operation not supported
If I disable emerge's network-sandbox which utilizes network
namespace, the error disappears.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1857811/+subscriptions
^ permalink raw reply
* Re: [PATCH v2 13/21] btrfs: move vairalbes for clustered allocation into find_free_extent_ctl
From: Christoph Hellwig @ 2020-02-20 14:27 UTC (permalink / raw)
To: Naohiro Aota
Cc: linux-btrfs, David Sterba, Chris Mason, Josef Bacik,
Nikolay Borisov, Damien Le Moal, Johannes Thumshirn,
Hannes Reinecke, Anand Jain, linux-fsdevel
In-Reply-To: <20200212072048.629856-14-naohiro.aota@wdc.com>
s/vairalbes/variables/ in the Subject.
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: Greg KH @ 2020-02-20 14:27 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220081420.GA3328448@kroah.com>
On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> >
> > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > leaks data across cores sharing the HW-RNG for vulnerable processors.
> >
> > This leak is fixed by a microcode update and is enabled by default.
> >
> > This new microcode serializes processor access during execution of RDRAND
> > or RDSEED. It ensures that the shared buffer is overwritten before it
> > is released for reuse.
> >
> > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > and latency of RT processing running on the socket while executing RDRAND or
> > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
>
> Then we need to stop using RDRAND internally for our "give me a random
> number api" which has spread to more and more parts of the kernel.
>
> Here's a patch that does so:
> https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> which I'm going to advise get merged now and backported to the stable
> branches.
Note, the author of that patch has reached out to me to say they found
this same issue. He did so independantly so odds are others already
know about this. He found it because he was wondering why rdrand was so
slow on newer systems, and then traced things backwards like all the
other researchers in this area.
So, what's the timeline here? Looks like this is already "in the wild"
from what I can tell.
greg k-h
^ permalink raw reply
* [Xen-devel] [linux-5.4 test] 147286: regressions - FAIL
From: osstest service owner @ 2020-02-20 14:27 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147286 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 146121
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 146121
Tests which are failing intermittently (not blocking):
test-amd64-amd64-libvirt-vhd 20 leak-check/check fail pass in 147210
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 146121
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail REGR. vs. 146121
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-thunderx 13 migrate-support-check fail never pass
test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
version targeted for testing:
linux 27dfbcc2f53d5b14ef78156d15ff92619807d46c
baseline version:
linux 122179cb7d648a6f36b20dd6bf34f953cb384c30
Last test of basis 146121 2020-01-15 17:42:04 Z 35 days
Failing since 146178 2020-01-17 02:59:07 Z 34 days 63 attempts
Testing same since 147129 2020-02-16 10:37:40 Z 4 days 3 attempts
------------------------------------------------------------
1051 people touched revisions under test,
not listing them all
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
test-amd64-i386-xl-qemuu-ovmf-amd64 fail
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-amd64-examine pass
test-arm64-arm64-examine pass
test-armhf-armhf-examine pass
test-amd64-i386-examine pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds fail
test-armhf-armhf-xl-rtds fail
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx pass
test-amd64-amd64-libvirt-vhd fail
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
(No revision log; it would be 55132 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 14:27 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo50pCb4OafEs9tLm7YEPqHc+BtDAvagRnwjXtZeQDNwUwg@mail.gmail.com>
On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct drm_display_mode):
> > 200 -> 136 bytes (-32%)
> >
> > 64bit bloat-o-meter -c drm.ko:
> > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > Function old new delta
> > ...
> > Total: Before=189430, After=188779, chg -0.34%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=11667, After=11667, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 1000 680 -320
> > edid_est_modes 3400 2312 -1088
> > edid_cea_modes_193 5400 3672 -1728
> > drm_dmt_modes 17600 11968 -5632
> > edid_cea_modes_1 25400 17272 -8128
> > Total: Before=71239, After=54343, chg -23.72%
> >
> >
> > 64bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > ...
> > Total: Before=272336, After=254789, chg -6.44%
> >
> >
> > 32bit sizeof(struct drm_display_mode):
> > 184 -> 120 bytes (-34%)
> >
> > 32bit bloat-o-meter -c drm.ko
> > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > Function old new delta
> > ...
> > Total: Before=172359, After=171734, chg -0.36%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=4227, After=4227, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 920 600 -320
> > edid_est_modes 3128 2040 -1088
> > edid_cea_modes_193 4968 3240 -1728
> > drm_dmt_modes 16192 10560 -5632
> > edid_cea_modes_1 23368 15240 -8128
> > Total: Before=59230, After=42334, chg -28.53%
> >
> > 32bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > ...
> > Total: Before=235816, After=218295, chg -7.43%
> >
> >
> > Some ideas for further reduction:
> > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > struct but would often require a heap alloc for the name (though
> > typical mode name is <10 bytes so still overall win perhaps)
> > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > place where we have to preserve the user provided name, elsewhere
> > could pehaps just generate on demand? Not sure how tricky this
> > would get.
>
> The series does some great work, with future work reaching the cache
> line for 64bit.
> Doing much more than that might be an overkill IMHO.
>
> In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> avoiding the heap alloc/calc on demand fun.
> While also ensuring the name is sufficiently large for the next decade or so.
Unfortunately it's part of the uabi. So can't change it without some
risk of userspace breakage.
The least demanding option is probably to nuke export_head. We need
one bit to replace it, which we can get by either:
- stealing from eg. mode->type, or perhaps mode->private_flags
- nuke private_flags outright and replace it with a bool for this
purpose
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 14:27 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <CACvgo50pCb4OafEs9tLm7YEPqHc+BtDAvagRnwjXtZeQDNwUwg@mail.gmail.com>
On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > struct drm_display_mode is extremely fat. Put it on diet.
> >
> > Some stats for the whole series:
> >
> > 64bit sizeof(struct drm_display_mode):
> > 200 -> 136 bytes (-32%)
> >
> > 64bit bloat-o-meter -c drm.ko:
> > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > Function old new delta
> > ...
> > Total: Before=189430, After=188779, chg -0.34%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=11667, After=11667, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 1000 680 -320
> > edid_est_modes 3400 2312 -1088
> > edid_cea_modes_193 5400 3672 -1728
> > drm_dmt_modes 17600 11968 -5632
> > edid_cea_modes_1 25400 17272 -8128
> > Total: Before=71239, After=54343, chg -23.72%
> >
> >
> > 64bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > ...
> > Total: Before=272336, After=254789, chg -6.44%
> >
> >
> > 32bit sizeof(struct drm_display_mode):
> > 184 -> 120 bytes (-34%)
> >
> > 32bit bloat-o-meter -c drm.ko
> > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > Function old new delta
> > ...
> > Total: Before=172359, After=171734, chg -0.36%
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Data old new delta
> > Total: Before=4227, After=4227, chg +0.00%
> > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > RO Data old new delta
> > edid_4k_modes 920 600 -320
> > edid_est_modes 3128 2040 -1088
> > edid_cea_modes_193 4968 3240 -1728
> > drm_dmt_modes 16192 10560 -5632
> > edid_cea_modes_1 23368 15240 -8128
> > Total: Before=59230, After=42334, chg -28.53%
> >
> > 32bit bloat-o-meter drm.ko:
> > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > ...
> > Total: Before=235816, After=218295, chg -7.43%
> >
> >
> > Some ideas for further reduction:
> > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > struct but would often require a heap alloc for the name (though
> > typical mode name is <10 bytes so still overall win perhaps)
> > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > place where we have to preserve the user provided name, elsewhere
> > could pehaps just generate on demand? Not sure how tricky this
> > would get.
>
> The series does some great work, with future work reaching the cache
> line for 64bit.
> Doing much more than that might be an overkill IMHO.
>
> In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> avoiding the heap alloc/calc on demand fun.
> While also ensuring the name is sufficiently large for the next decade or so.
Unfortunately it's part of the uabi. So can't change it without some
risk of userspace breakage.
The least demanding option is probably to nuke export_head. We need
one bit to replace it, which we can get by either:
- stealing from eg. mode->type, or perhaps mode->private_flags
- nuke private_flags outright and replace it with a bool for this
purpose
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 1/2] ARM: dts: exynos: Fix MMC regulator on Arndale5250 board
From: Marek Szyprowski @ 2020-02-20 14:28 UTC (permalink / raw)
To: linux-samsung-soc
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <CGME20200220142814eucas1p2a230d064c9cebcc029ce12b228fd31ac@eucas1p2.samsung.com>
According to the schematic, both eMMC and SDMMC use dedicated fixed
regulators connected directly to the DC5V and MAIN_DC rails. Remove the
GPX1-1 line assigned to the MMC regulator, because such control
connection doesn't exist. Also change its name to VDD_MMC to avoid
conflict with LDO18 output of S5M8767 PMIC.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index f8ebc620f42d..bff24c61212b 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -98,11 +98,9 @@
mmc_reg: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
- regulator-name = "VDD_33ON_2.8V";
+ regulator-name = "VDD_MMC";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
- gpio = <&gpx1 1 GPIO_ACTIVE_HIGH>;
- enable-active-high;
};
reg_hdmi_en: regulator@2 {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: exynos: Make fixed regulators always-on on Arndale5250
From: Marek Szyprowski @ 2020-02-20 14:28 UTC (permalink / raw)
To: linux-samsung-soc
Cc: Marek Szyprowski, Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20200220142806.19340-1-m.szyprowski@samsung.com>
The fixed regulators defined for Arndale5250 boards have no control lines,
so mark them as 'always-on' to better describe the hardware and also kill
the strange messages like 'MAIN_DC: disabling' after boot.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/boot/dts/exynos5250-arndale.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index bff24c61212b..6904091d4837 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -93,6 +93,7 @@
compatible = "regulator-fixed";
reg = <0>;
regulator-name = "MAIN_DC";
+ regulator-always-on;
};
mmc_reg: regulator@1 {
@@ -101,12 +102,14 @@
regulator-name = "VDD_MMC";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
+ regulator-always-on;
};
reg_hdmi_en: regulator@2 {
compatible = "regulator-fixed";
reg = <2>;
regulator-name = "hdmi-en";
+ regulator-always-on;
};
vcc_1v2_reg: regulator@3 {
@@ -115,6 +118,7 @@
regulator-name = "VCC_1V2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
+ regulator-always-on;
};
vcc_1v8_reg: regulator@4 {
@@ -123,6 +127,7 @@
regulator-name = "VCC_1V8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
+ regulator-always-on;
};
vcc_3v3_reg: regulator@5 {
@@ -131,6 +136,7 @@
regulator-name = "VCC_3V3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ regulator-always-on;
};
};
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
From: Eric Blake @ 2020-02-20 14:28 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <0b884ddcd0ac3a3c0b8cdd9d09c74566ac107c9a.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> Subcluster allocation in qcow2 is implemented by extending the
> existing L2 table entries and adding additional information to
> indicate the allocation status of each subcluster.
>
> This patch documents the changes to the qcow2 format and how they
> affect the calculation of the L2 cache size.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> docs/interop/qcow2.txt | 68 ++++++++++++++++++++++++++++++++++++++++--
> docs/qcow2-cache.txt | 19 +++++++++++-
> 2 files changed, 83 insertions(+), 4 deletions(-)
This adds a new feature bit; where is the corresponding patch to qcow2.c
to advertise the feature bit name in the optional feature name table?
/me reads ahead
good, patch 25 covers it. Quick comment added there as a result.
> +== Extended L2 Entries ==
> +
> +An image uses Extended L2 Entries if bit 3 is set on the incompatible_features
> +field of the header.
> +
> +In these images standard data clusters are divided into 32 subclusters of the
> +same size. They are contiguous and start from the beginning of the cluster.
> +Subclusters can be allocated independently and the L2 entry contains information
> +indicating the status of each one of them. Compressed data clusters don't have
> +subclusters so they are treated like in images without this feature.
Grammar; I'd suggest:
...don't have subclusters, so they are treated the same as in images
without this feature.
Are they truly the same, or do you still need to document that the extra
64 bits of the extended L2 entry are all zero?
> +
> +The size of an extended L2 entry is 128 bits so the number of entries per table
> +is calculated using this formula:
> +
> + l2_entries = (cluster_size / (2 * sizeof(uint64_t)))
> +
> +The first 64 bits have the same format as the standard L2 table entry described
> +in the previous section, with the exception of bit 0 of the standard cluster
> +descriptor.
> +
> +The last 64 bits contain a subcluster allocation bitmap with this format:
> +
> +Subcluster Allocation Bitmap (for standard clusters):
> +
> + Bit 0 - 31: Allocation status (one bit per subcluster)
> +
> + 1: the subcluster is allocated. In this case the
> + host cluster offset field must contain a valid
> + offset.
> + 0: the subcluster is not allocated. In this case
> + read requests shall go to the backing file or
> + return zeros if there is no backing file data.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 31 - x)
> +
Missing trailing '.'
> + 32 - 63 Subcluster reads as zeros (one bit per subcluster)
> +
> + 1: the subcluster reads as zeros. In this case the
> + allocation status bit must be unset. The host
> + cluster offset field may or may not be set.
Why must the allocation bit be unset? When we preallocate, we want a
cluster to reserve space, but still read as zero, so the combination of
both bits set makes sense to me.
> + 0: no effect.
> +
> + Bits are assigned starting from the most significant one.
> + (i.e. bit x is used for subcluster 63 - x)
and again.
> +
> +Subcluster Allocation Bitmap (for compressed clusters):
> +
> + Bit 0 - 63: Reserved (set to 0)
> + Compressed clusters don't have subclusters,
> + so this field is not used.
>
> == Snapshots ==
>
> diff --git a/docs/qcow2-cache.txt b/docs/qcow2-cache.txt
> index d57f409861..04eb4ce2f1 100644
> --- a/docs/qcow2-cache.txt
> +++ b/docs/qcow2-cache.txt
> @@ -1,6 +1,6 @@
> qcow2 L2/refcount cache configuration
> =====================================
> -Copyright (C) 2015, 2018 Igalia, S.L.
> +Copyright (C) 2015, 2018-2019 Igalia, S.L.
Our review is late; you could add 2020 if desired, now.
> Author: Alberto Garcia <berto@igalia.com>
>
> This work is licensed under the terms of the GNU GPL, version 2 or
> @@ -222,3 +222,20 @@ support this functionality, and is 0 (disabled) on other platforms.
> This functionality currently relies on the MADV_DONTNEED argument for
> madvise() to actually free the memory. This is a Linux-specific feature,
> so cache-clean-interval is not supported on other systems.
> +
> +
> +Extended L2 Entries
> +-------------------
> +All numbers shown in this document are valid for qcow2 images with normal
> +64-bit L2 entries.
> +
> +Images with extended L2 entries need twice as much L2 metadata, so the L2
> +cache size must be twice as large for the same disk space.
> +
> + disk_size = l2_cache_size * cluster_size / 16
> +
> +i.e.
> +
> + l2_cache_size = disk_size * 16 / cluster_size
> +
> +Refcount blocks are not affected by this.
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.