All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 2/2] qemu-cpu-models.rst: Document -noTSX, mds-no, taa-no, and tsx-ctrl
From: Kashyap Chamarthy @ 2020-02-20 14:02 UTC (permalink / raw)
  To: kchamart, qemu-devel; +Cc: peter.maydell, berrange, ehabkost
In-Reply-To: <20200220140210.14209-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>
---
 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:02 UTC (permalink / raw)
  To: kchamart, qemu-devel; +Cc: peter.maydell, berrange, ehabkost
In-Reply-To: <20200220140210.14209-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: [PULL 00/36] Block layer patches
From: Peter Maydell @ 2020-02-20 14:04 UTC (permalink / raw)
  To: Kevin Wolf; +Cc: QEMU Developers, Qemu-block
In-Reply-To: <20200218140722.23876-1-kwolf@redhat.com>

On Tue, 18 Feb 2020 at 14:08, Kevin Wolf <kwolf@redhat.com> wrote:
>
> The following changes since commit 6c599282f8ab382fe59f03a6cae755b89561a7b3:
>
>   Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2020-02-15-v2' into staging (2020-02-17 13:32:25 +0000)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to c45a88f4429d7a8f384b75f3fd3fed5138a6edca:
>
>   iotests: Check that @replaces can replace filters (2020-02-18 14:52:16 +0100)
>
> ----------------------------------------------------------------
> Block layer patches:
>
> - Fix check_to_replace_node()
> - commit: Expose on-error option in QMP
> - qcow2: Fix qcow2_alloc_cluster_abort() for external data file
> - mirror: Fix deadlock
> - vvfat: Fix segfault while closing read-write node
> - Code cleanups
>
> ----------------------------------------------------------------


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/5.0
for any user-visible changes.

-- PMM


^ permalink raw reply

* Re: a bug(BUG: kernel NULL pointer dereference) of ib or mlx happened in 5.4.21 but not in 5.4.20
From: Leon Romanovsky @ 2020-02-20 14:05 UTC (permalink / raw)
  To: Chuck Lever; +Cc: Wang Yugui, linux-rdma
In-Reply-To: <FD4E1E87-28CF-4F4C-BBF4-2BD945142A14@oracle.com>

On Thu, Feb 20, 2020 at 08:57:29AM -0500, Chuck Lever wrote:
> Hello!
>
> Thanks for your bug report.
>
>
> > On Feb 19, 2020, at 10:22 PM, Wang Yugui <wangyugui@e16-tech.com> wrote:
> >
> > Hi, chuck.lever
> >
> > a bug(BUG: kernel NULL pointer dereference) of ib or mlx happened in 5.4.21 but not in 5.4.20.
> >
> > maybe some releationship to xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch
>
> I don't see an obvious connection to fix-dma-scatter-gather-list-mapping-imbalance.
> The backtrace below is through IPoIB code paths. Those have nothing to do with
> NFS/RDMA, which is the only ULP code that is changed by my commit.
>
>
> > maybe the info is useful.
>
> I'm copying linux-rdma for a bigger set of eyeballs.
>
> My knee-jerk recommendation is that if you have a reliable reproducer, try "git bisect"
> between .20 and .21 to nail down a specific commit where the BUG starts to occur.

No need to bisect, it is me who broke.
The fix is already accepted, but not yet merged.
https://patchwork.kernel.org/patch/11387567/

Thanks

^ permalink raw reply

* Re: [RESEND RFC PATCH v3] clk: Use new helper in managed functions
From: Marc Gonzalez @ 2020-02-20 14:05 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Stephen Boyd, Michael Turquette, Kuninori Morimoto, Russell King,
	Sudip Mukherjee, Dmitry Torokhov, Guenter Roeck, Bjorn Andersson,
	Robin Murphy, Geert Uytterhoeven, Arnd Bergmann, Ard Biesheuvel,
	Rafael Wysocki, Suzuki Poulose, Mark Rutland, linux-clk,
	Linux ARM, LKML
In-Reply-To: <20200220112700.GJ3374196@kroah.com>

On 20/02/2020 12:27, Greg Kroah-Hartman wrote:

> On Thu, Feb 20, 2020 at 11:04:58AM +0100, Marc Gonzalez wrote:
>
>> Introduce devm_add() to wrap devres_alloc() / devres_add() calls.
>>
>> Using that helper produces simpler code, and smaller object size.
>> E.g. with gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu:
>>
>>     text	   data	    bss	    dec	    hex	filename
>> -   1708	     80	      0	   1788	    6fc	drivers/clk/clk-devres.o
>> +   1524	     80	      0	   1604	    644	drivers/clk/clk-devres.o
>>
>> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
>> ---
>> Differences from v2 to v3
>> x Make devm_add() return an error-code rather than the raw data pointer
>>   (in case devres_alloc ever returns an ERR_PTR) as suggested by Geert
>> x Provide a variadic version devm_vadd() to work with structs as suggested
>>   by Geert
>> x Don't use nested ifs in clk_devm* implementations (hopefully simpler
>>   code logic to follow) as suggested by Geert
>>
>> Questions:
>> x This patch might need to be split in two? (Introduce the new API, then use it)
>> x Convert other subsystems to show the value of this proposal?
>> x Maybe comment the API usage somewhere
>> ---
>>  drivers/base/devres.c    | 15 ++++++
>>  drivers/clk/clk-devres.c | 99 ++++++++++++++--------------------------
>>  include/linux/device.h   |  3 ++
>>  3 files changed, 53 insertions(+), 64 deletions(-)
>>
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
>> index 0bbb328bd17f..b2603789755b 100644
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -685,6 +685,21 @@ int devres_release_group(struct device *dev, void *id)
>>  }
>>  EXPORT_SYMBOL_GPL(devres_release_group);
>>  
>> +int devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
> 
> Please add a bunch of kerneldoc here, as I have no idea what this
> function does just by looking at the name of it :(

Fair enough. (This was one of my "Questions" in the patch comments.)

Note: My patch adds a new function, then makes use of said function.
Is this typically done in two patches or one?

Patch 1/2 augmenting the API.
Patch 2/2 making use of the new function.

Regards.

^ permalink raw reply

* Re: [RESEND RFC PATCH v3] clk: Use new helper in managed functions
From: Marc Gonzalez @ 2020-02-20 14:05 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Mark Rutland, linux-clk, LKML, Arnd Bergmann, Kuninori Morimoto,
	Ard Biesheuvel, Stephen Boyd, Suzuki Poulose, Michael Turquette,
	Dmitry Torokhov, Rafael Wysocki, Russell King, Bjorn Andersson,
	Geert Uytterhoeven, Linux ARM, Robin Murphy, Sudip Mukherjee,
	Guenter Roeck
In-Reply-To: <20200220112700.GJ3374196@kroah.com>

On 20/02/2020 12:27, Greg Kroah-Hartman wrote:

> On Thu, Feb 20, 2020 at 11:04:58AM +0100, Marc Gonzalez wrote:
>
>> Introduce devm_add() to wrap devres_alloc() / devres_add() calls.
>>
>> Using that helper produces simpler code, and smaller object size.
>> E.g. with gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu:
>>
>>     text	   data	    bss	    dec	    hex	filename
>> -   1708	     80	      0	   1788	    6fc	drivers/clk/clk-devres.o
>> +   1524	     80	      0	   1604	    644	drivers/clk/clk-devres.o
>>
>> Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
>> ---
>> Differences from v2 to v3
>> x Make devm_add() return an error-code rather than the raw data pointer
>>   (in case devres_alloc ever returns an ERR_PTR) as suggested by Geert
>> x Provide a variadic version devm_vadd() to work with structs as suggested
>>   by Geert
>> x Don't use nested ifs in clk_devm* implementations (hopefully simpler
>>   code logic to follow) as suggested by Geert
>>
>> Questions:
>> x This patch might need to be split in two? (Introduce the new API, then use it)
>> x Convert other subsystems to show the value of this proposal?
>> x Maybe comment the API usage somewhere
>> ---
>>  drivers/base/devres.c    | 15 ++++++
>>  drivers/clk/clk-devres.c | 99 ++++++++++++++--------------------------
>>  include/linux/device.h   |  3 ++
>>  3 files changed, 53 insertions(+), 64 deletions(-)
>>
>> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
>> index 0bbb328bd17f..b2603789755b 100644
>> --- a/drivers/base/devres.c
>> +++ b/drivers/base/devres.c
>> @@ -685,6 +685,21 @@ int devres_release_group(struct device *dev, void *id)
>>  }
>>  EXPORT_SYMBOL_GPL(devres_release_group);
>>  
>> +int devm_add(struct device *dev, dr_release_t func, void *arg, size_t size)
> 
> Please add a bunch of kerneldoc here, as I have no idea what this
> function does just by looking at the name of it :(

Fair enough. (This was one of my "Questions" in the patch comments.)

Note: My patch adds a new function, then makes use of said function.
Is this typically done in two patches or one?

Patch 1/2 augmenting the API.
Patch 2/2 making use of the new function.

Regards.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [dpdk-dev] [dpdk-stable] [PATCH] lib/cmdline_rdline: increase command line buf size
From: Wisam Monther @ 2020-02-20 14:06 UTC (permalink / raw)
  To: Thomas Monjalon
  Cc: dev@dpdk.org, Raslan Darawsheh, stable@dpdk.org,
	olivier.matz@6wind.com, bernard.iremonger@intel.com
In-Reply-To: <4718348.687JKscXgg@xps>

Hi,

Sure I'll handle the title with the right prefix.

- consequence on memory usage?
I don't think it will affect much,
Since we are reading from the same buffer all the time,
Read -> reset -> read again -> ...etc

- How critical is this change?
For now it's not that critical, but for testing perspective I think it's critical,
And it's a must to have so we can check un touched scenarios.
Example:
one rule can have outer items, inner items, actions ={ header rewrite, meta actions, duplicate actions, fate action, ..etc} 
thus to test such combination we need to parse more in the cmdline

- Which kind of command is so long?
RTE_FLOW Example:
flow create 2 ingress priority 0 group 4 transfer pattern eth / ipv4 tos spec 0x0 ttl spec 0x0 proto spec 0x6 src spec 4.4.4.11 dst spec 4.4.4.10 tos mask 0x0 ttl mask 0x0 proto mask 0x0 src mask 255.255.255.255 dst mask 255.255.255.255 / tcp src spec 5001 dst spec 38392 flags spec 0x0 src mask 65535 dst mask 65535 flags mask 0x5 / tag index is 0 data spec 0x00000200 data mask 0x0000ff00 / end actions count / set_tag index 0 data 0x00000200 mask 0x0000ff00 / set_tag index 0 data 0x0000002a mask 0x000000ff / set_meta data 0x00000001 mask 0x0000ffff / jump group 7 / end

BRs,
Wisam Jaddo

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: Thursday, February 20, 2020 3:43 PM
To: Wisam Monther <wisamm@mellanox.com>
Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>; stable@dpdk.org; olivier.matz@6wind.com; bernard.iremonger@intel.com
Subject: Re: [dpdk-stable] [PATCH] lib/cmdline_rdline: increase command line buf size

Hi,

About the title, I suggest:
cmdline: increase maximum line length

20/02/2020 14:18, Wisam Jaddo:
> The current size of buffer is not enough to fit all allowed 
> items/actions, thus it will block a lot of testing.
> 
> Cc: stable@dpdk.org

+Cc maintainers of cmdline and testpmd

> Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
[...]
> -#define RDLINE_BUF_SIZE 512
> +#define RDLINE_BUF_SIZE 2048

I feel 2k is reasonable.
What is the consequence on memory usage?

How critical is this change?
Which kind of command is so long?



^ permalink raw reply

* Re: [PATCH 4/8] libxfs: enable tools to check that metadata updates have been committed
From: Brian Foster @ 2020-02-20 14:06 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: sandeen, linux-xfs
In-Reply-To: <158216292664.601264.186457838279269618.stgit@magnolia>

On Wed, Feb 19, 2020 at 05:42:06PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Add a new function that will ensure that everything we changed has
> landed on stable media, and report the results.  Subsequent commits will
> teach the individual programs to report when things go wrong.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
>  include/xfs_mount.h |    3 +++
>  libxfs/init.c       |   43 +++++++++++++++++++++++++++++++++++++++++++
>  libxfs/libxfs_io.h  |    2 ++
>  libxfs/rdwr.c       |   27 +++++++++++++++++++++++++--
>  4 files changed, 73 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/include/xfs_mount.h b/include/xfs_mount.h
> index 29b3cc1b..c80aaf69 100644
> --- a/include/xfs_mount.h
> +++ b/include/xfs_mount.h
> @@ -187,4 +187,7 @@ extern xfs_mount_t	*libxfs_mount (xfs_mount_t *, xfs_sb_t *,
>  extern void	libxfs_umount (xfs_mount_t *);
>  extern void	libxfs_rtmount_destroy (xfs_mount_t *);
>  
> +void libxfs_flush_devices(struct xfs_mount *mp, int *datadev, int *logdev,
> +		int *rtdev);
> +
>  #endif	/* __XFS_MOUNT_H__ */
> diff --git a/libxfs/init.c b/libxfs/init.c
> index a0d4b7f4..d1d3f4df 100644
> --- a/libxfs/init.c
> +++ b/libxfs/init.c
> @@ -569,6 +569,8 @@ libxfs_buftarg_alloc(
>  	}
>  	btp->bt_mount = mp;
>  	btp->dev = dev;
> +	btp->lost_writes = false;
> +
>  	return btp;
>  }
>  
> @@ -791,6 +793,47 @@ libxfs_rtmount_destroy(xfs_mount_t *mp)
>  	mp->m_rsumip = mp->m_rbmip = NULL;
>  }
>  
> +static inline int
> +libxfs_flush_buftarg(
> +	struct xfs_buftarg	*btp)
> +{
> +	if (btp->lost_writes)
> +		return -ENOTRECOVERABLE;

I'm curious why we'd want to skip the flush just because some writes
happened to fail..? I suppose the fs might be borked, but it seems a
little strange to at least not try the flush, particularly since we
might still flush any of the other two possible devices.

> +
> +	return libxfs_blkdev_issue_flush(btp);
> +}
> +
> +/*
> + * Purge the buffer cache to write all dirty buffers to disk and free all
> + * incore buffers.  Buffers that cannot be written will cause the lost_writes
> + * flag to be set in the buftarg.  If there were no lost writes, flush the
> + * device to make sure the writes made it to stable storage.
> + *
> + * For each device, the return code will be set to -ENOTRECOVERABLE if we
> + * couldn't write something to disk; or the results of the block device flush
> + * operation.

Why not -EIO?

Brian

> + */
> +void
> +libxfs_flush_devices(
> +	struct xfs_mount	*mp,
> +	int			*datadev,
> +	int			*logdev,
> +	int			*rtdev)
> +{
> +	*datadev = *logdev = *rtdev = 0;
> +
> +	libxfs_bcache_purge();
> +
> +	if (mp->m_ddev_targp)
> +		*datadev = libxfs_flush_buftarg(mp->m_ddev_targp);
> +
> +	if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp)
> +		*logdev = libxfs_flush_buftarg(mp->m_logdev_targp);
> +
> +	if (mp->m_rtdev_targp)
> +		*rtdev = libxfs_flush_buftarg(mp->m_rtdev_targp);
> +}
> +
>  /*
>   * Release any resource obtained during a mount.
>   */
> diff --git a/libxfs/libxfs_io.h b/libxfs/libxfs_io.h
> index 579df52b..fc0fd060 100644
> --- a/libxfs/libxfs_io.h
> +++ b/libxfs/libxfs_io.h
> @@ -23,10 +23,12 @@ struct xfs_perag;
>  struct xfs_buftarg {
>  	struct xfs_mount	*bt_mount;
>  	dev_t			dev;
> +	bool			lost_writes;
>  };
>  
>  extern void	libxfs_buftarg_init(struct xfs_mount *mp, dev_t ddev,
>  				    dev_t logdev, dev_t rtdev);
> +int libxfs_blkdev_issue_flush(struct xfs_buftarg *btp);
>  
>  #define LIBXFS_BBTOOFF64(bbs)	(((xfs_off_t)(bbs)) << BBSHIFT)
>  
> diff --git a/libxfs/rdwr.c b/libxfs/rdwr.c
> index 8b47d438..92e497f9 100644
> --- a/libxfs/rdwr.c
> +++ b/libxfs/rdwr.c
> @@ -17,6 +17,7 @@
>  #include "xfs_inode_fork.h"
>  #include "xfs_inode.h"
>  #include "xfs_trans.h"
> +#include "libfrog/platform.h"
>  
>  #include "libxfs.h"		/* for LIBXFS_EXIT_ON_FAILURE */
>  
> @@ -1227,9 +1228,11 @@ libxfs_brelse(
>  
>  	if (!bp)
>  		return;
> -	if (bp->b_flags & LIBXFS_B_DIRTY)
> +	if (bp->b_flags & LIBXFS_B_DIRTY) {
>  		fprintf(stderr,
>  			"releasing dirty buffer to free list!\n");
> +		bp->b_target->lost_writes = true;
> +	}
>  
>  	pthread_mutex_lock(&xfs_buf_freelist.cm_mutex);
>  	list_add(&bp->b_node.cn_mru, &xfs_buf_freelist.cm_list);
> @@ -1248,9 +1251,11 @@ libxfs_bulkrelse(
>  		return 0 ;
>  
>  	list_for_each_entry(bp, list, b_node.cn_mru) {
> -		if (bp->b_flags & LIBXFS_B_DIRTY)
> +		if (bp->b_flags & LIBXFS_B_DIRTY) {
>  			fprintf(stderr,
>  				"releasing dirty buffer (bulk) to free list!\n");
> +			bp->b_target->lost_writes = true;
> +		}
>  		count++;
>  	}
>  
> @@ -1479,6 +1484,24 @@ libxfs_irele(
>  	kmem_cache_free(xfs_inode_zone, ip);
>  }
>  
> +/*
> + * Flush everything dirty in the kernel and disk write caches to stable media.
> + * Returns 0 for success or a negative error code.
> + */
> +int
> +libxfs_blkdev_issue_flush(
> +	struct xfs_buftarg	*btp)
> +{
> +	int			fd, ret;
> +
> +	if (btp->dev == 0)
> +		return 0;
> +
> +	fd = libxfs_device_to_fd(btp->dev);
> +	ret = platform_flush_device(fd, btp->dev);
> +	return ret ? -errno : 0;
> +}
> +
>  /*
>   * Write out a buffer list synchronously.
>   *
> 


^ permalink raw reply

* Re: [PATCH 5/8] xfs_db: check that metadata updates have been committed
From: Brian Foster @ 2020-02-20 14:06 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: sandeen, linux-xfs
In-Reply-To: <158216293385.601264.3202158027072387776.stgit@magnolia>

On Wed, Feb 19, 2020 at 05:42:13PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Add a new function that will ensure that everything we scribbled on has
> landed on stable media, and report the results.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
>  db/init.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> 
> diff --git a/db/init.c b/db/init.c
> index 0ac37368..e92de232 100644
> --- a/db/init.c
> +++ b/db/init.c
> @@ -184,6 +184,7 @@ main(
>  	char	*input;
>  	char	**v;
>  	int	start_iocur_sp;
> +	int	d, l, r;
>  
>  	init(argc, argv);
>  	start_iocur_sp = iocur_sp;
> @@ -216,6 +217,19 @@ main(
>  	 */
>  	while (iocur_sp > start_iocur_sp)
>  		pop_cur();
> +
> +	libxfs_flush_devices(mp, &d, &l, &r);
> +	if (d)
> +		fprintf(stderr, _("%s: cannot flush data device (%d).\n"),
> +				progname, d);
> +	if (l)
> +		fprintf(stderr, _("%s: cannot flush log device (%d).\n"),
> +				progname, l);
> +	if (r)
> +		fprintf(stderr, _("%s: cannot flush realtime device (%d).\n"),
> +				progname, r);
> +
> +

Seems like we could reduce some boilerplate by passing progname into
libxfs_flush_devices() and letting it dump out of the error messages,
unless there's some future code that cares about individual device error
state.

That said, it also seems the semantics of libxfs_flush_devices() are a
bit different from convention. Just below we invoke
libxfs_device_close() for each device (rather than for all three), and
device_close() also happens to call fsync() and platform_flush_device()
itself...

Brian

>  	libxfs_umount(mp);
>  	if (x.ddev)
>  		libxfs_device_close(x.ddev);
> 


^ permalink raw reply

* Re: [PATCH v2] test-vmstate: Fix memleaks in test_load_qlist
From: Laurent Vivier @ 2020-02-20 14:06 UTC (permalink / raw)
  To: kuhn.chenqun, qemu-devel
  Cc: thuth, zhang.zhanghailiang, quintela, qemu-trivial, dgilbert,
	ehabkost
In-Reply-To: <20200220134103.26224-1-kuhn.chenqun@huawei.com>

Le 20/02/2020 à 14:41, kuhn.chenqun@huawei.com a écrit :
> From: Chen Qun <kuhn.chenqun@huawei.com>
> 
> There is memleak in test_load_qlist().It's not a big deal,
> but test-vmstate will fail if sanitizers is enabled.
> 
> In addition, "ret" is written twice with the same value
>  in test_gtree_load_iommu().
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
>  tests/test-vmstate.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
> index cea363dd69..f7b3868881 100644
> --- a/tests/test-vmstate.c
> +++ b/tests/test-vmstate.c
> @@ -1241,7 +1241,6 @@ static void test_gtree_load_iommu(void)
>      TestGTreeIOMMU *orig_iommu = create_iommu();
>      QEMUFile *fsave, *fload;
>      char eof;
> -    int ret;
>  
>      fsave = open_test_file(true);
>      qemu_put_buffer(fsave, iommu_dump, sizeof(iommu_dump));
> @@ -1250,10 +1249,8 @@ static void test_gtree_load_iommu(void)
>  
>      fload = open_test_file(false);
>      vmstate_load_state(fload, &vmstate_iommu, dest_iommu, 1);
> -    ret = qemu_file_get_error(fload);
>      eof = qemu_get_byte(fload);
> -    ret = qemu_file_get_error(fload);
> -    g_assert(!ret);
> +    g_assert(!qemu_file_get_error(fload));/
>      g_assert_cmpint(orig_iommu->id, ==, dest_iommu->id);
>      g_assert_cmpint(eof, ==, QEMU_VM_EOF);
>  
> @@ -1395,6 +1392,7 @@ static void test_load_qlist(void)
>      compare_containers(orig_container, dest_container);
>      free_container(orig_container);
>      free_container(dest_container);
> +    qemu_fclose(fload);
>  }
>  
>  typedef struct TmpTestStruct {
> 

Reviewed-by: Laurent Vivier <laurent@vivier.eu>


^ permalink raw reply

* Re: [PATCH 8/8] libfrog: always fsync when flushing a device
From: Brian Foster @ 2020-02-20 14:06 UTC (permalink / raw)
  To: Darrick J. Wong; +Cc: sandeen, linux-xfs
In-Reply-To: <158216295197.601264.12572804096602430873.stgit@magnolia>

On Wed, Feb 19, 2020 at 05:42:31PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
> 
> Always call fsync() when we're flushing a device, even if it is a block
> device.  It's probably redundant to call fsync /and/ BLKFLSBUF, but the
> latter has odd behavior so we want to make sure the standard flush
> methods have a chance to run first.
> 
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---

Reviewed-by: Brian Foster <bfoster@redhat.com>

>  libfrog/linux.c |   10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> 
> diff --git a/libfrog/linux.c b/libfrog/linux.c
> index 60bc1dc4..40a839d1 100644
> --- a/libfrog/linux.c
> +++ b/libfrog/linux.c
> @@ -155,14 +155,18 @@ platform_flush_device(
>  	if (major(device) == RAMDISK_MAJOR)
>  		return 0;
>  
> +	ret = fsync(fd);
> +	if (ret)
> +		return ret;
> +
>  	ret = fstat(fd, &st);
>  	if (ret)
>  		return ret;
>  
> -	if (S_ISREG(st.st_mode))
> -		return fsync(fd);
> +	if (S_ISBLK(st.st_mode))
> +		return ioctl(fd, BLKFLSBUF, 0);
>  
> -	return ioctl(fd, BLKFLSBUF, 0);
> +	return 0;
>  }
>  
>  void
> 


^ permalink raw reply

* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Daniel Thompson @ 2020-02-20 14:06 UTC (permalink / raw)
  To: minyard
  Cc: Will Deacon, 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."
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> * The exception handling hits a breakpoint and stops.
> * The user continues from the breakpoint, so the kernel is no longer
>   expecting a single step.
> * On the return from the first exception, the single step flag in
>   pt_regs is still set, so a single step trap happens.
> * The kernel keels over from an unexpected single step.
> 
> 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.
> 
> Signed-off-by: Corey Minyard <cminyard@mvista.com>

I've pointed the kgdbtest suite at this patch (and run one of the
historically unstable test cases an extra 100 times just in case).

kgdbtest hasn't got great coverage, runs the code in qemu and some
of the strongest tests are still marked XFAIL on arm64 (for reasons
unrelated to stepping).

So the best I can say based on the above is that the test suite does not
observe any regression (but equally no improvement). Nevertheless FWIW:


Tested-by: Daniel Thompson <daniel.thompson@linaro.org>


Daniel.

^ permalink raw reply

* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Daniel Thompson @ 2020-02-20 14:06 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 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."
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> * The exception handling hits a breakpoint and stops.
> * The user continues from the breakpoint, so the kernel is no longer
>   expecting a single step.
> * On the return from the first exception, the single step flag in
>   pt_regs is still set, so a single step trap happens.
> * The kernel keels over from an unexpected single step.
> 
> 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.
> 
> Signed-off-by: Corey Minyard <cminyard@mvista.com>

I've pointed the kgdbtest suite at this patch (and run one of the
historically unstable test cases an extra 100 times just in case).

kgdbtest hasn't got great coverage, runs the code in qemu and some
of the strongest tests are still marked XFAIL on arm64 (for reasons
unrelated to stepping).

So the best I can say based on the above is that the test suite does not
observe any regression (but equally no improvement). Nevertheless FWIW:


Tested-by: Daniel Thompson <daniel.thompson@linaro.org>


Daniel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2] test-vmstate: Fix memleaks in test_load_qlist
From: Laurent Vivier @ 2020-02-20 14:06 UTC (permalink / raw)
  To: kuhn.chenqun, qemu-devel
  Cc: thuth, ehabkost, quintela, qemu-trivial, dgilbert,
	zhang.zhanghailiang
In-Reply-To: <20200220134103.26224-1-kuhn.chenqun@huawei.com>

Le 20/02/2020 à 14:41, kuhn.chenqun@huawei.com a écrit :
> From: Chen Qun <kuhn.chenqun@huawei.com>
> 
> There is memleak in test_load_qlist().It's not a big deal,
> but test-vmstate will fail if sanitizers is enabled.
> 
> In addition, "ret" is written twice with the same value
>  in test_gtree_load_iommu().
> 
> Reported-by: Euler Robot <euler.robot@huawei.com>
> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com>
> ---
>  tests/test-vmstate.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/test-vmstate.c b/tests/test-vmstate.c
> index cea363dd69..f7b3868881 100644
> --- a/tests/test-vmstate.c
> +++ b/tests/test-vmstate.c
> @@ -1241,7 +1241,6 @@ static void test_gtree_load_iommu(void)
>      TestGTreeIOMMU *orig_iommu = create_iommu();
>      QEMUFile *fsave, *fload;
>      char eof;
> -    int ret;
>  
>      fsave = open_test_file(true);
>      qemu_put_buffer(fsave, iommu_dump, sizeof(iommu_dump));
> @@ -1250,10 +1249,8 @@ static void test_gtree_load_iommu(void)
>  
>      fload = open_test_file(false);
>      vmstate_load_state(fload, &vmstate_iommu, dest_iommu, 1);
> -    ret = qemu_file_get_error(fload);
>      eof = qemu_get_byte(fload);
> -    ret = qemu_file_get_error(fload);
> -    g_assert(!ret);
> +    g_assert(!qemu_file_get_error(fload));/
>      g_assert_cmpint(orig_iommu->id, ==, dest_iommu->id);
>      g_assert_cmpint(eof, ==, QEMU_VM_EOF);
>  
> @@ -1395,6 +1392,7 @@ static void test_load_qlist(void)
>      compare_containers(orig_container, dest_container);
>      free_container(orig_container);
>      free_container(dest_container);
> +    qemu_fclose(fload);
>  }
>  
>  typedef struct TmpTestStruct {
> 

Reviewed-by: Laurent Vivier <laurent@vivier.eu>


^ permalink raw reply

* Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Peter Ujfalusi @ 2020-02-20 14:07 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: alsa-devel, linux-omap, Kuninori Morimoto, Aaro Koskinen,
	linux-kernel, Merlijn Wajer, Takashi Iwai, Liam Girdwood,
	Mark Brown, Pavel Machek, Sebastian Reichel, Arthur D .,
	Jarkko Nikula
In-Reply-To: <20200218152833.GH35972@atomide.com>



On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>>> and everything happens betwee the modem and the cpcap pmic.
>>>>
>>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>>> or McPDM...
>>>>
>>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>>
>>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>>> mcbsp for voice call.
>>>
>>> According to Sebastian sounds like mcbsp can be idle at that point.
>>>
>>> But what about capture of voice call at the mcbsp from the
>>> TDM slot? In that case mcbsp would be active.
>>
>> Sure, but with the dummy dai it won't....
> 
> Right. I'm not attached to the dummy dai, but looks like currently
> snd-soc-audio-graph-card won't work without it.

The generic cards will link up a dummy dai/codec when it is needed by DPMC.

> And we potentially
> do need a place to configure TDM slot specific stuff for mcbsp.

Yes, but you still have one port and one endpoint should not change the
configuration which is already in used for the other endpoint.

>> If I understand correctly the HW setup:
>> McBSP2 -> CPCAP_hifi (only playback)
>>
>> CPCAP_voice is the i2s clock master.
>> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
>> i2s lines.
>>
>> In case of Voice call with analog mic/speaker only CPCAP_voice and
>> MDM6600 is used.
>> In case of Voice call with BT only MDM6600 and WL1285 is used (but
>> CPCAP_voice must provide the clocks?)
> 
> Yes my guess is cpcap voice is the clock master in that case.
> It should show up from the cpcap register dump from Android with
> audio playing to a bluetooth headset.

OK.

>> In case you would have any algorithm running on OMAP4 for the calls,
>> then you will have McBSP3 inserted and used between MDM6600 and
>> CPAC_voice/WL1285.
>> Similarly, if you would like to tap in and record the data from the bus
>> you will have McBSP3 enabled.
>>
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
>>
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
> 
> Oh, I think there are Android apps to do that though.. Never tried
> if they work on droid4. But if they do, doing a register dump of
> mcbsp3 would show up how it's configured.

I don't see how you could record the data from the line which is
connected to McBSP_DX pin (the pin is output).

But I might be missing something.

>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 	1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 	2.1: to CPCAP_voice
>> 	2.2: to WL1285
>> CPCAP: 2 ports
>> 	hifi:	3.1: to McBSP2
>> 	voice:	4.1: to McBSP3
>> 		4.2: to MDM6600
>> MDM6600: 2 ports
>> 	5.1: to CPAC_voice
>> 	5.2: to WL1285
>> WL1285: 2 ports
>> 	6.1: to McBSP3
>> 	6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
> 
> OK
> 
>> Can a generic card provide such a functionality?
> 
> I think the link for the patches you posted is patching the
> snd-soc-audio-graph-card already?

Yes it does, but the functionality is there via custom machine drivers.
What I afraid is that such a complex wiring as the Droid4 have it might
be not possible to use a generic - fits everything - driver without
making it a customized one ;)

Otho, if the only thing is the machine level DAPM switching and linking
the paths then it might be relatively straight forward to extend the
simple-card family.

>> In case of B/C you should not have a running stream imho.
>> In all cases CPCAP_voice should be able to run the clocks on i2s, even
>> if it is not used by the audio setup.
>> Not sure if you can just turn Wl1285 as master, but it is possible that
>> it is master, but silent when it is not used?
> 
> Yeah, no idea.. But that's easy to configure in the dts based on
> the graph bindings :)

Yep, indeed.

>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
> 
> Right. So right now it seems that for snd-soc-audio-graph-card
> needs the dummy dai, but it's unclear what would need to be
> changed to not use a dummy dai for mcbsp.

Since simple-card family can and will connect up dummy dai/codec when
needed based on the setup, I would look at that and make it do so.

> The dts snippets I posted earlier do follow the graph bindings
> as far as I know. But just to confirm, do you see any need to
> move things around there?

It also states that a port is a physical port which can have multiple
endpoints. But multiple endpoint != DAI. port == dai.

>>>>>>>> I know it was discussed, but can not find the mail:
>>>>>>>> Can you brief again on the audio connection?
>>>>>>>
>>>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>>>> the audio connection:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>>>
>>>>>> Thanks!
>>>>>>  
>>>>>>>> Do you have branch with working code?
>>>>>>>
>>>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>>>> kernel.org git branch with voice calls working.
>>>>>>
>>>>>> I think I should put my droid4 out and try to get it working...
>>>>>> Do you have a link for dummies to follow to get started? ;)
>>>>>
>>>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>>>> test image using v5.5 kernel + modem and audio patches:
>>>>>
>>>>> https://leste.maemo.org/Motorola_Droid_4
>>>>>
>>>>> Just use a decent speed micro-sd card rated "a1" for example.
>>>>
>>>> Cool. Now I can dual boot the droid4 :D
>>>> I needed to rewrite the /etc/shadow to get a known root password so I
>>>> can log in.
>>>
>>> Not sure if you mean password for the droid4-kexecboot or the
>>> Linux distro you installed..
>>
>> It was for the maemo-leste.
>> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
>> reference image...
> 
> Gentoo cool :)
> 
> I've had good luck with just plain alpine armv7 edge, the package
> updates work very fast for a slow system. The musl stuff requires
> running stellarium with 3d acceleration in a minimal devuan or
> whatever chroot environment though for stellarium etc..

I see, I might go via the lazy route and take buildroot ;)

>>> But for droid4-kexecboot, you
>>> can configure it to automatically download new kernels over wlan.
>>> There's some info on the machine specific password and how to
>>> configure wlan in the droid4-kexecboot buildroot commits here:
>>>
>>> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
>>>
>>>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>>>> the /boot/boot/boot.cfg to boot my kernel, right?
>>>
>>> Yeah you can update kernels and modules over wlan from the distro(s)
>>> you have configured, and also from droid4-kexecboot as above.
>>
>> I need to try droid4-kexecboot's wifi support then.
> 
> Yeah you need to configure wpa_supplicant.conf and wlan.conf or
> whatever it was called. And make sure you have copied the old
> stock v3.0.8 kernel wlan modules and firmware as mentioned in
> the droid4-kexecboot git readme and install files.

OK.

> Oh, and also read about the flags you need to use for mkfs.ext4 if
> doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
> all the new flags if you want a partition to be readable for the
> droid4-kexecboot bootloader. And also the all the old Android
> distros currently still stuck with the ancient v3.0.8 kernel :p

I see, thanks for the warning!

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply

* Re: [PATCH] ASoC: ti: Allocate dais dynamically for TDM and audio graph card
From: Peter Ujfalusi @ 2020-02-20 14:07 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Jaroslav Kysela,
	Takashi Iwai, alsa-devel, linux-kernel, linux-omap, Aaro Koskinen,
	Arthur D ., Jarkko Nikula, Merlijn Wajer, Pavel Machek,
	Sebastian Reichel
In-Reply-To: <20200218152833.GH35972@atomide.com>



On 18/02/2020 17.28, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200218 12:44]:
>> Hi Tony,
>>
>> On 18/02/2020 1.10, Tony Lindgren wrote:
>>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [200217 12:10]:
>>>> On 14/02/2020 19.03, Tony Lindgren wrote:
>>>>> But right now in droid4 voice call case mcbsp is just the i2s transport,
>>>>> and everything happens betwee the modem and the cpcap pmic.
>>>>
>>>> Iow you don't need McBSP DAI at all. If you would have added the dummy
>>>> codec to McBSP !3 and use that, it would work in a same way, or to DMIC
>>>> or McPDM...
>>>>
>>>> The McBSP ops are NULL for the dummy dai, so McBSP is turned off.
>>>
>>> Hmm yeah I don't know if the cpcap codec on the same mcbsp needs
>>> mcbsp for voice call.
>>>
>>> According to Sebastian sounds like mcbsp can be idle at that point.
>>>
>>> But what about capture of voice call at the mcbsp from the
>>> TDM slot? In that case mcbsp would be active.
>>
>> Sure, but with the dummy dai it won't....
> 
> Right. I'm not attached to the dummy dai, but looks like currently
> snd-soc-audio-graph-card won't work without it.

The generic cards will link up a dummy dai/codec when it is needed by DPMC.

> And we potentially
> do need a place to configure TDM slot specific stuff for mcbsp.

Yes, but you still have one port and one endpoint should not change the
configuration which is already in used for the other endpoint.

>> If I understand correctly the HW setup:
>> McBSP2 -> CPCAP_hifi (only playback)
>>
>> CPCAP_voice is the i2s clock master.
>> McBSP3, CPCAP_voice, MDM6600 and WL1285 are all connected together via
>> i2s lines.
>>
>> In case of Voice call with analog mic/speaker only CPCAP_voice and
>> MDM6600 is used.
>> In case of Voice call with BT only MDM6600 and WL1285 is used (but
>> CPCAP_voice must provide the clocks?)
> 
> Yes my guess is cpcap voice is the clock master in that case.
> It should show up from the cpcap register dump from Android with
> audio playing to a bluetooth headset.

OK.

>> In case you would have any algorithm running on OMAP4 for the calls,
>> then you will have McBSP3 inserted and used between MDM6600 and
>> CPAC_voice/WL1285.
>> Similarly, if you would like to tap in and record the data from the bus
>> you will have McBSP3 enabled.
>>
>> The simplest use cases you want to support:
>> A. McBSP3 <-> CPCAP_voice (playback/capture)
>> B. MDM6600 <-> CPCAP_voice (handset mic/speaker voice call)
>> C. MDM6600 <-> WL1285 (BT voice call)
>> D. McBSP3 <-> BT (VoIP?)
>>
>> I would not bother with recording the call as you would need tom
>> reconfigure the McBSP playback pin (is it even possible) as input to
>> OMAP4, I think..
> 
> Oh, I think there are Android apps to do that though.. Never tried
> if they work on droid4. But if they do, doing a register dump of
> mcbsp3 would show up how it's configured.

I don't see how you could record the data from the line which is
connected to McBSP_DX pin (the pin is output).

But I might be missing something.

>> B/C is codec2codec, McBSP3 is not involved at all.
>> A/D is when McBSP3 is used only.
>>
>> Imho this can be represented as
>> McBSP2: 1 port
>> 	1.1: to CPCAP_hifi
>>
>> McBSP3: 1 port, 2 endpoint
>> 	2.1: to CPCAP_voice
>> 	2.2: to WL1285
>> CPCAP: 2 ports
>> 	hifi:	3.1: to McBSP2
>> 	voice:	4.1: to McBSP3
>> 		4.2: to MDM6600
>> MDM6600: 2 ports
>> 	5.1: to CPAC_voice
>> 	5.2: to WL1285
>> WL1285: 2 ports
>> 	6.1: to McBSP3
>> 	6.2: to MDM6600
>>
>> The machine driver should switch between the graph links based on the
>> use case for the interconnected devices:
>> A: 2.2 <-> 4.1
>> B: 4.2 <-> 5.1
>> C: 6.2 <-> 5.1
>> D: 2.2 <-> 6.1
> 
> OK
> 
>> Can a generic card provide such a functionality?
> 
> I think the link for the patches you posted is patching the
> snd-soc-audio-graph-card already?

Yes it does, but the functionality is there via custom machine drivers.
What I afraid is that such a complex wiring as the Droid4 have it might
be not possible to use a generic - fits everything - driver without
making it a customized one ;)

Otho, if the only thing is the machine level DAPM switching and linking
the paths then it might be relatively straight forward to extend the
simple-card family.

>> In case of B/C you should not have a running stream imho.
>> In all cases CPCAP_voice should be able to run the clocks on i2s, even
>> if it is not used by the audio setup.
>> Not sure if you can just turn Wl1285 as master, but it is possible that
>> it is master, but silent when it is not used?
> 
> Yeah, no idea.. But that's easy to configure in the dts based on
> the graph bindings :)

Yep, indeed.

>> I'm not sure if we should span out dummy dais for endpoints within a
>> port. Imho the port _is_ the dai. Different endpoints might use
>> different TDM slots on the port (or the same slot, which makes them
>> exclusive).
> 
> Right. So right now it seems that for snd-soc-audio-graph-card
> needs the dummy dai, but it's unclear what would need to be
> changed to not use a dummy dai for mcbsp.

Since simple-card family can and will connect up dummy dai/codec when
needed based on the setup, I would look at that and make it do so.

> The dts snippets I posted earlier do follow the graph bindings
> as far as I know. But just to confirm, do you see any need to
> move things around there?

It also states that a port is a physical port which can have multiple
endpoints. But multiple endpoint != DAI. port == dai.

>>>>>>>> I know it was discussed, but can not find the mail:
>>>>>>>> Can you brief again on the audio connection?
>>>>>>>
>>>>>>> Below is a link to a mailing list thread where Sebastian describes
>>>>>>> the audio connection:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2018/3/28/881
>>>>>>
>>>>>> Thanks!
>>>>>>  
>>>>>>>> Do you have branch with working code?
>>>>>>>
>>>>>>> Yeah I have slightly older set of the patches in my droid4-pending-v5.5
>>>>>>> kernel.org git branch with voice calls working.
>>>>>>
>>>>>> I think I should put my droid4 out and try to get it working...
>>>>>> Do you have a link for dummies to follow to get started? ;)
>>>>>
>>>>> Probably the easiest one to use right now is the Maemo-leste devuan based
>>>>> test image using v5.5 kernel + modem and audio patches:
>>>>>
>>>>> https://leste.maemo.org/Motorola_Droid_4
>>>>>
>>>>> Just use a decent speed micro-sd card rated "a1" for example.
>>>>
>>>> Cool. Now I can dual boot the droid4 :D
>>>> I needed to rewrite the /etc/shadow to get a known root password so I
>>>> can log in.
>>>
>>> Not sure if you mean password for the droid4-kexecboot or the
>>> Linux distro you installed..
>>
>> It was for the maemo-leste.
>> Bringing up Gentoo will be a bit harder as I don't have wifi stuff in my
>> reference image...
> 
> Gentoo cool :)
> 
> I've had good luck with just plain alpine armv7 edge, the package
> updates work very fast for a slow system. The musl stuff requires
> running stellarium with 3d acceleration in a minimal devuan or
> whatever chroot environment though for stellarium etc..

I see, I might go via the lazy route and take buildroot ;)

>>> But for droid4-kexecboot, you
>>> can configure it to automatically download new kernels over wlan.
>>> There's some info on the machine specific password and how to
>>> configure wlan in the droid4-kexecboot buildroot commits here:
>>>
>>> https://github.com/tmlind/buildroot/commits/droid4-kexecboot-2017.11
>>>
>>>> Wifi is up, so in theory I can scp kernel/dtb to /boot/boot/ and update
>>>> the /boot/boot/boot.cfg to boot my kernel, right?
>>>
>>> Yeah you can update kernels and modules over wlan from the distro(s)
>>> you have configured, and also from droid4-kexecboot as above.
>>
>> I need to try droid4-kexecboot's wifi support then.
> 
> Yeah you need to configure wpa_supplicant.conf and wlan.conf or
> whatever it was called. And make sure you have copied the old
> stock v3.0.8 kernel wlan modules and firmware as mentioned in
> the droid4-kexecboot git readme and install files.

OK.

> Oh, and also read about the flags you need to use for mkfs.ext4 if
> doing mkfs.ext4 on a PC, the old v3.0.8 kernel won't understand
> all the new flags if you want a partition to be readable for the
> droid4-kexecboot bootloader. And also the all the old Android
> distros currently still stuck with the ancient v3.0.8 kernel :p

I see, thanks for the warning!

> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

^ permalink raw reply

* Re: [PATCH v8 15/15] bugreport: summarize contents of alternates file
From: Johannes Schindelin @ 2020-02-20 14:08 UTC (permalink / raw)
  To: Emily Shaffer; +Cc: git
In-Reply-To: <20200220015858.181086-16-emilyshaffer@google.com>

Hi Emily,

On Wed, 19 Feb 2020, Emily Shaffer wrote:

> In some cases, it could be that the user is having a problem with an
> object which isn't present in their normal object directory. We can get
> a hint that that might be the case by examining the list of alternates
> where their object may be stored instead. Since paths to alternates may
> be sensitive, we'll instead count how many alternates have been
> specified and note how many of them exist or are broken.
>
> While object-cache.h describes a function "foreach_alt_odb()", this
> function does not provide information on broken alternates, which are
> skipped over in "link_alt_odb_entry()". Since the goal is to identify
> missing alternates, we can gather the contents of
> .git/objects/info/alternates manually.

Makes sense.

> diff --git a/bugreport.c b/bugreport.c
> index 1d61e0f642..1640a71086 100644
> --- a/bugreport.c
> +++ b/bugreport.c
> @@ -255,6 +255,48 @@ static void get_object_info_summary(struct strbuf *obj_info, int nongit)
>  	strbuf_release(&dirpath);
>  }
>
> +static void get_alternates_summary(struct strbuf *alternates_info, int nongit)
> +{
> +	struct strbuf alternates_path = STRBUF_INIT;
> +	struct strbuf alternate = STRBUF_INIT;

I am not sure that those variables and the parameter need to repeat
"alternate", I find it rather distracting. If it were me, I would rename
the parameter to `info`, the first strbuf to `path` and the second to
`line`. This function is so specific to read the alternates file that it
is quite obvious what their roles are.

> +	FILE *file;
> +	size_t exists = 0, broken = 0;
> +
> +	if (nongit) {
> +		strbuf_addstr(alternates_info,
> +			"not run from a git repository - alternates unavailable\n");
> +		return;
> +	}
> +
> +	strbuf_addstr(&alternates_path, get_object_directory());
> +	strbuf_complete(&alternates_path, '/');
> +	strbuf_addstr(&alternates_path, "info/alternates");
> +
> +	file = fopen(alternates_path.buf, "r");
> +	if (!file) {
> +		strbuf_addstr(alternates_info, "No alternates file found.\n");
> +		strbuf_release(&alternates_path);
> +		return;
> +	}
> +
> +	while (strbuf_getline(&alternate, file) != EOF) {
> +		if (!access(alternate.buf, F_OK))

Should we make sure that the alternate is actually valid objects directory
here? Like, look whether it is a directory, not a file or a (possibly
dangling) symbolic link. This seems to be the only check
`alt_odb_usable()` performs, so that should probably be good enough here,
too.

> +			exists++;
> +		else
> +			broken++;
> +	}
> +
> +	strbuf_addf(alternates_info,
> +		    "%zd alternates found (%zd working, %zd broken)\n",

Sadly, `%zd` is not portable. Therefore, `pu` (and `es/bugreport`) do not
even _build_ on Windows. I need this to make it work:

-- snip --
diff --git a/bugreport.c b/bugreport.c
index 3770aa73fae..5033668e22f 100644
--- a/bugreport.c
+++ b/bugreport.c
@@ -287,10 +287,11 @@ static void get_alternates_summary(struct strbuf *alternates_info, int nongit)
 	}

 	strbuf_addf(alternates_info,
-		    "%zd alternates found (%zd working, %zd broken)\n",
-		    exists + broken,
-		    exists,
-		    broken);
+		    "%"PRIuMAX" alternates found "
+		    "(%"PRIuMAX" working, %"PRIuMAX" broken)\n",
+		    (uintmax_t)(exists + broken),
+		    (uintmax_t)exists,
+		    (uintmax_t)broken);

 	fclose(file);
 	strbuf_release(&alternate);
-- snap --

Could you incorporate that into the next iteration, please?

Thanks,
Dscho

> +		    exists + broken,
> +		    exists,
> +		    broken);
> +
> +	fclose(file);
> +	strbuf_release(&alternate);
> +	strbuf_release(&alternates_path);
> +}
> +
>  static const char * const bugreport_usage[] = {
>  	N_("git bugreport [-o|--output-directory <file>] [-s|--suffix <format>]"),
>  	NULL
> @@ -355,6 +397,9 @@ int cmd_main(int argc, const char **argv)
>  	get_header(&buffer, "Object Info Summary");
>  	get_object_info_summary(&buffer, nongit_ok);
>
> +	get_header(&buffer, "Alternates");
> +	get_alternates_summary(&buffer, nongit_ok);
> +
>  	report = fopen_for_writing(report_path.buf);
>
>  	if (report == NULL) {
> --
> 2.25.0.265.gbab2e86ba0-goog
>
>

^ permalink raw reply related

* [PATCH liburing] man/io_uring_setup.2: fix 'sq_thread_idle' description
From: Stefano Garzarella @ 2020-02-20 14:08 UTC (permalink / raw)
  To: Jens Axboe; +Cc: io-uring, linux-kernel

In the kernel we are using msecs_to_jiffies() to convert the
'sq_thread_idle' parameter, provided by the user, in jiffies.
So, the value is interpreted in milliseconds and not microseconds.

Fixes: 59bb09c553eb ("man: add io_uring_setup.2 man page")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
 man/io_uring_setup.2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/io_uring_setup.2 b/man/io_uring_setup.2
index 4057e4b..20c67dc 100644
--- a/man/io_uring_setup.2
+++ b/man/io_uring_setup.2
@@ -82,7 +82,7 @@ doing a single system call.
 
 If the kernel thread is idle for more than
 .I sq_thread_idle
-microseconds, it will set the
+milliseconds, it will set the
 .B IORING_SQ_NEED_WAKEUP
 bit in the
 .I flags
-- 
2.24.1


^ permalink raw reply related

* [dpdk-dev] [PATCH v2] cmdline: increase maximum line length
From: Wisam Jaddo @ 2020-02-20 14:10 UTC (permalink / raw)
  To: dev, rasland, thomas; +Cc: olivier.matz, bernard.iremonger, stable

The current length of buffer is not enough to
fit all allowed items/actions, thus it will
block a lot of testing.

Cc: stable@dpdk.org

Signed-off-by: Wisam Jaddo <wisamm@mellanox.com>
---
 lib/librte_cmdline/cmdline_rdline.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_cmdline/cmdline_rdline.h b/lib/librte_cmdline/cmdline_rdline.h
index d217029..8193e1d 100644
--- a/lib/librte_cmdline/cmdline_rdline.h
+++ b/lib/librte_cmdline/cmdline_rdline.h
@@ -39,7 +39,7 @@ extern "C" {
 #endif
 
 /* configuration */
-#define RDLINE_BUF_SIZE 512
+#define RDLINE_BUF_SIZE 2048
 #define RDLINE_PROMPT_SIZE  32
 #define RDLINE_VT100_BUF_SIZE  8
 #define RDLINE_HISTORY_BUF_SIZE BUFSIZ
-- 
2.7.4


^ permalink raw reply related

* [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
  To: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
	Igor Opanyuk, Philippe Schenker, Mark Brown


- the memory optimization in fsl-spi
- the fix of the max speed setting bug in spidev


Oleksandr Suvorov (2):
  spi: fsl-lpspi: remove unneeded array
  spi: spidev: fix a max speed setting

 drivers/spi/spi-fsl-lpspi.c |  7 ++-----
 drivers/spi/spidev.c        | 10 ++++++----
 2 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.24.1

^ permalink raw reply

* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Roger Pau Monné @ 2020-02-20 14:11 UTC (permalink / raw)
  To: Jan Beulich
  Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
	Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
	xen-devel
In-Reply-To: <ecf1c47c-4cbb-c7c4-7ccf-d3620a1992b3@suse.com>

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.

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

^ permalink raw reply

* [PATCH 1/2] spi: fsl-lpspi: remove unneeded array
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
  To: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
  Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
	Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>

- replace the array with the shift operation
- remove the extra comparing operation.

Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
---

 drivers/spi/spi-fsl-lpspi.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d0b8cc741a24..298329b781d2 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -86,8 +86,6 @@
 #define TCR_RXMSK	BIT(19)
 #define TCR_TXMSK	BIT(18)
 
-static int clkdivs[] = {1, 2, 4, 8, 16, 32, 64, 128};
-
 struct lpspi_config {
 	u8 bpw;
 	u8 chip_select;
@@ -331,15 +329,14 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi)
 	}
 
 	for (prescale = 0; prescale < 8; prescale++) {
-		scldiv = perclk_rate /
-			 (clkdivs[prescale] * config.speed_hz) - 2;
+		scldiv = perclk_rate / config.speed_hz / (1 << prescale) - 2;
 		if (scldiv < 256) {
 			fsl_lpspi->config.prescale = prescale;
 			break;
 		}
 	}
 
-	if (prescale == 8 && scldiv >= 256)
+	if (scldiv >= 256)
 		return -EINVAL;
 
 	writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
-- 
2.24.1

^ permalink raw reply related

* [PATCH 2/2] spi: spidev: fix a max speed setting
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
  To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
  Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
	Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov@toradex.com>

SPI_IOC_WR_MAX_SPEED_HZ command always sets spi->max_speed_hz
to the initial value come from DT.
It leads to set a wrong max speed with IOCTL call.

Fix the logic of a max speed assignment.

Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---

 drivers/spi/spidev.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 1e217e3e9486..b9b3ac70eb18 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -449,11 +449,13 @@ spidev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 
 			spi->max_speed_hz = tmp;
 			retval = spi_setup(spi);
-			if (retval >= 0)
+			if (retval) {
+				spi->max_speed_hz = save;
+			} else {
 				spidev->speed_hz = tmp;
-			else
-				dev_dbg(&spi->dev, "%d Hz (max)\n", tmp);
-			spi->max_speed_hz = save;
+				dev_dbg(&spi->dev, "%d Hz (max)\n",
+					spidev->speed_hz);
+			}
 		}
 		break;
 
-- 
2.24.1

^ permalink raw reply related

* [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
  To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
  Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
	Igor Opanyuk, Philippe Schenker, Mark Brown


- the memory optimization in fsl-spi
- the fix of the max speed setting bug in spidev


Oleksandr Suvorov (2):
  spi: fsl-lpspi: remove unneeded array
  spi: spidev: fix a max speed setting

 drivers/spi/spi-fsl-lpspi.c |  7 ++-----
 drivers/spi/spidev.c        | 10 ++++++----
 2 files changed, 8 insertions(+), 9 deletions(-)

-- 
2.24.1


^ permalink raw reply

* [PATCH 1/2] spi: fsl-lpspi: remove unneeded array
From: Oleksandr Suvorov @ 2020-02-20 14:11 UTC (permalink / raw)
  To: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
  Cc: Oleksandr Suvorov, Oleksandr Suvorov, Marcel Ziswiler,
	Igor Opanyuk, Philippe Schenker, Mark Brown
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov@toradex.com>

- replace the array with the shift operation
- remove the extra comparing operation.

Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
---

 drivers/spi/spi-fsl-lpspi.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d0b8cc741a24..298329b781d2 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -86,8 +86,6 @@
 #define TCR_RXMSK	BIT(19)
 #define TCR_TXMSK	BIT(18)
 
-static int clkdivs[] = {1, 2, 4, 8, 16, 32, 64, 128};
-
 struct lpspi_config {
 	u8 bpw;
 	u8 chip_select;
@@ -331,15 +329,14 @@ static int fsl_lpspi_set_bitrate(struct fsl_lpspi_data *fsl_lpspi)
 	}
 
 	for (prescale = 0; prescale < 8; prescale++) {
-		scldiv = perclk_rate /
-			 (clkdivs[prescale] * config.speed_hz) - 2;
+		scldiv = perclk_rate / config.speed_hz / (1 << prescale) - 2;
 		if (scldiv < 256) {
 			fsl_lpspi->config.prescale = prescale;
 			break;
 		}
 	}
 
-	if (prescale == 8 && scldiv >= 256)
+	if (scldiv >= 256)
 		return -EINVAL;
 
 	writel(scldiv | (scldiv << 8) | ((scldiv >> 1) << 16),
-- 
2.24.1


^ permalink raw reply related


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.