* [PATCH V2] arm64: dts: ipq6018: Add a few device nodes
From: Sivaprakash Murugesan @ 2020-02-20 11:50 UTC (permalink / raw)
To: agross, bjorn.andersson, robh+dt, mark.rutland, linux-arm-msm,
devicetree, linux-kernel
Cc: sivaprak
add i2c, spi, crypto, rng, watchdog, peripheral nodes, also add
support for wcss Q6 remoteproc driver and enable hw mutex, smem,
mailbox, smp2p and rpmsg drivers
Signed-off-by: Sivaprakash Murugesan <sivaprak@codeaurora.org>
---
[V2] * Addressed review comments from Stephen
This patch depends on Sricharan's ipq6018 dts patch
https://patchwork.kernel.org/patch/11340681/
arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts | 34 ++++
arch/arm64/boot/dts/qcom/ipq6018.dtsi | 226 +++++++++++++++++++++++++++
2 files changed, 260 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
index 897b4b2..b31117a 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
+++ b/arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dts
@@ -28,3 +28,37 @@
pinctrl-names = "default";
status = "ok";
};
+
+&i2c_1 {
+ pinctrl-0 = <&i2c_1_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+};
+
+&spi_0 {
+ cs-select = <0>;
+ status = "ok";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ compatible = "n25q128a11";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&tlmm {
+ i2c_1_pins: i2c-1-pins {
+ pins = "gpio42", "gpio43";
+ function = "blsp2_i2c";
+ drive-strength = <8>;
+ };
+
+ spi_0_pins: spi-0-pins {
+ pins = "gpio38", "gpio39", "gpio40", "gpio41";
+ function = "blsp0_spi";
+ drive-strength = <8>;
+ bias-pull-down;
+ };
+};
diff --git a/arch/arm64/boot/dts/qcom/ipq6018.dtsi b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
index 0fb44e5..1aa8d85 100644
--- a/arch/arm64/boot/dts/qcom/ipq6018.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq6018.dtsi
@@ -7,6 +7,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-ipq6018.h>
+#include <dt-bindings/reset/qcom,gcc-ipq6018.h>
/ {
#address-cells = <2>;
@@ -69,6 +70,18 @@
};
};
+ firmware {
+ scm {
+ compatible = "qcom,scm";
+ };
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
pmuv8: pmu {
compatible = "arm,cortex-a53-pmu";
interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4) |
@@ -89,6 +102,22 @@
reg = <0x0 0x48500000 0x0 0x00200000>;
no-map;
};
+
+ smem_region: memory@4aa00000 {
+ reg = <0x0 0x4aa00000 0x0 0x00100000>;
+ no-map;
+ };
+
+ q6_region: memory@4ab00000 {
+ reg = <0x0 0x4ab00000 0x0 0x02800000>;
+ no-map;
+ };
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_region>;
+ hwlocks = <&tcsr_mutex 0>;
};
soc: soc {
@@ -98,6 +127,36 @@
dma-ranges;
compatible = "simple-bus";
+ prng: qrng@e1000 {
+ compatible = "qcom,prng-ee";
+ reg = <0xe3000 0x1000>;
+ clocks = <&gcc GCC_PRNG_AHB_CLK>;
+ clock-names = "core";
+ };
+
+ cryptobam: dma@704000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x00704000 0x20000>;
+ interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_CRYPTO_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <1>;
+ qcom,controlled-remotely = <1>;
+ qcom,config-pipe-trust-reg = <0>;
+ };
+
+ crypto: crypto@73a000 {
+ compatible = "qcom,crypto-v5.1";
+ reg = <0x0073a000 0x6000>;
+ clocks = <&gcc GCC_CRYPTO_AHB_CLK>,
+ <&gcc GCC_CRYPTO_AXI_CLK>,
+ <&gcc GCC_CRYPTO_CLK>;
+ clock-names = "iface", "bus", "core";
+ dmas = <&cryptobam 2>, <&cryptobam 3>;
+ dma-names = "rx", "tx";
+ };
+
tlmm: pinctrl@1000000 {
compatible = "qcom,ipq6018-pinctrl";
reg = <0x01000000 0x300000>;
@@ -125,6 +184,26 @@
#reset-cells = <1>;
};
+ tcsr_mutex_regs: syscon@1905000 {
+ compatible = "syscon";
+ reg = <0x01905000 0x8000>;
+ };
+
+ tcsr_q6: syscon@1945000 {
+ compatible = "syscon";
+ reg = <0x01945000 0xe000>;
+ };
+
+ blsp_dma: dma@7884000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x07884000 0x2b000>;
+ interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "bam_clk";
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+ };
+
blsp1_uart3: serial@78b1000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x078b1000 0x200>;
@@ -135,6 +214,66 @@
status = "disabled";
};
+ spi_0: spi@78b5000 {
+ compatible = "qcom,spi-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b5000 0x600>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <50000000>;
+ clocks = <&gcc GCC_BLSP1_QUP1_SPI_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 12>, <&blsp_dma 13>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ spi_1: spi@78b6000 {
+ compatible = "qcom,spi-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b6000 0x600>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ spi-max-frequency = <50000000>;
+ clocks = <&gcc GCC_BLSP1_QUP2_SPI_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ dmas = <&blsp_dma 14>, <&blsp_dma 15>;
+ dma-names = "tx", "rx";
+ status = "disabled";
+ };
+
+ i2c_0: i2c@78b6000 {
+ compatible = "qcom,i2c-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b6000 0x600>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+ <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+ clock-names = "iface", "core";
+ clock-frequency = <400000>;
+ dmas = <&blsp_dma 15>, <&blsp_dma 14>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ i2c_1: i2c@78b7000 { /* BLSP1 QUP2 */
+ compatible = "qcom,i2c-qup-v2.2.1";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x078b7000 0x600>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+ <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+ clock-names = "iface", "core";
+ clock-frequency = <400000>;
+ dmas = <&blsp_dma 17>, <&blsp_dma 16>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
intc: interrupt-controller@b000000 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
@@ -146,6 +285,21 @@
interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
};
+ watchdog@b017000 {
+ compatible = "qcom,kpss-wdt";
+ interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x0b017000 0x40>;
+ clocks = <&sleep_clk>;
+ timeout-sec = <10>;
+ };
+
+ apcs_glb: mailbox@b111000 {
+ compatible = "qcom,ipq8074-apcs-apps-global";
+ reg = <0x0b111000 0xc>;
+
+ #mbox-cells = <1>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
@@ -213,5 +367,77 @@
};
};
+ q6v5_wcss: remoteproc@cd00000 {
+ compatible = "qcom,ipq8074-wcss-pil";
+ reg = <0x0cd00000 0x4040>,
+ <0x004ab000 0x20>;
+ reg-names = "qdsp6",
+ "rmb";
+ interrupts-extended = <&intc GIC_SPI 325 IRQ_TYPE_EDGE_RISING>,
+ <&wcss_smp2p_in 0 0>,
+ <&wcss_smp2p_in 1 0>,
+ <&wcss_smp2p_in 2 0>,
+ <&wcss_smp2p_in 3 0>;
+ interrupt-names = "wdog",
+ "fatal",
+ "ready",
+ "handover",
+ "stop-ack";
+
+ resets = <&gcc GCC_WCSSAON_RESET>,
+ <&gcc GCC_WCSS_BCR>,
+ <&gcc GCC_WCSS_Q6_BCR>;
+
+ reset-names = "wcss_aon_reset",
+ "wcss_reset",
+ "wcss_q6_reset";
+
+ clocks = <&gcc GCC_PRNG_AHB_CLK>;
+ clock-names = "prng";
+
+ qcom,halt-regs = <&tcsr_q6 0xa000 0xd000 0x0>;
+
+ qcom,smem-states = <&wcss_smp2p_out 0>,
+ <&wcss_smp2p_out 1>;
+ qcom,smem-state-names = "shutdown",
+ "stop";
+
+ memory-region = <&q6_region>;
+
+ glink-edge {
+ interrupts = <GIC_SPI 321 IRQ_TYPE_EDGE_RISING>;
+ qcom,remote-pid = <1>;
+ mboxes = <&apcs_glb 8>;
+
+ qrtr_requests {
+ qcom,glink-channels = "IPCRTR";
+ };
+ };
+ };
+
+ };
+
+ wcss: wcss-smp2p {
+ compatible = "qcom,smp2p";
+ qcom,smem = <435>, <428>;
+
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 322 IRQ_TYPE_EDGE_RISING>;
+
+ mboxes = <&apcs_glb 9>;
+
+ qcom,local-pid = <0>;
+ qcom,remote-pid = <1>;
+
+ wcss_smp2p_out: master-kernel {
+ qcom,entry-name = "master-kernel";
+ #qcom,smem-state-cells = <1>;
+ };
+
+ wcss_smp2p_in: slave-kernel {
+ qcom,entry-name = "slave-kernel";
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
};
};
--
2.7.4
^ permalink raw reply related
* RE: Race condition in overlayed qcow2?
From: Pavel Dovgalyuk @ 2020-02-20 11:48 UTC (permalink / raw)
To: 'Vladimir Sementsov-Ogievskiy'; +Cc: kwolf, qemu-devel, mreitz
In-Reply-To: <ea13d572-4840-3e88-bc7f-d7c4351cc345@virtuozzo.com>
> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
> 20.02.2020 13:00, Pavel Dovgalyuk wrote:
> >> From: Vladimir Sementsov-Ogievskiy [mailto:vsementsov@virtuozzo.com]
> >> 20.02.2020 11:31, dovgaluk wrote:
> >>> Vladimir Sementsov-Ogievskiy писал 2020-02-19 19:07:
> >>>> 19.02.2020 17:32, dovgaluk wrote:
> >>>>> I encountered a problem with record/replay of QEMU execution and figured out the
> >> following, when
> >>>>> QEMU is started with one virtual disk connected to the qcow2 image with applied
> 'snapshot'
> >> option.
> >>>>>
> >>>>> The patch d710cf575ad5fb3ab329204620de45bfe50caa53 "block/qcow2: introduce parallel
> >> subrequest handling in read and write"
> >>>>> introduces some kind of race condition, which causes difference in the data read from
> the
> >> disk.
> >>>>>
> >>>>> I detected this by adding the following code, which logs IO operation checksum. And this
> >> checksum may be different in different runs of the same recorded execution.
> >>>>>
> >>>>> logging in blk_aio_complete function:
> >>>>> qemu_log("%"PRId64": blk_aio_complete\n", replay_get_current_icount());
> >>>>> QEMUIOVector *qiov = acb->rwco.iobuf;
> >>>>> if (qiov && qiov->iov) {
> >>>>> size_t i, j;
> >>>>> uint64_t sum = 0;
> >>>>> int count = 0;
> >>>>> for (i = 0 ; i < qiov->niov ; ++i) {
> >>>>> for (j = 0 ; j < qiov->iov[i].iov_len ; ++j) {
> >>>>> sum += ((uint8_t*)qiov->iov[i].iov_base)[j];
> >>>>> ++count;
> >>>>> }
> >>>>> }
> >>>>> qemu_log("--- iobuf offset %"PRIx64" len %x sum: %"PRIx64"\n", acb-
> >>> rwco.offset, count, sum);
> >>>>> }
> >>>>>
> >>>>> I tried to get rid of aio task by patching qcow2_co_preadv_part:
> >>>>> ret = qcow2_co_preadv_task(bs, ret, cluster_offset, offset, cur_bytes, qiov,
> qiov_offset);
> >>>>>
> >>>>> That change fixed a bug, but I have no idea what to debug next to figure out the exact
> >> reason of the failure.
> >>>>>
> >>>>> Do you have any ideas or hints?
> >>>>>
> >>>>
> >>>> Hi!
> >>>>
> >>>> Hmm, do mean that read from the disk may return wrong data? It would
> >>>> be very bad of course :(
> >>>> Could you provide a reproducer, so that I can look at it and debug?
> >>>
> >>> It is just a winxp-32 image. I record the execution and replay it with the following
> command
> >> lines:
> >>>
> >>> qemu-system-i386 -icount shift=7,rr=record,rrfile=replay.bin -m 512M -drive
> >> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive
> driver=blkreplay,if=none,image=device-
> >> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -
> net
> >> none
> >>>
> >>> qemu-system-i386 -icount shift=7,rr=replay,rrfile=replay.bin -m 512M -drive
> >> file=xp.qcow2,if=none,id=device-34-file,snapshot -drive
> driver=blkreplay,if=none,image=device-
> >> 34-file,id=device-34-driver -device ide-hd,drive=device-34-driver,bus=ide.0,id=device-34 -
> net
> >> none
> >>>
> >>> Replay stalls at some moment due to the non-determinism of the execution (probably caused
> by
> >> the wrong data read).
> >>
> >> Hmm.. I tried it (with x86_64 qemu and centos image). I waited for some time for a first
> >> command, than Ctrl+C it. After it replay.bin was 4M. Than started the second command. It
> >> works, not failing, not finishing. Is it bad? What is expected behavior and what is wrong?
> >
> > The second command should finish. There is no replay introspection yet (in master), but you
> can
> > stop qemu with gdb and inspect replay_state.current_icount field. It should increase with
> every
> > virtual CPU instruction execution. If that counter has stopped, it means that replay hangs.
>
> It hangs for me even with QCOW2_MAX_WORKERS = 1..
There could be some other bugs in record/replay.
To be sure try winxp on i386.
Pavel Dovgalyuk
^ permalink raw reply
* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Wei Liu @ 2020-02-20 11:48 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <3d9584c2-9c7f-f3e5-283c-c80bb9bebd73@suse.com>
On Thu, Feb 20, 2020 at 12:45:54PM +0100, Jan Beulich wrote:
> On 20.02.2020 12:43, Wei Liu wrote:
> > On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
> >> As the code comment says, this will allow use of a 2Mb super page
> >> mapping at the end of "low" memory.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> --- a/tools/libxl/libxl_dm.c
> >> +++ b/tools/libxl/libxl_dm.c
> >> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
> >> /* Just check if RDM > our memory boundary. */
> >> if (rdm_start > rdm_mem_boundary) {
> >> /*
> >> + * For HAP guests round down to a 2Mb boundary to allow use
> >> + * of large page mappings.
> >> + */
> >> + if (libxl_defbool_val(d_config->c_info.hap)
> >> + && rdm_start > 0x200000)
> >
> > Please use MB(2) here.
>
> Will do, but then what about the ~0x1fffff on the next line? Should
> this become ~(MB(2) - 1)?
Yes that would be good too.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH] cmd: Add unlz4 command
From: Yusuke Ashiduka @ 2020-02-20 11:48 UTC (permalink / raw)
To: u-boot
This command is a new command called "unlz4" that decompresses from memory
into memory.
Used with the CONFIG_CMD_UNLZ4 optionenabled.
Signed-off-by: Yusuke Ashiduka <ashiduka@fujitsu.com>
---
cmd/Kconfig | 7 +++++++
cmd/Makefile | 1 +
cmd/unlz4.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 53 insertions(+)
create mode 100644 cmd/unlz4.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc45a5..3607edd2d2 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -769,6 +769,13 @@ config CMD_LZMADEC
Support decompressing an LZMA (Lempel-Ziv-Markov chain algorithm)
image from memory.
+config CMD_UNLZ4
+ bool "unlz4"
+ default y if CMD_BOOTI
+ select LZ4
+ help
+ Support decompressing an LZ4 image from memory region.
+
config CMD_UNZIP
bool "unzip"
default y if CMD_BOOTI
diff --git a/cmd/Makefile b/cmd/Makefile
index f1dd513a4b..6692ed96c6 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -144,6 +144,7 @@ obj-$(CONFIG_CMD_TSI148) += tsi148.o
obj-$(CONFIG_CMD_UBI) += ubi.o
obj-$(CONFIG_CMD_UBIFS) += ubifs.o
obj-$(CONFIG_CMD_UNIVERSE) += universe.o
+obj-$(CONFIG_CMD_UNLZ4) += unlz4.o
obj-$(CONFIG_CMD_UNZIP) += unzip.o
obj-$(CONFIG_CMD_VIRTIO) += virtio.o
obj-$(CONFIG_CMD_WDT) += wdt.o
diff --git a/cmd/unlz4.c b/cmd/unlz4.c
new file mode 100644
index 0000000000..4d3af53fea
--- /dev/null
+++ b/cmd/unlz4.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020
+ * FUJITSU COMPUTERTECHNOLOGIES LIMITED. All rights reserved.
+ */
+
+#include <common.h>
+#include <command.h>
+#include <env.h>
+#include <lz4.h>
+
+static int do_unlz4(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ unsigned long src, dst;
+ size_t src_len = ~0UL, dst_len = ~0UL;
+ int ret;
+
+ switch (argc) {
+ case 4:
+ src = simple_strtoul(argv[1], NULL, 16);
+ dst = simple_strtoul(argv[2], NULL, 16);
+ dst_len = simple_strtoul(argv[3], NULL, 16);
+ break;
+ default:
+ return CMD_RET_USAGE;
+ }
+
+ ret = ulz4fn((void *)src, src_len, (void *)dst, &dst_len);
+ if (ret) {
+ printf("Uncompressed err :%d\n", ret);
+ return 1;
+ }
+
+ printf("Uncompressed size: %ld = 0x%lX\n", dst_len, dst_len);
+ env_set_hex("filesize", dst_len);
+
+ return 0;
+}
+
+U_BOOT_CMD(unlz4, 4, 1, do_unlz4,
+ "lz4 uncompress a memory region",
+ "srcaddr dstaddr dstsize\n"
+ "NOTE: Specify the destination size that is sufficiently larger\n"
+ " than the source size.\n"
+);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 1/8] x86/fpu/xstate: Define new macros for supervisor and user xstates
From: Borislav Petkov @ 2020-02-20 11:47 UTC (permalink / raw)
To: Yu-cheng Yu
Cc: linux-kernel, x86, H. Peter Anvin, Thomas Gleixner, Ingo Molnar,
Dave Hansen, Tony Luck, Andy Lutomirski, Rik van Riel,
Ravi V. Shankar, Sebastian Andrzej Siewior, Fenghua Yu,
Peter Zijlstra
In-Reply-To: <20200121201843.12047-2-yu-cheng.yu@intel.com>
On Tue, Jan 21, 2020 at 12:18:36PM -0800, Yu-cheng Yu wrote:
> From: Fenghua Yu <fenghua.yu@intel.com>
>
> XCNTXT_MASK is 'all supported xfeatures' before introducing supervisor
> xstates. Rename it to SUPPORTED_XFEATURES_MASK_USER to make clear that
> these are user xstates.
>
> XFEATURE_MASK_SUPERVISOR is replaced with the following:
> - SUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently nothing. ENQCMD and
> Control-flow Enforcement Technology (CET) will be introduced in separate
> series.
> - UNSUPPORTED_XFEATURES_MASK_SUPERVISOR: Currently only Processor Trace.
> - ALL_XFEATURES_MASK_SUPERVISOR: the combination of above.
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Co-developed-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
> Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> ---
> arch/x86/include/asm/fpu/xstate.h | 36 ++++++++++++++++++++-----------
> arch/x86/kernel/fpu/init.c | 3 ++-
> arch/x86/kernel/fpu/xstate.c | 26 +++++++++++-----------
> 3 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/arch/x86/include/asm/fpu/xstate.h b/arch/x86/include/asm/fpu/xstate.h
> index c6136d79f8c0..014c386deaa3 100644
> --- a/arch/x86/include/asm/fpu/xstate.h
> +++ b/arch/x86/include/asm/fpu/xstate.h
> @@ -21,19 +21,29 @@
> #define XSAVE_YMM_SIZE 256
> #define XSAVE_YMM_OFFSET (XSAVE_HDR_SIZE + XSAVE_HDR_OFFSET)
>
> -/* Supervisor features */
> -#define XFEATURE_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> -
> -/* All currently supported features */
> -#define XCNTXT_MASK (XFEATURE_MASK_FP | \
> - XFEATURE_MASK_SSE | \
> - XFEATURE_MASK_YMM | \
> - XFEATURE_MASK_OPMASK | \
> - XFEATURE_MASK_ZMM_Hi256 | \
> - XFEATURE_MASK_Hi16_ZMM | \
> - XFEATURE_MASK_PKRU | \
> - XFEATURE_MASK_BNDREGS | \
> - XFEATURE_MASK_BNDCSR)
> +/* All currently supported user features */
> +#define SUPPORTED_XFEATURES_MASK_USER (XFEATURE_MASK_FP | \
> + XFEATURE_MASK_SSE | \
> + XFEATURE_MASK_YMM | \
> + XFEATURE_MASK_OPMASK | \
> + XFEATURE_MASK_ZMM_Hi256 | \
> + XFEATURE_MASK_Hi16_ZMM | \
> + XFEATURE_MASK_PKRU | \
> + XFEATURE_MASK_BNDREGS | \
> + XFEATURE_MASK_BNDCSR)
> +
> +/* All currently supported supervisor features */
> +#define SUPPORTED_XFEATURES_MASK_SUPERVISOR (0)
> +
> +/*
> + * Unsupported supervisor features. When a supervisor feature in this mask is
> + * supported in the future, move it to the supported supervisor feature mask.
> + */
> +#define UNSUPPORTED_XFEATURES_MASK_SUPERVISOR (XFEATURE_MASK_PT)
> +
> +/* All supervisor states including supported and unsupported states. */
> +#define ALL_XFEATURES_MASK_SUPERVISOR (SUPPORTED_XFEATURES_MASK_SUPERVISOR | \
> + UNSUPPORTED_XFEATURES_MASK_SUPERVISOR)
So frankly having the namespace prepended in those macros makes it more
readable to me: you know that those masks all belong together if you had
this:
XFEATURE_MASK_SUPERVISOR
XFEATURE_MASK_SUPERVISOR_SUPPORTED
XFEATURE_MASK_SUPERVISOR_UNSUPPORTED
XFEATURE_MASK_SUPERVISOR_ALL
XFEATURE_MASK_USER_SUPPORTED
Now they all begin with different words: "ALL", "UNSUPPORTED",
"SUPPORTED", ... and makes you go and look up the mask to make sure it
is the correct type of mask used.
Even more so if the single feature masks also start with
"XFEATURE_MASK_" so it is only logical to have them all start with
XFEATURE_MASK_ IMO.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* [Virtio-fs] [PATCH v3 2/2] virtiofs: Fix xattr operations
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
To: virtio-fs; +Cc: vgoyal
In-Reply-To: <20200220114704.11592-1-misono.tomohiro@jp.fujitsu.com>
Current virtiofsd has problems about xattr operations and
they does not work properly for directory/symlink/special file.
The fundamental cause is that virtiofsd uses openat() + f...xattr()
systemcalls for xattr operation but we should not open symlink/special
file in the daemon. Therefore the function is restricted.
Fix this problem by:
1. during setup of each thread, call unshare(CLONE_FS)
2. in xattr operations (i.e. lo_getxattr), if inode is not a regular
file or directory, use fchdir(proc_loot_fd) + ...xattr() +
fchdir(root.fd) instead of openat() + f...xattr()
(Note: for a regular file/directory openat() + f...xattr()
is still used for performance reason)
With this patch, xfstests generic/062 passes on virtiofs.
This fix is suggested by Miklos Szeredi and Stefan Hajnoczi.
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
---
tools/virtiofsd/fuse_virtio.c | 13 +++++
tools/virtiofsd/passthrough_ll.c | 99 +++++++++++++++++---------------
tools/virtiofsd/seccomp.c | 6 ++
3 files changed, 71 insertions(+), 47 deletions(-)
diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
index 655b9a1413..21c5d76d58 100644
--- a/tools/virtiofsd/fuse_virtio.c
+++ b/tools/virtiofsd/fuse_virtio.c
@@ -463,6 +463,8 @@ err:
return ret;
}
+static __thread bool clone_fs_called;
+
/* Process one FVRequest in a thread pool */
static void fv_queue_worker(gpointer data, gpointer user_data)
{
@@ -478,6 +480,17 @@ static void fv_queue_worker(gpointer data, gpointer user_data)
assert(se->bufsize > sizeof(struct fuse_in_header));
+ if (!clone_fs_called) {
+ int ret;
+
+ /* unshare FS for xattr operation */
+ ret = unshare(CLONE_FS);
+ /* should not fail */
+ assert(ret == 0);
+
+ clone_fs_called = true;
+ }
+
/*
* An element contains one request and the space to send our response
* They're spread over multiple descriptors in a scatter/gather set
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 33cff8c2c8..7d648af916 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -130,7 +130,7 @@ struct lo_inode {
pthread_mutex_t plock_mutex;
GHashTable *posix_locks; /* protected by lo_inode->plock_mutex */
- bool is_symlink;
+ mode_t filetype;
};
struct lo_cred {
@@ -734,7 +734,7 @@ static int utimensat_empty(struct lo_data *lo, struct lo_inode *inode,
struct lo_inode *parent;
char path[PATH_MAX];
- if (inode->is_symlink) {
+ if (S_ISLNK(inode->filetype)) {
res = utimensat(inode->fd, "", tv, AT_EMPTY_PATH);
if (res == -1 && errno == EINVAL) {
/* Sorry, no race free way to set times on symlink. */
@@ -1037,7 +1037,8 @@ static int lo_do_lookup(fuse_req_t req, fuse_ino_t parent, const char *name,
goto out_err;
}
- inode->is_symlink = S_ISLNK(e->attr.st_mode);
+ /* cache only filetype */
+ inode->filetype = (e->attr.st_mode & S_IFMT);
/*
* One for the caller and one for nlookup (released in
@@ -1264,7 +1265,7 @@ static int linkat_empty_nofollow(struct lo_data *lo, struct lo_inode *inode,
struct lo_inode *parent;
char path[PATH_MAX];
- if (inode->is_symlink) {
+ if (S_ISLNK(inode->filetype)) {
res = linkat(inode->fd, "", dfd, name, AT_EMPTY_PATH);
if (res == -1 && (errno == ENOENT || errno == EINVAL)) {
/* Sorry, no race free way to hard-link a symlink. */
@@ -2378,12 +2379,6 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
fuse_log(FUSE_LOG_DEBUG, "lo_getxattr(ino=%" PRIu64 ", name=%s size=%zd)\n",
ino, name, size);
- if (inode->is_symlink) {
- /* Sorry, no race free way to getxattr on symlink. */
- saverr = EPERM;
- goto out;
- }
-
if (size) {
value = malloc(size);
if (!value) {
@@ -2392,12 +2387,19 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
}
sprintf(procname, "%i", inode->fd);
- fd = openat(lo->proc_self_fd, procname, O_RDONLY);
- if (fd < 0) {
- goto out_err;
+ if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+ fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+ if (fd < 0) {
+ goto out_err;
+ }
+ ret = fgetxattr(fd, name, value, size);
+ } else {
+ /* fchdir should not fail here */
+ assert(fchdir(lo->proc_self_fd) == 0);
+ ret = getxattr(procname, name, value, size);
+ assert(fchdir(lo->root.fd) == 0);
}
- ret = fgetxattr(fd, name, value, size);
if (ret == -1) {
goto out_err;
}
@@ -2451,12 +2453,6 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
fuse_log(FUSE_LOG_DEBUG, "lo_listxattr(ino=%" PRIu64 ", size=%zd)\n", ino,
size);
- if (inode->is_symlink) {
- /* Sorry, no race free way to listxattr on symlink. */
- saverr = EPERM;
- goto out;
- }
-
if (size) {
value = malloc(size);
if (!value) {
@@ -2465,12 +2461,19 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
}
sprintf(procname, "%i", inode->fd);
- fd = openat(lo->proc_self_fd, procname, O_RDONLY);
- if (fd < 0) {
- goto out_err;
+ if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+ fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+ if (fd < 0) {
+ goto out_err;
+ }
+ ret = flistxattr(fd, value, size);
+ } else {
+ /* fchdir should not fail here */
+ assert(fchdir(lo->proc_self_fd) == 0);
+ ret = listxattr(procname, value, size);
+ assert(fchdir(lo->root.fd) == 0);
}
- ret = flistxattr(fd, value, size);
if (ret == -1) {
goto out_err;
}
@@ -2524,20 +2527,21 @@ static void lo_setxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
fuse_log(FUSE_LOG_DEBUG, "lo_setxattr(ino=%" PRIu64
", name=%s value=%s size=%zd)\n", ino, name, value, size);
- if (inode->is_symlink) {
- /* Sorry, no race free way to setxattr on symlink. */
- saverr = EPERM;
- goto out;
- }
-
sprintf(procname, "%i", inode->fd);
- fd = openat(lo->proc_self_fd, procname, O_RDWR);
- if (fd < 0) {
- saverr = errno;
- goto out;
+ if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+ fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+ if (fd < 0) {
+ saverr = errno;
+ goto out;
+ }
+ ret = fsetxattr(fd, name, value, size, flags);
+ } else {
+ /* fchdir should not fail here */
+ assert(fchdir(lo->proc_self_fd) == 0);
+ ret = setxattr(procname, name, value, size, flags);
+ assert(fchdir(lo->root.fd) == 0);
}
- ret = fsetxattr(fd, name, value, size, flags);
saverr = ret == -1 ? errno : 0;
if (!saverr) {
@@ -2575,20 +2579,21 @@ static void lo_removexattr(fuse_req_t req, fuse_ino_t ino, const char *name)
fuse_log(FUSE_LOG_DEBUG, "lo_removexattr(ino=%" PRIu64 ", name=%s)\n", ino,
name);
- if (inode->is_symlink) {
- /* Sorry, no race free way to setxattr on symlink. */
- saverr = EPERM;
- goto out;
- }
-
sprintf(procname, "%i", inode->fd);
- fd = openat(lo->proc_self_fd, procname, O_RDWR);
- if (fd < 0) {
- saverr = errno;
- goto out;
+ if (S_ISREG(inode->filetype) || S_ISDIR(inode->filetype)) {
+ fd = openat(lo->proc_self_fd, procname, O_RDONLY);
+ if (fd < 0) {
+ saverr = errno;
+ goto out;
+ }
+ ret = fremovexattr(fd, name);
+ } else {
+ /* fchdir should not fail here */
+ assert(fchdir(lo->proc_self_fd) == 0);
+ ret = removexattr(procname, name);
+ assert(fchdir(lo->root.fd) == 0);
}
- ret = fremovexattr(fd, name);
saverr = ret == -1 ? errno : 0;
if (!saverr) {
@@ -3185,7 +3190,7 @@ static void setup_root(struct lo_data *lo, struct lo_inode *root)
exit(1);
}
- root->is_symlink = false;
+ root->filetype = S_IFDIR;
root->fd = fd;
root->key.ino = stat.st_ino;
root->key.dev = stat.st_dev;
diff --git a/tools/virtiofsd/seccomp.c b/tools/virtiofsd/seccomp.c
index 2d9d4a7ec0..bd9e7b083c 100644
--- a/tools/virtiofsd/seccomp.c
+++ b/tools/virtiofsd/seccomp.c
@@ -41,6 +41,7 @@ static const int syscall_whitelist[] = {
SCMP_SYS(exit),
SCMP_SYS(exit_group),
SCMP_SYS(fallocate),
+ SCMP_SYS(fchdir),
SCMP_SYS(fchmodat),
SCMP_SYS(fchownat),
SCMP_SYS(fcntl),
@@ -62,7 +63,9 @@ static const int syscall_whitelist[] = {
SCMP_SYS(getpid),
SCMP_SYS(gettid),
SCMP_SYS(gettimeofday),
+ SCMP_SYS(getxattr),
SCMP_SYS(linkat),
+ SCMP_SYS(listxattr),
SCMP_SYS(lseek),
SCMP_SYS(madvise),
SCMP_SYS(mkdirat),
@@ -85,6 +88,7 @@ static const int syscall_whitelist[] = {
SCMP_SYS(recvmsg),
SCMP_SYS(renameat),
SCMP_SYS(renameat2),
+ SCMP_SYS(removexattr),
SCMP_SYS(rt_sigaction),
SCMP_SYS(rt_sigprocmask),
SCMP_SYS(rt_sigreturn),
@@ -98,10 +102,12 @@ static const int syscall_whitelist[] = {
SCMP_SYS(setresuid32),
#endif
SCMP_SYS(set_robust_list),
+ SCMP_SYS(setxattr),
SCMP_SYS(symlinkat),
SCMP_SYS(time), /* Rarely needed, except on static builds */
SCMP_SYS(tgkill),
SCMP_SYS(unlinkat),
+ SCMP_SYS(unshare),
SCMP_SYS(utimensat),
SCMP_SYS(write),
SCMP_SYS(writev),
--
2.21.1
^ permalink raw reply related
* [Virtio-fs] [PATCH v3 1/2] virtiofs: passthrough_ll: cleanup getxattr/listxattr
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
To: virtio-fs; +Cc: vgoyal
In-Reply-To: <20200220114704.11592-1-misono.tomohiro@jp.fujitsu.com>
This is a cleanup patch to simplify the following xattr fix and
there is no functional changes.
- Move memory allocation to head of the function
- Unify fgetxattr/flistxattr call for both size == 0 and
size != 0 case
- Remove redundant lo_inode_put call in error path
(Note: second call is ignored now since @inode is already NULL)
Signed-off-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
---
tools/virtiofsd/passthrough_ll.c | 62 ++++++++++++++------------------
1 file changed, 26 insertions(+), 36 deletions(-)
diff --git a/tools/virtiofsd/passthrough_ll.c b/tools/virtiofsd/passthrough_ll.c
index 9772823066..33cff8c2c8 100644
--- a/tools/virtiofsd/passthrough_ll.c
+++ b/tools/virtiofsd/passthrough_ll.c
@@ -2370,8 +2370,8 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
return;
}
- saverr = ENOSYS;
if (!lo_data(req)->xattr) {
+ saverr = ENOSYS;
goto out;
}
@@ -2384,34 +2384,30 @@ static void lo_getxattr(fuse_req_t req, fuse_ino_t ino, const char *name,
goto out;
}
+ if (size) {
+ value = malloc(size);
+ if (!value) {
+ goto out_err;
+ }
+ }
+
sprintf(procname, "%i", inode->fd);
fd = openat(lo->proc_self_fd, procname, O_RDONLY);
if (fd < 0) {
goto out_err;
}
+ ret = fgetxattr(fd, name, value, size);
+ if (ret == -1) {
+ goto out_err;
+ }
if (size) {
- value = malloc(size);
- if (!value) {
- goto out_err;
- }
-
- ret = fgetxattr(fd, name, value, size);
- if (ret == -1) {
- goto out_err;
- }
- saverr = 0;
if (ret == 0) {
+ saverr = 0;
goto out;
}
-
fuse_reply_buf(req, value, ret);
} else {
- ret = fgetxattr(fd, name, NULL, 0);
- if (ret == -1) {
- goto out_err;
- }
-
fuse_reply_xattr(req, ret);
}
out_free:
@@ -2427,7 +2423,6 @@ out_free:
out_err:
saverr = errno;
out:
- lo_inode_put(lo, &inode);
fuse_reply_err(req, saverr);
goto out_free;
}
@@ -2448,8 +2443,8 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
return;
}
- saverr = ENOSYS;
if (!lo_data(req)->xattr) {
+ saverr = ENOSYS;
goto out;
}
@@ -2462,34 +2457,30 @@ static void lo_listxattr(fuse_req_t req, fuse_ino_t ino, size_t size)
goto out;
}
+ if (size) {
+ value = malloc(size);
+ if (!value) {
+ goto out_err;
+ }
+ }
+
sprintf(procname, "%i", inode->fd);
fd = openat(lo->proc_self_fd, procname, O_RDONLY);
if (fd < 0) {
goto out_err;
}
+ ret = flistxattr(fd, value, size);
+ if (ret == -1) {
+ goto out_err;
+ }
if (size) {
- value = malloc(size);
- if (!value) {
- goto out_err;
- }
-
- ret = flistxattr(fd, value, size);
- if (ret == -1) {
- goto out_err;
- }
- saverr = 0;
if (ret == 0) {
+ saverr = 0;
goto out;
}
-
fuse_reply_buf(req, value, ret);
} else {
- ret = flistxattr(fd, NULL, 0);
- if (ret == -1) {
- goto out_err;
- }
-
fuse_reply_xattr(req, ret);
}
out_free:
@@ -2505,7 +2496,6 @@ out_free:
out_err:
saverr = errno;
out:
- lo_inode_put(lo, &inode);
fuse_reply_err(req, saverr);
goto out_free;
}
--
2.21.1
^ permalink raw reply related
* [Virtio-fs] [PATCH v3 0/2] Fix xattr operation
From: Misono Tomohiro @ 2020-02-20 11:47 UTC (permalink / raw)
To: virtio-fs; +Cc: vgoyal
This fixes the xattr operation for directory and special files
(which can be tested by xfstests generic/062 with -o xattr option).
The overall logic is switched back to the same as v1 in favor of performance
(i.e. keep original implementation for regular files/directories)
but I add a cleanup patch to improve readability as requested by Vivek.
Known issue is that if xattr enabled, seek sanity tests (generic/285,
436) will fail. However, I understand this is not a very serious bug
like data corruption so leave it for now.
One question; I remove error handling of fchdir() in v3 since
I believe fchdir to proc_self_fd/root.fd cannot fail in the situation
but should I add error handling?
change v2 -> v3:
- rebased to current dev branch
- add cleanup path (first one) to simplify main patch (second patch)
- restore the logic of v1 in favor of performance
(as a result seek sanity test failure is not fixed by this series)
- remove error handling of fchdir
- drop ACL fix included in v2 for now to focus xattr
v2 patch: https://www.redhat.com/archives/virtio-fs/2020-January/msg00131.html
Thanks!
Misono Tomohiro (2):
virtiofs: passthrough_ll: cleanup getxattr/listxattr
virtiofs: Fix xattr operations
tools/virtiofsd/fuse_virtio.c | 13 +++
tools/virtiofsd/passthrough_ll.c | 141 +++++++++++++++----------------
tools/virtiofsd/seccomp.c | 6 ++
3 files changed, 87 insertions(+), 73 deletions(-)
--
2.21.1
^ permalink raw reply
* Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()
From: Andy Shevchenko @ 2020-02-20 11:46 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Sascha Hauer, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Linux Kernel Mailing List, Jacek Anaszewski, Pavel Machek,
Jiri Slaby, Linux LED Subsystem, Dan Murphy
In-Reply-To: <20200220105718.eoevd3kb63zzrotu@pengutronix.de>
On Thu, Feb 20, 2020 at 12:57 PM Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> On Thu, Feb 20, 2020 at 12:22:36PM +0200, Andy Shevchenko wrote:
> > On Thu, Feb 20, 2020 at 9:49 AM Uwe Kleine-König
> > <u.kleine-koenig@pengutronix.de> wrote:
> > > On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> > > > On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
> > > > >
> > > > > This function is in the same spirit as the other kstrto* functions and
> > > > > uses the same calling convention. It expects the input string to be in
> > > > > the format %u:%u and implements stricter parsing than sscanf as it
> > > > > returns an error on trailing data (other than the usual \n).
> >
> > ...
> >
> > > > On top of that, why kstrtodev_t is so important? How many users are
> > > > already in the kernel to get an advantage out of it?
> > >
> > > Does it need to be important? It matches the other kstrto* functions and
> > > so it seemed more natural to me to put it near the other functions. I'm
> > > not aware of other potential users and surprised you seem to suggest
> > > this as a requirement.
> >
> > Yes it does. The kstrtox() are quite generic, what you are proposing
> > is rather one particular case with blurry understanding how many users
> > will be out of it.
>
> In my understanding one user is a hard requirement.
Yes. But looking at the LOCs you introduce to entire kernel in such
generic area (I wouldn't tell you anything if, for instance, you
introduced a support for hypothetical S2P bus with one host controller
driver) like lib/.
> > If you had told "look, we have 1234 users which may benefit out of
> > it", I would have given no comment against.
>
> Sure, having >1000 potential users would be a good argument pro this
> function. But having only one isn't a good contra IMHO.
For lib/ is a good argument in my opinion.
> > > > What to do with all other possible variants ("%d:%d", "%dx%d" and its
> > > > %u variant, etc)?
> > >
> > > I don't see how %d:%d is relevant, major and minor cannot be negative
> > > can they? I never saw 'x' as separator between major and minor. I
> > > considered shortly parsing %u, but given that (I think) this is an
> > > internal representation only I chose to not make it more visible than it
> > > already is.
> >
> > See above, if we are going to make it generic, perhaps better to cover
> > more possible users, right?
> > Otherwise your change provokes pile of (replaced)
> > kstrto_resolution() /* %ux:%u */
> > kstrto_range() /* %d:%d */
> > kstrto_you_name_it()
>
> Given there are respective types that this can be stored to, I don't
> object more functions of this type and don't see a good reason to not
> add such a function. And in my eyes I prefer to have such a function in
> a visible place (i.e. where all the other kstrto* functions are) to
> prevent code duplication.
You can easily satisfy above by adding a function parameter 'char
*delim', right?
> Also I don't understand yet, what you want me to do.
I have issues with kstrto() not playing with simple numbers (boolean
is a special case, but still a number at the end).
I also don't feel good with too narrow usage of the newly introduced helper
> Assume I'd be
> willing to use simple_strtoul, I'd still want to have a function that
> gives me a dev_t from a given string. Should I put this directly in my
> led-trigger driver?
I see the following possibilities:
a) put it inside the caller and forget about generic helper
b) do a generic helper, but 1/ in string_*() namespace, 2/ with a
delimiter parameter and 3/ possibility to take negative numbers
In b) case, add to the commit message how many potential _existing_
users may be converted to this.
Also it would be good to have two versions strict (only \n at the end
is allowed) and non-strict (based on the amount of users for each
group).
> > > And given that I was asked for strict
> > > parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
> > > is a step backwards. Also simple_strtoul() has "This function is obsolete.
> > > Please use kstrtoul instead." in its docstring which seems to apply to
> > > the other simple_strto*() functions, too.
> >
> > I specifically fixed a doc string to approve its use in the precisely
> > cases you have here.
>
> Can you please be a bit more constructive here and point to the change
> you talk about? I didn't find a commit in next.
https://elixir.bootlin.com/linux/v5.6-rc2/source/include/linux/kernel.h#L446
Note, there is no more word 'obsolete' there.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [Xen-devel] [PATCH 0/5] libxl/PCI: reserved device memory adjustments
From: Wei Liu @ 2020-02-20 11:45 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <b5d94bd8-9a39-c88b-4c3c-f89e655f3abf@suse.com>
On Tue, Feb 18, 2020 at 04:44:11PM +0100, Jan Beulich wrote:
> While playing with this, I've noticed a number of issues,
> some actual bugs, some merely cosmetic (at least at this point
> in time. This is the collection of adjustments made, with bug
> fixes first.
I will leave committing this series to you because your patches don't
seem to work with git-am.
In any case, please allow some time for Anthony and Ian to comment on
this series.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Jan Beulich @ 2020-02-20 11:45 UTC (permalink / raw)
To: Wei Liu; +Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson
In-Reply-To: <20200220114331.m6yolb4hoyfvfmsa@debian>
On 20.02.2020 12:43, Wei Liu wrote:
> On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
>> As the code comment says, this will allow use of a 2Mb super page
>> mapping at the end of "low" memory.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
>> /* Just check if RDM > our memory boundary. */
>> if (rdm_start > rdm_mem_boundary) {
>> /*
>> + * For HAP guests round down to a 2Mb boundary to allow use
>> + * of large page mappings.
>> + */
>> + if (libxl_defbool_val(d_config->c_info.hap)
>> + && rdm_start > 0x200000)
>
> Please use MB(2) here.
Will do, but then what about the ~0x1fffff on the next line? Should
this become ~(MB(2) - 1)?
> With this fixed:
>
> Acked-by: Wei Liu <wl@xen.org>
Thanks.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH] image.h: use uint32_t instead of u32 in android_image_get_dtb*
From: Sam Protsenko @ 2020-02-20 11:45 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200217102353.11174-1-erosca@de.adit-jv.com>
Hi Eugeniu,
On Mon, Feb 17, 2020 at 12:24 PM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
>
> Replace 'u32' by 'uint32_t' in image.h, since the former may lead to
> build failures in U-Boot tooling (see [1]).
>
> Avoid using 'uint', since it is not a fixed-width type [2], potentially
> leading to a dangerous mismatch between the prototypes and definitions
> of the android_image_get_dtb* functions.
>
> This should be the quickest way to overcome the tooling build failure,
> with more future-proof solutions being proposed by Yamada-san in [1].
>
> [1] https://patchwork.ozlabs.org/patch/1238245/
> [2] Excerpt from https://en.cppreference.com/w/cpp/language/types
> -----------8<------------
> Type specifier Width in bits by data model
> LP32 ILP32 LLP64 LP64
> unsigned int 16 32 32 32
> -----------8<------------
>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: Sam Protsenko <joe.skb7@gmail.com>
> Fixes: 7f2531502c74c0 ("image: android: Add routine to get dtbo params")
> Fixes: c3bfad825a71ea ("image: android: Add functions for handling dtb field")
> Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
> Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
> ---
Reviewed-by: Sam Protsenko <joe.skb7@gmail.com>
> include/image.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/image.h b/include/image.h
> index b316d167d8d7..1341fbed62ba 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1425,9 +1425,9 @@ int android_image_get_ramdisk(const struct andr_img_hdr *hdr,
> ulong *rd_data, ulong *rd_len);
> int android_image_get_second(const struct andr_img_hdr *hdr,
> ulong *second_data, ulong *second_len);
> -bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, u32 *size);
> -bool android_image_get_dtb_by_index(ulong hdr_addr, u32 index, ulong *addr,
> - u32 *size);
> +bool android_image_get_dtbo(ulong hdr_addr, ulong *addr, uint32_t *size);
> +bool android_image_get_dtb_by_index(ulong hdr_addr, uint32_t index, ulong *addr,
> + uint32_t *size);
> ulong android_image_get_end(const struct andr_img_hdr *hdr);
> ulong android_image_get_kload(const struct andr_img_hdr *hdr);
> ulong android_image_get_kcomp(const struct andr_img_hdr *hdr);
> --
> 2.25.0
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH 3/5] libxl/PCI: make "rdm=" parsing comply with documentation
From: Wei Liu @ 2020-02-20 11:44 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <7c8de367-4833-c603-fcdd-89c1e6ceda3a@suse.com>
On Tue, Feb 18, 2020 at 04:47:04PM +0100, Jan Beulich wrote:
> Documentation says "<RDM_RESERVATION_STRING> is a comma separated list
> of <KEY=VALUE> settings, from the following list". There's no mention
> of a specific order, yet so far the parsing logic did accept only
> strategy, then policy (and neither of the two omitted). Make "state"
> move
> - back to STATE_TYPE when finding a comma after having parsed the
> <VALUE> part of a setting,
> - to STATE_TERMINAL otherwise.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Wei Liu @ 2020-02-20 11:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <2a9a998e-f2d0-3c07-e85e-7fdda18b506e@suse.com>
On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
> As the code comment says, this will allow use of a 2Mb super page
> mapping at the end of "low" memory.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
> /* Just check if RDM > our memory boundary. */
> if (rdm_start > rdm_mem_boundary) {
> /*
> + * For HAP guests round down to a 2Mb boundary to allow use
> + * of large page mappings.
> + */
> + if (libxl_defbool_val(d_config->c_info.hap)
> + && rdm_start > 0x200000)
Please use MB(2) here.
With this fixed:
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
From: Martin Kepplinger @ 2020-02-20 11:43 UTC (permalink / raw)
To: Jun Li, Peter Chen, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org, dl-linux-imx, Anson Huang,
shawnguo@kernel.org, kernel@pengutronix.de
In-Reply-To: <VE1PR04MB65289878A84E662D6CCAF13089130@VE1PR04MB6528.eurprd04.prod.outlook.com>
On 20.02.20 07:31, Jun Li wrote:
>> -----Original Message-----
>> From: Martin Kepplinger <martin.kepplinger@puri.sm>
>> Sent: 2020年2月20日 1:37
>> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
>> mathias.nyman@intel.com
>> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Anson Huang
>> <anson.huang@nxp.com>; shawnguo@kernel.org; kernel@pengutronix.de
>> Subject: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
>>
>> From: Li Jun <jun.li@nxp.com>
>>
>> i.MX8MQ USB3 host needs XHCI_MISSING_CAS quirk to warm reset the port to enum the
>> USB3 device plugged in while system sleep, as the port state is stuck in polling
>> mode after resume.
>>
>> Signed-off-by: Li Jun <jun.li@nxp.com>
>> Acked-by: Peter Chen <peter.chen@nxp.com>
>> ---
>>
>> Hi,
>>
>> Because resume from S3 suspend is broken for me on imx8mq, I stumbled upon this
>> patch in NXP's linux tree. (Please note that I'm not the author and I've not yet
>> put my SoB tag under it). This is just a
>> question:
>>
>> This patch (and the docs) clearly is missing in mainline Linux because the imx8mq
>> devicetree description includes it (which does nothing now).
>>
>> I've tested this and this particular addition doesn't fix my problem:
>>
>> [ 84.257538] imx8mq-usb-phy 381f0040.usb-phy: bus resume
>> [ 84.263195] imx8mq-usb-phy 382f0040.usb-phy: bus resume
>> [ 84.268898] dwc3 38100000.usb: driver resume
>>
>> during resume from S3 suspend, here it still hangs.
>
> Is your problem a system hang? If yes, this may another issue,
> where the hang happens? dwc3_resume_common()?
exactly! I followed to the point it hangs once again and it's
dwc3_core_init() called from dwc3_resume_common()'s "OTG" case.
Specifically, dwc3_writel() is what I don't get past:
https://elixir.bootlin.com/linux/v5.6-rc2/source/drivers/usb/dwc3/core.c#L934
do you have an idea why this writel() hangs?
>
> The question patch is to give a warm reset for connected USB
> device if the link state is not connect/CAS after system resume,
> otherwise host will wait 2s for device appear:
>
> [ 44.834831] usb 2-1: Waited 2000ms for CONNECT
> ...
> [ 45.055718] PM: resume devices took 3.132 seconds
>
> I will post this patch and doc(to be updated) to upstream later.
>
ok, good, thanks,
martin
^ permalink raw reply
* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Janosch Frank @ 2020-02-20 11:42 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220123953.5b0272a4.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 3459 bytes --]
On 2/20/20 12:39 PM, Cornelia Huck wrote:
> On Thu, 20 Feb 2020 12:24:23 +0100
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> On 2/20/20 11:48 AM, Cornelia Huck wrote:
>>> On Fri, 14 Feb 2020 10:16:25 -0500
>>> Janosch Frank <frankja@linux.ibm.com> wrote:
>>>
>>>> Migration is not yet supported.
>>>>
>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>> ---
>>>> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>>> index 5fa4372083..d64724af91 100644
>>>> --- a/hw/s390x/s390-virtio-ccw.c
>>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>>> @@ -42,6 +42,9 @@
>>>> #include "hw/s390x/tod.h"
>>>> #include "sysemu/sysemu.h"
>>>> #include "hw/s390x/pv.h"
>>>> +#include "migration/blocker.h"
>>>> +
>>>> +static Error *pv_mig_blocker;
>>>>
>>>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>>>> {
>>>> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
>>>> CPUState *cs, *t;
>>>> S390CPU *cpu;
>>>> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
>>>> + static Error *local_err;
>>>>
>>>> /* get the reset parameters, reset them once done */
>>>> s390_ipl_get_reset_request(&cs, &reset_type);
>>>> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
>>>> }
>>>> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
>>>>
>>>> + if (!pv_mig_blocker) {
>>>> + error_setg(&pv_mig_blocker,
>>>> + "protected VMs are currently not migrateable.");
>>>> + }
>>>> + migrate_add_blocker(pv_mig_blocker, &local_err);
>>>
>>> If I'm not lost in the context, that's during PV_RESET. I'm a bit
>>> confused why you'd add the blocker here?
>>
>> Where would you want me to add it?
>> It's here where we switch into secure mode and I need to block before
>> switching and unblock if it fails.
>>
>> When having the blocker in diag.c, I'd have a hard time unblocking on a
>> PV switch fail.
>>
>>>
>>>> + if (local_err) {
>>>> + error_report_err(local_err);
>>>> + error_free(pv_mig_blocker);
>>>> + exit(1);
>>>
>>> Why the exit()? Can't you fail the call?
>>
>> Well, if that fails and we go protected, I wouldn't be protected agains
>> migrations, right?
>
> No, I meant not go protected, if that's possible.
That would be an option, now that we have a proper d308 rc for such a thing.
Will add!
>
>>
>>>
>>>> + }
>>>> +
>>>> if (s390_machine_pv_secure(ms)) {
>
> Ok, I think what confuses me is this call: it reads as if you actually
> tear down things if the machine is secure. Call it
> s390_machine_pv_make_secure() to make sure it is actively doing
> something and not checking a previously set value?
Ok, will use something along these lines
>
>>>> CPU_FOREACH(t) {
>>>> s390_pv_vcpu_destroy(t);
>>>> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
>>>> ms->pv = false;
>>>>
>>>> s390_machine_inject_pv_error(cs);
>>>> + migrate_del_blocker(pv_mig_blocker);
>>>> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>>>> return;
>>>> }
>>>
>>>
>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [Buildroot] [PATCH v3 1/2] support/scripts/pkg-stats: add support for CVE reporting
From: Peter Korsgaard @ 2020-02-20 11:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <97bf24b6-a272-3707-b825-676c9410d60a@railnova.eu>
>>>>> "Titouan" == Titouan Christophe <titouan.christophe@railnova.eu> writes:
Hi,
> I tried to evaluate how much memory the NVD JSON files actually use
> when loaded as Python objects. To do that, I used the function given
> here:
> https://goshippo.com/blog/measure-real-size-any-python-object/.
> I used the file for the year 2018 as example. This file weights 10MB
> in compressed form, and 254MB when uncompressed. I then call the
> function get_size on
> json.load(gzip.GzipFile("nvdcve-1.0-2018.json.gz"))
> In Python 2.7, the total size used is as high as 1531882276 Bytes (or
> ~1.5GB) ! The same test in Python 3.6 gives me 718038090 Bytes
> (~718MB).
Wow!
>>
>> I did a full run to verify these findings, observing the free memory with 'top'.
>> Even though this is not a fully scientific method, the 'used' memory
>> before was ~4800 MB and while the CVE parsing was ongoing I saw peaks
>> up to ~7900 MB. So yes, it seems there is a large memory footprint.
>> As my machine has enough RAM, the analysis does complete and results
>> seem correct.
>>
>>
>> This seems to be caused mostly by the fact that we load the entire
>> json file in memory.
>> As a test, I just loaded the file from an interactive python session.
> I guess we should then process the CVE files in streaming. This is
> quite easy to do in the CVE.read_nvd_dir() method. I'll give it a try
> today.
Yes, should not be too bad as we process the CVEs one at a time. What
will you use? ijson?
--
Bye, Peter Korsgaard
^ permalink raw reply
* RE: [PATCH net] gianfar: Don't force RGMII mode after reset, use defaults
From: Claudiu Manoil @ 2020-02-20 11:42 UTC (permalink / raw)
To: Daniel Walker (danielwa)
Cc: HEMANT RAMDASI (hramdasi), David S . Miller,
netdev@vger.kernel.org,
Sathish Jarugumalli -X (sjarugum - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco)
In-Reply-To: <20200219185747.GK24043@zorba>
>-----Original Message-----
>From: Daniel Walker (danielwa) <danielwa@cisco.com>
>Sent: Wednesday, February 19, 2020 8:58 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: HEMANT RAMDASI (hramdasi) <hramdasi@cisco.com>; David S . Miller
><davem@davemloft.net>; netdev@vger.kernel.org; Sathish Jarugumalli -X
>(sjarugum - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco)
><sjarugum@cisco.com>
>Subject: Re: [PATCH net] gianfar: Don't force RGMII mode after reset, use
>defaults
>
>On Wed, Nov 13, 2019 at 04:01:39PM +0000, Claudiu Manoil wrote:
>> >-----Original Message-----
>> >From: HEMANT RAMDASI (hramdasi) <hramdasi@cisco.com>
>> [..]
>> >
>> >>> This bit must be set when in half-duplex mode (MACCFG2[Full_Duplex]
>is cleared).
>> >>
>> >> Should the bit be clear when in full duplex or it does not matter?
>> >>
>> >
>> >> From my tests, in full duplex mode small frames won't get padded if
>> >> this bit is disabled, and will be counted as undersize frames and
>> >> dropped. So this bit needs to be set in full duplex mode to get packets
>smaller than 64B past the MAC (w/o software padding).
>> >
>> >This is little strange as we do not see this problem on all pkt type,
>> >icmp passes well and we observed issue with tftp ack.
>>
>> I tested on a 1Gbit (full duplex) link, and ARP and small ICMP ipv4
>> packets were not passing with the PAD_CRC bit disabled.
>
>
>Have you looked into this patch any further ?
>
Hi,
I have an idea on how to parameterize the interface mode setting.
Let me try a patch and if it passes on my boards I'll send it as v2.
^ permalink raw reply
* Re: [Xen-devel] [PATCH 4/5] libxl/PCI: pass correct "hotplug" argument to libxl__device_pci_setdefault()
From: Wei Liu @ 2020-02-20 11:41 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <c7adfa84-2310-3d1d-a6db-574a10247380@suse.com>
On Tue, Feb 18, 2020 at 04:47:27PM +0100, Jan Beulich wrote:
> Uniformly passing "false" can't be right, but has been benign because of
> the function not using this parameter.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH 5.6] mt76: fix array overflow on receiving too many fragments for a packet
From: Felix Fietkau @ 2020-02-20 11:41 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, stable
If the hardware receives an oversized packet with too many rx fragments,
skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
This becomes especially visible if it corrupts the freelist pointer of
a slab page.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/dma.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 6173c80189ba..1847f55e199b 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -447,10 +447,13 @@ mt76_add_fragment(struct mt76_dev *dev, struct mt76_queue *q, void *data,
struct page *page = virt_to_head_page(data);
int offset = data - page_address(page);
struct sk_buff *skb = q->rx_head;
+ struct skb_shared_info *shinfo = skb_shinfo(skb);
- offset += q->buf_offset;
- skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset, len,
- q->buf_size);
+ if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) {
+ offset += q->buf_offset;
+ skb_add_rx_frag(skb, shinfo->nr_frags, page, offset, len,
+ q->buf_size);
+ }
if (more)
return;
--
2.24.0
^ permalink raw reply related
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
From: Patchwork @ 2020-02-20 11:41 UTC (permalink / raw)
To: Christian König; +Cc: intel-gfx
In-Reply-To: <20200217154509.2265-1-christian.koenig@amd.com>
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16603_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16603_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16603_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16603_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_balancer@hang:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balancer@hang.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@gem_exec_balancer@hang.html
Known issues
------------
Here are the changes found in Patchwork_16603_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb6/igt@gem_busy@busy-vcs1.html
* igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_schedule@pi-shared-iova-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb4/igt@gem_exec_schedule@pi-shared-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gem_exec_suspend@basic-s3:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) +2 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl4/igt@gem_exec_suspend@basic-s3.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl4/igt@gem_exec_suspend@basic-s3.html
* igt@gem_partial_pwrite_pread@reads-uncached:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_partial_pwrite_pread@reads-uncached.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@gem_partial_pwrite_pread@reads-uncached.html
* igt@i915_selftest@live_gt_heartbeat:
- shard-skl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#112406])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl7/igt@i915_selftest@live_gt_heartbeat.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl8/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_gt_lrc:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1233])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb2/igt@i915_selftest@live_gt_lrc.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#488])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_flip@flip-vs-suspend.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl1/igt@kms_flip@flip-vs-suspend.html
- shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@kms_flip@flip-vs-suspend.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl2/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#49])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][27] -> [FAIL][28] ([fdo#108145])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#108145] / [i915#265])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109441]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][33] -> [SKIP][34] ([fdo#109276]) +21 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@prime_busy@hang-bsd2.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb7/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [FAIL][35] ([i915#679]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [INCOMPLETE][37] ([fdo#103665]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_eio@in-flight-suspend.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl1/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][39] ([fdo#112146]) -> [PASS][40] +2 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb3/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [SKIP][41] ([fdo#109276]) -> [PASS][42] +13 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb3/igt@gem_exec_schedule@independent-bsd2.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_exec_schedule@independent-bsd2.html
* igt@gem_exec_store@cachelines-vcs1:
- shard-iclb: [SKIP][43] ([fdo#112080]) -> [PASS][44] +7 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_store@cachelines-vcs1.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_exec_store@cachelines-vcs1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][45] ([i915#644]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-glk1/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-apl: [FAIL][47] ([i915#644]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl3/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][49] ([fdo#109271]) -> [PASS][50] +1 similar issue
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-snb6/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][51] ([i915#180]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][53] ([i915#79]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][55] ([i915#668]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* {igt@kms_hdr@bpc-switch-dpms}:
- shard-skl: [FAIL][57] ([i915#1188]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_hdr@bpc-switch-dpms.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][59] ([i915#180]) -> [PASS][60] +1 similar issue
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][61] ([fdo#108145]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][63] ([fdo#108145] / [i915#265]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][65] ([i915#173]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@no_drrs.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][67] ([fdo#109441]) -> [PASS][68] +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][69] ([i915#31]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@kms_setmode@basic.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl6/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][71] ([i915#69]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl5/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][73] ([fdo#112271] / [i915#51]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl4/igt@perf@short-reads.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][75] ([i915#831]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][77] ([fdo#112080]) -> [FAIL][78] ([IGT#28])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][79] ([i915#818]) -> [FAIL][80] ([i915#694]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_tiled_blits@normal.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@gem_tiled_blits@normal.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[IGT#5]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[fdo#112406]: https://bugs.freedesktop.org/show_bug.cgi?id=112406
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16603
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16603: 9d3bcd8ee6f9b86d423d0135b12a1e8cb81d2c5f @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Cornelia Huck @ 2020-02-20 11:39 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <fbcacbf4-75d6-55f9-2ad3-6cd47b400fce@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]
On Thu, 20 Feb 2020 12:24:23 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:
> On 2/20/20 11:48 AM, Cornelia Huck wrote:
> > On Fri, 14 Feb 2020 10:16:25 -0500
> > Janosch Frank <frankja@linux.ibm.com> wrote:
> >
> >> Migration is not yet supported.
> >>
> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> >> ---
> >> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >> index 5fa4372083..d64724af91 100644
> >> --- a/hw/s390x/s390-virtio-ccw.c
> >> +++ b/hw/s390x/s390-virtio-ccw.c
> >> @@ -42,6 +42,9 @@
> >> #include "hw/s390x/tod.h"
> >> #include "sysemu/sysemu.h"
> >> #include "hw/s390x/pv.h"
> >> +#include "migration/blocker.h"
> >> +
> >> +static Error *pv_mig_blocker;
> >>
> >> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
> >> {
> >> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
> >> CPUState *cs, *t;
> >> S390CPU *cpu;
> >> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
> >> + static Error *local_err;
> >>
> >> /* get the reset parameters, reset them once done */
> >> s390_ipl_get_reset_request(&cs, &reset_type);
> >> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
> >> }
> >> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
> >>
> >> + if (!pv_mig_blocker) {
> >> + error_setg(&pv_mig_blocker,
> >> + "protected VMs are currently not migrateable.");
> >> + }
> >> + migrate_add_blocker(pv_mig_blocker, &local_err);
> >
> > If I'm not lost in the context, that's during PV_RESET. I'm a bit
> > confused why you'd add the blocker here?
>
> Where would you want me to add it?
> It's here where we switch into secure mode and I need to block before
> switching and unblock if it fails.
>
> When having the blocker in diag.c, I'd have a hard time unblocking on a
> PV switch fail.
>
> >
> >> + if (local_err) {
> >> + error_report_err(local_err);
> >> + error_free(pv_mig_blocker);
> >> + exit(1);
> >
> > Why the exit()? Can't you fail the call?
>
> Well, if that fails and we go protected, I wouldn't be protected agains
> migrations, right?
No, I meant not go protected, if that's possible.
>
> >
> >> + }
> >> +
> >> if (s390_machine_pv_secure(ms)) {
Ok, I think what confuses me is this call: it reads as if you actually
tear down things if the machine is secure. Call it
s390_machine_pv_make_secure() to make sure it is actively doing
something and not checking a previously set value?
> >> CPU_FOREACH(t) {
> >> s390_pv_vcpu_destroy(t);
> >> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
> >> ms->pv = false;
> >>
> >> s390_machine_inject_pv_error(cs);
> >> + migrate_del_blocker(pv_mig_blocker);
> >> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
> >> return;
> >> }
> >
> >
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] Add Cadence XSPI driver
From: Mark Brown @ 2020-02-20 11:40 UTC (permalink / raw)
To: Konrad Kociolek; +Cc: linux-kernel, linux-spi
In-Reply-To: <20200220082354.GA15619@global.cadence.com>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, Feb 20, 2020 at 09:23:56AM +0100, Konrad Kociolek wrote:
> The 02/10/2020 19:16, Mark Brown wrote:
> > > # Add new SPI master controllers in alphabetical order above this line
> > Please keep Kconfig and Makefile alphabetically sorted as the comment in
> > the context from the diff says. :/
> What I see is Kconfig is first and Makefile is second file in diff,
> according to:
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> Is that wrong?
Please keep the *contents* of the files Kconfig and Makefile
alphabetically sorted as the comment in the context from the diff says.
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id cdns_xspi_of_match[] = {
> > > + {
> > > + .compatible = "cdns,xspi-nor-fpga",
> > > + },
> > Why -fpga?
> This is because this driver was tested only on FPGA board.
> This driver was not tested for ASIC version as PHY
> initialization algorithm is differ.
So there will need to be a separate compatible for any silicon
integrations? Will that always be the same for all silicon integrations
or should we have properties for the PHY type?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] Add Cadence XSPI driver
From: Mark Brown @ 2020-02-20 11:40 UTC (permalink / raw)
To: Konrad Kociolek
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200220082354.GA15619-3ZcXq++oLud4Zxsjz0bX7NBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, Feb 20, 2020 at 09:23:56AM +0100, Konrad Kociolek wrote:
> The 02/10/2020 19:16, Mark Brown wrote:
> > > # Add new SPI master controllers in alphabetical order above this line
> > Please keep Kconfig and Makefile alphabetically sorted as the comment in
> > the context from the diff says. :/
> What I see is Kconfig is first and Makefile is second file in diff,
> according to:
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> Is that wrong?
Please keep the *contents* of the files Kconfig and Makefile
alphabetically sorted as the comment in the context from the diff says.
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id cdns_xspi_of_match[] = {
> > > + {
> > > + .compatible = "cdns,xspi-nor-fpga",
> > > + },
> > Why -fpga?
> This is because this driver was tested only on FPGA board.
> This driver was not tested for ASIC version as PHY
> initialization algorithm is differ.
So there will need to be a separate compatible for any silicon
integrations? Will that always be the same for all silicon integrations
or should we have properties for the PHY type?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency for TYPEC_HD3SS3220
From: Marian-Cristian Rotariu @ 2020-02-20 11:40 UTC (permalink / raw)
To: Pavel Machek; +Cc: cip-dev@lists.cip-project.org
In-Reply-To: <20200219081627.GE31996@amd>
Hi!
> -----Original Message-----
> From: Pavel Machek <pavel@denx.de>
> Sent: 19 February 2020 08:16
> To: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Cc: cip-dev@lists.cip-project.org
> Subject: Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency
> for TYPEC_HD3SS3220
>
> On Tue 2020-02-18 14:05:14, Marian-Cristian Rotariu wrote:
> > From: Mao Wenan <maowenan@huawei.com>
> >
> > commit da4b5d18dd949abdda7c8ea76c9483b5edd49616 upstream.
> >
> > If CONFIG_TYPEC_HD3SS3220=y, CONFIG_USB_ROLE_SWITCH=m, below
> errors
> > can be found:
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_remove':
> > hd3ss3220.c:(.text+0x64): undefined reference to `usb_role_switch_put'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_dr_set':
> > hd3ss3220.c:(.text+0x154): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_set_role':
> > hd3ss3220.c:(.text+0x294): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x2f4): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x348): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x390): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_probe':
> > hd3ss3220.c:(.text+0x5e8): undefined reference to
> `fwnode_usb_role_switch_get'
> > hd3ss3220.c:(.text+0x8a4): undefined reference to `usb_role_switch_put'
> > make: *** [vmlinux] Error 1
>
> I guess it is okay here, but for more serious bugs it would be nice to merge
> the buggy patch with a fix -- not to break bisect.
I kind of forgot about bisect. I was mostly focused on keeping the original patches
from upstream (in this case, it is more about the commit message as the fix is trivial).
I will send this patch in v2 also, since you mostly agreed with it. Please let me know
if otherwise.
Cheers,
Marian
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ 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.