* [PATCH 3/3] mm: remove tmem specifics from frontswap
From: Juergen Gross @ 2019-05-27 10:32 UTC (permalink / raw)
To: linux-kernel, linux-doc, linux-mm
Cc: Juergen Gross, Jonathan Corbet, Konrad Rzeszutek Wilk
In-Reply-To: <20190527103207.13287-1-jgross@suse.com>
The frontswap module contains several parts which are specific to
tmem. With that no longer present those parts can be removed.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
Documentation/vm/frontswap.rst | 17 +----
include/linux/frontswap.h | 5 --
mm/Kconfig | 16 ++---
mm/frontswap.c | 156 +----------------------------------------
4 files changed, 7 insertions(+), 187 deletions(-)
diff --git a/Documentation/vm/frontswap.rst b/Documentation/vm/frontswap.rst
index 511c921bc8d2..2c674c0c6a77 100644
--- a/Documentation/vm/frontswap.rst
+++ b/Documentation/vm/frontswap.rst
@@ -19,7 +19,7 @@ for a detailed overview of frontswap and related kernel parts)
Frontswap is so named because it can be thought of as the opposite of
a "backing" store for a swap device. The storage is assumed to be
a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
-to the requirements of transcendent memory (such as Xen's "tmem", or
+to the requirements of transcendent memory (such as
in-kernel compressed memory, aka "zcache", or future RAM-like devices);
this pseudo-RAM device is not directly accessible or addressable by the
kernel and is of unknown and possibly time-varying size. The driver
@@ -113,21 +113,6 @@ many servers in a cluster can swap, dynamically as needed, to a single
server configured with a large amount of RAM... without pre-configuring
how much of the RAM is available for each of the clients!
-In the virtual case, the whole point of virtualization is to statistically
-multiplex physical resources across the varying demands of multiple
-virtual machines. This is really hard to do with RAM and efforts to do
-it well with no kernel changes have essentially failed (except in some
-well-publicized special-case workloads).
-Specifically, the Xen Transcendent Memory backend allows otherwise
-"fallow" hypervisor-owned RAM to not only be "time-shared" between multiple
-virtual machines, but the pages can be compressed and deduplicated to
-optimize RAM utilization. And when guest OS's are induced to surrender
-underutilized RAM (e.g. with "selfballooning"), sudden unexpected
-memory pressure may result in swapping; frontswap allows those pages
-to be swapped to and from hypervisor RAM (if overall host system memory
-conditions allow), thus mitigating the potentially awful performance impact
-of unplanned swapping.
-
A KVM implementation is underway and has been RFC'ed to lkml. And,
using frontswap, investigation is also underway on the use of NVM as
a memory extension technology.
diff --git a/include/linux/frontswap.h b/include/linux/frontswap.h
index 6d775984905b..052480aa3756 100644
--- a/include/linux/frontswap.h
+++ b/include/linux/frontswap.h
@@ -24,11 +24,6 @@ struct frontswap_ops {
};
extern void frontswap_register_ops(struct frontswap_ops *ops);
-extern void frontswap_shrink(unsigned long);
-extern unsigned long frontswap_curr_pages(void);
-extern void frontswap_writethrough(bool);
-#define FRONTSWAP_HAS_EXCLUSIVE_GETS
-extern void frontswap_tmem_exclusive_gets(bool);
extern bool __frontswap_test(struct swap_info_struct *, pgoff_t);
extern void __frontswap_init(unsigned type, unsigned long *map);
diff --git a/mm/Kconfig b/mm/Kconfig
index 5166fe4af00b..971b615ad3a6 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -436,20 +436,14 @@ config NEED_PER_CPU_KM
default y
config FRONTSWAP
- bool "Enable frontswap to cache swap pages if tmem is present"
+ bool "Enable frontswap to cache swap pages if zswap is present"
depends on SWAP
help
Frontswap is so named because it can be thought of as the opposite
- of a "backing" store for a swap device. The data is stored into
- "transcendent memory", memory that is not directly accessible or
- addressable by the kernel and is of unknown and possibly
- time-varying size. When space in transcendent memory is available,
- a significant swap I/O reduction may be achieved. When none is
- available, all frontswap calls are reduced to a single pointer-
- compare-against-NULL resulting in a negligible performance hit
- and swap data is stored as normal on the matching swap device.
-
- If unsure, say Y to enable frontswap.
+ of a "backing" store for a swap device. The only user right now is
+ zswap.
+
+ If unsure, say "n".
config CMA
bool "Contiguous Memory Allocator"
diff --git a/mm/frontswap.c b/mm/frontswap.c
index 157e5bf63504..e3370e46a0a5 100644
--- a/mm/frontswap.c
+++ b/mm/frontswap.c
@@ -33,23 +33,6 @@ static struct frontswap_ops *frontswap_ops __read_mostly;
#define for_each_frontswap_ops(ops) \
for ((ops) = frontswap_ops; (ops); (ops) = (ops)->next)
-/*
- * If enabled, frontswap_store will return failure even on success. As
- * a result, the swap subsystem will always write the page to swap, in
- * effect converting frontswap into a writethrough cache. In this mode,
- * there is no direct reduction in swap writes, but a frontswap backend
- * can unilaterally "reclaim" any pages in use with no data loss, thus
- * providing increases control over maximum memory usage due to frontswap.
- */
-static bool frontswap_writethrough_enabled __read_mostly;
-
-/*
- * If enabled, the underlying tmem implementation is capable of doing
- * exclusive gets, so frontswap_load, on a successful tmem_get must
- * mark the page as no longer in frontswap AND mark it dirty.
- */
-static bool frontswap_tmem_exclusive_gets_enabled __read_mostly;
-
#ifdef CONFIG_DEBUG_FS
/*
* Counters available via /sys/kernel/debug/frontswap (if debugfs is
@@ -167,24 +150,6 @@ void frontswap_register_ops(struct frontswap_ops *ops)
}
EXPORT_SYMBOL(frontswap_register_ops);
-/*
- * Enable/disable frontswap writethrough (see above).
- */
-void frontswap_writethrough(bool enable)
-{
- frontswap_writethrough_enabled = enable;
-}
-EXPORT_SYMBOL(frontswap_writethrough);
-
-/*
- * Enable/disable frontswap exclusive gets (see above).
- */
-void frontswap_tmem_exclusive_gets(bool enable)
-{
- frontswap_tmem_exclusive_gets_enabled = enable;
-}
-EXPORT_SYMBOL(frontswap_tmem_exclusive_gets);
-
/*
* Called when a swap device is swapon'd.
*/
@@ -280,9 +245,6 @@ int __frontswap_store(struct page *page)
} else {
inc_frontswap_failed_stores();
}
- if (frontswap_writethrough_enabled)
- /* report failure so swap also writes to swap device */
- ret = -1;
return ret;
}
EXPORT_SYMBOL(__frontswap_store);
@@ -314,13 +276,8 @@ int __frontswap_load(struct page *page)
if (!ret) /* successful load */
break;
}
- if (ret == 0) {
+ if (ret == 0)
inc_frontswap_loads();
- if (frontswap_tmem_exclusive_gets_enabled) {
- SetPageDirty(page);
- __frontswap_clear(sis, offset);
- }
- }
return ret;
}
EXPORT_SYMBOL(__frontswap_load);
@@ -369,117 +326,6 @@ void __frontswap_invalidate_area(unsigned type)
}
EXPORT_SYMBOL(__frontswap_invalidate_area);
-static unsigned long __frontswap_curr_pages(void)
-{
- unsigned long totalpages = 0;
- struct swap_info_struct *si = NULL;
-
- assert_spin_locked(&swap_lock);
- plist_for_each_entry(si, &swap_active_head, list)
- totalpages += atomic_read(&si->frontswap_pages);
- return totalpages;
-}
-
-static int __frontswap_unuse_pages(unsigned long total, unsigned long *unused,
- int *swapid)
-{
- int ret = -EINVAL;
- struct swap_info_struct *si = NULL;
- int si_frontswap_pages;
- unsigned long total_pages_to_unuse = total;
- unsigned long pages = 0, pages_to_unuse = 0;
-
- assert_spin_locked(&swap_lock);
- plist_for_each_entry(si, &swap_active_head, list) {
- si_frontswap_pages = atomic_read(&si->frontswap_pages);
- if (total_pages_to_unuse < si_frontswap_pages) {
- pages = pages_to_unuse = total_pages_to_unuse;
- } else {
- pages = si_frontswap_pages;
- pages_to_unuse = 0; /* unuse all */
- }
- /* ensure there is enough RAM to fetch pages from frontswap */
- if (security_vm_enough_memory_mm(current->mm, pages)) {
- ret = -ENOMEM;
- continue;
- }
- vm_unacct_memory(pages);
- *unused = pages_to_unuse;
- *swapid = si->type;
- ret = 0;
- break;
- }
-
- return ret;
-}
-
-/*
- * Used to check if it's necessory and feasible to unuse pages.
- * Return 1 when nothing to do, 0 when need to shink pages,
- * error code when there is an error.
- */
-static int __frontswap_shrink(unsigned long target_pages,
- unsigned long *pages_to_unuse,
- int *type)
-{
- unsigned long total_pages = 0, total_pages_to_unuse;
-
- assert_spin_locked(&swap_lock);
-
- total_pages = __frontswap_curr_pages();
- if (total_pages <= target_pages) {
- /* Nothing to do */
- *pages_to_unuse = 0;
- return 1;
- }
- total_pages_to_unuse = total_pages - target_pages;
- return __frontswap_unuse_pages(total_pages_to_unuse, pages_to_unuse, type);
-}
-
-/*
- * Frontswap, like a true swap device, may unnecessarily retain pages
- * under certain circumstances; "shrink" frontswap is essentially a
- * "partial swapoff" and works by calling try_to_unuse to attempt to
- * unuse enough frontswap pages to attempt to -- subject to memory
- * constraints -- reduce the number of pages in frontswap to the
- * number given in the parameter target_pages.
- */
-void frontswap_shrink(unsigned long target_pages)
-{
- unsigned long pages_to_unuse = 0;
- int uninitialized_var(type), ret;
-
- /*
- * we don't want to hold swap_lock while doing a very
- * lengthy try_to_unuse, but swap_list may change
- * so restart scan from swap_active_head each time
- */
- spin_lock(&swap_lock);
- ret = __frontswap_shrink(target_pages, &pages_to_unuse, &type);
- spin_unlock(&swap_lock);
- if (ret == 0)
- try_to_unuse(type, true, pages_to_unuse);
- return;
-}
-EXPORT_SYMBOL(frontswap_shrink);
-
-/*
- * Count and return the number of frontswap pages across all
- * swap devices. This is exported so that backend drivers can
- * determine current usage without reading debugfs.
- */
-unsigned long frontswap_curr_pages(void)
-{
- unsigned long totalpages = 0;
-
- spin_lock(&swap_lock);
- totalpages = __frontswap_curr_pages();
- spin_unlock(&swap_lock);
-
- return totalpages;
-}
-EXPORT_SYMBOL(frontswap_curr_pages);
-
static int __init init_frontswap(void)
{
#ifdef CONFIG_DEBUG_FS
--
2.16.4
^ permalink raw reply related
* [PATCH 4/5] docs: by default, build docs a lot faster with Sphinx >= 1.7
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558955082.git.mchehab+samsung@kernel.org>
Since Sphinx version 1.7, it is possible to use "-jauto" in
order to speedup documentation builds. On older versions,
while -j was already supported, one would need to set the
number of threads manually.
So, if SPHINXOPTS is not provided, add -jauto, in order to
speed up the build. That makes it *a lot* times faster than
without -j.
If one really wants to slow things down, it can just use:
make SPHINXOPTS=-j1 htmldocs
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 380e24053d6f..794233d05789 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -28,6 +28,8 @@ ifeq ($(HAVE_SPHINX),0)
else # HAVE_SPHINX
+SPHINXOPTS = $(shell perl -e 'open IN,"sphinx-build --version |"; while (<IN>) { if (m/([\d\.]+)/) { print "-jauto" if ($$1 >= "1.7") } ;} close IN')
+
# User-friendly check for pdflatex and latexmk
HAVE_PDFLATEX := $(shell if which $(PDFLATEX) >/dev/null 2>&1; then echo 1; else echo 0; fi)
HAVE_LATEXMK := $(shell if which latexmk >/dev/null 2>&1; then echo 1; else echo 0; fi)
--
2.21.0
^ permalink raw reply related
* [PATCH 5/5] docs: requirements.txt: recommend Sphinx 1.7.9
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet, Federico Vaga, Mike Rapoport, Matthew Wilcox,
Joel Nider
In-Reply-To: <cover.1558955082.git.mchehab+samsung@kernel.org>
As discussed at the linux-doc ML, while we'll still support
version 1.3, it is time to recommend a more modern version.
So, let's switch the minimal requirements to Sphinx 1.7.9,
as it has the "-jauto" flag, with makes a lot faster when
building documentation.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/doc-guide/sphinx.rst | 17 ++++++++---------
Documentation/sphinx/requirements.txt | 4 ++--
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/Documentation/doc-guide/sphinx.rst b/Documentation/doc-guide/sphinx.rst
index c039224b404e..4ba081f43e98 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -27,8 +27,7 @@ Sphinx Install
==============
The ReST markups currently used by the Documentation/ files are meant to be
-built with ``Sphinx`` version 1.3 or higher. If you desire to build
-PDF output, it is recommended to use version 1.4.6 or higher.
+built with ``Sphinx`` version 1.3 or higher.
There's a script that checks for the Sphinx requirements. Please see
:ref:`sphinx-pre-install` for further details.
@@ -56,13 +55,13 @@ or ``virtualenv``, depending on how your distribution packaged Python 3.
those expressions are written using LaTeX notation. It needs texlive
installed with amdfonts and amsmath in order to evaluate them.
-In summary, if you want to install Sphinx version 1.4.9, you should do::
+In summary, if you want to install Sphinx version 1.7.9, you should do::
- $ virtualenv sphinx_1.4
- $ . sphinx_1.4/bin/activate
- (sphinx_1.4) $ pip install -r Documentation/sphinx/requirements.txt
+ $ virtualenv sphinx_1.7.9
+ $ . sphinx_1.7.9/bin/activate
+ (sphinx_1.7.9) $ pip install -r Documentation/sphinx/requirements.txt
-After running ``. sphinx_1.4/bin/activate``, the prompt will change,
+After running ``. sphinx_1.7.9/bin/activate``, the prompt will change,
in order to indicate that you're using the new environment. If you
open a new shell, you need to rerun this command to enter again at
the virtual environment before building the documentation.
@@ -105,8 +104,8 @@ command line options for your distro::
You should run:
sudo dnf install -y texlive-luatex85
- /usr/bin/virtualenv sphinx_1.4
- . sphinx_1.4/bin/activate
+ /usr/bin/virtualenv sphinx_1.7.9
+ . sphinx_1.7.9/bin/activate
pip install -r Documentation/sphinx/requirements.txt
Can't build as 1 mandatory dependency is missing at ./scripts/sphinx-pre-install line 468.
diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt
index 742be3e12619..14e29a0ae480 100644
--- a/Documentation/sphinx/requirements.txt
+++ b/Documentation/sphinx/requirements.txt
@@ -1,3 +1,3 @@
-docutils==0.12
-Sphinx==1.4.9
+docutils
+Sphinx==1.7.9
sphinx_rtd_theme
--
2.21.0
^ permalink raw reply related
* [PATCH 0/5] Improvements to the documentation build system
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List, Jonathan Corbet
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Joel Nider, Federico Vaga, Matthew Wilcox, Mike Rapoport
The first three patches here address some issues with the script which
detects the requirements for running Sphinx, making it a smarter and
running it all the times, in order to allow recommending version
updates.
The 4th patch adds "-jauto" by default, if Sphinx version supports it
(e. g. version 1.7 or upper).
The final patch changes the recommendation to use at least Sphinx
version 1.7.9, as discussed at linux-doc ML.
Mauro Carvalho Chehab (5):
scripts/sphinx-pre-install: make activate hint smarter
scripts/sphinx-pre-install: get rid of RHEL7 explicity check
scripts/sphinx-pre-install: always check if version is compatible with
build
docs: by default, build docs a lot faster with Sphinx >= 1.7
docs: requirements.txt: recommend Sphinx 1.7.9
Documentation/Makefile | 7 +++
Documentation/doc-guide/sphinx.rst | 17 +++---
Documentation/sphinx/requirements.txt | 4 +-
scripts/sphinx-pre-install | 75 +++++++++++++++------------
4 files changed, 58 insertions(+), 45 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH 3/5] scripts/sphinx-pre-install: always check if version is compatible with build
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558955082.git.mchehab+samsung@kernel.org>
Call the script every time a make docs target is selected, on
a simplified check mode.
With this change, the script will set two vars:
$min_version - obtained from `needs_sphinx` var inside
conf.py (currently, '1.3')
$rec_version - obtained from sphinx/requirements.txt.
With those changes, a target like "make htmldocs" will do:
1) If no sphinx-build/sphinx-build3 is found, it will run
the script on normal mode as before, checking for all
system dependencies and providing install hints for the
needed programs and will abort the build;
2) If no sphinx-build/sphinx-build3 is found, but there is
a sphinx_${VER}/bin/activate file, and if
${VER} >= $min_version (string comparation), it will
run in full mode, and will recommend to activate the
virtualenv. If there are multiple virtualenvs, it
will string sort the versions, recommending the
highest version and will abort the build;
3) If Sphinx is detected but has a version lower than
$min_version, it will run in full mode - with will
recommend creating a virtual env using sphinx/requirements.txt,
and will abort the build.
4) If Sphinx is detected and version is lower than
$rec_version, it will run in full mode and will
recommend creating a virtual env using sphinx/requirements.txt.
In this case, it **won't** abort the build.
5) If Sphinx is detected and version is equal or righer than
$rec_version it will return just after detecting the
version ("quick mode"), not checking if are there any
missing dependencies.
Just like before, if one wants to install Sphinx from the
distro, it has to call the script manually and use `--no-virtualenv`
argument to get the hints for his OS:
You should run:
sudo dnf install -y python3-sphinx python3-sphinx_rtd_theme
While here, add a small help for the three optional arguments
for the script.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/Makefile | 5 +++++
scripts/sphinx-pre-install | 46 +++++++++++++++++++++++++-------------
2 files changed, 35 insertions(+), 16 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e889e7cb8511..380e24053d6f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -70,12 +70,14 @@ quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
$(abspath $(BUILDDIR)/$3/$4)
htmldocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,html,$(var),,$(var)))
linkcheckdocs:
@$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,linkcheck,$(var),,$(var)))
latexdocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,latex,$(var),latex,$(var)))
ifeq ($(HAVE_PDFLATEX),0)
@@ -87,14 +89,17 @@ pdfdocs:
else # HAVE_PDFLATEX
pdfdocs: latexdocs
+ @./scripts/sphinx-pre-install --version-check
$(foreach var,$(SPHINXDIRS), $(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit;)
endif # HAVE_PDFLATEX
epubdocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,epub,$(var),epub,$(var)))
xmldocs:
+ @./scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call loop_cmd,sphinx,xml,$(var),xml,$(var)))
endif # HAVE_SPHINX
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index ded3e2ef3f8d..f001fc2fcf12 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -38,6 +38,7 @@ my $min_version;
my $pdf = 1;
my $virtualenv = 1;
+my $version_check = 0;
#
# List of required texlive packages on Fedora and OpenSuse
@@ -277,20 +278,22 @@ sub check_sphinx()
die "$sphinx didn't return its version" if (!$cur_version);
- printf "Sphinx version %s (minimal: %s, recommended >= %s)\n",
- $cur_version, $min_version, $rec_version;
-
if ($cur_version lt $min_version) {
- print "Warning: Sphinx version should be >= $min_version\n\n";
+ printf "ERROR: Sphinx version is %s. It should be >= %s (recommended >= %s)\n",
+ $cur_version, $min_version, $rec_version;;
$need_sphinx = 1;
return;
}
if ($cur_version lt $rec_version) {
+ printf "Sphinx version %s\n", $cur_version;
print "Warning: It is recommended at least Sphinx version $rec_version.\n";
- print " To upgrade, use:\n\n";
$rec_sphinx_upgrade = 1;
+ return;
}
+
+ # On version check mode, just assume Sphinx has all mandatory deps
+ exit (0) if ($version_check);
}
#
@@ -575,14 +578,18 @@ sub check_distros()
sub check_needs()
{
- if ($system_release) {
- print "Detected OS: $system_release.\n";
- } else {
- print "Unknown OS\n";
- }
-
# Check for needed programs/tools
check_sphinx();
+
+ if ($system_release) {
+ print "Detected OS: $system_release.\n\n";
+ } else {
+ print "Unknown OS\n\n";
+ }
+
+ print "To upgrade Sphinx, use:\n\n" if ($rec_sphinx_upgrade);
+
+ # Check for needed programs/tools
check_perl_module("Pod::Usage", 0);
check_program("make", 0);
check_program("gcc", 0);
@@ -601,13 +608,14 @@ sub check_needs()
}
if ($need_sphinx || $rec_sphinx_upgrade) {
my $min_activate = "$ENV{'PWD'}/${virtenv_prefix}${min_version}/bin/activate";
- my @activates = glob "$ENV{'PWD'}/${virtenv_prefix}*/bin/activate";
+ my @activates = glob "$ENV{'PWD'}/${virtenv_prefix}*/bin/activate";
- @activates = sort {$b cmp $a} @activates;
+ @activates = sort {$b cmp $a} @activates;
- if (scalar @activates > 0 && $activates[0] ge $min_activate) {
- printf "\nNeed to activate virtualenv with:\n";
+ if ($need_sphinx && scalar @activates > 0 && $activates[0] ge $min_activate) {
+ printf "\nNeed to activate a compatible Sphinx version on virtualenv with:\n";
printf "\t. $activates[0]\n";
+ exit (1);
} else {
my $rec_activate = "$virtenv_dir/bin/activate";
my $virtualenv = findprog("virtualenv-3");
@@ -646,8 +654,14 @@ while (@ARGV) {
$virtualenv = 0;
} elsif ($arg eq "--no-pdf"){
$pdf = 0;
+ } elsif ($arg eq "--version-check"){
+ $version_check = 1;
} else {
- print "Usage:\n\t$0 <--no-virtualenv> <--no-pdf>\n\n";
+ print "Usage:\n\t$0 <--no-virtualenv> <--no-pdf> <--version-check>\n\n";
+ print "Where:\n";
+ print "\t--no-virtualenv\t- Recommend installing Sphinx instead of using a virtualenv\n";
+ print "\t--version-check\t- if version is compatible, don't check for missing dependencies\n";
+ print "\t--no-pdf\t- don't check for dependencies required to build PDF docs\n\n";
exit -1;
}
}
--
2.21.0
^ permalink raw reply related
* [PATCH 1/5] scripts/sphinx-pre-install: make activate hint smarter
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558955082.git.mchehab+samsung@kernel.org>
It is possible that multiple Sphinx virtualenvs are installed
on a given kernel tree. Change the logic to get the latest
version of those, as this is probably what the user wants.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/sphinx-pre-install | 22 ++++++++++++++--------
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 8c2d1bcf2e02..11239eb29695 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -1,7 +1,7 @@
#!/usr/bin/perl
use strict;
-# Copyright (c) 2017 Mauro Carvalho Chehab <mchehab@kernel.org>
+# Copyright (c) 2017-2019 Mauro Carvalho Chehab <mchehab@kernel.org>
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
@@ -15,6 +15,7 @@ use strict;
my $conf = "Documentation/conf.py";
my $requirement_file = "Documentation/sphinx/requirements.txt";
+my $virtenv_prefix = "sphinx_";
#
# Static vars
@@ -28,7 +29,8 @@ my $need_symlink = 0;
my $need_sphinx = 0;
my $rec_sphinx_upgrade = 0;
my $install = "";
-my $virtenv_dir = "sphinx_";
+my $virtenv_dir = "";
+my $min_version;
#
# Command line arguments
@@ -229,7 +231,6 @@ sub get_sphinx_fname()
sub check_sphinx()
{
- my $min_version;
my $rec_version;
my $cur_version;
@@ -255,7 +256,7 @@ sub check_sphinx()
die "Can't get recommended sphinx version from $requirement_file" if (!$min_version);
- $virtenv_dir .= $rec_version;
+ $virtenv_dir = $virtenv_prefix . $rec_version;
my $sphinx = get_sphinx_fname();
return if ($sphinx eq "");
@@ -612,18 +613,23 @@ sub check_needs()
which("sphinx-build-3");
}
if ($need_sphinx || $rec_sphinx_upgrade) {
- my $activate = "$virtenv_dir/bin/activate";
- if (-e "$ENV{'PWD'}/$activate") {
+ my $min_activate = "$ENV{'PWD'}/${virtenv_prefix}${min_version}/bin/activate";
+ my @activates = glob "$ENV{'PWD'}/${virtenv_prefix}*/bin/activate";
+
+ @activates = sort {$b cmp $a} @activates;
+
+ if (scalar @activates > 0 && $activates[0] ge $min_activate) {
printf "\nNeed to activate virtualenv with:\n";
- printf "\t. $activate\n";
+ printf "\t. $activates[0]\n";
} else {
+ my $rec_activate = "$virtenv_dir/bin/activate";
my $virtualenv = findprog("virtualenv-3");
$virtualenv = findprog("virtualenv-3.5") if (!$virtualenv);
$virtualenv = findprog("virtualenv") if (!$virtualenv);
$virtualenv = "virtualenv" if (!$virtualenv);
printf "\t$virtualenv $virtenv_dir\n";
- printf "\t. $activate\n";
+ printf "\t. $rec_activate\n";
printf "\tpip install -r $requirement_file\n";
$need++ if (!$rec_sphinx_upgrade);
--
2.21.0
^ permalink raw reply related
* [PATCH 2/5] scripts/sphinx-pre-install: get rid of RHEL7 explicity check
From: Mauro Carvalho Chehab @ 2019-05-27 11:07 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, Mauro Carvalho Chehab, linux-kernel,
Jonathan Corbet
In-Reply-To: <cover.1558955082.git.mchehab+samsung@kernel.org>
RHEL8 was already launched. This test won't get it, and will
do the wrong thing. Ok, we could fix it, but now we check
Sphinx version to ensure that it matches the minimal (1.3),
so there's no need for an explicit check there.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
scripts/sphinx-pre-install | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/scripts/sphinx-pre-install b/scripts/sphinx-pre-install
index 11239eb29695..ded3e2ef3f8d 100755
--- a/scripts/sphinx-pre-install
+++ b/scripts/sphinx-pre-install
@@ -581,19 +581,6 @@ sub check_needs()
print "Unknown OS\n";
}
- # RHEL 7.x and clones have Sphinx version 1.1.x and incomplete texlive
- if (($system_release =~ /Red Hat Enterprise Linux/) ||
- ($system_release =~ /CentOS/) ||
- ($system_release =~ /Scientific Linux/) ||
- ($system_release =~ /Oracle Linux Server/)) {
- $virtualenv = 1;
- $pdf = 0;
-
- printf("NOTE: On this distro, Sphinx and TexLive shipped versions are incompatible\n");
- printf("with doc build. So, use Sphinx via a Python virtual environment.\n\n");
- printf("This script can't install a TexLive version that would provide PDF.\n");
- }
-
# Check for needed programs/tools
check_sphinx();
check_perl_module("Pod::Usage", 0);
--
2.21.0
^ permalink raw reply related
* Re: Ingenic Timer/Counter Unit (TCU) patchset v12
From: Mathieu Malaterre @ 2019-05-27 11:39 UTC (permalink / raw)
To: Paul Cercueil
Cc: Rob Herring, Mark Rutland, Ralf Baechle, Paul Burton, James Hogan,
Jonathan Corbet, Daniel Lezcano, Thomas Gleixner,
Michael Turquette, Stephen Boyd, Jason Cooper, Marc Zyngier,
Lee Jones, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-mips, linux-doc, linux-clk, od
In-Reply-To: <20190521145141.9813-1-paul@crapouillou.net>
On Tue, May 21, 2019 at 4:51 PM Paul Cercueil <paul@crapouillou.net> wrote:
>
> Hi,
>
> Here's the V12 of my patchset to add support for the Timer/Counter Unit
> (TCU) present on the JZ47xx SoCs from Ingenic.
>
> This patchset is much shorter at only 13 patches vs. 27 patches in V11;
> the remaining patches will be sent in parallel (if applicable) or as a
> follow-up patchset once this one is merged.
>
> In V11 the clocksource maintainers weren't happy with the size of the
> ingenic-timer driver, which included clocks and irqchip setup code.
> On the other hand, devicetree maintainers wanted one single node for
> the TCU hardware since it's effectively just one hardware block.
>
> In this patchset the functionality is cut in four different drivers:
> a MFD one to provide the regmap, probe the children and which provides
> several API functions; a clocks driver; a irqchip driver; a clocksource
> driver. All these drivers work with the same regmap, have the same
> compatible strings, and will probe _with the same devicetree node_.
For the series:
Tested-by: Mathieu Malaterre <malat@debian.org>
System: MIPS Creator CI20
For reference, here is my local patch:
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 1bfac58da5df..e7b7da32f278 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include <dt-bindings/clock/jz4780-cgu.h>
+#include <dt-bindings/clock/ingenic,tcu.h>
#include <dt-bindings/dma/jz4780-dma.h>
/ {
@@ -80,6 +81,15 @@
interrupt-parent = <&intc>;
interrupts = <27 26 25>;
+
+ watchdog: watchdog@0 {
+ compatible = "ingenic,jz4780-watchdog";
+ reg = <0x0 0xc>;
+
+ clocks = <&tcu TCU_CLK_WDT>;
+ clock-names = "wdt";
+ };
+
};
rtc_dev: rtc@10003000 {
@@ -287,14 +297,6 @@
status = "disabled";
};
- watchdog: watchdog@10002000 {
- compatible = "ingenic,jz4780-watchdog";
- reg = <0x10002000 0x10>;
-
- clocks = <&cgu JZ4780_CLK_RTCLK>;
- clock-names = "rtc";
- };
-
nemc: nemc@13410000 {
compatible = "ingenic,jz4780-nemc";
reg = <0x13410000 0x10000>;
> Regards,
> -Paul
>
>
^ permalink raw reply related
* Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
From: Loys Ollivier @ 2019-05-27 12:14 UTC (permalink / raw)
To: Atish Patra, linux-kernel
Cc: mark.rutland, Jonathan Corbet, Albert Ou, linux-doc,
ard.biesheuvel, catalin.marinas, Anup Patel, Zong Li, Atish Patra,
Nick Kossifidis, Palmer Dabbelt, paul.walmsley@sifive.com,
Karsten Merker, linux-riscv, marek.vasut@gmail.com,
linux-arm-kernel
In-Reply-To: <20190524041814.7497-1-atish.patra@wdc.com>
On Thu 23 May 2019 at 21:18, Atish Patra <atish.patra@wdc.com> wrote:
> Currently, the last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot
> process.
>
> Add an image header that boot loader understands and boot Linux from
> flat Image directly.
>
> This header is based on ARM64 boot image header and provides an
> opportunity to combine both ARM64 & RISC-V image headers in future.
>
> Also make sure that PE/COFF header can co-exist in the same image so
> that EFI stub can be supported for RISC-V in future. EFI specification
> needs PE/COFF image header in the beginning of the kernel image in order
> to load it as an EFI application. In order to support EFI stub, code0
> should be replaced with "MZ" magic string and res4(at offset 0x3c)
> should point to the rest of the PE/COFF header (which will be added
> during EFI support).
>
> Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
Thanks Atish, happy to have this support that makes the boot process
more straightforward.
Tested on HiFive Unleashed using OpenSBI + U-Boot v2019.07-rc2 + Linux.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Karsten Merker <merker@debian.org>
> Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
Tested-by: Loys Ollivier <lollivier@baylibre.com>
^ permalink raw reply
* Re: [PATCH 2/3] mm: remove cleancache.c
From: David Sterba @ 2019-05-27 13:10 UTC (permalink / raw)
To: Juergen Gross
Cc: linux-kernel, linux-doc, linux-erofs, devel, linux-fsdevel,
linux-btrfs, linux-ext4, linux-f2fs-devel, linux-mm,
Jonathan Corbet, Gao Xiang, Chao Yu, Greg Kroah-Hartman,
Alexander Viro, Chris Mason, Josef Bacik, David Sterba,
Theodore Ts'o, Andreas Dilger, Jaegeuk Kim, Mark Fasheh,
Joel Becker, Joseph Qi, ocfs2-devel
In-Reply-To: <20190527103207.13287-3-jgross@suse.com>
On Mon, May 27, 2019 at 12:32:06PM +0200, Juergen Gross wrote:
> With the removal of tmem and xen-selfballoon the only user of
> cleancache is gone. Remove it, too.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> Documentation/vm/cleancache.rst | 296 ------------------------------------
> Documentation/vm/frontswap.rst | 10 +-
> Documentation/vm/index.rst | 1 -
> MAINTAINERS | 7 -
> drivers/staging/erofs/data.c | 6 -
> drivers/staging/erofs/internal.h | 1 -
> fs/block_dev.c | 5 -
For the btrfs part:
> fs/btrfs/extent_io.c | 9 --
> fs/btrfs/super.c | 2 -
Acked-by: David Sterba <dsterba@suse.com>
^ permalink raw reply
* Re: [PATCH v7 1/1] iommu: enhance IOMMU dma mode build options
From: Joerg Roedel @ 2019-05-27 14:21 UTC (permalink / raw)
To: Zhen Lei
Cc: Jean-Philippe Brucker, John Garry, Robin Murphy, Will Deacon,
Jonathan Corbet, linux-doc, Sebastian Ott, Gerald Schaefer,
Martin Schwidefsky, Heiko Carstens, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Tony Luck, Fenghua Yu,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H . Peter Anvin,
David Woodhouse, iommu, linux-kernel, linux-s390, linuxppc-dev,
x86, linux-ia64, Hanjun Guo
In-Reply-To: <20190520135947.14960-2-thunder.leizhen@huawei.com>
Hi Zhen Lei,
On Mon, May 20, 2019 at 09:59:47PM +0800, Zhen Lei wrote:
> arch/ia64/kernel/pci-dma.c | 2 +-
> arch/powerpc/platforms/powernv/pci-ioda.c | 3 ++-
> arch/s390/pci/pci_dma.c | 2 +-
> arch/x86/kernel/pci-dma.c | 7 ++---
> drivers/iommu/Kconfig | 44 ++++++++++++++++++++++++++-----
> drivers/iommu/amd_iommu_init.c | 3 ++-
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/iommu/iommu.c | 3 ++-
> 8 files changed, 48 insertions(+), 18 deletions(-)
This needs Acks from the arch maintainers of ia64, powerpc, s390 and
x86, at least.
It is easier for them if you split it up into the Kconfig change and
separete patches per arch and per iommu driver. Then collect the Acks on
the individual patches.
Thanks,
Joerg
^ permalink raw reply
* Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
From: Ard Biesheuvel @ 2019-05-27 14:34 UTC (permalink / raw)
To: Atish Patra
Cc: Linux Kernel Mailing List, Karsten Merker, Albert Ou, Anup Patel,
Jonathan Corbet, Linux Doc Mailing List, linux-riscv,
Nick Kossifidis, Palmer Dabbelt, Zong Li,
paul.walmsley@sifive.com, marek.vasut@gmail.com, linux-arm-kernel,
Mark Rutland, Catalin Marinas
In-Reply-To: <20190524041814.7497-1-atish.patra@wdc.com>
On Fri, 24 May 2019 at 06:18, Atish Patra <atish.patra@wdc.com> wrote:
>
> Currently, the last stage boot loaders such as U-Boot can accept only
> uImage which is an unnecessary additional step in automating boot
> process.
>
> Add an image header that boot loader understands and boot Linux from
> flat Image directly.
>
> This header is based on ARM64 boot image header and provides an
> opportunity to combine both ARM64 & RISC-V image headers in future.
>
> Also make sure that PE/COFF header can co-exist in the same image so
> that EFI stub can be supported for RISC-V in future. EFI specification
> needs PE/COFF image header in the beginning of the kernel image in order
> to load it as an EFI application. In order to support EFI stub, code0
> should be replaced with "MZ" magic string and res4(at offset 0x3c)
> should point to the rest of the PE/COFF header (which will be added
> during EFI support).
>
> Tested on both QEMU and HiFive Unleashed using OpenSBI + U-Boot + Linux.
>
> Signed-off-by: Atish Patra <atish.patra@wdc.com>
> Reviewed-by: Karsten Merker <merker@debian.org>
> Tested-by: Karsten Merker <merker@debian.org> (QEMU+OpenSBI+U-Boot)
>
> ---
> I have not sent out corresponding U-Boot patch as all the changes are
> compatible with current u-boot support. Once, the kernel header format
> is agreed upon, I will update the U-Boot patch.
>
> Changes from v3->v4
> 1. Update the commit text to clarify about PE/COFF header.
>
> Changes from v2->v3
> 1. Modified reserved fields to define a header version.
> 2. Added header documentation.
>
> Changes from v1-v2:
> 1. Added additional reserved elements to make it fully PE compatible.
> ---
> Documentation/riscv/boot-image-header.txt | 50 ++++++++++++++++++
> arch/riscv/include/asm/image.h | 64 +++++++++++++++++++++++
> arch/riscv/kernel/head.S | 32 ++++++++++++
> 3 files changed, 146 insertions(+)
> create mode 100644 Documentation/riscv/boot-image-header.txt
> create mode 100644 arch/riscv/include/asm/image.h
>
> diff --git a/Documentation/riscv/boot-image-header.txt b/Documentation/riscv/boot-image-header.txt
> new file mode 100644
> index 000000000000..68abc2353cec
> --- /dev/null
> +++ b/Documentation/riscv/boot-image-header.txt
> @@ -0,0 +1,50 @@
> + Boot image header in RISC-V Linux
> + =============================================
> +
> +Author: Atish Patra <atish.patra@wdc.com>
> +Date : 20 May 2019
> +
> +This document only describes the boot image header details for RISC-V Linux.
> +The complete booting guide will be available at Documentation/riscv/booting.txt.
> +
> +The following 64-byte header is present in decompressed Linux kernel image.
> +
> + u32 code0; /* Executable code */
> + u32 code1; /* Executable code */
Apologies for not mentioning this in my previous reply, but given that
you already know that you will need to put the magic string MZ at
offset 0x0, it makes more sense to not put any code there at all, but
educate the bootloader that the first executable instruction is at
offset 0x20, and put the spare fields right after it in case you ever
need more than 2 slots. (On arm64, we were lucky to be able to find an
opcode that happened to contain the MZ bit pattern and act almost like
a NOP, but it seems silly to rely on that for RISC-V as well)
So something like
u16 pe_res1; /* MZ for EFI bootable images, don't care otherwise */
u8 magic[6]; /* "RISCV\0"
u64 text_offset; /* Image load offset, little endian */
u64 image_size; /* Effective Image size, little endian */
u64 flags; /* kernel flags, little endian */
u32 code0; /* Executable code */
u32 code1; /* Executable code */
u64 reserved[2]; /* reserved for future use */
u32 version; /* Version of this header */
u32 pe_res2; /* Reserved for PE COFF offset */
> +This header format is compliant with PE/COFF header and largely inspired from
> +ARM64 header. Thus, both ARM64 & RISC-V header can be combined into one common
> +header in future.
> +
> +Notes:
> +- This header can also be reused to support EFI stub for RISC-V in future. EFI
> + specification needs PE/COFF image header in the beginning of the kernel image
> + in order to load it as an EFI application. In order to support EFI stub,
> + code0 should be replaced with "MZ" magic string and res5(at offset 0x3c) should
> + point to the rest of the PE/COFF header.
> +
> +- version field indicate header version number.
> + Bits 0:15 - Minor version
> + Bits 16:31 - Major version
> +
> + This preserves compatibility across newer and older version of the header.
> + The current version is defined as 0.1.
> +
> +- res3 is reserved for offset to any other additional fields. This makes the
> + header extendible in future. One example would be to accommodate ISA
> + extension for RISC-V in future. For current version, it is set to be zero.
> +
> +- In current header, the flag field has only one field.
> + Bit 0: Kernel endianness. 1 if BE, 0 if LE.
> +
> +- Image size is mandatory for boot loader to load kernel image. Booting will
> + fail otherwise.
> diff --git a/arch/riscv/include/asm/image.h b/arch/riscv/include/asm/image.h
> new file mode 100644
> index 000000000000..61c9f20d2f19
> --- /dev/null
> +++ b/arch/riscv/include/asm/image.h
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef __ASM_IMAGE_H
> +#define __ASM_IMAGE_H
> +
> +#define RISCV_IMAGE_MAGIC "RISCV"
> +
> +
> +#define RISCV_IMAGE_FLAG_BE_SHIFT 0
> +#define RISCV_IMAGE_FLAG_BE_MASK 0x1
> +
> +#define RISCV_IMAGE_FLAG_LE 0
> +#define RISCV_IMAGE_FLAG_BE 1
> +
> +
> +#ifdef CONFIG_CPU_BIG_ENDIAN
> +#define __HEAD_FLAG_BE RISCV_IMAGE_FLAG_BE
> +#else
> +#define __HEAD_FLAG_BE RISCV_IMAGE_FLAG_LE
> +#endif
> +
> +#define __HEAD_FLAG(field) (__HEAD_FLAG_##field << \
> + RISCV_IMAGE_FLAG_##field##_SHIFT)
> +
> +#define __HEAD_FLAGS (__HEAD_FLAG(BE))
> +
> +#define RISCV_HEADER_VERSION_MAJOR 0
> +#define RISCV_HEADER_VERSION_MINOR 1
> +
> +#define RISCV_HEADER_VERSION (RISCV_HEADER_VERSION_MAJOR << 16 | \
> + RISCV_HEADER_VERSION_MINOR)
> +
> +#ifndef __ASSEMBLY__
> +/*
> + * struct riscv_image_header - riscv kernel image header
> + *
> + * @code0: Executable code
> + * @code1: Executable code
> + * @text_offset: Image load offset
> + * @image_size: Effective Image size
> + * @flags: kernel flags
> + * @version: version
> + * @reserved: reserved
> + * @reserved: reserved
> + * @magic: Magic number
> + * @reserved: reserved (will be used for additional RISC-V specific header)
> + * @reserved: reserved (will be used for PE COFF offset)
> + */
> +
> +struct riscv_image_header {
> + u32 code0;
> + u32 code1;
> + u64 text_offset;
> + u64 image_size;
> + u64 flags;
> + u32 version;
> + u32 res1;
> + u64 res2;
> + u64 magic;
> + u32 res3;
> + u32 res4;
> +};
> +#endif /* __ASSEMBLY__ */
> +#endif /* __ASM_IMAGE_H */
> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
> index 370c66ce187a..577893bb150d 100644
> --- a/arch/riscv/kernel/head.S
> +++ b/arch/riscv/kernel/head.S
> @@ -19,9 +19,41 @@
> #include <asm/thread_info.h>
> #include <asm/page.h>
> #include <asm/csr.h>
> +#include <asm/image.h>
>
> __INIT
> ENTRY(_start)
> + /*
> + * Image header expected by Linux boot-loaders. The image header data
> + * structure is described in asm/image.h.
> + * Do not modify it without modifying the structure and all bootloaders
> + * that expects this header format!!
> + */
> + /* jump to start kernel */
> + j _start_kernel
> + /* reserved */
> + .word 0
> + .balign 8
> +#if __riscv_xlen == 64
> + /* Image load offset(2MB) from start of RAM */
> + .dword 0x200000
> +#else
> + /* Image load offset(4MB) from start of RAM */
> + .dword 0x400000
> +#endif
> + /* Effective size of kernel image */
> + .dword _end - _start
> + .dword __HEAD_FLAGS
> + .word RISCV_HEADER_VERSION
> + .word 0
> + .dword 0
> + .asciz RISCV_IMAGE_MAGIC
> + .word 0
> + .balign 4
> + .word 0
> +
> +.global _start_kernel
> +_start_kernel:
> /* Mask all interrupts */
> csrw CSR_SIE, zero
> csrw CSR_SIP, zero
> --
> 2.21.0
>
^ permalink raw reply
* Re: [v4 PATCH] RISC-V: Add an Image header that boot loader can parse.
From: Karsten Merker @ 2019-05-27 22:16 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Atish Patra, Linux Kernel Mailing List, Karsten Merker, Albert Ou,
Anup Patel, Jonathan Corbet, Linux Doc Mailing List, linux-riscv,
Nick Kossifidis, Palmer Dabbelt, Zong Li,
paul.walmsley@sifive.com, marek.vasut@gmail.com, linux-arm-kernel,
Mark Rutland, Catalin Marinas
In-Reply-To: <CAKv+Gu9U56b50TrfriBfRFed_1aoXg2Y624tu7v5m2y+6DVq5w@mail.gmail.com>
On Mon, May 27, 2019 at 04:34:57PM +0200, Ard Biesheuvel wrote:
> On Fri, 24 May 2019 at 06:18, Atish Patra <atish.patra@wdc.com> wrote:
> > Currently, the last stage boot loaders such as U-Boot can accept only
> > uImage which is an unnecessary additional step in automating boot
> > process.
> >
> > Add an image header that boot loader understands and boot Linux from
> > flat Image directly.
> >
> > This header is based on ARM64 boot image header and provides an
> > opportunity to combine both ARM64 & RISC-V image headers in future.
> >
> > Also make sure that PE/COFF header can co-exist in the same image so
> > that EFI stub can be supported for RISC-V in future. EFI specification
> > needs PE/COFF image header in the beginning of the kernel image in order
> > to load it as an EFI application. In order to support EFI stub, code0
> > should be replaced with "MZ" magic string and res4(at offset 0x3c)
> > should point to the rest of the PE/COFF header (which will be added
> > during EFI support).
[...]
> > Documentation/riscv/boot-image-header.txt | 50 ++++++++++++++++++
> > arch/riscv/include/asm/image.h | 64 +++++++++++++++++++++++
> > arch/riscv/kernel/head.S | 32 ++++++++++++
> > 3 files changed, 146 insertions(+)
> > create mode 100644 Documentation/riscv/boot-image-header.txt
> > create mode 100644 arch/riscv/include/asm/image.h
> >
> > diff --git a/Documentation/riscv/boot-image-header.txt b/Documentation/riscv/boot-image-header.txt
> > new file mode 100644
> > index 000000000000..68abc2353cec
> > --- /dev/null
> > +++ b/Documentation/riscv/boot-image-header.txt
> > @@ -0,0 +1,50 @@
> > + Boot image header in RISC-V Linux
> > + =============================================
> > +
> > +Author: Atish Patra <atish.patra@wdc.com>
> > +Date : 20 May 2019
> > +
> > +This document only describes the boot image header details for RISC-V Linux.
> > +The complete booting guide will be available at Documentation/riscv/booting.txt.
> > +
> > +The following 64-byte header is present in decompressed Linux kernel image.
> > +
> > + u32 code0; /* Executable code */
> > + u32 code1; /* Executable code */
>
> Apologies for not mentioning this in my previous reply, but given that
> you already know that you will need to put the magic string MZ at
> offset 0x0, it makes more sense to not put any code there at all, but
> educate the bootloader that the first executable instruction is at
> offset 0x20, and put the spare fields right after it in case you ever
> need more than 2 slots. (On arm64, we were lucky to be able to find an
> opcode that happened to contain the MZ bit pattern and act almost like
> a NOP, but it seems silly to rely on that for RISC-V as well)
>
> So something like
>
> u16 pe_res1; /* MZ for EFI bootable images, don't care otherwise */
> u8 magic[6]; /* "RISCV\0"
>
> u64 text_offset; /* Image load offset, little endian */
> u64 image_size; /* Effective Image size, little endian */
> u64 flags; /* kernel flags, little endian */
>
> u32 code0; /* Executable code */
> u32 code1; /* Executable code */
>
> u64 reserved[2]; /* reserved for future use */
>
> u32 version; /* Version of this header */
> u32 pe_res2; /* Reserved for PE COFF offset */
Hello,
wouldn't that immediately break existing systems (including qemu
when loading kernels with the "-kernel" option) that rely on the
fact that the kernel entry point is always at the kernel load
address? The ARM64 header and Atish's original RISC-V proposal
based on the ARM64 header keep the property that jumping to the
kernel load address always works, regardless of what the
particular header looks like and which potential future
extensions it includes, but the proposed change above wouldn't do
that.
Although I agree that having to integrate the "MZ" string as an
instruction isn't particularly nice, I don't think that this is a
sufficient justification for breaking compatibility with prior
kernel releases and/or existing boot firmware. On RISC-V, the
"MZ" string is a compressed load immediate to x20/s4, i.e. an
instruction that should be "harmless" as far as the kernel boot
flow is concerned as the x20/s4 register AFAIK doesn't contain any
information that the kernel would use.
Regards,
Karsten
--
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
^ permalink raw reply
* [PATCH 0/7] The eternal battle against docs-build warnings
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
Here's a collection of trivial changes meant to eliminate a number of
"no structured comments found" warnings - plus a kernel-doc tweak to
make those problems easier to track down.
Jonathan Corbet (7):
docs: Do not seek comments in kernel/rcu/tree_plugin.h
docs: Fix a misdirected kerneldoc directive
docs: Do not seek kerneldoc comments in hw-consumer.h
docs: No structured comments in target_core_device.c
docs: no structured comments in fs/file_table.c
docs: No structured comments in include/linux/interconnect.h
kernel-doc: always name missing kerneldoc sections
Documentation/core-api/kernel-api.rst | 2 --
Documentation/driver-api/basics.rst | 3 ---
.../driver-api/firmware/other_interfaces.rst | 2 +-
Documentation/driver-api/iio/hw-consumer.rst | 1 -
Documentation/driver-api/target.rst | 4 ++--
Documentation/filesystems/api-summary.rst | 3 ---
Documentation/interconnect/interconnect.rst | 5 ++---
scripts/kernel-doc | 16 +++++++++-------
8 files changed, 14 insertions(+), 22 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH 1/7] docs: Do not seek comments in kernel/rcu/tree_plugin.h
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
There are no kerneldoc comments in this file, so do not attempt to
include them in the docs build.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/core-api/kernel-api.rst | 2 --
Documentation/driver-api/basics.rst | 3 ---
2 files changed, 5 deletions(-)
diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst
index a29c99d13331..a53ec2eb8176 100644
--- a/Documentation/core-api/kernel-api.rst
+++ b/Documentation/core-api/kernel-api.rst
@@ -358,8 +358,6 @@ Read-Copy Update (RCU)
.. kernel-doc:: kernel/rcu/tree.c
-.. kernel-doc:: kernel/rcu/tree_plugin.h
-
.. kernel-doc:: kernel/rcu/tree_exp.h
.. kernel-doc:: kernel/rcu/update.c
diff --git a/Documentation/driver-api/basics.rst b/Documentation/driver-api/basics.rst
index e970fadf4d1a..1ba88c7b3984 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -115,9 +115,6 @@ Kernel utility functions
.. kernel-doc:: kernel/rcu/tree.c
:export:
-.. kernel-doc:: kernel/rcu/tree_plugin.h
- :export:
-
.. kernel-doc:: kernel/rcu/update.c
:export:
--
2.21.0
^ permalink raw reply related
* [PATCH 2/7] docs: Fix a misdirected kerneldoc directive
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
The stratix10 service layer documentation tried to include a kerneldoc
comments for a nonexistent struct; leading to a "no structured comments
found" message. Switch it to stratix10_svc_command_config_type, which
appears at that spot in the sequence and was not included.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/driver-api/firmware/other_interfaces.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/driver-api/firmware/other_interfaces.rst b/Documentation/driver-api/firmware/other_interfaces.rst
index a4ac54b5fd79..b81794e0cfbb 100644
--- a/Documentation/driver-api/firmware/other_interfaces.rst
+++ b/Documentation/driver-api/firmware/other_interfaces.rst
@@ -33,7 +33,7 @@ of the requests on to a secure monitor (EL3).
:functions: stratix10_svc_client_msg
.. kernel-doc:: include/linux/firmware/intel/stratix10-svc-client.h
- :functions: stratix10_svc_command_reconfig_payload
+ :functions: stratix10_svc_command_config_type
.. kernel-doc:: include/linux/firmware/intel/stratix10-svc-client.h
:functions: stratix10_svc_cb_data
--
2.21.0
^ permalink raw reply related
* [PATCH 3/7] docs: Do not seek kerneldoc comments in hw-consumer.h
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
There are no kerneldoc comments here, so looking for them just yields a
warning in the docs build.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/driver-api/iio/hw-consumer.rst | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/driver-api/iio/hw-consumer.rst b/Documentation/driver-api/iio/hw-consumer.rst
index e0fe0b98230e..819fb9edc005 100644
--- a/Documentation/driver-api/iio/hw-consumer.rst
+++ b/Documentation/driver-api/iio/hw-consumer.rst
@@ -45,7 +45,6 @@ A typical IIO HW consumer setup looks like this::
More details
============
-.. kernel-doc:: include/linux/iio/hw-consumer.h
.. kernel-doc:: drivers/iio/buffer/industrialio-hw-consumer.c
:export:
--
2.21.0
^ permalink raw reply related
* [PATCH 4/7] docs: No structured comments in target_core_device.c
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
Documentation/driver-api/target.rst is seeking kerneldoc comments in
drivers/target/target_core_device.c, but no such comments exist. Take out
the kernel-doc directive and eliminate one warning from the build.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/driver-api/target.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/driver-api/target.rst b/Documentation/driver-api/target.rst
index 4363611dd86d..620ec6173a93 100644
--- a/Documentation/driver-api/target.rst
+++ b/Documentation/driver-api/target.rst
@@ -10,8 +10,8 @@ TBD
Target core device interfaces
=============================
-.. kernel-doc:: drivers/target/target_core_device.c
- :export:
+This section is blank because no kerneldoc comments have been added to
+drivers/target/target_core_device.c.
Target core transport interfaces
================================
--
2.21.0
^ permalink raw reply related
* [PATCH 5/7] docs: no structured comments in fs/file_table.c
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
Remove the kernel-doc directive, since there are only warnings to be found
there.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/filesystems/api-summary.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/filesystems/api-summary.rst b/Documentation/filesystems/api-summary.rst
index aa51ffcfa029..bbb0c1c0e5cf 100644
--- a/Documentation/filesystems/api-summary.rst
+++ b/Documentation/filesystems/api-summary.rst
@@ -89,9 +89,6 @@ Other Functions
.. kernel-doc:: fs/direct-io.c
:export:
-.. kernel-doc:: fs/file_table.c
- :export:
-
.. kernel-doc:: fs/libfs.c
:export:
--
2.21.0
^ permalink raw reply related
* [PATCH 7/7] kernel-doc: always name missing kerneldoc sections
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
The "no structured comments found" warning is not particularly useful if
there are several invocations, one of which is looking for something
wrong. So if something specific has been requested, make it clear that
it's the one we weren't able to find.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
scripts/kernel-doc | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 3350e498b4ce..c0cb41e65b9b 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -285,7 +285,7 @@ use constant {
OUTPUT_INTERNAL => 4, # output non-exported symbols
};
my $output_selection = OUTPUT_ALL;
-my $show_not_found = 0;
+my $show_not_found = 0; # No longer used
my @export_file_list;
@@ -435,7 +435,7 @@ while ($ARGV[0] =~ m/^--?(.*)/) {
} elsif ($cmd eq 'enable-lineno') {
$enable_lineno = 1;
} elsif ($cmd eq 'show-not-found') {
- $show_not_found = 1;
+ $show_not_found = 1; # A no-op but don't fail
} else {
# Unknown argument
usage();
@@ -2163,12 +2163,14 @@ sub process_file($) {
}
# Make sure we got something interesting.
- if ($initial_section_counter == $section_counter) {
- if ($output_mode ne "none") {
- print STDERR "${file}:1: warning: no structured comments found\n";
+ if ($initial_section_counter == $section_counter && $
+ output_mode ne "none") {
+ if ($output_selection == OUTPUT_INCLUDE) {
+ print STDERR "${file}:1: warning: '$_' not found\n"
+ for keys %function_table;
}
- if (($output_selection == OUTPUT_INCLUDE) && ($show_not_found == 1)) {
- print STDERR " Was looking for '$_'.\n" for keys %function_table;
+ else {
+ print STDERR "${file}:1: warning: no structured comments found\n";
}
}
}
--
2.21.0
^ permalink raw reply related
* [PATCH 6/7] docs: No structured comments in include/linux/interconnect.h
From: Jonathan Corbet @ 2019-05-27 22:26 UTC (permalink / raw)
To: linux-doc; +Cc: Jonathan Corbet
In-Reply-To: <20190527222658.27304-1-corbet@lwn.net>
Remove the kernel-doc directive for this file, since there's nothing there
and it generates a warning.
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
Documentation/interconnect/interconnect.rst | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/interconnect/interconnect.rst b/Documentation/interconnect/interconnect.rst
index b8107dcc4cd3..c3e004893796 100644
--- a/Documentation/interconnect/interconnect.rst
+++ b/Documentation/interconnect/interconnect.rst
@@ -89,6 +89,5 @@ Interconnect consumers
Interconnect consumers are the clients which use the interconnect APIs to
get paths between endpoints and set their bandwidth/latency/QoS requirements
-for these interconnect paths.
-
-.. kernel-doc:: include/linux/interconnect.h
+for these interconnect paths. These interfaces are not currently
+documented.
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 2/3] mm: remove cleancache.c
From: Joseph Qi @ 2019-05-28 0:50 UTC (permalink / raw)
To: Juergen Gross, linux-kernel, linux-doc, linux-erofs, devel,
linux-fsdevel, linux-btrfs, linux-ext4, linux-f2fs-devel,
linux-mm
Cc: Jonathan Corbet, Gao Xiang, Chao Yu, Greg Kroah-Hartman,
Alexander Viro, Chris Mason, Josef Bacik, David Sterba,
Theodore Ts'o, Andreas Dilger, Jaegeuk Kim, Mark Fasheh,
Joel Becker, ocfs2-devel
In-Reply-To: <20190527103207.13287-3-jgross@suse.com>
On 19/5/27 18:32, Juergen Gross wrote:
> With the removal of tmem and xen-selfballoon the only user of
> cleancache is gone. Remove it, too.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> Documentation/vm/cleancache.rst | 296 ------------------------------------
> Documentation/vm/frontswap.rst | 10 +-
> Documentation/vm/index.rst | 1 -
> MAINTAINERS | 7 -
> drivers/staging/erofs/data.c | 6 -
> drivers/staging/erofs/internal.h | 1 -
> fs/block_dev.c | 5 -
> fs/btrfs/extent_io.c | 9 --
> fs/btrfs/super.c | 2 -
> fs/ext4/readpage.c | 6 -
> fs/ext4/super.c | 2 -
> fs/f2fs/data.c | 3 +-
> fs/mpage.c | 7 -
> fs/ocfs2/super.c | 2 -
For ocfs2 part,
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> fs/super.c | 3 -
> include/linux/cleancache.h | 124 ---------------
> include/linux/fs.h | 5 -
> mm/Kconfig | 22 ---
> mm/Makefile | 1 -
> mm/cleancache.c | 317 ---------------------------------------
> mm/filemap.c | 11 --
> mm/truncate.c | 15 +-
^ permalink raw reply
* Re: [PATCH 2/3] mm: remove cleancache.c
From: Chao Yu @ 2019-05-28 1:24 UTC (permalink / raw)
To: Juergen Gross, linux-kernel, linux-doc, linux-erofs, devel,
linux-fsdevel, linux-btrfs, linux-ext4, linux-f2fs-devel,
linux-mm
Cc: Jonathan Corbet, Gao Xiang, Greg Kroah-Hartman, Alexander Viro,
Chris Mason, Josef Bacik, David Sterba, Theodore Ts'o,
Andreas Dilger, Jaegeuk Kim, Mark Fasheh, Joel Becker, Joseph Qi,
ocfs2-devel
In-Reply-To: <20190527103207.13287-3-jgross@suse.com>
On 2019/5/27 18:32, Juergen Gross wrote:
> With the removal of tmem and xen-selfballoon the only user of
> cleancache is gone. Remove it, too.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> Documentation/vm/cleancache.rst | 296 ------------------------------------
> Documentation/vm/frontswap.rst | 10 +-
> Documentation/vm/index.rst | 1 -
> MAINTAINERS | 7 -
> drivers/staging/erofs/data.c | 6 -
> drivers/staging/erofs/internal.h | 1 -
> fs/block_dev.c | 5 -
> fs/btrfs/extent_io.c | 9 --
> fs/btrfs/super.c | 2 -
> fs/ext4/readpage.c | 6 -
> fs/ext4/super.c | 2 -
> fs/f2fs/data.c | 3 +-
For erofs and f2fs part,
Acked-by: Chao Yu <yuchao0@huawei.com>
Thanks,
> fs/mpage.c | 7 -
> fs/ocfs2/super.c | 2 -
> fs/super.c | 3 -
> include/linux/cleancache.h | 124 ---------------
> include/linux/fs.h | 5 -
> mm/Kconfig | 22 ---
> mm/Makefile | 1 -
> mm/cleancache.c | 317 ---------------------------------------
> mm/filemap.c | 11 --
> mm/truncate.c | 15 +-
^ permalink raw reply
* Re: [PATCH v2 1/3] KVM: x86: add support for user wait instructions
From: Tao Xu @ 2019-05-28 5:11 UTC (permalink / raw)
To: Peter Zijlstra
Cc: pbonzini, rkrcmar, corbet, tglx, mingo, bp, hpa,
sean.j.christopherson, x86, kvm, linux-doc, linux-kernel,
jingqi.liu
In-Reply-To: <20190527103003.GX2623@hirez.programming.kicks-ass.net>
On 27/05/2019 18:30, Peter Zijlstra wrote:
> On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote:
>> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions
>> in kvm, and by default dont't expose it to kvm and provide a capability
>> to enable it.
>
> I'm thinking this should be conditional on the guest being a 1:1 guest,
> and I also seem to remember we have bits for that already -- they were
> used to disable paravirt spinlocks for example.
>
Hi Peter,
I am wondering if "1:1 guest" means different guests in the same host
should have different settings on user wait instructions?
User wait instructions(UMONITOR, UMWAIT and TPAUSE) can use in guest
only when the VMCS Secondary Processor-Based VM-Execution Control bit 26
is 1, otherwise any execution of TPAUSE, UMONITOR, or UMWAIT causes a #UD.
So with a capability to enable it, we use qemu kvm_vm_ioctl_enable_cap()
to enable it. The qemu link is blew:
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05810.html
By using different QEMU parameters, different guests in the same host
would have different features with or without user wait instructions.
About "disable paravirt spinlocks" case, I am wondering if it uses
kernel parameters? If it uses kernel parameters, different guests in the
same host may have same settings on user wait instructions.
Or when we uses kernel parameters to disable user wait instructions, for
a host chooses to enable user wait instructions, we should do some work
on QEMU to choose disable or enable user wait instructions?
Thanks
Tao
^ permalink raw reply
* Re: [PATCH v2 1/3] KVM: x86: add support for user wait instructions
From: Wanpeng Li @ 2019-05-28 6:11 UTC (permalink / raw)
To: Tao Xu
Cc: Peter Zijlstra, Paolo Bonzini, Radim Krcmar, Jonathan Corbet,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin,
Sean Christopherson, the arch/x86 maintainers, kvm, linux-doc,
LKML, jingqi.liu
In-Reply-To: <43e2a62a-e992-2138-f038-1e4b2fb79ad1@intel.com>
On Tue, 28 May 2019 at 13:16, Tao Xu <tao3.xu@intel.com> wrote:
>
>
> On 27/05/2019 18:30, Peter Zijlstra wrote:
> > On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote:
> >> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions
> >> in kvm, and by default dont't expose it to kvm and provide a capability
> >> to enable it.
> >
> > I'm thinking this should be conditional on the guest being a 1:1 guest,
> > and I also seem to remember we have bits for that already -- they were
> > used to disable paravirt spinlocks for example.
> >
>
> Hi Peter,
>
> I am wondering if "1:1 guest" means different guests in the same host
> should have different settings on user wait instructions?
>
> User wait instructions(UMONITOR, UMWAIT and TPAUSE) can use in guest
> only when the VMCS Secondary Processor-Based VM-Execution Control bit 26
> is 1, otherwise any execution of TPAUSE, UMONITOR, or UMWAIT causes a #UD.
>
> So with a capability to enable it, we use qemu kvm_vm_ioctl_enable_cap()
> to enable it. The qemu link is blew:
> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05810.html
>
> By using different QEMU parameters, different guests in the same host
> would have different features with or without user wait instructions.
>
> About "disable paravirt spinlocks" case, I am wondering if it uses
Please refer to a4429e53c9 (KVM: Introduce paravirtualization hints
and KVM_HINTS_DEDICATED) and b2798ba0b87 (KVM: X86: Choose qspinlock
when dedicated physical CPUs are available).
> kernel parameters? If it uses kernel parameters, different guests in the
> same host may have same settings on user wait instructions.
>
> Or when we uses kernel parameters to disable user wait instructions, for
> a host chooses to enable user wait instructions, we should do some work
> on QEMU to choose disable or enable user wait instructions?
>
> Thanks
>
> Tao
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox