* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Double check bumping after the spinlock
From: Patchwork @ 2020-02-20 16:51 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20200220123608.1666271-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [1/2] drm/i915: Double check bumping after the spinlock
URL : https://patchwork.freedesktop.org/series/73707/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
00c160893898 drm/i915: Double check bumping after the spinlock
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#10:
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")'
#10:
References: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
total: 1 errors, 1 warnings, 0 checks, 9 lines checked
e5bc0f843da3 drm/i915: Protect i915_request_await_start from early waits
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v9 2/3] Acceptance test: add "boot_linux" tests
From: Wainer dos Santos Moschetta @ 2020-02-20 16:49 UTC (permalink / raw)
To: Cleber Rosa, qemu-devel
Cc: Fam Zheng, Eduardo Habkost, Alex Bennée, Willian Rampazzo,
Philippe Mathieu-Daudé, Beraldo Leal
In-Reply-To: <20200220020652.16276-3-crosa@redhat.com>
On 2/19/20 11:06 PM, Cleber Rosa wrote:
> This acceptance test, validates that a full blown Linux guest can
> successfully boot in QEMU. In this specific case, the guest chosen is
> Fedora version 31.
>
> * x86_64, pc-i440fx and pc-q35 machine types, with TCG and KVM as
> accelerators
>
> * aarch64 and virt machine type, with TCG and KVM as accelerators
>
> * ppc64 and pseries machine type with TCG as accelerator
>
> * s390x and s390-ccw-virtio machine type with TCG as accelerator
>
> The Avocado vmimage utils library is used to download and cache the
> Linux guest images, and from those images a snapshot image is created
> and given to QEMU. If a qemu-img binary is available in the build
> directory, it's used to create the snapshot image, so that matching
> qemu-system-* and qemu-img are used in the same test run. If qemu-img
> is not available in the build tree, one is attempted to be found
> installed system-wide (in the $PATH). If qemu-img is not found in the
> build dir or in the $PATH, the test is canceled.
>
> The method for checking the successful boot is based on "cloudinit"
> and its "phone home" feature. The guest is given an ISO image with
> the location of the phone home server, and the information to post
> (the instance ID). Upon receiving the correct information, from the
> guest, the test is considered to have PASSed.
>
> This test is currently limited to user mode networking only, and
> instructs the guest to connect to the "router" address that is hard
> coded in QEMU.
>
> To create the cloudinit ISO image that will be used to configure the
> guest, the pycdlib library is also required and has been added as
> requirement to the virtual environment created by "check-venv".
>
> The console output is read by a separate thread, by means of the
> Avocado datadrainer utility module.
>
> Signed-off-by: Cleber Rosa <crosa@redhat.com>
> ---
> .travis.yml | 2 +-
> tests/acceptance/boot_linux.py | 215 +++++++++++++++++++++++++++++++++
> tests/requirements.txt | 3 +-
> 3 files changed, 218 insertions(+), 2 deletions(-)
> create mode 100644 tests/acceptance/boot_linux.py
>
> diff --git a/.travis.yml b/.travis.yml
> index 5887055951..0c54cdf40f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -313,7 +313,7 @@ matrix:
> # Acceptance (Functional) tests
> - name: "GCC check-acceptance"
> env:
> - - CONFIG="--target-list=aarch64-softmmu,alpha-softmmu,arm-softmmu,m68k-softmmu,microblaze-softmmu,mips-softmmu,mips64el-softmmu,nios2-softmmu,or1k-softmmu,ppc-softmmu,ppc64-softmmu,s390x-softmmu,sparc-softmmu,x86_64-softmmu,xtensa-softmmu"
> + - CONFIG="--enable-tools --target-list=aarch64-softmmu,alpha-softmmu,arm-softmmu,m68k-softmmu,microblaze-softmmu,mips-softmmu,mips64el-softmmu,nios2-softmmu,or1k-softmmu,ppc-softmmu,ppc64-softmmu,s390x-softmmu,sparc-softmmu,x86_64-softmmu,xtensa-softmmu"
> - TEST_CMD="make check-acceptance"
> after_script:
> - python3 -c 'import json; r = json.load(open("tests/results/latest/results.json")); [print(t["logfile"]) for t in r["tests"] if t["status"] not in ("PASS", "SKIP")]' | xargs cat
> diff --git a/tests/acceptance/boot_linux.py b/tests/acceptance/boot_linux.py
> new file mode 100644
> index 0000000000..6787e79aea
> --- /dev/null
> +++ b/tests/acceptance/boot_linux.py
> @@ -0,0 +1,215 @@
> +# Functional test that boots a complete Linux system via a cloud image
> +#
> +# Copyright (c) 2018-2020 Red Hat, Inc.
> +#
> +# Author:
> +# Cleber Rosa <crosa@redhat.com>
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# later. See the COPYING file in the top-level directory.
> +
> +import os
> +
> +from avocado_qemu import Test, BUILD_DIR
> +
> +from qemu.accel import kvm_available
> +from qemu.accel import tcg_available
> +
> +from avocado.utils import cloudinit
> +from avocado.utils import network
> +from avocado.utils import vmimage
> +from avocado.utils import datadrainer
> +
> +ACCEL_NOT_AVAILABLE_FMT = "%s accelerator does not seem to be available"
> +KVM_NOT_AVAILABLE = ACCEL_NOT_AVAILABLE_FMT % "KVM"
> +TCG_NOT_AVAILABLE = ACCEL_NOT_AVAILABLE_FMT % "TCG"
> +
> +
> +class BootLinux(Test):
> + """
> + Boots a Linux system, checking for a successful initialization
> + """
> +
> + timeout = 900
> + chksum = None
> +
> + def setUp(self):
> + super(BootLinux, self).setUp()
> + self.prepare_boot()
> + self.vm.add_args('-smp', '2')
> + self.vm.add_args('-m', '1024')
> + self.vm.add_args('-drive', 'file=%s' % self.boot.path)
> + self.prepare_cloudinit()
> +
> + def prepare_boot(self):
> + self.log.info('Downloading/preparing boot image')
> + # Fedora 31 only provides ppc64le images
> + image_arch = self.arch
> + if image_arch == 'ppc64':
> + image_arch = 'ppc64le'
> + # If qemu-img has been built, use it, otherwise the system wide one
> + # will be used. If none is available, the test will cancel.
> + qemu_img = os.path.join(BUILD_DIR, 'qemu-img')
> + if os.path.exists(qemu_img):
> + vmimage.QEMU_IMG = qemu_img
> + try:
> + self.boot = vmimage.get(
> + 'fedora', arch=image_arch, version='31',
> + checksum=self.chksum,
> + algorithm='sha256',
> + cache_dir=self.cache_dirs[0],
> + snapshot_dir=self.workdir)
> + except:
> + self.cancel('Failed to download/prepare boot image')
> +
> + def prepare_cloudinit(self):
> + self.log.info('Preparing cloudinit image')
> + try:
> + cloudinit_iso = os.path.join(self.workdir, 'cloudinit.iso')
> + self.phone_home_port = network.find_free_port()
> + cloudinit.iso(cloudinit_iso, self.name,
> + username='root',
> + password='password',
> + # QEMU's hard coded usermode router address
> + phone_home_host='10.0.2.2',
> + phone_home_port=self.phone_home_port)
> + self.vm.add_args('-drive', 'file=%s,format=raw' % cloudinit_iso)
> + except Exception:
> + self.cancel('Failed to prepared cloudinit image')
> +
> + def launch_and_wait(self):
> + self.vm.set_console()
> + self.vm.launch()
> + console_drainer = datadrainer.LineLogger(self.vm.console_socket.fileno(),
> + logger=self.log.getChild('console'))
> + console_drainer.start()
> + self.log.info('VM launched, waiting for boot confirmation from guest')
> + cloudinit.wait_for_phone_home(('0.0.0.0', self.phone_home_port), self.name)
> +
> +
> +class BootLinuxX8664(BootLinux):
> + """
> + :avocado: tags=arch:x86_64
> + """
> +
> + chksum = 'e3c1b309d9203604922d6e255c2c5d098a309c2d46215d8fc026954f3c5c27a0'
> +
> + def test_pc_i440fx_tcg(self):
> + """
> + :avocado: tags=machine:pc
> + :avocado: tags=machine:pc-i440fx
> + :avocado: tags=accel:tcg
> + """
> + if not tcg_available(self.qemu_bin):
> + self.cancel(TCG_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "tcg")
> + self.launch_and_wait()
> +
> + def test_pc_i440fx_kvm(self):
> + """
> + :avocado: tags=machine:pc
> + :avocado: tags=machine:pc-i440fx
> + :avocado: tags=accel:kvm
> + """
> + if not kvm_available(self.arch, self.qemu_bin):
> + self.cancel(KVM_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "kvm")
> + self.launch_and_wait()
> +
> + def test_pc_q35_tcg(self):
> + """
> + :avocado: tags=machine:pc
> + :avocado: tags=machine:pc-q35
> + :avocado: tags=accel:tcg
> + """
> + if not tcg_available(self.qemu_bin):
> + self.cancel(TCG_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "tcg")
> + self.launch_and_wait()
> +
> + def test_pc_q35_kvm(self):
> + """
> + :avocado: tags=machine:q35
> + :avocado: tags=machine:pc-q35
> + :avocado: tags=accel:kvm
> + """
> + if not kvm_available(self.arch, self.qemu_bin):
> + self.cancel(KVM_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "kvm")
> + self.launch_and_wait()
> +
> +
> +class BootLinuxAarch64(BootLinux):
> + """
> + :avocado: tags=arch:aarch64
> + :avocado: tags=machine:virt
> + """
> +
> + chksum = '1e18d9c0cf734940c4b5d5ec592facaed2af0ad0329383d5639c997fdf16fe49'
> +
> + def add_common_args(self):
> + self.vm.add_args('-bios',
> + os.path.join(BUILD_DIR, 'pc-bios',
> + 'edk2-aarch64-code.fd'))
> + self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
> + self.vm.add_args('-object', 'rng-random,id=rng0,filename=/dev/urandom')
> +
> + def test_virt_tcg(self):
> + """
> + :avocado: tags=accel:tcg
> + :avocado: tags=cpu:cortex-a53
> + """
> + if not tcg_available(self.qemu_bin):
> + self.cancel(TCG_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "tcg")
> + self.vm.add_args('-cpu', 'cortex-a53')
> + self.add_common_args()
> + self.launch_and_wait()
> +
> + def test_virt_kvm(self):
> + """
> + :avocado: tags=accel:kvm
> + :avocado: tags=cpu:host
> + """
> + if not kvm_available(self.arch, self.qemu_bin):
> + self.cancel(KVM_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "kvm")
> + self.vm.add_args("-cpu", "host")
> + self.add_common_args()
> + self.launch_and_wait()
For aarch64 tests it seems '-cpu max' is the best choice. See in
https://www.mail-archive.com/qemu-devel@nongnu.org/msg672755.html
> +
> +
> +class BootLinuxPPC64(BootLinux):
> + """
> + :avocado: tags=arch:ppc64
> + """
> +
> + chksum = '7c3528b85a3df4b2306e892199a9e1e43f991c506f2cc390dc4efa2026ad2f58'
> +
> + def test_pseries_tcg(self):
> + """
> + :avocado: tags=machine:pseries
> + :avocado: tags=accel:tcg
> + """
> + if not tcg_available(self.qemu_bin):
> + self.cancel(TCG_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "tcg")
> + self.launch_and_wait()
> +
> +
> +class BootLinuxS390X(BootLinux):
> + """
> + :avocado: tags=arch:s390x
> + """
> +
> + chksum = '4caaab5a434fd4d1079149a072fdc7891e354f834d355069ca982fdcaf5a122d'
> +
> + def test_s390_ccw_virtio_tcg(self):
> + """
> + :avocado: tags=machine:s390-ccw-virtio
> + :avocado: tags=accel:tcg
> + """
> + if not tcg_available(self.qemu_bin):
> + self.cancel(TCG_NOT_AVAILABLE)
> + self.vm.add_args("-accel", "tcg")
> + self.launch_and_wait()
> diff --git a/tests/requirements.txt b/tests/requirements.txt
> index a2a587223a..a3b5fe4159 100644
> --- a/tests/requirements.txt
> +++ b/tests/requirements.txt
> @@ -1,4 +1,5 @@
> # Add Python module requirements, one per line, to be installed
> # in the tests/venv Python virtual environment. For more info,
> # refer to: https://pip.pypa.io/en/stable/user_guide/#id1
> -avocado-framework==72.0
> +avocado-framework==74.0
> +pycdlib==1.9.0
Tested on x86_64 machine, the tests behave correctly with following
configurations:
1. ---target-list=x86_64-softmmu --disable-tcg
2. ---target-list=x86_64-softmmu --disable-kvm
3. --target-list=x86_64-softmmu,aarch64-softmmu,ppc64-softmmu,s390x-softmmu
But failed if:
3. ---target-list=x86_64-softmmu --disable-tools.
And the error message is:
(01/32)
tests/acceptance/boot_linux.py:BootLinuxX8664.test_pc_i440fx_tcg: ERROR:
Command 'qemu-img' could not be found in any of the PATH dirs:
['/usr/bin', '/usr/sbin', '/usr/lib64/ccache', '/bin', '/root/bin',
'/sbin', '/usr/local/sbin', '/usr/local/bin', '/usr/libexec'] (1.58 s)
Thanks!
- Wainer
^ permalink raw reply
* [PATCH] ltp: Use upstreamed patch for time64 syscall fixes
From: Khem Raj @ 2020-02-20 16:50 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
...or-time64-unsafe-syscalls-before-usi.patch | 109 +++++++++++-------
1 file changed, 66 insertions(+), 43 deletions(-)
diff --git a/meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch b/meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
index 92e5fdfe6e..c431669716 100644
--- a/meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
+++ b/meta/recipes-extended/ltp/ltp/0001-syscalls-Check-for-time64-unsafe-syscalls-before-usi.patch
@@ -1,4 +1,4 @@
-From 09e631419d9763a4ff08b32d9801c12b475d8ec5 Mon Sep 17 00:00:00 2001
+From b66905b094e08a84c30bc135003c3611f65d53ec Mon Sep 17 00:00:00 2001
From: Khem Raj <raj.khem@gmail.com>
Date: Wed, 12 Feb 2020 22:22:17 -0800
Subject: [PATCH] syscalls: Check for time64 unsafe syscalls before using them
@@ -7,75 +7,98 @@ musl is using 64bit time_t now on 32bit architectures and these syscalls
no longer exist, therefore its better to check for them being available
before using them
-Upstream-Status: Submitted [http://lists.linux.it/pipermail/ltp/2020-February/015400.html]
+Upstream-Status: Submitted [https://patchwork.ozlabs.org/patch/1241258/]
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
- lib/tst_clocks.c | 9 +++++++++
- testcases/kernel/syscalls/gettimeofday/gettimeofday01.c | 4 ++++
- testcases/kernel/syscalls/gettimeofday/gettimeofday02.c | 4 ++++
- 3 files changed, 17 insertions(+)
+ lib/tst_clocks.c | 9 +++++----
+ testcases/kernel/syscalls/gettimeofday/gettimeofday01.c | 6 ++----
+ testcases/kernel/syscalls/gettimeofday/gettimeofday02.c | 8 +++-----
+ 3 files changed, 10 insertions(+), 13 deletions(-)
-diff --git a/lib/tst_clocks.c b/lib/tst_clocks.c
-index 35798a4aaf..6a5b05c4ea 100644
--- a/lib/tst_clocks.c
+++ b/lib/tst_clocks.c
-@@ -28,15 +28,24 @@
+@@ -22,21 +22,22 @@
+ #define _GNU_SOURCE
+ #include <unistd.h>
+ #include <time.h>
+-#include <sys/syscall.h>
+-
++#define TST_NO_DEFAULT_MAIN
++#include "tst_test.h"
+ #include "tst_clocks.h"
++#include "lapi/syscalls.h"
int tst_clock_getres(clockid_t clk_id, struct timespec *res)
{
-+#if defined(__NR_clock_getres)
- return syscall(SYS_clock_getres, clk_id, res);
-+#endif
-+ return -1;
+- return syscall(SYS_clock_getres, clk_id, res);
++ return tst_syscall(__NR_clock_getres, clk_id, res);
}
int tst_clock_gettime(clockid_t clk_id, struct timespec *ts)
{
-+#if defined(__NR_clock_gettime)
- return syscall(SYS_clock_gettime, clk_id, ts);
-+#endif
-+ return -1;
+- return syscall(SYS_clock_gettime, clk_id, ts);
++ return tst_syscall(__NR_clock_gettime, clk_id, ts);
}
int tst_clock_settime(clockid_t clk_id, struct timespec *ts)
{
-+#if defined(__NR_clock_settime)
- return syscall(SYS_clock_settime, clk_id, ts);
-+#endif
-+ return -1;
+- return syscall(SYS_clock_settime, clk_id, ts);
++ return tst_syscall(__NR_clock_settime, clk_id, ts);
}
-diff --git a/testcases/kernel/syscalls/gettimeofday/gettimeofday01.c b/testcases/kernel/syscalls/gettimeofday/gettimeofday01.c
-index 583d8f7b9b..b498de5b68 100644
--- a/testcases/kernel/syscalls/gettimeofday/gettimeofday01.c
+++ b/testcases/kernel/syscalls/gettimeofday/gettimeofday01.c
-@@ -41,7 +41,11 @@
- #include <sys/syscall.h>
+@@ -38,10 +38,8 @@
+ #include <sys/time.h>
+ #include <errno.h>
+ #include "test.h"
+-#include <sys/syscall.h>
#include <unistd.h>
-
-+#ifdef __NR_gettimeofday
- #define gettimeofday(a,b) syscall(__NR_gettimeofday,a,b)
-+#else
-+#define gettimeofday(a,b) (-1)
-+#endif
+-
+-#define gettimeofday(a,b) syscall(__NR_gettimeofday,a,b)
++#include "lapi/syscalls.h"
char *TCID = "gettimeofday01";
int TST_TOTAL = 1;
-diff --git a/testcases/kernel/syscalls/gettimeofday/gettimeofday02.c b/testcases/kernel/syscalls/gettimeofday/gettimeofday02.c
-index 1d60f448e8..218e017df8 100644
+@@ -63,7 +61,7 @@ int main(int ac, char **av)
+ for (lc = 0; TEST_LOOPING(lc); lc++) {
+ tst_count = 0;
+
+- TEST(gettimeofday((void *)-1, (void *)-1));
++ TEST(ltp_syscall(__NR_gettimeofday, (void *)-1, (void *)-1));
+
+ /* gettimeofday returns an int, so we need to turn the long
+ * TEST_RETURN into an int to test with */
--- a/testcases/kernel/syscalls/gettimeofday/gettimeofday02.c
+++ b/testcases/kernel/syscalls/gettimeofday/gettimeofday02.c
-@@ -23,7 +23,11 @@
+@@ -16,14 +16,12 @@
+ #include <stdint.h>
+ #include <sys/time.h>
+ #include <stdlib.h>
+-#include <sys/syscall.h>
+ #include <unistd.h>
+ #include <time.h>
+ #include <errno.h>
#include "tst_test.h"
-
-+#ifdef __NR_gettimeofday
- #define gettimeofday(a,b) syscall(__NR_gettimeofday,a,b)
-+#else
-+#define gettimeofday(a,b) (-1)
-+#endif
+-
+-#define gettimeofday(a,b) syscall(__NR_gettimeofday,a,b)
++#include "lapi/syscalls.h"
static volatile sig_atomic_t done;
static char *str_rtime;
---
-2.25.0
-
+@@ -48,13 +46,13 @@ static void verify_gettimeofday(void)
+
+ alarm(rtime);
+
+- if (gettimeofday(&tv1, NULL)) {
++ if (tst_syscall(__NR_gettimeofday, &tv1, NULL)) {
+ tst_res(TBROK | TERRNO, "gettimeofday() failed");
+ return;
+ }
+
+ while (!done) {
+- if (gettimeofday(&tv2, NULL)) {
++ if (tst_syscall(__NR_gettimeofday, &tv2, NULL)) {
+ tst_res(TBROK | TERRNO, "gettimeofday() failed");
+ return;
+ }
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 1/2] RDMA/rw: fix error flow during RDMA context initialization
From: Logan Gunthorpe @ 2020-02-20 16:50 UTC (permalink / raw)
To: Max Gurtovoy, jgg, leon, linux-rdma; +Cc: israelr
In-Reply-To: <20200220100819.41860-1-maxg@mellanox.com>
On 2020-02-20 3:08 a.m., Max Gurtovoy wrote:
> In case the SGL was mapped for P2P DMA operation, we must unmap it using
> pci_p2pdma_unmap_sg.
>
> Fixes: 7f73eac3a713 ("PCI/P2PDMA: Introduce pci_p2pdma_unmap_sg()")
> Signed-off-by: Max Gurtovoy <maxg@mellanox.com>
Makes sense to me.
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Thanks!
Logan
^ permalink raw reply
* Re: [PATCH v2 1/2] s390x: fix memleaks in cpu_finalize
From: Peter Maydell @ 2020-02-20 16:49 UTC (permalink / raw)
To: Cornelia Huck
Cc: zhanghailiang, Alistair Francis, Pan Nengyuan, QEMU Developers,
mav2-rk.cave-ayland, qemu-arm, qemu-ppc, Euler Robot,
Edgar E. Iglesias, Richard Henderson, David Gibson
In-Reply-To: <20200220165950.3a5ec74a.cohuck@redhat.com>
On Thu, 20 Feb 2020 at 16:01, Cornelia Huck <cohuck@redhat.com> wrote:
> I may be missing something, but what cleans up the timers if we fail
> further down in this function? I don't think the unrealize callback is
> invoked by the core in case of error?
FWIW I sent a mail to one of these threads a few days ago
where I claimed we did call unrealize if realize fails,
but looking again at the device_set_realized() code I think
I was misreading it. If the device's own 'realize' method
fails, we go to the 'fail' label, which just reports back the
error and doesn't call unrealize. It's only if the device's
'realize' method succeeds and we get a failure in some later
thing like calling 'realize' on the child bus objects that we
will call the device unrealize as part of cleanup.
Apologies for any confusion caused.
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v3 00/12] Enable per-file/directory DAX operations V3
From: Ira Weiny @ 2020-02-20 16:49 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Jeff Moyer, Dan Williams, Linux Kernel Mailing List,
Alexander Viro, Dave Chinner, Christoph Hellwig,
Theodore Y. Ts'o, Jan Kara, linux-ext4, linux-xfs,
linux-fsdevel
In-Reply-To: <20200220163024.GV9506@magnolia>
On Thu, Feb 20, 2020 at 08:30:24AM -0800, Darrick J. Wong wrote:
> On Thu, Feb 20, 2020 at 08:20:28AM -0800, Ira Weiny wrote:
> > On Tue, Feb 18, 2020 at 03:54:30PM -0800, 'Ira Weiny' wrote:
> > > On Tue, Feb 18, 2020 at 09:22:58AM -0500, Jeff Moyer wrote:
> > > > Ira Weiny <ira.weiny@intel.com> writes:
> > > > > If my disassembly of read_pages is correct it looks like readpage is null which
> > > > > makes sense because all files should be IS_DAX() == true due to the mount option...
> > > > >
> > > > > But tracing code indicates that the patch:
> > > > >
> > > > > fs: remove unneeded IS_DAX() check
> > > > >
> > > > > ... may be the culprit and the following fix may work...
> > > > >
> > > > > diff --git a/mm/filemap.c b/mm/filemap.c
> > > > > index 3a7863ba51b9..7eaf74a2a39b 100644
> > > > > --- a/mm/filemap.c
> > > > > +++ b/mm/filemap.c
> > > > > @@ -2257,7 +2257,7 @@ generic_file_read_iter(struct kiocb *iocb, struct iov_iter *iter)
> > > > > if (!count)
> > > > > goto out; /* skip atime */
> > > > >
> > > > > - if (iocb->ki_flags & IOCB_DIRECT) {
> > > > > + if (iocb->ki_flags & IOCB_DIRECT || IS_DAX(inode)) {
> > > > > struct file *file = iocb->ki_filp;
> > > > > struct address_space *mapping = file->f_mapping;
> > > > > struct inode *inode = mapping->host;
> > > >
> > > > Well, you'll have to up-level the inode variable instantiation,
> > > > obviously. That solves this particular issue.
> > >
> > > Well... This seems to be a random issue. I've had BMC issues with
> > > my server most of the day... But even with this patch I still get the failure
> > > in read_pages(). :-/
> > >
> > > And I have gotten it to both succeed and fail with qemu... :-/
> >
> > ... here is the fix. I made the change in xfs_diflags_to_linux() early on with
> > out factoring in the flag logic changes we have agreed upon...
> >
> > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > index 62d9f622bad1..d592949ad396 100644
> > --- a/fs/xfs/xfs_ioctl.c
> > +++ b/fs/xfs/xfs_ioctl.c
> > @@ -1123,11 +1123,11 @@ xfs_diflags_to_linux(
> > inode->i_flags |= S_NOATIME;
> > else
> > inode->i_flags &= ~S_NOATIME;
> > - if (xflags & FS_XFLAG_DAX)
> > +
> > + if (xfs_inode_enable_dax(ip))
> > inode->i_flags |= S_DAX;
> > else
> > inode->i_flags &= ~S_DAX;
> > -
> > }
> >
> > But the one thing which tripped me up, and concerns me, is we have 2 functions
> > which set the inode flags.
> >
> > xfs_diflags_to_iflags()
> > xfs_diflags_to_linux()
> >
> > xfs_diflags_to_iflags() is geared toward initialization but logically they do
> > the same thing. I see no reason to keep them separate. Does anyone?
> >
> > Based on this find, the discussion on behavior in this thread, and the comments
> > from Dave I'm reworking the series because the flag check/set functions have
> > all changed and I really want to be as clear as possible with both the patches
> > and the resulting code.[*] So v4 should be out today including attempting to
> > document what we have discussed here and being as clear as possible on the
> > behavior. :-D
> >
> > Thanks so much for testing this!
> >
> > Ira
> >
> > [*] I will probably throw in a patch to remove xfs_diflags_to_iflags() as I
> > really don't see a reason to keep it.
> >
>
> I prefer you keep the one in xfs_iops.c since ioctls are a higher level
> function than general inode operations.
Makes sense. Do you prefer the xfs_diflags_to_iflags() name as well?
Ira
>
> --D
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.5 219/542] ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
From: Sasha Levin @ 2020-02-20 16:49 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, linux-omap, linux-kernel, stable, linux-arm-kernel
In-Reply-To: <a7666322-f931-63f1-a4c5-d44c2ba4ed0c@ti.com>
On Fri, Feb 14, 2020 at 12:34:58PM -0600, Suman Anna wrote:
>Hi Sasha,
>
>On 2/14/20 9:43 AM, Sasha Levin wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> [ Upstream commit 4601832f40501efc3c2fd264a5a69bd1ac17d520 ]
>>
>> The IPU1 MMU has been using common IOMMU pdata quirks defined and
>> used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
>> pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
>> plugged in, so that the IPU1 power domain can be restricted to ON
>> state during the boot and active period of the IPU1 remote processor.
>> This eliminates the pre-conditions for the IPU1 boot issue as
>> described in commit afe518400bdb ("iommu/omap: fix boot issue on
>> remoteprocs with AMMU/Unicache").
>>
>> NOTE:
>> 1. RET is not a valid target power domain state on DRA7 platforms,
>> and IPU power domain is normally programmed for OFF. The IPU1
>> still fails to boot though, and an unclearable l3_noc error is
>> thrown currently on 4.14 kernel without this fix. This behavior
>> is slightly different from previous 4.9 LTS kernel.
>> 2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
>> other affected processors on OMAP4/OMAP5/DRA7 are in domains
>> that are not entering RET. IPU2 on DRA7 is in CORE power domain
>> which is only programmed for ON power state. The fix can be easily
>> scaled if these domains do hit RET in the future.
>> 3. The issue was not seen on current DRA7 platforms if any of the
>> DSP remote processors were booted and using one of the GPTimers
>> 5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
>> errata fix for i874 implemented in commit 1cbabcb9807e ("ARM:
>> DRA7: clockdomain: Implement timer workaround for errata i874")
>> which keeps the IPU1 power domain from entering RET when the
>> timers are active. But the timer workaround did not make any
>> difference on 4.14 kernel, and an l3_noc error was seen still
>> without this fix.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>And drop this one as well, since mainline doesn't yet boot
>the processors, so this is not needed for stable queue.
Now dropped, thank you.
--
Thanks,
Sasha
_______________________________________________
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 AUTOSEL 5.5 219/542] ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
From: Sasha Levin @ 2020-02-20 16:49 UTC (permalink / raw)
To: Suman Anna
Cc: linux-kernel, stable, Tony Lindgren, linux-omap, linux-arm-kernel
In-Reply-To: <a7666322-f931-63f1-a4c5-d44c2ba4ed0c@ti.com>
On Fri, Feb 14, 2020 at 12:34:58PM -0600, Suman Anna wrote:
>Hi Sasha,
>
>On 2/14/20 9:43 AM, Sasha Levin wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> [ Upstream commit 4601832f40501efc3c2fd264a5a69bd1ac17d520 ]
>>
>> The IPU1 MMU has been using common IOMMU pdata quirks defined and
>> used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
>> pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
>> plugged in, so that the IPU1 power domain can be restricted to ON
>> state during the boot and active period of the IPU1 remote processor.
>> This eliminates the pre-conditions for the IPU1 boot issue as
>> described in commit afe518400bdb ("iommu/omap: fix boot issue on
>> remoteprocs with AMMU/Unicache").
>>
>> NOTE:
>> 1. RET is not a valid target power domain state on DRA7 platforms,
>> and IPU power domain is normally programmed for OFF. The IPU1
>> still fails to boot though, and an unclearable l3_noc error is
>> thrown currently on 4.14 kernel without this fix. This behavior
>> is slightly different from previous 4.9 LTS kernel.
>> 2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the
>> other affected processors on OMAP4/OMAP5/DRA7 are in domains
>> that are not entering RET. IPU2 on DRA7 is in CORE power domain
>> which is only programmed for ON power state. The fix can be easily
>> scaled if these domains do hit RET in the future.
>> 3. The issue was not seen on current DRA7 platforms if any of the
>> DSP remote processors were booted and using one of the GPTimers
>> 5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the
>> errata fix for i874 implemented in commit 1cbabcb9807e ("ARM:
>> DRA7: clockdomain: Implement timer workaround for errata i874")
>> which keeps the IPU1 power domain from entering RET when the
>> timers are active. But the timer workaround did not make any
>> difference on 4.14 kernel, and an l3_noc error was seen still
>> without this fix.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>And drop this one as well, since mainline doesn't yet boot
>the processors, so this is not needed for stable queue.
Now dropped, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH v2 1/2] s390x: fix memleaks in cpu_finalize
From: Peter Maydell @ 2020-02-20 16:49 UTC (permalink / raw)
To: Cornelia Huck
Cc: zhanghailiang, Alistair Francis, Pan Nengyuan, QEMU Developers,
mav2-rk.cave-ayland, qemu-arm, qemu-ppc, Euler Robot,
Richard Henderson, andrzej zaborowski, David Gibson
In-Reply-To: <20200220165950.3a5ec74a.cohuck@redhat.com>
On Thu, 20 Feb 2020 at 16:01, Cornelia Huck <cohuck@redhat.com> wrote:
> I may be missing something, but what cleans up the timers if we fail
> further down in this function? I don't think the unrealize callback is
> invoked by the core in case of error?
FWIW I sent a mail to one of these threads a few days ago
where I claimed we did call unrealize if realize fails,
but looking again at the device_set_realized() code I think
I was misreading it. If the device's own 'realize' method
fails, we go to the 'fail' label, which just reports back the
error and doesn't call unrealize. It's only if the device's
'realize' method succeeds and we get a failure in some later
thing like calling 'realize' on the child bus objects that we
will call the device unrealize as part of cleanup.
Apologies for any confusion caused.
thanks
-- PMM
^ permalink raw reply
* Re: [RFC PATCH v3 07/27] qcow2: Add subcluster-related fields to BDRVQcow2State
From: Eric Blake @ 2020-02-20 16:48 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <w51blptb4lc.fsf@maestria.local.igalia.com>
On 2/20/20 10:34 AM, Alberto Garcia wrote:
> On Thu 20 Feb 2020 04:28:07 PM CET, Eric Blake wrote:
>>> Images without subclusters are treated as if they had exactly one,
>>> with subcluster_size = cluster_size.
>>
>> The qcow2 spec changes earlier in the series made it sound like your
>> choices are exactly 1 or 32,
>
>>> +#define QCOW_MAX_SUBCLUSTERS_PER_CLUSTER 32
>>> +
>>
>> ...but this name sounds like other values (2, 4, 8, 16) might be
>> possible?
>
> I guess I didn't want to call it QCOW_SUBCLUSTERS_PER_CLUSTER because
> there's already BDRVQcow2State.subclusters_per_cluster. And that one can
> have two possible values (1 and 32) so 32 would be the maximum.
>
> I get your point, however, and I'm open to suggestions.
Maybe QCOW_EXTL2_SUBCLUSTERS_PER_CLUSTER
since it is a hard-coded property of the EXTL2 feature.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Roger Pau Monné @ 2020-02-20 16:48 UTC (permalink / raw)
To: Durrant, Paul
Cc: Valentin, Eduardo, peterz@infradead.org, benh@kernel.crashing.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, pavel@ucw.cz,
hpa@zytor.com, tglx@linutronix.de, sstabellini@kernel.org,
fllinden@amaozn.com, x86@kernel.org, mingo@redhat.com,
xen-devel@lists.xenproject.org, Singh, Balbir,
len.brown@intel.com, jgross@suse.com, konrad.wilk@oracle.com,
Agarwal, Anchal, bp@alien8.de, boris.ostrovsky@oracle.com,
axboe@kernel.dk, netdev@vger.kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, Kamata, Munehisa, vkuznets@redhat.com,
davem@davemloft.net, Woodhouse, David
In-Reply-To: <c9662397256a4568a5cc7d70a84940e5@EX13D32EUC003.ant.amazon.com>
On Thu, Feb 20, 2020 at 04:23:13PM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Roger Pau Monné <roger.pau@citrix.com>
> > Sent: 20 February 2020 15:45
> > To: Durrant, Paul <pdurrant@amazon.co.uk>
> > Cc: Agarwal, Anchal <anchalag@amazon.com>; Valentin, Eduardo
> > <eduval@amazon.com>; len.brown@intel.com; peterz@infradead.org;
> > benh@kernel.crashing.org; x86@kernel.org; linux-mm@kvack.org;
> > pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de; sstabellini@kernel.org;
> > fllinden@amaozn.com; Kamata, Munehisa <kamatam@amazon.com>;
> > mingo@redhat.com; xen-devel@lists.xenproject.org; Singh, Balbir
> > <sblbir@amazon.com>; axboe@kernel.dk; konrad.wilk@oracle.com;
> > bp@alien8.de; boris.ostrovsky@oracle.com; jgross@suse.com;
> > netdev@vger.kernel.org; linux-pm@vger.kernel.org; rjw@rjwysocki.net;
> > linux-kernel@vger.kernel.org; vkuznets@redhat.com; davem@davemloft.net;
> > Woodhouse, David <dwmw@amazon.co.uk>
> > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks
> > for PM suspend and hibernation
> >
> > On Thu, Feb 20, 2020 at 08:54:36AM +0000, Durrant, Paul wrote:
> > > > -----Original Message-----
> > > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > > > Roger Pau Monné
> > > > Sent: 20 February 2020 08:39
> > > > To: Agarwal, Anchal <anchalag@amazon.com>
> > > > Cc: Valentin, Eduardo <eduval@amazon.com>; len.brown@intel.com;
> > > > peterz@infradead.org; benh@kernel.crashing.org; x86@kernel.org; linux-
> > > > mm@kvack.org; pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de;
> > > > sstabellini@kernel.org; fllinden@amaozn.com; Kamata, Munehisa
> > > > <kamatam@amazon.com>; mingo@redhat.com; xen-
> > devel@lists.xenproject.org;
> > > > Singh, Balbir <sblbir@amazon.com>; axboe@kernel.dk;
> > > > konrad.wilk@oracle.com; bp@alien8.de; boris.ostrovsky@oracle.com;
> > > > jgross@suse.com; netdev@vger.kernel.org; linux-pm@vger.kernel.org;
> > > > rjw@rjwysocki.net; linux-kernel@vger.kernel.org; vkuznets@redhat.com;
> > > > davem@davemloft.net; Woodhouse, David <dwmw@amazon.co.uk>
> > > > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add
> > callbacks
> > > > for PM suspend and hibernation
> > > >
> > > > Thanks for this work, please see below.
> > > >
> > > > On Wed, Feb 19, 2020 at 06:04:24PM +0000, Anchal Agarwal wrote:
> > > > > On Tue, Feb 18, 2020 at 10:16:11AM +0100, Roger Pau Monné wrote:
> > > > > > On Mon, Feb 17, 2020 at 11:05:53PM +0000, Anchal Agarwal wrote:
> > > > > > > On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > > > > > > > On Fri, Feb 14, 2020 at 11:25:34PM +0000, Anchal Agarwal
> > wrote:
> > > > > > > Quiescing the queue seemed a better option here as we want to
> > make
> > > > sure ongoing
> > > > > > > requests dispatches are totally drained.
> > > > > > > I should accept that some of these notion is borrowed from how
> > nvme
> > > > freeze/unfreeze
> > > > > > > is done although its not apple to apple comparison.
> > > > > >
> > > > > > That's fine, but I would still like to requests that you use the
> > same
> > > > > > logic (as much as possible) for both the Xen and the PM initiated
> > > > > > suspension.
> > > > > >
> > > > > > So you either apply this freeze/unfreeze to the Xen suspension
> > (and
> > > > > > drop the re-issuing of requests on resume) or adapt the same
> > approach
> > > > > > as the Xen initiated suspension. Keeping two completely different
> > > > > > approaches to suspension / resume on blkfront is not suitable long
> > > > > > term.
> > > > > >
> > > > > I agree with you on overhaul of xen suspend/resume wrt blkfront is a
> > > > good
> > > > > idea however, IMO that is a work for future and this patch series
> > should
> > > > > not be blocked for it. What do you think?
> > > >
> > > > It's not so much that I think an overhaul of suspend/resume in
> > > > blkfront is needed, it's just that I don't want to have two completely
> > > > different suspend/resume paths inside blkfront.
> > > >
> > > > So from my PoV I think the right solution is to either use the same
> > > > code (as much as possible) as it's currently used by Xen initiated
> > > > suspend/resume, or to also switch Xen initiated suspension to use the
> > > > newly introduced code.
> > > >
> > > > Having two different approaches to suspend/resume in the same driver
> > > > is a recipe for disaster IMO: it adds complexity by forcing developers
> > > > to take into account two different suspend/resume approaches when
> > > > there's no need for it.
> > >
> > > I disagree. S3 or S4 suspend/resume (or perhaps we should call them
> > power state transitions to avoid confusion) are quite different from Xen
> > suspend/resume.
> > > Power state transitions ought to be, and indeed are, visible to the
> > software running inside the guest. Applications, as well as drivers, can
> > receive notification and take whatever action they deem appropriate.
> > > Xen suspend/resume OTOH is used when a guest is migrated and the code
> > should go to all lengths possible to make any software running inside the
> > guest (other than Xen specific enlightened code, such as PV drivers)
> > completely unaware that anything has actually happened.
> >
> > So from what you say above PM state transitions are notified to all
> > drivers, and Xen suspend/resume is only notified to PV drivers, and
> > here we are speaking about blkfront which is a PV driver, and should
> > get notified in both cases. So I'm unsure why the same (or at least
> > very similar) approach can't be used in both cases.
> >
> > The suspend/resume approach proposed by this patch is completely
> > different than the one used by a xenbus initiated suspend/resume, and
> > I don't see a technical reason that warrants this difference.
> >
>
> Within an individual PV driver it may well be ok to use common mechanisms for connecting to the backend but issues will arise if any subsequent action is visible to the guest. E.g. a network frontend needs to issue gratuitous ARPs without anything else in the network stack (or monitoring the network stack) knowing that it has happened.
>
> > I'm not saying that the approach used here is wrong, it's just that I
> > don't see the point in having two different ways to do suspend/resume
> > in the same driver, unless there's a technical reason for it, which I
> > don't think has been provided.
>
> The technical justification is that the driver needs to know what kind of suspend or resume it is doing, so that it doesn't do the wrong thing. There may also be differences in the state of the system e.g. in Windows, at least some of the resume-from-xen-suspend code runs with interrupts disabled (which is necessary to make sure enough state is restored before things become visible to other kernel code).
>
> >
> > I would be fine with switching xenbus initiated suspend/resume to also
> > use the approach proposed here: freeze the queues and drain the shared
> > rings before suspending.
> >
>
> I think abstracting away at the xenbus level to some degree is probably feasible, but some sort of flag should be passed to the individual drivers so they know what circumstances they are operating under.
>
> > > So, whilst it may be possible to use common routines to, for example,
> > re-establish PV frontend/backend communication, PV frontend code should be
> > acutely aware of the circumstances they are operating in. I can cite
> > example code in the Windows PV driver, which have supported guest S3/S4
> > power state transitions since day 1.
> >
> > Hm, please bear with me, as I'm not sure I fully understand. Why isn't
> > the current suspend/resume logic suitable for PM transitions?
> >
>
> I don’t know the details for Linux but it may well be to do with assumptions made about the system e.g. the ability to block waiting for something to happen on another CPU (which may have already been quiesced in a PM context).
>
> > As said above, I'm happy to switch xenbus initiated suspend/resume to
> > use the logic in this patch, but unless there's a technical reason for
> > it I don't see why blkfront should have two completely different
> > approaches to suspend/resume depending on whether it's a PM or a
> > xenbus state change.
> >
>
> Hopefully what I said above illustrates why it may not be 100% common.
Yes, that's fine. I don't expect it to be 100% common (as I guess
that the hooks will have different prototypes), but I expect
that routines can be shared, and that the approach taken can be the
same.
For example one necessary difference will be that xenbus initiated
suspend won't close the PV connection, in case suspension fails. On PM
suspend you seem to always close the connection beforehand, so you
will always have to re-negotiate on resume even if suspension failed.
What I'm mostly worried about is the different approach to ring
draining. Ie: either xenbus is changed to freeze the queues and drain
the shared rings, or PM uses the already existing logic of not
flushing the rings an re-issuing in-flight requests on resume.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Roger Pau Monné @ 2020-02-20 16:48 UTC (permalink / raw)
To: Durrant, Paul
Cc: Agarwal, Anchal, Valentin, Eduardo, len.brown@intel.com,
peterz@infradead.org, benh@kernel.crashing.org, x86@kernel.org,
linux-mm@kvack.org, pavel@ucw.cz, hpa@zytor.com,
tglx@linutronix.de, sstabellini@kernel.org, fllinden@amaozn.com,
Kamata, Munehisa, mingo@redhat.com,
xen-devel@lists.xenproject.org, Singh, Balbir, axboe@kernel.dk,
konrad.wilk@oracle.com, bp@alien8.de, boris.ostrovsky@oracle.com,
jgross@suse.com, netdev@vger.kernel.org, linux-pm@vger.kernel.org,
rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
vkuznets@redhat.com, davem@davemloft.net, Woodhouse, David
In-Reply-To: <c9662397256a4568a5cc7d70a84940e5@EX13D32EUC003.ant.amazon.com>
On Thu, Feb 20, 2020 at 04:23:13PM +0000, Durrant, Paul wrote:
> > -----Original Message-----
> > From: Roger Pau Monné <roger.pau@citrix.com>
> > Sent: 20 February 2020 15:45
> > To: Durrant, Paul <pdurrant@amazon.co.uk>
> > Cc: Agarwal, Anchal <anchalag@amazon.com>; Valentin, Eduardo
> > <eduval@amazon.com>; len.brown@intel.com; peterz@infradead.org;
> > benh@kernel.crashing.org; x86@kernel.org; linux-mm@kvack.org;
> > pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de; sstabellini@kernel.org;
> > fllinden@amaozn.com; Kamata, Munehisa <kamatam@amazon.com>;
> > mingo@redhat.com; xen-devel@lists.xenproject.org; Singh, Balbir
> > <sblbir@amazon.com>; axboe@kernel.dk; konrad.wilk@oracle.com;
> > bp@alien8.de; boris.ostrovsky@oracle.com; jgross@suse.com;
> > netdev@vger.kernel.org; linux-pm@vger.kernel.org; rjw@rjwysocki.net;
> > linux-kernel@vger.kernel.org; vkuznets@redhat.com; davem@davemloft.net;
> > Woodhouse, David <dwmw@amazon.co.uk>
> > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add callbacks
> > for PM suspend and hibernation
> >
> > On Thu, Feb 20, 2020 at 08:54:36AM +0000, Durrant, Paul wrote:
> > > > -----Original Message-----
> > > > From: Xen-devel <xen-devel-bounces@lists.xenproject.org> On Behalf Of
> > > > Roger Pau Monné
> > > > Sent: 20 February 2020 08:39
> > > > To: Agarwal, Anchal <anchalag@amazon.com>
> > > > Cc: Valentin, Eduardo <eduval@amazon.com>; len.brown@intel.com;
> > > > peterz@infradead.org; benh@kernel.crashing.org; x86@kernel.org; linux-
> > > > mm@kvack.org; pavel@ucw.cz; hpa@zytor.com; tglx@linutronix.de;
> > > > sstabellini@kernel.org; fllinden@amaozn.com; Kamata, Munehisa
> > > > <kamatam@amazon.com>; mingo@redhat.com; xen-
> > devel@lists.xenproject.org;
> > > > Singh, Balbir <sblbir@amazon.com>; axboe@kernel.dk;
> > > > konrad.wilk@oracle.com; bp@alien8.de; boris.ostrovsky@oracle.com;
> > > > jgross@suse.com; netdev@vger.kernel.org; linux-pm@vger.kernel.org;
> > > > rjw@rjwysocki.net; linux-kernel@vger.kernel.org; vkuznets@redhat.com;
> > > > davem@davemloft.net; Woodhouse, David <dwmw@amazon.co.uk>
> > > > Subject: Re: [Xen-devel] [RFC PATCH v3 06/12] xen-blkfront: add
> > callbacks
> > > > for PM suspend and hibernation
> > > >
> > > > Thanks for this work, please see below.
> > > >
> > > > On Wed, Feb 19, 2020 at 06:04:24PM +0000, Anchal Agarwal wrote:
> > > > > On Tue, Feb 18, 2020 at 10:16:11AM +0100, Roger Pau Monné wrote:
> > > > > > On Mon, Feb 17, 2020 at 11:05:53PM +0000, Anchal Agarwal wrote:
> > > > > > > On Mon, Feb 17, 2020 at 11:05:09AM +0100, Roger Pau Monné wrote:
> > > > > > > > On Fri, Feb 14, 2020 at 11:25:34PM +0000, Anchal Agarwal
> > wrote:
> > > > > > > Quiescing the queue seemed a better option here as we want to
> > make
> > > > sure ongoing
> > > > > > > requests dispatches are totally drained.
> > > > > > > I should accept that some of these notion is borrowed from how
> > nvme
> > > > freeze/unfreeze
> > > > > > > is done although its not apple to apple comparison.
> > > > > >
> > > > > > That's fine, but I would still like to requests that you use the
> > same
> > > > > > logic (as much as possible) for both the Xen and the PM initiated
> > > > > > suspension.
> > > > > >
> > > > > > So you either apply this freeze/unfreeze to the Xen suspension
> > (and
> > > > > > drop the re-issuing of requests on resume) or adapt the same
> > approach
> > > > > > as the Xen initiated suspension. Keeping two completely different
> > > > > > approaches to suspension / resume on blkfront is not suitable long
> > > > > > term.
> > > > > >
> > > > > I agree with you on overhaul of xen suspend/resume wrt blkfront is a
> > > > good
> > > > > idea however, IMO that is a work for future and this patch series
> > should
> > > > > not be blocked for it. What do you think?
> > > >
> > > > It's not so much that I think an overhaul of suspend/resume in
> > > > blkfront is needed, it's just that I don't want to have two completely
> > > > different suspend/resume paths inside blkfront.
> > > >
> > > > So from my PoV I think the right solution is to either use the same
> > > > code (as much as possible) as it's currently used by Xen initiated
> > > > suspend/resume, or to also switch Xen initiated suspension to use the
> > > > newly introduced code.
> > > >
> > > > Having two different approaches to suspend/resume in the same driver
> > > > is a recipe for disaster IMO: it adds complexity by forcing developers
> > > > to take into account two different suspend/resume approaches when
> > > > there's no need for it.
> > >
> > > I disagree. S3 or S4 suspend/resume (or perhaps we should call them
> > power state transitions to avoid confusion) are quite different from Xen
> > suspend/resume.
> > > Power state transitions ought to be, and indeed are, visible to the
> > software running inside the guest. Applications, as well as drivers, can
> > receive notification and take whatever action they deem appropriate.
> > > Xen suspend/resume OTOH is used when a guest is migrated and the code
> > should go to all lengths possible to make any software running inside the
> > guest (other than Xen specific enlightened code, such as PV drivers)
> > completely unaware that anything has actually happened.
> >
> > So from what you say above PM state transitions are notified to all
> > drivers, and Xen suspend/resume is only notified to PV drivers, and
> > here we are speaking about blkfront which is a PV driver, and should
> > get notified in both cases. So I'm unsure why the same (or at least
> > very similar) approach can't be used in both cases.
> >
> > The suspend/resume approach proposed by this patch is completely
> > different than the one used by a xenbus initiated suspend/resume, and
> > I don't see a technical reason that warrants this difference.
> >
>
> Within an individual PV driver it may well be ok to use common mechanisms for connecting to the backend but issues will arise if any subsequent action is visible to the guest. E.g. a network frontend needs to issue gratuitous ARPs without anything else in the network stack (or monitoring the network stack) knowing that it has happened.
>
> > I'm not saying that the approach used here is wrong, it's just that I
> > don't see the point in having two different ways to do suspend/resume
> > in the same driver, unless there's a technical reason for it, which I
> > don't think has been provided.
>
> The technical justification is that the driver needs to know what kind of suspend or resume it is doing, so that it doesn't do the wrong thing. There may also be differences in the state of the system e.g. in Windows, at least some of the resume-from-xen-suspend code runs with interrupts disabled (which is necessary to make sure enough state is restored before things become visible to other kernel code).
>
> >
> > I would be fine with switching xenbus initiated suspend/resume to also
> > use the approach proposed here: freeze the queues and drain the shared
> > rings before suspending.
> >
>
> I think abstracting away at the xenbus level to some degree is probably feasible, but some sort of flag should be passed to the individual drivers so they know what circumstances they are operating under.
>
> > > So, whilst it may be possible to use common routines to, for example,
> > re-establish PV frontend/backend communication, PV frontend code should be
> > acutely aware of the circumstances they are operating in. I can cite
> > example code in the Windows PV driver, which have supported guest S3/S4
> > power state transitions since day 1.
> >
> > Hm, please bear with me, as I'm not sure I fully understand. Why isn't
> > the current suspend/resume logic suitable for PM transitions?
> >
>
> I don’t know the details for Linux but it may well be to do with assumptions made about the system e.g. the ability to block waiting for something to happen on another CPU (which may have already been quiesced in a PM context).
>
> > As said above, I'm happy to switch xenbus initiated suspend/resume to
> > use the logic in this patch, but unless there's a technical reason for
> > it I don't see why blkfront should have two completely different
> > approaches to suspend/resume depending on whether it's a PM or a
> > xenbus state change.
> >
>
> Hopefully what I said above illustrates why it may not be 100% common.
Yes, that's fine. I don't expect it to be 100% common (as I guess
that the hooks will have different prototypes), but I expect
that routines can be shared, and that the approach taken can be the
same.
For example one necessary difference will be that xenbus initiated
suspend won't close the PV connection, in case suspension fails. On PM
suspend you seem to always close the connection beforehand, so you
will always have to re-negotiate on resume even if suspension failed.
What I'm mostly worried about is the different approach to ring
draining. Ie: either xenbus is changed to freeze the queues and drain
the shared rings, or PM uses the already existing logic of not
flushing the rings an re-issuing in-flight requests on resume.
Thanks, Roger.
^ permalink raw reply
* [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
From: Marek Vasut @ 2020-02-20 16:48 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB265943EC9CC933AD57868454A2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 3:32 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>>> From: Chee Hong Ang <chee.hong.ang@intel.com>
>>>
>>> Allow clock manager driver to access the System Manager's Boot Scratch
>>> Register 0 in non-secure mode (EL2) on SoC 64bits platform.
>>>
>>> Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
>>> ---
>>> arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +++--
>>> arch/arm/mach-socfpga/clock_manager_s10.c | 5 +++--
>>> 2 files changed, 6 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c
>>> b/arch/arm/mach-socfpga/clock_manager_agilex.c
>>> index 4ee2b7b..e5a0998 100644
>>> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
>>> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
>>> @@ -12,6 +12,7 @@
>>> #include <asm/arch/system_manager.h>
>>> #include <asm/io.h>
>>> #include <dt-bindings/clock/agilex-clock.h>
>>> +#include <asm/arch/secure_reg_helper.h>
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -65,8 +66,8 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
>>>
>>> u32 cm_get_qspi_controller_clk_hz(void)
>>> {
>>> - return readl(socfpga_get_sysmgr_addr() +
>>> - SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
>>> + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
>>> +
>> SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
>>> }
>>>
>>> void cm_print_clock_quick_summary(void)
>>> diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c
>>> b/arch/arm/mach-socfpga/clock_manager_s10.c
>>> index 05e4212..02578cc 100644
>>> --- a/arch/arm/mach-socfpga/clock_manager_s10.c
>>> +++ b/arch/arm/mach-socfpga/clock_manager_s10.c
>>> @@ -9,6 +9,7 @@
>>> #include <asm/arch/clock_manager.h>
>>> #include <asm/arch/handoff_s10.h>
>>> #include <asm/arch/system_manager.h>
>>> +#include <asm/arch/secure_reg_helper.h>
>>>
>>> DECLARE_GLOBAL_DATA_PTR;
>>>
>>> @@ -385,8 +386,8 @@ unsigned int cm_get_l4_sp_clk_hz(void)
>>>
>>> unsigned int cm_get_qspi_controller_clk_hz(void)
>>> {
>>> - return readl(socfpga_get_sysmgr_addr() +
>>> - SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
>>> + return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
>>> +
>> SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
>>> }
>>>
>>> unsigned int cm_get_spi_controller_clk_hz(void)
>>
>> Shouldn't the IO accessors already provide the necessary abstraction ?
> This function accesses the system manager registers, therefore it is required
> to call the secure register read function to make sure it still can access
> the system manager register if it's running EL2 (non-secure).
But shouldn't the standard IO accessors handle that transparently ?
What does Linux do ?
^ permalink raw reply
* Re: [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Mark Brown @ 2020-02-20 16:47 UTC (permalink / raw)
To: Oleksandr Suvorov
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org,
Oleksandr Suvorov, Marcel Ziswiler, Igor Opanyuk,
Philippe Schenker
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov@toradex.com>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Thu, Feb 20, 2020 at 02:11:46PM +0000, Oleksandr Suvorov wrote:
> Oleksandr Suvorov (2):
> spi: fsl-lpspi: remove unneeded array
> spi: spidev: fix a max speed setting
Please don't merge unrelated changes into a patch series, at best it's
confusing at worst it can result in unrelated patches holding each other
up.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] bcache: ignore pending signals when creating gc and allocator thread
From: Coly Li @ 2020-02-20 16:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: axboe, linux-bcache, linux-block
In-Reply-To: <20200220163803.GA12147@infradead.org>
On 2020/2/21 12:38 上午, Christoph Hellwig wrote:
> On Thu, Feb 20, 2020 at 09:20:49PM +0800, Coly Li wrote:
>> Therefore I need to explicitly call pending_signal() before calling
>> kthread_run().
>
> Right now you have to. But the proper fix is to not require this and
> fix kthread_run to work from a thread that has been selected by the OOM
> killer. In the most trivial version by moving your code into
> kthread_run, but there probably are better ways as well.
>
Yes I see. Let me think about it, at this moment kthread_run() is still
not very clear in my mind.
Thanks for the hint.
--
Coly Li
^ permalink raw reply
* Re: [PATCH 0/2] trivial fixes for fsl-spi and spidev
From: Mark Brown @ 2020-02-20 16:47 UTC (permalink / raw)
To: Oleksandr Suvorov
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Oleksandr Suvorov, Marcel Ziswiler, Igor Opanyuk,
Philippe Schenker
In-Reply-To: <20200220141143.3902922-1-oleksandr.suvorov-2KBjVHiyJgBBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Thu, Feb 20, 2020 at 02:11:46PM +0000, Oleksandr Suvorov wrote:
> Oleksandr Suvorov (2):
> spi: fsl-lpspi: remove unneeded array
> spi: spidev: fix a max speed setting
Please don't merge unrelated changes into a patch series, at best it's
confusing at worst it can result in unrelated patches holding each other
up.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.BAT: failure for Refactor Gen11+ SAGV support
From: Patchwork @ 2020-02-20 16:47 UTC (permalink / raw)
To: Stanislav Lisovskiy; +Cc: intel-gfx
In-Reply-To: <20200220120741.6917-1-stanislav.lisovskiy@intel.com>
== Series Details ==
Series: Refactor Gen11+ SAGV support
URL : https://patchwork.freedesktop.org/series/73703/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> Patchwork_16644
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16644 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16644, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16644:
### IGT changes ###
#### Possible regressions ####
* igt@debugfs_test@read_all_entries:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-hsw-peppy/igt@debugfs_test@read_all_entries.html
* igt@runner@aborted:
- fi-pnv-d510: NOTRUN -> [FAIL][3]
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-pnv-d510/igt@runner@aborted.html
- fi-hsw-peppy: NOTRUN -> [FAIL][4]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-hsw-peppy/igt@runner@aborted.html
- fi-gdg-551: NOTRUN -> [FAIL][5]
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-gdg-551/igt@runner@aborted.html
- fi-byt-n2820: NOTRUN -> [FAIL][6]
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-byt-n2820/igt@runner@aborted.html
- fi-ivb-3770: NOTRUN -> [FAIL][7]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-ivb-3770/igt@runner@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][8]
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-blb-e6850/igt@runner@aborted.html
#### Warnings ####
* igt@runner@aborted:
- fi-elk-e7500: [FAIL][9] ([fdo#110446]) -> [FAIL][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-elk-e7500/igt@runner@aborted.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-elk-e7500/igt@runner@aborted.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-ehl-1}: NOTRUN -> [FAIL][11]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-ehl-1/igt@runner@aborted.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and Patchwork_16644:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rpm@basic-rte:
- Statuses :
- Exec time: [None] s
* igt@i915_pm_rps@basic-api:
- Statuses :
- Exec time: [None] s
Known issues
------------
Here are the changes found in Patchwork_16644 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s0:
- fi-bsw-nick: [PASS][12] -> [INCOMPLETE][13] ([i915#392])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-nick/igt@gem_exec_suspend@basic-s0.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bsw-nick/igt@gem_exec_suspend@basic-s0.html
- fi-bdw-5557u: [PASS][14] -> [INCOMPLETE][15] ([i915#146])
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@gem_exec_suspend@basic-s0.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bdw-5557u/igt@gem_exec_suspend@basic-s0.html
- fi-bsw-n3050: [PASS][16] -> [INCOMPLETE][17] ([i915#392])
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bsw-n3050/igt@gem_exec_suspend@basic-s0.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-bsw-n3050/igt@gem_exec_suspend@basic-s0.html
- fi-byt-n2820: [PASS][18] -> [INCOMPLETE][19] ([i915#45])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_exec_suspend@basic-s0.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-byt-n2820/igt@gem_exec_suspend@basic-s0.html
#### Warnings ####
* igt@runner@aborted:
- fi-kbl-8809g: [FAIL][20] ([i915#1209]) -> [FAIL][21] ([i915#192] / [i915#193] / [i915#194])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-8809g/igt@runner@aborted.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/fi-kbl-8809g/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#110446]: https://bugs.freedesktop.org/show_bug.cgi?id=110446
[i915#1209]: https://gitlab.freedesktop.org/drm/intel/issues/1209
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#192]: https://gitlab.freedesktop.org/drm/intel/issues/192
[i915#193]: https://gitlab.freedesktop.org/drm/intel/issues/193
[i915#194]: https://gitlab.freedesktop.org/drm/intel/issues/194
[i915#392]: https://gitlab.freedesktop.org/drm/intel/issues/392
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
Participating hosts (49 -> 29)
------------------------------
Additional (2): fi-ivb-3770 fi-pnv-d510
Missing (22): fi-skl-6770hq fi-apl-guc fi-snb-2520m fi-skl-6600u fi-snb-2600 fi-bxt-dsi fi-glk-dsi fi-bwr-2160 fi-ilk-650 fi-kbl-7500u fi-ctg-p8600 fi-kbl-r fi-ilk-m540 fi-cfl-8700k fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-guc fi-kbl-x1275 fi-cfl-8109u fi-bsw-kefka fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7973 -> Patchwork_16644
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16644: b0b1b0e549ad74fa7344f75fd33303542e12ef37 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b0b1b0e549ad drm/i915: Enable SAGV support for Gen12
e96fefdd8ad6 drm/i915: Restrict qgv points which don't have enough bandwidth.
0acee8e77bfd drm/i915: Added required new PCode commands
44d1ee8de76a drm/i915: Refactor intel_can_enable_sagv
44448ba23cf9 drm/i915: Init obj state in intel_atomic_get_old/new_global_obj_state
0ada6eb4565d drm/i915: Introduce skl_plane_wm_level accessor.
5d070083c766 drm/i915: Start passing latency as parameter
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16644/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
From: Marek Vasut @ 2020-02-20 16:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB26599675D3B0549DA2F15D2DA2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 3:02 AM, Ang, Chee Hong wrote:
[...]
>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
>>> +u32 socfpga_secure_reg_read32(phys_addr_t reg_addr); void
>>> +socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr); void
>>> +socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val);
>>> +#else
>>> +#define socfpga_secure_reg_read32 readl
>>> +#define socfpga_secure_reg_write32 writel
>>> +#define socfpga_secure_reg_update32 clrsetbits_le32
>>> +#endif
>>
>> I think I don't understand how this is supposed to work. Would every place in U-
>> Boot have to be patched to call these functions now ?
>
> Not every register access need this. Only those accessing registers in secure zone such
> as 'System Manager' registers need to call this. It's basically determine whether the driver
> should issue SMC/PSCI call if it's running in EL2 (non-secure) or access the registers directly
> by simply using readl/writel and etc if it's running in EL3 (secure).
> Accessing those registers in secure zone in non-secure mode (EL2) will cause SError exception.
> So we can determine this behaviour in compile time:
> SPL always running in EL3. So it just simply fallback to use readl/writel/clrsetbits_le32.
>
> For U-Boot proper (SSBL), there are 2 scenarios:
> 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies that U-Boot proper will be
> running in EL2 (non-secure), then it will use SMC/PSCI calls to access the secure registers.
>
> 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will be running in EL3 which
> will fall back to simply using the direct access functions (readl/writel and etc).
I would expect the standard IO accessors would or should handle this stuff ?
^ permalink raw reply
* Re: [PATCH] nvme-multipath: do not reset on unknown status
From: Christoph Hellwig @ 2020-02-20 16:47 UTC (permalink / raw)
To: Keith Busch; +Cc: hare, John Meneghini, hch, linux-nvme, sagi
In-Reply-To: <20200220145241.12982-1-kbusch@kernel.org>
On Thu, Feb 20, 2020 at 11:52:41PM +0900, Keith Busch wrote:
> From: John Meneghini <johnm@netapp.com>
>
> The nvme multipath error handling defaults to controller reset if the
> error is unknown. There are, however, no existing nvme status codes that
> indicate a reset should be used, and resetting causes unnecessary
> disruption to the rest of IO.
>
> Change nvme's error handling to first check if failover should happen.
> If not, let the normal error handling take over rather than reset the
> controller.
>
> Signed-off-by: John Meneghini <johnm@netapp.com>
> [changelog]
> Signed-off-by: Keith Busch <kbusch@kernel.org>
This pretty much looks like my edited version of Hanne's patch with
John's changelog and your edits..
> if ((req->cmd_flags & REQ_NVME_MPATH) &&
> + nvme_failover_req(req))
> - blk_path_error(status)) {
> - nvme_failover_req(req);
> + nvme_failover_req(req))
This conditional could now fit onto a single line.
Otherwise this looks fine to me.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 4/8] libxfs: enable tools to check that metadata updates have been committed
From: Darrick J. Wong @ 2020-02-20 16:46 UTC (permalink / raw)
To: Brian Foster; +Cc: sandeen, linux-xfs
In-Reply-To: <20200220140612.GB48977@bfoster>
On Thu, Feb 20, 2020 at 09:06:12AM -0500, Brian Foster wrote:
> 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.
My thinking here was that if the write verifiers (or the pwrite() calls
themselves) failed then there's no point in telling the disk to flush
its write cache since we already know it's not in sync with the buffer
cache.
> > +
> > + 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?
Originally I thought it might be useful to be able to distinguish
between "dirty buffers never even made it out of the buffer cache" vs.
"dirty buffers were sent to the disk but the disk sent back media
errors", though in the end the userspace tools don't make any
distinction.
That said, looking at this again, maybe I should track write verifier
failure separately so that we can return EFSCORRUPTED for that?
--D
>
> 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 AUTOSEL 5.5 218/542] ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
From: Sasha Levin @ 2020-02-20 16:46 UTC (permalink / raw)
To: Suman Anna
Cc: Tony Lindgren, linux-omap, linux-kernel, stable, linux-arm-kernel
In-Reply-To: <1ea1b9d3-ce1e-83ca-e2a4-dfb67b12754d@ti.com>
On Fri, Feb 14, 2020 at 12:34:19PM -0600, Suman Anna wrote:
>Hi Sasha,
>
>On 2/14/20 9:43 AM, Sasha Levin wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> [ Upstream commit 2f14101a1d760db72393910d481fbf7768c44530 ]
>>
>> Errata Title:
>> i879: DSP MStandby requires CD_EMU in SW_WKUP
>>
>> Description:
>> The DSP requires the internal emulation clock to be actively toggling
>> in order to successfully enter a low power mode via execution of the
>> IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
>> other prerequisites and software sequence are followed.
>>
>> Workaround:
>> The emulation clock to the DSP is free-running anytime CCS is connected
>> via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
>> is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
>> via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
>>
>> Implementation:
>> This patch implements this workaround by denying the HW_AUTO mode
>> for the EMU clockdomain during the power-up of any DSP processor
>> and re-enabling the HW_AUTO mode during the shutdown of the last
>> DSP processor (actually done during the enabling and disabling of
>> the respective DSP MDMA MMUs). Reference counting has to be used to
>> manage the independent sequencing between the multiple DSP processors.
>>
>> This switching is done at runtime rather than a static clockdomain
>> flags value to meet the target power domain state for the EMU power
>> domain during suspend.
>>
>> Note that the DSP MStandby behavior is not consistent across all
>> boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
>> OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
>> details.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>You can drop this from the 5.5-stable queue. Mainline doesn't yet boot
>the processors, so this is not needed for stable queue.
Now dropped, thank you.
--
Thanks,
Sasha
_______________________________________________
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 AUTOSEL 5.5 218/542] ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879
From: Sasha Levin @ 2020-02-20 16:46 UTC (permalink / raw)
To: Suman Anna
Cc: linux-kernel, stable, Tony Lindgren, linux-omap, linux-arm-kernel
In-Reply-To: <1ea1b9d3-ce1e-83ca-e2a4-dfb67b12754d@ti.com>
On Fri, Feb 14, 2020 at 12:34:19PM -0600, Suman Anna wrote:
>Hi Sasha,
>
>On 2/14/20 9:43 AM, Sasha Levin wrote:
>> From: Suman Anna <s-anna@ti.com>
>>
>> [ Upstream commit 2f14101a1d760db72393910d481fbf7768c44530 ]
>>
>> Errata Title:
>> i879: DSP MStandby requires CD_EMU in SW_WKUP
>>
>> Description:
>> The DSP requires the internal emulation clock to be actively toggling
>> in order to successfully enter a low power mode via execution of the
>> IDLE instruction and PRCM MStandby/Idle handshake. This assumes that
>> other prerequisites and software sequence are followed.
>>
>> Workaround:
>> The emulation clock to the DSP is free-running anytime CCS is connected
>> via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain
>> is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode
>> via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field.
>>
>> Implementation:
>> This patch implements this workaround by denying the HW_AUTO mode
>> for the EMU clockdomain during the power-up of any DSP processor
>> and re-enabling the HW_AUTO mode during the shutdown of the last
>> DSP processor (actually done during the enabling and disabling of
>> the respective DSP MDMA MMUs). Reference counting has to be used to
>> manage the independent sequencing between the multiple DSP processors.
>>
>> This switching is done at runtime rather than a static clockdomain
>> flags value to meet the target power domain state for the EMU power
>> domain during suspend.
>>
>> Note that the DSP MStandby behavior is not consistent across all
>> boards prior to this fix. Please see commit 45f871eec6c0 ("ARM:
>> OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for
>> details.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
>You can drop this from the 5.5-stable queue. Mainline doesn't yet boot
>the processors, so this is not needed for stable queue.
Now dropped, thank you.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 2/4] ci: fix Travis config warnings
From: David Marchand @ 2020-02-20 16:46 UTC (permalink / raw)
To: Thomas Monjalon, Aaron Conole; +Cc: dev, Michael Santana
In-Reply-To: <6771332.6fTUFtlzNn@xps>
On Thu, Feb 20, 2020 at 12:03 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 19/02/2020 20:41, David Marchand:
> > Reading https://config.travis-ci.com/ and using
> > https://config.travis-ci.com/explore to check changes, we can cleanup
> > some warnings reported by the config validation options in Travis.
>
> For documentation purpose, would be good to describe issues in the commit log.
Since I only have this commitlog to update, I intend to push the
series with the following addition:
Example on a job in master:
https://travis-ci.com/DPDK/dpdk/builds/149537002/config
Build config validation:
root: deprecated key doc_packages (anchor on a non-private key)
root: deprecated key build_32b_packages (anchor on a non-private key)
root: deprecated key libabigail_build_packages (anchor on a non-private key)
root: deprecated key extra_packages (anchor on a non-private key)
root: deprecated key aarch64_packages (anchor on a non-private key)
root: key matrix is an alias for jobs, using jobs
For the "(anchor on a non-private key)" warnings, the Travis
documentation [1] recommends prefixing private keys with _ (Travis
schema is available at [2]).
The use of the "matrix" key is allowed, but it is just an alias to the
"jobs" key.
1: https://docs.travis-ci.com/user/build-config-yaml#private-keys-as-yaml-anchors-and-aliases-and-external-tooling
2: https://github.com/travis-ci/travis-yml/blob/730a77f4028b91293a55c8c1c52fc72e64379dde/schema.json
--
David Marchand
^ permalink raw reply
* Re: [PATCH 13/13] KVM: selftests: Introduce num-pages conversion utilities
From: Paolo Bonzini @ 2020-02-20 16:46 UTC (permalink / raw)
To: Andrew Jones, kvm; +Cc: bgardon, borntraeger, frankja, thuth, peterx
In-Reply-To: <20200214145920.30792-14-drjones@redhat.com>
On 14/02/20 15:59, Andrew Jones wrote:
> Guests and hosts don't have to have the same page size. This means
> calculations are necessary when selecting the number of guest pages
> to allocate in order to ensure the number is compatible with the
> host. Provide utilities to help with those calculations and apply
> them where appropriate.
>
> We also revert commit bffed38d4fb5 ("kvm: selftests: aarch64:
> dirty_log_test: fix unaligned memslot size") and then use
> vm_adjust_num_guest_pages() there instead.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> .../selftests/kvm/demand_paging_test.c | 8 ++---
> tools/testing/selftests/kvm/dirty_log_test.c | 13 ++++----
> .../testing/selftests/kvm/include/kvm_util.h | 8 +++++
> .../testing/selftests/kvm/include/test_util.h | 2 ++
> tools/testing/selftests/kvm/lib/kvm_util.c | 32 +++++++++++++++++++
> 5 files changed, 50 insertions(+), 13 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/demand_paging_test.c b/tools/testing/selftests/kvm/demand_paging_test.c
> index a5e57bd63e78..a9289a9386c0 100644
> --- a/tools/testing/selftests/kvm/demand_paging_test.c
> +++ b/tools/testing/selftests/kvm/demand_paging_test.c
> @@ -164,12 +164,7 @@ static struct kvm_vm *create_vm(enum vm_guest_mode mode, int vcpus,
> pages += (2 * pages) / PTES_PER_4K_PT;
> pages += ((2 * vcpus * vcpu_memory_bytes) >> PAGE_SHIFT_4K) /
> PTES_PER_4K_PT;
> -
> - /*
> - * If the host is uing 64K pages, then we need the number of 4K
> - * guest pages to be a multiple of 16.
> - */
> - pages += 16 - pages % 16;
> + pages = vm_adjust_num_guest_pages(mode, pages);
>
> pr_info("Testing guest mode: %s\n", vm_guest_mode_string(mode));
>
> @@ -382,6 +377,7 @@ static void run_test(enum vm_guest_mode mode, bool use_uffd,
> "Guest memory size is not guest page size aligned.");
>
> guest_num_pages = (vcpus * vcpu_memory_bytes) / guest_page_size;
> + guest_num_pages = vm_adjust_num_guest_pages(mode, guest_num_pages);
>
> #ifdef __s390x__
> /* Round up to multiple of 1M (segment size) */
Moved this part to "fixup! KVM: selftests: Support multiple vCPUs in
demand paging test".
Paolo
> diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c
> index 12acf90826c1..a723333b138a 100644
> --- a/tools/testing/selftests/kvm/dirty_log_test.c
> +++ b/tools/testing/selftests/kvm/dirty_log_test.c
> @@ -178,12 +178,11 @@ static void *vcpu_worker(void *data)
> return NULL;
> }
>
> -static void vm_dirty_log_verify(unsigned long *bmap)
> +static void vm_dirty_log_verify(enum vm_guest_mode mode, unsigned long *bmap)
> {
> + uint64_t step = vm_num_host_pages(mode, 1);
> uint64_t page;
> uint64_t *value_ptr;
> - uint64_t step = host_page_size >= guest_page_size ? 1 :
> - guest_page_size / host_page_size;
>
> for (page = 0; page < host_num_pages; page += step) {
> value_ptr = host_test_mem + page * host_page_size;
> @@ -291,14 +290,14 @@ static void run_test(enum vm_guest_mode mode, unsigned long iterations,
> * case where the size is not aligned to 64 pages.
> */
> guest_num_pages = (1ul << (DIRTY_MEM_BITS -
> - vm_get_page_shift(vm))) + 16;
> + vm_get_page_shift(vm))) + 3;
> + guest_num_pages = vm_adjust_num_guest_pages(mode, guest_num_pages);
> #ifdef __s390x__
> /* Round up to multiple of 1M (segment size) */
> guest_num_pages = (guest_num_pages + 0xff) & ~0xffUL;
> #endif
> host_page_size = getpagesize();
> - host_num_pages = (guest_num_pages * guest_page_size) / host_page_size +
> - !!((guest_num_pages * guest_page_size) % host_page_size);
> + host_num_pages = vm_num_host_pages(mode, guest_num_pages);
>
> if (!phys_offset) {
> guest_test_phys_mem = (vm_get_max_gfn(vm) -
> @@ -369,7 +368,7 @@ static void run_test(enum vm_guest_mode mode, unsigned long iterations,
> kvm_vm_clear_dirty_log(vm, TEST_MEM_SLOT_INDEX, bmap, 0,
> host_num_pages);
> #endif
> - vm_dirty_log_verify(bmap);
> + vm_dirty_log_verify(mode, bmap);
> iteration++;
> sync_global_to_guest(vm, iteration);
> }
> diff --git a/tools/testing/selftests/kvm/include/kvm_util.h b/tools/testing/selftests/kvm/include/kvm_util.h
> index 45c6c7ea24c5..bc7c67913fe0 100644
> --- a/tools/testing/selftests/kvm/include/kvm_util.h
> +++ b/tools/testing/selftests/kvm/include/kvm_util.h
> @@ -158,6 +158,14 @@ unsigned int vm_get_page_size(struct kvm_vm *vm);
> unsigned int vm_get_page_shift(struct kvm_vm *vm);
> unsigned int vm_get_max_gfn(struct kvm_vm *vm);
>
> +unsigned int vm_num_host_pages(enum vm_guest_mode mode, unsigned int num_guest_pages);
> +unsigned int vm_num_guest_pages(enum vm_guest_mode mode, unsigned int num_host_pages);
> +static inline unsigned int
> +vm_adjust_num_guest_pages(enum vm_guest_mode mode, unsigned int num_guest_pages)
> +{
> + return vm_num_guest_pages(mode, vm_num_host_pages(mode, num_guest_pages));
> +}
> +
> struct kvm_userspace_memory_region *
> kvm_userspace_memory_region_find(struct kvm_vm *vm, uint64_t start,
> uint64_t end);
> diff --git a/tools/testing/selftests/kvm/include/test_util.h b/tools/testing/selftests/kvm/include/test_util.h
> index c921ea719ae0..a60cf4ffcc3b 100644
> --- a/tools/testing/selftests/kvm/include/test_util.h
> +++ b/tools/testing/selftests/kvm/include/test_util.h
> @@ -19,6 +19,8 @@
> #include <fcntl.h>
> #include "kselftest.h"
>
> +#define getpageshift() (__builtin_ffs(getpagesize()) - 1)
> +
> static inline int _no_printf(const char *format, ...) { return 0; }
>
> #ifdef DEBUG
> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
> index 5e26e24bd609..44f1ef064085 100644
> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
> @@ -583,6 +583,10 @@ void vm_userspace_mem_region_add(struct kvm_vm *vm,
> size_t huge_page_size = KVM_UTIL_PGS_PER_HUGEPG * vm->page_size;
> size_t alignment;
>
> + TEST_ASSERT(vm_adjust_num_guest_pages(vm->mode, npages) == npages,
> + "Number of guest pages is not compatible with the host. "
> + "Try npages=%d", vm_adjust_num_guest_pages(vm->mode, npages));
> +
> TEST_ASSERT((guest_paddr % vm->page_size) == 0, "Guest physical "
> "address not on a page boundary.\n"
> " guest_paddr: 0x%lx vm->page_size: 0x%x",
> @@ -1718,3 +1722,31 @@ unsigned int vm_get_max_gfn(struct kvm_vm *vm)
> {
> return vm->max_gfn;
> }
> +
> +static unsigned int vm_calc_num_pages(unsigned int num_pages,
> + unsigned int page_shift,
> + unsigned int new_page_shift,
> + bool ceil)
> +{
> + unsigned int n = 1 << (new_page_shift - page_shift);
> +
> + if (page_shift >= new_page_shift)
> + return num_pages * (1 << (page_shift - new_page_shift));
> +
> + return num_pages / n + !!(ceil && num_pages % n);
> +}
> +
> +unsigned int
> +vm_num_host_pages(enum vm_guest_mode mode, unsigned int num_guest_pages)
> +{
> + return vm_calc_num_pages(num_guest_pages,
> + vm_guest_mode_params[mode].page_shift,
> + getpageshift(), true);
> +}
> +
> +unsigned int
> +vm_num_guest_pages(enum vm_guest_mode mode, unsigned int num_host_pages)
> +{
> + return vm_calc_num_pages(num_host_pages, getpageshift(),
> + vm_guest_mode_params[mode].page_shift, false);
> +}
>
^ permalink raw reply
* [PATCH v2 09/21] arm: socfpga: Define SMC function identifiers for PSCI SiP services
From: Marek Vasut @ 2020-02-20 16:46 UTC (permalink / raw)
To: u-boot
In-Reply-To: <BN7PR11MB26593E27783A6CCC5FD7B220A2130@BN7PR11MB2659.namprd11.prod.outlook.com>
On 2/20/20 2:42 AM, Ang, Chee Hong wrote:
>> On 2/19/20 1:25 PM, chee.hong.ang at intel.com wrote:
>> [...]
>>> +++ b/include/linux/intel-smc.h
>>> @@ -0,0 +1,374 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * Copyright (C) 2017-2018, Intel Corporation
>>
>> 2020 ?
> This file is new in U-Boot but it already exists in Linux kernel and adapted from there.
> Should I change it to 2020 ?
Then it's 2017-2020 .
[...]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.