* Re: [PATCH 3/5] net: thunderx: Fix configuration of L3/L4 length checking
From: Corentin Labbe @ 2016-11-14 12:33 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, Sunil Goutham, linux-kernel, linux-arm-kernel
In-Reply-To: <1479120886-13425-4-git-send-email-sunil.kovvuri@gmail.com>
On Mon, Nov 14, 2016 at 04:24:44PM +0530, sunil.kovvuri@gmail.com wrote:
> From: Sunil Goutham <sgoutham@cavium.com>
>
> This patch fixes enabling of HW verification of L3/L4 length and
> TCP/UDP checksum which is currently being cleared. Also fixed VLAN
> stripping config which is being cleared when multiqset is enabled.
>
> Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> index f0e0ca6..3050177 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
> @@ -538,9 +538,12 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
> mbx.rq.cfg = (1ULL << 62) | (RQ_CQ_DROP << 8);
> nicvf_send_msg_to_pf(nic, &mbx);
>
> - nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0, 0x00);
> - if (!nic->sqs_mode)
> + if (!nic->sqs_mode && (qidx == 0)) {
> + /* Enable checking L3/L4 length and TCP/UDP checksums */
> + nicvf_queue_reg_write(nic, NIC_QSET_RQ_GEN_CFG, 0,
> + ((1 << 24) | (1 << 23) | (1 << 21)));
Hello
You could use the BIT() macro here
Regards
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support
From: Vincent Palatin @ 2016-11-14 12:33 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel, Paolo Bonzini
In-Reply-To: <534ec708-1466-df02-37f0-14df6aba2fd0@weilnetz.de>
On Mon, Nov 14, 2016 at 1:21 PM, Stefan Weil <sw@weilnetz.de> wrote:
> Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
>> I took a stab at trying to rebase/upstream the support for Intel HAXM.
>> (Hardware Accelerated Execution Manager).
>> Intel HAX is kernel-based hardware acceleration module for Windows and MacOSX.
>>
>> I have based my work on the last version of the source code I found:
>> the emu-2.2-release branch in the external/qemu-android repository as used by
>> the Android emulator.
>> In patch 2/5, I have forward-ported the core HAX code mostly unmodified from
>> there, I just did some minor touch up to make it build and run properly,
>> and fixed the style issues to go through checkpatch.pl.
>> I have not included the Darwin support.
>> It might contain some outdated constructs and probably requires more
>> attention (thus the 'RFC' for this patchset).
>>
>> In patch 3/5, I'm removing a good chunk of the support for CPUs without UG mode
>> as advised by Paolo to simplify the initial version.
>>
>> In patch 5/5, I have put the plumbing into the QEMU code base, I did some clean
>> up there and it is reasonably intrusive: i.e.
>> Makefile.target | 1 +
>> configure | 18 ++++++++++
>> cpus.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++-
>> exec.c | 16 +++++++++
>> hw/intc/apic_common.c | 3 +-
>> include/qom/cpu.h | 5 +++
>> include/sysemu/hw_accel.h | 9 +++++
>> qemu-options.hx | 11 ++++++
>> target-i386/Makefile.objs | 7 ++++
>> vl.c | 15 ++++++--
>> 10 files changed, 167 insertions(+), 5 deletions(-)
>>
>> The qemu_cpu_kick_thread mess in cpus.c is probably still not perfact though.
>>
>> The patch 1/5 just extracts from KVM specific header the cpu_synchronize_
>> functions that HAX is also using.
>>
>> I have tested the end result on a Windows 10 Pro machine (with UG support)
>> with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to
>> exercise various code paths. It looks stable.
>> I also did a quick regression testing of the integration by running a Linux
>> build with KVM enabled.
>
>
> A full build for Windows needs the patch below to
> fix missing declarations, otherwise it fails with
> compiler warnings and linker errors.
Thanks for filing the gaps. That's very helpful !
Do you mind if I merge it with your SoB into Patch 1/5 where it belongs ?
or do you prefer keeping it as a separate patch ?
> From 91481639a1005ed3278eb55c77c99bb1bcc135ce Mon Sep 17 00:00:00 2001
> From: Stefan Weil <sw@weilnetz.de>
> Date: Mon, 14 Nov 2016 13:09:53 +0100
> Subject: [PATCH] Fix include statements for HAXM support
>
> We need sysemu/hw_accel.h. As sysemu/hw_accel.h already includes
> sysemu/kvm.h, that one can be removed.
>
> Signed-off-by: Stefan Weil <sw@weilnetz.de>
> ---
> hw/ppc/pnv_xscom.c | 2 +-
> hw/ppc/ppce500_spin.c | 4 ++--
> hw/ppc/spapr.c | 2 +-
> hw/ppc/spapr_hcall.c | 2 +-
> hw/s390x/s390-pci-inst.c | 1 +
> target-ppc/mmu-hash64.c | 2 +-
> target-ppc/translate_init.c | 2 +-
> target-s390x/gdbstub.c | 1 +
> 8 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/pnv_xscom.c b/hw/ppc/pnv_xscom.c
> index 5aaa264..abcb85d 100644
> --- a/hw/ppc/pnv_xscom.c
> +++ b/hw/ppc/pnv_xscom.c
> @@ -20,7 +20,7 @@
> #include "qapi/error.h"
> #include "hw/hw.h"
> #include "qemu/log.h"
> -#include "sysemu/kvm.h"
> +#include "sysemu/hw_accel.h"
> #include "target-ppc/cpu.h"
> #include "hw/sysbus.h"
>
> diff --git a/hw/ppc/ppce500_spin.c b/hw/ppc/ppce500_spin.c
> index cf958a9..eb219ab 100644
> --- a/hw/ppc/ppce500_spin.c
> +++ b/hw/ppc/ppce500_spin.c
> @@ -29,9 +29,9 @@
>
> #include "qemu/osdep.h"
> #include "hw/hw.h"
> -#include "sysemu/sysemu.h"
> #include "hw/sysbus.h"
> -#include "sysemu/kvm.h"
> +#include "sysemu/hw_accel.h"
> +#include "sysemu/sysemu.h"
> #include "e500.h"
>
> #define MAX_CPUS 32
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 0cbab24..174f4d3 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -36,7 +36,7 @@
> #include "sysemu/device_tree.h"
> #include "sysemu/block-backend.h"
> #include "sysemu/cpus.h"
> -#include "sysemu/kvm.h"
> +#include "sysemu/hw_accel.h"
> #include "kvm_ppc.h"
> #include "migration/migration.h"
> #include "mmu-hash64.h"
> diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
> index 9a9bedf..b2a8e48 100644
> --- a/hw/ppc/spapr_hcall.c
> +++ b/hw/ppc/spapr_hcall.c
> @@ -1,5 +1,6 @@
> #include "qemu/osdep.h"
> #include "qapi/error.h"
> +#include "sysemu/hw_accel.h"
> #include "sysemu/sysemu.h"
> #include "qemu/log.h"
> #include "cpu.h"
> @@ -9,7 +10,6 @@
> #include "mmu-hash64.h"
> #include "cpu-models.h"
> #include "trace.h"
> -#include "sysemu/kvm.h"
> #include "kvm_ppc.h"
> #include "hw/ppc/spapr_ovec.h"
>
> diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
> index 0864d9b..4d0775c 100644
> --- a/hw/s390x/s390-pci-inst.c
> +++ b/hw/s390x/s390-pci-inst.c
> @@ -18,6 +18,7 @@
> #include "s390-pci-bus.h"
> #include "exec/memory-internal.h"
> #include "qemu/error-report.h"
> +#include "sysemu/hw_accel.h"
>
> /* #define DEBUG_S390PCI_INST */
> #ifdef DEBUG_S390PCI_INST
> diff --git a/target-ppc/mmu-hash64.c b/target-ppc/mmu-hash64.c
> index fdb7a78..0efc8c6 100644
> --- a/target-ppc/mmu-hash64.c
> +++ b/target-ppc/mmu-hash64.c
> @@ -23,7 +23,7 @@
> #include "exec/exec-all.h"
> #include "exec/helper-proto.h"
> #include "qemu/error-report.h"
> -#include "sysemu/kvm.h"
> +#include "sysemu/hw_accel.h"
> #include "kvm_ppc.h"
> #include "mmu-hash64.h"
> #include "exec/log.h"
> diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
> index 208fa1e..1a049af 100644
> --- a/target-ppc/translate_init.c
> +++ b/target-ppc/translate_init.c
> @@ -21,10 +21,10 @@
> #include "qemu/osdep.h"
> #include "disas/bfd.h"
> #include "exec/gdbstub.h"
> -#include "sysemu/kvm.h"
> #include "kvm_ppc.h"
> #include "sysemu/arch_init.h"
> #include "sysemu/cpus.h"
> +#include "sysemu/hw_accel.h"
> #include "cpu-models.h"
> #include "mmu-hash32.h"
> #include "mmu-hash64.h"
> diff --git a/target-s390x/gdbstub.c b/target-s390x/gdbstub.c
> index 3d223de..3c652fb 100644
> --- a/target-s390x/gdbstub.c
> +++ b/target-s390x/gdbstub.c
> @@ -23,6 +23,7 @@
> #include "exec/exec-all.h"
> #include "exec/gdbstub.h"
> #include "qemu/bitops.h"
> +#include "sysemu/hw_accel.h"
>
> int s390_cpu_gdb_read_register(CPUState *cs, uint8_t *mem_buf, int n)
> {
> --
> 2.10.2
>
^ permalink raw reply
* Re: [patch] [media] Input: synaptics-rmi4 - unlock on error
From: Hans Verkuil @ 2016-11-14 12:24 UTC (permalink / raw)
To: Dan Carpenter, Dmitry Torokhov, Nick Dyer
Cc: Hans Verkuil, Mauro Carvalho Chehab, linux-input, kernel-janitors
In-Reply-To: <20161014171427.GA21917@mwanda>
On 10/14/2016 07:14 PM, Dan Carpenter wrote:
> We should unlock before returning on this error path.
>
> Fixes: 3a762dbd5347 ('[media] Input: synaptics-rmi4 - add support for F54 diagnostics')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Dmitry, will you pick this up? It probably should to in for 4.9.
Even though it was prefixed with [media] it wasn't send to linux-media, so it never
ended up in our patchwork.
If you don't want to process this patch, then let me know and I'll take it.
Regards,
Hans
>
> diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
> index cf805b9..2e934ae 100644
> --- a/drivers/input/rmi4/rmi_f54.c
> +++ b/drivers/input/rmi4/rmi_f54.c
> @@ -200,7 +200,7 @@ static int rmi_f54_request_report(struct rmi_function *fn, u8 report_type)
>
> error = rmi_write(rmi_dev, fn->fd.command_base_addr, F54_GET_REPORT);
> if (error < 0)
> - return error;
> + goto unlock;
>
> init_completion(&f54->cmd_done);
>
> @@ -209,9 +209,10 @@ static int rmi_f54_request_report(struct rmi_function *fn, u8 report_type)
>
> queue_delayed_work(f54->workqueue, &f54->work, 0);
>
> +unlock:
> mutex_unlock(&f54->data_mutex);
>
> - return 0;
> + return error;
> }
>
> static size_t rmi_f54_get_report_size(struct f54_data *f54)
>
^ permalink raw reply
* [Qemu-devel] [PATCH 0/3] add cleanup operation in handle/proxy backend
From: Li Qiang @ 2016-11-14 12:32 UTC (permalink / raw)
To: groug, qemu-devel; +Cc: liqiang6-s, Li Qiang
From: Li Qiang <liq3ea@gmail.com>
Currently, the backend of VirtFS doesn't have a cleanup
function. This will leak some resources in handle and proxy
backend driver. This patchset addresses this issue.
Li Qiang (3):
9pfs: add cleanup operation in FileOperations
9pfs: add cleanup operation for handle backend driver
9pfs: add cleanup operation for proxy backend driver
fsdev/file-op-9p.h | 1 +
hw/9pfs/9p-handle.c | 8 ++++++++
hw/9pfs/9p-proxy.c | 10 ++++++++++
hw/9pfs/9p.c | 3 +++
4 files changed, 22 insertions(+)
--
1.8.3.1
^ permalink raw reply
* [Qemu-devel] [PATCH 2/3] 9pfs: add cleanup operation for handle backend driver
From: Li Qiang @ 2016-11-14 12:32 UTC (permalink / raw)
To: groug, qemu-devel; +Cc: liqiang6-s, Li Qiang
In-Reply-To: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
From: Li Qiang <liq3ea@gmail.com>
In the init operation of handle backend dirver, it allocates a
handle_data struct and opens a mount file. We should free these
resources when the 9pfs device is unrealized. This is what this
patch does.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
---
hw/9pfs/9p-handle.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/hw/9pfs/9p-handle.c b/hw/9pfs/9p-handle.c
index 3d77594..9b50f40 100644
--- a/hw/9pfs/9p-handle.c
+++ b/hw/9pfs/9p-handle.c
@@ -649,6 +649,13 @@ out:
return ret;
}
+static void handle_cleanup(FsContext *ctx)
+{
+ struct handle_data *data = ctx->private;
+ close(data->mountfd);
+ g_free(data);
+}
+
static int handle_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse)
{
const char *sec_model = qemu_opt_get(opts, "security_model");
@@ -671,6 +678,7 @@ static int handle_parse_opts(QemuOpts *opts, struct FsDriverEntry *fse)
FileOperations handle_ops = {
.parse_opts = handle_parse_opts,
.init = handle_init,
+ .cleanup = handle_cleanup,
.lstat = handle_lstat,
.readlink = handle_readlink,
.close = handle_close,
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/3] 9pfs: add cleanup operation in FileOperations
From: Li Qiang @ 2016-11-14 12:32 UTC (permalink / raw)
To: groug, qemu-devel; +Cc: liqiang6-s, Li Qiang
In-Reply-To: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
From: Li Qiang <liq3ea@gmail.com>
Currently, the backend of VirtFS doesn't have a cleanup
function. This will lead resource leak issues if the backed
driver allocates resources. This patch addresses this issue.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
---
fsdev/file-op-9p.h | 1 +
hw/9pfs/9p.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
index 6db9fea..a56dc84 100644
--- a/fsdev/file-op-9p.h
+++ b/fsdev/file-op-9p.h
@@ -100,6 +100,7 @@ struct FileOperations
{
int (*parse_opts)(QemuOpts *, struct FsDriverEntry *);
int (*init)(struct FsContext *);
+ void (*cleanup)(struct FsContext *);
int (*lstat)(FsContext *, V9fsPath *, struct stat *);
ssize_t (*readlink)(FsContext *, V9fsPath *, char *, size_t);
int (*chmod)(FsContext *, V9fsPath *, FsCred *);
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index aea7e9d..166b5a7 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3532,6 +3532,9 @@ void v9fs_device_unrealize_common(V9fsState *s, Error **errp)
{
g_free(s->ctx.fs_root);
g_free(s->tag);
+ if (s->ops->cleanup) {
+ s->ops->cleanup(&s->ctx);
+ }
}
typedef struct VirtfsCoResetData {
--
1.8.3.1
^ permalink raw reply related
* [Qemu-devel] [PATCH 3/3] 9pfs: add cleanup operation for proxy backend driver
From: Li Qiang @ 2016-11-14 12:32 UTC (permalink / raw)
To: groug, qemu-devel; +Cc: liqiang6-s, Li Qiang
In-Reply-To: <1479126778-125867-1-git-send-email-Qiang(liqiang6-s@360.cn)>
From: Li Qiang <liq3ea@gmail.com>
In the init operation of proxy backend dirver, it allocates a
V9fsProxy struct and some other resources. We should free these
resources when the 9pfs device is unrealized. This is what this
patch does.
Signed-off-by: Li Qiang <liq3ea@gmail.com>
---
hw/9pfs/9p-proxy.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/hw/9pfs/9p-proxy.c b/hw/9pfs/9p-proxy.c
index f2417b7..4b22f57 100644
--- a/hw/9pfs/9p-proxy.c
+++ b/hw/9pfs/9p-proxy.c
@@ -1168,9 +1168,19 @@ static int proxy_init(FsContext *ctx)
return 0;
}
+static void proxy_cleanup(FsContext *ctx)
+{
+ V9fsProxy *proxy = ctx->private;
+ close(proxy->sockfd);
+ g_free(proxy->in_iovec.iov_base);
+ g_free(proxy->out_iovec.iov_base);
+ g_free(proxy);
+}
+
FileOperations proxy_ops = {
.parse_opts = proxy_parse_opts,
.init = proxy_init,
+ .cleanup = proxy_cleanup,
.lstat = proxy_lstat,
.readlink = proxy_readlink,
.close = proxy_close,
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] ioctl.h: add missing kernel compatibility header for BUILD_ASSERT
From: David Sterba @ 2016-11-14 12:34 UTC (permalink / raw)
To: Sergei Trofimovich; +Cc: linux-btrfs
In-Reply-To: <20161112221449.0cd3d16b@sf>
On Sat, Nov 12, 2016 at 10:14:49PM +0000, Sergei Trofimovich wrote:
> > > Basically gcc tries to say us BUILD_ASSERT is not visible.
> > >
> > > BUILD_ASSERT lives in kerncompat.h which this change adds.
> >
> > I think including the kerncompat.h is too intrusive here, I've fixed by
> > providing an empty macro if it's not defined. I'll release 4.8.2 soon.
>
> Apologies. I did not test your fix right afterwards. Seems now header is incomplete
> due to missing NULL (gcc-6):
>
> btrfs-progs-v4.8.3 $ gcc -c ioctl.h -o /tmp/a.o
> ioctl.h: In function 'btrfs_err_str':
> ioctl.h:711:11: error: 'NULL' undeclared (first use in this function)
> return NULL;
> ^~~~
> ioctl.h:711:11: note: each undeclared identifier is reported only once for each function it appears in
The ioctl.h file can be included in both C and C++ code, I'd rahter
avoid to ifdef the right definition of NULL, so s/NULL/0/ seems as a
best fix to me.
Compiling with g++ shows other type errors like
ioctl.h:709:5: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
"in progress";
so we'd have to change the type to 'const char*'. I'm not sure how much
breakage this could cause in programs using the header.
^ permalink raw reply
* reproducable oops in btrfs/130 with latests mainline
From: Christoph Hellwig @ 2016-11-14 12:35 UTC (permalink / raw)
To: linux-btrfs
btrfs/130 [ 384.645337] run fstests btrfs/130 at 2016-11-14
12:33:26
[ 384.827333] BTRFS: device fsid bf118b00-e2e0-4a96-a177-765789170093 devid 1 transid 3 /dev/vdc
[ 384.851643] BTRFS info (device vdc): disk space caching is enabled
[ 384.852113] BTRFS info (device vdc): flagging fs with big metadata feature
[ 384.857043] BTRFS info (device vdc): creating UUID tree
[ 384.988347] BTRFS: device fsid 3b92b8c1-295d-4099-8623-d71a3cb270f8 devid 1 transid 3 /dev/vdc
[ 385.001946] BTRFS info (device vdc): disk space caching is enabled
[ 385.002846] BTRFS info (device vdc): flagging fs with big metadata
feature
[ 385.008870] BTRFS info (device vdc): creating UUID tree
[ 416.318581] NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [btrfs:12782]
[ 416.319139] Modules linked in:
[ 416.319366] CPU: 3 PID: 12782 Comm: btrfs Not tainted 4.9.0-rc1 #826
[ 416.319789] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 416.320466] task: ffff8801355a4140 task.stack: ffffc900000a4000
[ 416.320864] RIP: 0010:[<ffffffff816a197d>] [<ffffffff816a197d>] find_parent_nodes+0xb7d/0x1530
[ 416.321455] RSP: 0018:ffffc900000a79b0 EFLAGS: 00000286
[ 416.321811] RAX: ffff88012de45640 RBX: 0000000000000000 RCX: ffffc900000a7a28
[ 416.322285] RDX: ffff88012de45660 RSI: 0000000001ca8000 RDI: ffff88013b803e40
[ 416.322759] RBP: ffffc900000a7ab0 R08: 0000000002400040 R09: ffff88010077a478
[ 416.323317] R10: ffff880127652f70 R11: ffff880127652f08 R12: ffff880000000000
[ 416.323791] R13: 6db6db6db6db6db7 R14: ffff8801295093b0 R15: 0000000000000000
[ 416.324262] FS: 00007f83ef8398c0(0000) GS:ffff88013fd80000(0000) knlGS:0000000000000000
[ 416.324795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 416.325176] CR2: 00007f83ee4dbe38 CR3: 0000000136b56000 CR4: 00000000000006e0
[ 416.325649] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 416.326120] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 416.326590] Stack:
[ 416.326730] 0000000000000000 ffff880102400040 ffff88012a340000 0000000000001063
[ 416.327257] 0000000100000001 ffff88012dd0e800 ffff88012a340000 0000000000000001
[ 416.327780] ffff88012a340000 0000000000000000 ffff88013b803e40 0000000000c40000
[ 416.328304] Call Trace:
[ 416.328475] [<ffffffff816afbe0>] ? changed_cb+0xb70/0xb70
[ 416.328841] [<ffffffff816a2eb7>] iterate_extent_inodes+0xe7/0x270
[ 416.329251] [<ffffffff8165ecf6>] ? release_extent_buffer+0x26/0xc0
[ 416.329657] [<ffffffff8165f266>] ? free_extent_buffer+0x46/0x80
[ 416.330068] [<ffffffff816adb8f>] process_extent+0x69f/0xb00
[ 416.330452] [<ffffffff816af33b>] changed_cb+0x2cb/0xb70
[ 416.330811] [<ffffffff8165fa52>] ? read_extent_buffer+0xe2/0x140
[ 416.331380] [<ffffffff81615e82>] ? btrfs_search_slot_for_read+0xc2/0x1b0
[ 416.331905] [<ffffffff816b0ff7>] btrfs_ioctl_send+0x1187/0x12c0
[ 416.332309] [<ffffffff811de83a>] ? kmem_cache_alloc+0x8a/0x160
[ 416.332704] [<ffffffff81675edc>] btrfs_ioctl+0x7dc/0x21f0
[ 416.333071] [<ffffffff8109076c>] ? flat_send_IPI_mask+0xc/0x10
[ 416.333465] [<ffffffff8108cd6d>] ? default_send_IPI_single+0x2d/0x30
[ 416.333893] [<ffffffff81088e87>] ? native_smp_send_reschedule+0x27/0x40
[ 416.334340] [<ffffffff810f1d3d>] ? resched_curr+0xad/0xb0
[ 416.334706] [<ffffffff811f83db>] do_vfs_ioctl+0x8b/0x5b0
[ 416.335065] [<ffffffff810cba02>] ? _do_fork+0x132/0x390
[ 416.335423] [<ffffffff811f893c>] SyS_ioctl+0x3c/0x70
[ 416.335763] [<ffffffff81df2177>] entry_SYSCALL_64_fastpath+0x1a/0xa9
^ permalink raw reply
* [PATCH] T4240RBD: add device tree entry for W83793
From: Florian Larysch @ 2016-11-14 12:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Florian Larysch
The T4240RDB contains a W83793 hardware monitoring chip. Add a device
tree entry to make the driver attach to it, as the i2c-mpc bus driver
dropped support for class-based instantiation of devices a long time
ago.
Signed-off-by: Florian Larysch <fl@n621.de>
---
arch/powerpc/boot/dts/fsl/t4240rdb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
index cc0a264..b35eea1 100644
--- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
@@ -142,6 +142,10 @@
reg = <0x68>;
interrupts = <0x1 0x1 0 0>;
};
+ hwmon@2f {
+ compatible = "winbond,w83793";
+ reg = <0x2f>;
+ };
};
sdhc@114000 {
--
2.10.2
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support
From: Stefan Weil @ 2016-11-14 12:36 UTC (permalink / raw)
To: Vincent Palatin, qemu-devel
In-Reply-To: <cover.1478863621.git.vpalatin@chromium.org>
Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
[...]
> I have tested the end result on a Windows 10 Pro machine (with UG support)
> with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to
> exercise various code paths. It looks stable.
> I also did a quick regression testing of the integration by running a Linux
> build with KVM enabled.
My test on Windows 7 with HAXM 6.0.4 fails:
$ test/qemu-system-x86_64.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
$ test/qemu-system-i386.exe --enable-hax
HAX is working and emulator runs in fast virt mode.
Unknown hax vcpu return 1
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
I tested debug code (configure --enable-debug && make) based on
latest QEMU from git, this patch series and my include fixes.
Stefan
^ permalink raw reply
* Re: [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-14 12:36 UTC (permalink / raw)
To: Eric Auger, eric.auger.pro-Re5JQEeQqe8AvxtiuMwx3w,
christoffer.dall-QSEj5FYQhm4dnm+yROfE0A, marc.zyngier-5wv7dgnIgG8,
alex.williamson-H+wXaHxf7aLQT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
joro-zLv9SwRftAIdnm+yROfE0A, tglx-hfZtesqFncYOwBW4kG4KsQ,
jason-NLaQJdtUoK4Be96aLqz0jA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: drjones-H+wXaHxf7aLQT0dZR+AlfA, kvm-u79uwXL29TY76Z2rM5mHXA,
punit.agrawal-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
pranav.sawargaonkar-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1478258646-3117-4-git-send-email-eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Eric Auger <eric.auger-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
OK, following the discussion elsewhere I've had a go at the less stupid,
but more involved, version. Thoughts?
Robin.
----->8-----
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
---
drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
include/linux/dma-iommu.h | 6 +++
2 files changed, 100 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..33d66a8273c6 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
- struct iommu_dma_cookie *cookie;
-
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
- if (!cookie)
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
- domain->iova_cookie = cookie;
return 0;
}
EXPORT_SYMBOL(iommu_get_dma_cookie);
/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ struct iommu_dma_cookie *cookie;
+
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!cookie)
+ return -ENOMEM;
+
+ cookie->msi_iova = base;
+ domain->iova_cookie = cookie;
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_msi_cookie);
+
+/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- msi_addr &= ~(phys_addr_t)iova_mask(iovad);
list_for_each_entry(msi_page, &cookie->msi_page_list, list)
if (msi_page->phys == msi_addr)
return msi_page;
@@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- if (!iova)
- goto out_free_page;
-
msi_page->phys = msi_addr;
- msi_page->iova = iova_dma_addr(iovad, iova);
- if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
+
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..d69932474576 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@ int iommu_dma_init(void);
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
2.10.2.dirty
^ permalink raw reply related
* [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-14 12:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478258646-3117-4-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
OK, following the discussion elsewhere I've had a go at the less stupid,
but more involved, version. Thoughts?
Robin.
----->8-----
From: Robin Murphy <robin.murphy@arm.com>
Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
include/linux/dma-iommu.h | 6 +++
2 files changed, 100 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..33d66a8273c6 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
- struct iommu_dma_cookie *cookie;
-
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
- if (!cookie)
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
- domain->iova_cookie = cookie;
return 0;
}
EXPORT_SYMBOL(iommu_get_dma_cookie);
/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ struct iommu_dma_cookie *cookie;
+
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!cookie)
+ return -ENOMEM;
+
+ cookie->msi_iova = base;
+ domain->iova_cookie = cookie;
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_msi_cookie);
+
+/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- msi_addr &= ~(phys_addr_t)iova_mask(iovad);
list_for_each_entry(msi_page, &cookie->msi_page_list, list)
if (msi_page->phys == msi_addr)
return msi_page;
@@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- if (!iova)
- goto out_free_page;
-
msi_page->phys = msi_addr;
- msi_page->iova = iova_dma_addr(iovad, iova);
- if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
+
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..d69932474576 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@ int iommu_dma_init(void);
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
2.10.2.dirty
^ permalink raw reply related
* Re: [PATCH] arm: dts: Add pnor label for wspoon and romulus
From: Cédric Le Goater @ 2016-11-14 12:29 UTC (permalink / raw)
To: Joel Stanley; +Cc: OpenBMC Maillist, Cyril Bur
In-Reply-To: <CACPK8XeUh65FM9OC45FZnwVSwLN1ZF7Z5zfasNurHzdBfVKGvA@mail.gmail.com>
On 11/14/2016 06:21 AM, Joel Stanley wrote:
> On Fri, Nov 11, 2016 at 6:32 PM, Cédric Le Goater <clg@kaod.org> wrote:
>> So, according to :
>>
>> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>> Documentation/devicetree/bindings/mtd/partitions.txt
>>
>> we can not label the flash module node but we can label the
>> partition instead. Would a patch like below fit the need ?
>> Here is what we get on a palmetto and an EVB, the approach
>> are different.
>
> Okay. That's annoying.
>
> Is there a reason we can't coax the ast2400 version to call it just
> 'pnor' as well?
none. that was a proposal for different solutions.
>>
>> root@palmetto:~# cat /proc/mtd
>> dev: size erasesize name
>> mtd0: 00060000 00001000 "u-boot"
>> mtd1: 00020000 00001000 "u-boot-env"
>> mtd2: 00280000 00001000 "kernel"
>> mtd3: 001c0000 00001000 "initramfs"
>> mtd4: 01740000 00001000 "rofs"
>> mtd5: 00400000 00001000 "rwfs"
>> mtd6: 02000000 00010000 "1e630000.spi:pnor@0"
we can do a strstr when parsing /proc/mtd. This is probably the
best solution to simply handle compatibility.
>> root@evb-ast2500:~# cat /proc/mtd
>> dev: size erasesize name
>> mtd0: 00060000 00001000 "u-boot"
>> mtd1: 00020000 00001000 "u-boot-env"
>> mtd2: 00280000 00001000 "kernel"
>> mtd3: 001c0000 00001000 "initramfs"
>> mtd4: 01740000 00001000 "rofs"
>> mtd5: 00400000 00001000 "rwfs"
>> mtd6: 02000000 00010000 "pnor"
The problem here is that we need to know the size of the pnor ...
>>
>> The partition definitions probably belongs to the machine dts.
>>
>> And a udev rules would also fit the purpose I think.
>
> What would you suggest? A symlink to create a /dev/pnor node?
yes. like we did for the vuart. we will need to find a udev
attribute for it. I think this is the cleanest.
Cheers,
C.
>
> Cheers,
>
> Joel
>
^ permalink raw reply
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: Baolin Wang @ 2016-11-14 12:36 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel, Dmitry Eremin-Solenikov,
David Woodhouse, robh, Jun Li, Marek Szyprowski, Ruslan Bilovol,
Peter Chen, Alan Stern, grygorii.strashko, Yoshihiro Shimoda,
Lee Jones, Mark Brown, John Stultz, Charles Keepax, patches,
Linux PM list, USB
In-Reply-To: <87eg2ek7ye.fsf@notabene.neil.brown.name>
On 14 November 2016 at 12:21, NeilBrown <neilb@suse.com> wrote:
> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> Hi
>>
>> On 8 November 2016 at 04:36, NeilBrown <neilb@suse.com> wrote:
>>> On Mon, Nov 07 2016, Baolin Wang wrote:
>>>
>>>> On 3 November 2016 at 09:25, NeilBrown <neilb@suse.com> wrote:
>>>>> On Tue, Nov 01 2016, Baolin Wang wrote:
>>>>
>>>> I agree with your most opinions, but these are optimization.
>>>
>>> I see them as bug fixes, not optimizations.
>>>
>>>> Firstly I
>>>> think we should upstream the USB charger driver.
>>>
>>> I think you missed the point. The point is that we don't *need* your
>>> "USB charger driver" because all the infrastructure we need is *already*
>>> present in the kernel. It is buggy and not used uniformly, and could
>>> usefully be polished and improved. But the structure is already
>>> present.
>>>
>>> If everyone just added new infrastructure when they didn't like, or
>>> didn't understand, what was already present, the kernel would become
>>> like the Mad Hatter's tea party, full of dirty dishes.
>>>
>>>> What I want to ask is
>>>> how can we notify power driver if we don't set the
>>>> usb_register_notifier(), then I think you give the answer is: power
>>>> driver can register by 'struct usb_phy->notifier'. But why usb phy
>>>> should notify the power driver how much current should be drawn, and I
>>>> still think we should notify the current in usb charger driver which
>>>> is better, and do not need to notify current for power driver in usb
>>>> phy driver.
>>>
>>> I accept that it isn't clear that the phy *should* be involved in
>>> communicating the negotiated power availability, but nor is it clear
>>> that it shouldn't. The power does travel through the physical
>>> interface, so physically it plays a role.
>>>
>>> But more importantly, it already *does* get told (in some cases).
>>> There is an interface "usb_phy_set_power()" which exists explicitly to
>>> tell the phy what power has been negotiated. Given that infrastructure
>>> exists and works, it make sense to use it.
>>>
>>> If you think it is a broken design and should be removed, then fine:
>>> make a case for that. Examine the history. Make sure you know why it
>>> is there (or make sure that information cannot be found), and then
>>> present a case as to why it should be removed and replaced with
>>> something else. But don't just leave it there and pretend it doesn't
>>> exist and create something similar-but-different and hope people will
>>> know why yours is better. That way lies madness.
>>
>> Like Peter said, it is not only PHY can detect the USB charger type,
>> which means there are other places can detect the charger type.
>
> If I understand Peter's example correctly, it shows a configuration
> where the USB PHysical interface is partly implemented in the SOC and
> partly in the PMIC. I appreciate that would make it more challenging to
> implement a PHY driver, but there is no reason it should impact anything
> outside of the PHY.
Like Peter's example, it need to use controller register to pull up dp
to begin the secondary detection, which is not belonged to phy driver
and I don't think it is suitable we implemented these in phy driver.
>
>> Second, some controller need to detect the charger type manually which
>> USB phy did not support.
>
> "manually" is an odd term to use in this context.
Sorry for the confusing.
> I think you mean that to detect the charger type you need to issue some
> command to the hardware and wait for it to respond, then assess the
> response.
Yes.
> That isn't at all surprising. The charger type is detected by measuring
> resistance between ID and GND, which may require setting up a potential
> and activating ADCs to measure the voltage. This can all be done
> internally to the phy driver.
> Sometimes it is easy (I did https://lkml.org/lkml/2015/2/23/746 for
> twl4030, though it never got upstream).
> The code for the imx7d does look more complex, but not intrinsically
> different.
But you should implement these in every phy driver, why not one
standard framework?
>
>> Third, it did not handle what current should
>> be drawn in USB phy.
>
> The standards define that. The extcon just reports the cable type.
> Certainly it would be sensible to provide a library function to
> translate from cable type to current range. You don't need a new
> subsystem to do that, just a library function.
I don't think the extcon should handle current things. For example,
the extcon can not know the gadget speed, which is used to change the
default current values for super speed gadget.
>
>> Fourth, we need integrate all charger plugin/out
>> event in one framework, not from extcon, maybe type-c in future.
>
> Why not extcon? Given that a charger is connected by an external
> connector, extcon seems like exactly the right thing to use.
My mistake, what I mean is not only from extcon, maybe from other
places in future.
>
> Obviously extcon doesn't report the current that was negotiated, but
> that is best kept separate. The battery charger can be advised of the
> available current either via extcon or separately via the usb
> subsystem. Don't conflate the two.
>
>
>> In a
>> word, we need one standard integration of this feature we need, though
>> like you said we should do some clean up or fix to make it better.
>
> But really, I'm not the person you need to convince. I'm just a vaguely
> interested bystander who is rapidly losing interest. You need to
> convince a maintainer, but they have so far shown remarkably little
> interest. I don't know why, but I'd guess that reviewing a complex new
> subsystem isn't much fun. Reviewing and applying clear bugfixes and
> incremental improvements is much easier and more enjoyable. But that is
> just a guess.
Maybe you missed previous comments, and we had a lot of discussion
about this patchset. Also Felipe had reviewed this patchset with some
suggestion.
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH 5/5] rsi: Added support for 802.11d
From: Prameela Rani Garnepudi @ 2016-11-14 12:17 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.garnepudi,
Prameela Rani Garnepudi
Transmit power value in a channel are determined based on the dfs region
in firmware. To support regulatory rules dfs region should be configured
to device during set channel request. Also antenna gain values are taken
from the mac80211 channel parameters.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 30 ++++++++++++++++++++++++++++-
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 26 ++++++++++++++++++++-----
drivers/net/wireless/rsi/rsi_main.h | 1 +
drivers/net/wireless/rsi/rsi_mgmt.h | 3 ++-
4 files changed, 53 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 07314ea..064f38b 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -376,7 +376,7 @@ static int rsi_channel_change(struct ieee80211_hw *hw)
status = rsi_band_check(common);
if (!status)
- status = rsi_set_channel(adapter->priv, channel);
+ status = rsi_set_channel(adapter->priv, curchan);
if (bss->assoc) {
if (common->hw_data_qs_blocked &&
@@ -1147,6 +1147,32 @@ static int rsi_mac80211_get_antenna(struct ieee80211_hw *hw,
return 0;
}
+static void rsi_reg_notify(struct wiphy *wiphy,
+ struct regulatory_request *request)
+{
+ struct ieee80211_supported_band *sband;
+ struct ieee80211_channel *ch;
+ struct ieee80211_hw *hw = wiphy_to_ieee80211_hw(wiphy);
+ struct rsi_hw * adapter = hw->priv;
+ int i;
+
+ sband = wiphy->bands[NL80211_BAND_5GHZ];
+
+ for (i = 0; i < sband->n_channels; i++) {
+ ch = &sband->channels[i];
+ if (ch->flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (ch->flags & IEEE80211_CHAN_RADAR)
+ ch->flags |= IEEE80211_CHAN_NO_IR;
+ }
+
+ rsi_dbg(INFO_ZONE,
+ "country = %s dfs_region = %d\n",
+ request->alpha2, request->dfs_region);
+ adapter->dfs_region = request->dfs_region;
+}
+
static struct ieee80211_ops mac80211_ops = {
.tx = rsi_mac80211_tx,
.start = rsi_mac80211_start,
@@ -1229,6 +1255,8 @@ int rsi_mac80211_attach(struct rsi_common *common)
wiphy->bands[NL80211_BAND_5GHZ] =
&adapter->sbands[NL80211_BAND_5GHZ];
+ wiphy->reg_notifier = rsi_reg_notify;
+
status = ieee80211_register_hw(hw);
if (status)
return status;
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 16dc3ac..a4d7bf9 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -924,7 +924,8 @@ int rsi_band_check(struct rsi_common *common)
*
* Return: 0 on success, corresponding error code on failure.
*/
-int rsi_set_channel(struct rsi_common *common, u16 channel)
+int rsi_set_channel(struct rsi_common *common,
+ struct ieee80211_channel *channel)
{
struct sk_buff *skb = NULL;
struct rsi_mac_frame *mgmt_frame;
@@ -939,24 +940,39 @@ int rsi_set_channel(struct rsi_common *common, u16 channel)
return -ENOMEM;
}
+ if (!channel) {
+ dev_kfree_skb(skb);
+ return 0;
+ }
memset(skb->data, 0, FRAME_DESC_SZ);
mgmt_frame = (struct rsi_mac_frame *)skb->data;
mgmt_frame->desc_word[0] = cpu_to_le16(RSI_WIFI_MGMT_Q << 12);
mgmt_frame->desc_word[1] = cpu_to_le16(SCAN_REQUEST);
- mgmt_frame->desc_word[4] = cpu_to_le16(channel);
+ mgmt_frame->desc_word[4] = cpu_to_le16(channel->hw_value);
+
+ mgmt_frame->desc_word[4] |=
+ cpu_to_le16(((char)(channel->max_antenna_gain)) << 8);
+ mgmt_frame->desc_word[5] =
+ cpu_to_le16((char)(channel->max_antenna_gain));
mgmt_frame->desc_word[7] = cpu_to_le16(PUT_BBP_RESET |
BBP_REG_WRITE |
(RSI_RF_TYPE << 4));
- mgmt_frame->desc_word[5] = cpu_to_le16(0x01);
- mgmt_frame->desc_word[6] = cpu_to_le16(0x12);
+ if (!(channel->flags & IEEE80211_CHAN_NO_IR) &&
+ !(channel->flags & IEEE80211_CHAN_RADAR)) {
+ if (common->tx_power < channel->max_power)
+ mgmt_frame->desc_word[6] = cpu_to_le16(common->tx_power);
+ else
+ mgmt_frame->desc_word[6] = cpu_to_le16(channel->max_power);
+ }
+ mgmt_frame->desc_word[7] = cpu_to_le16(common->priv->dfs_region);
if (common->channel_width == BW_40MHZ)
mgmt_frame->desc_word[5] |= cpu_to_le16(0x1 << 8);
- common->channel = channel;
+ common->channel = channel->hw_value;
skb_put(skb, FRAME_DESC_SZ);
diff --git a/drivers/net/wireless/rsi/rsi_main.h b/drivers/net/wireless/rsi/rsi_main.h
index 2405b30..1d5904b 100644
--- a/drivers/net/wireless/rsi/rsi_main.h
+++ b/drivers/net/wireless/rsi/rsi_main.h
@@ -223,6 +223,7 @@ struct rsi_hw {
struct rsi_debugfs *dfsentry;
u8 num_debugfs_entries;
#endif
+ u8 dfs_region;
void *rsi_dev;
int (*host_intf_read_pkt)(struct rsi_hw *adapter, u8 *pkt, u32 len);
int (*host_intf_write_pkt)(struct rsi_hw *adapter, u8 *pkt, u32 len);
diff --git a/drivers/net/wireless/rsi/rsi_mgmt.h b/drivers/net/wireless/rsi/rsi_mgmt.h
index 1111c07..8e4c01d 100644
--- a/drivers/net/wireless/rsi/rsi_mgmt.h
+++ b/drivers/net/wireless/rsi/rsi_mgmt.h
@@ -324,7 +324,8 @@ int rsi_send_aggregation_params_frame(struct rsi_common *common, u16 tid,
u16 ssn, u8 buf_size, u8 event);
int rsi_hal_load_key(struct rsi_common *common, u8 *data, u16 key_len,
u8 key_type, u8 key_id, u32 cipher);
-int rsi_set_channel(struct rsi_common *common, u16 chno);
+int rsi_set_channel(struct rsi_common *common,
+ struct ieee80211_channel *channel);
int rsi_send_block_unblock_frame(struct rsi_common *common, bool event);
void rsi_inform_bss_status(struct rsi_common *common, u8 status,
const u8 *bssid, u8 qos_enable, u16 aid);
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation
From: Baolin Wang @ 2016-11-14 12:36 UTC (permalink / raw)
To: NeilBrown
Cc: Felipe Balbi, Greg KH, Sebastian Reichel, Dmitry Eremin-Solenikov,
David Woodhouse, robh, Jun Li, Marek Szyprowski, Ruslan Bilovol,
Peter Chen, Alan Stern, grygorii.strashko, Yoshihiro Shimoda,
Lee Jones, Mark Brown, John Stultz, Charles Keepax, patches,
Linux PM list, USB, device-mainlining, LKML
In-Reply-To: <87eg2ek7ye.fsf@notabene.neil.brown.name>
On 14 November 2016 at 12:21, NeilBrown <neilb@suse.com> wrote:
> On Thu, Nov 10 2016, Baolin Wang wrote:
>
>> Hi
>>
>> On 8 November 2016 at 04:36, NeilBrown <neilb@suse.com> wrote:
>>> On Mon, Nov 07 2016, Baolin Wang wrote:
>>>
>>>> On 3 November 2016 at 09:25, NeilBrown <neilb@suse.com> wrote:
>>>>> On Tue, Nov 01 2016, Baolin Wang wrote:
>>>>
>>>> I agree with your most opinions, but these are optimization.
>>>
>>> I see them as bug fixes, not optimizations.
>>>
>>>> Firstly I
>>>> think we should upstream the USB charger driver.
>>>
>>> I think you missed the point. The point is that we don't *need* your
>>> "USB charger driver" because all the infrastructure we need is *already*
>>> present in the kernel. It is buggy and not used uniformly, and could
>>> usefully be polished and improved. But the structure is already
>>> present.
>>>
>>> If everyone just added new infrastructure when they didn't like, or
>>> didn't understand, what was already present, the kernel would become
>>> like the Mad Hatter's tea party, full of dirty dishes.
>>>
>>>> What I want to ask is
>>>> how can we notify power driver if we don't set the
>>>> usb_register_notifier(), then I think you give the answer is: power
>>>> driver can register by 'struct usb_phy->notifier'. But why usb phy
>>>> should notify the power driver how much current should be drawn, and I
>>>> still think we should notify the current in usb charger driver which
>>>> is better, and do not need to notify current for power driver in usb
>>>> phy driver.
>>>
>>> I accept that it isn't clear that the phy *should* be involved in
>>> communicating the negotiated power availability, but nor is it clear
>>> that it shouldn't. The power does travel through the physical
>>> interface, so physically it plays a role.
>>>
>>> But more importantly, it already *does* get told (in some cases).
>>> There is an interface "usb_phy_set_power()" which exists explicitly to
>>> tell the phy what power has been negotiated. Given that infrastructure
>>> exists and works, it make sense to use it.
>>>
>>> If you think it is a broken design and should be removed, then fine:
>>> make a case for that. Examine the history. Make sure you know why it
>>> is there (or make sure that information cannot be found), and then
>>> present a case as to why it should be removed and replaced with
>>> something else. But don't just leave it there and pretend it doesn't
>>> exist and create something similar-but-different and hope people will
>>> know why yours is better. That way lies madness.
>>
>> Like Peter said, it is not only PHY can detect the USB charger type,
>> which means there are other places can detect the charger type.
>
> If I understand Peter's example correctly, it shows a configuration
> where the USB PHysical interface is partly implemented in the SOC and
> partly in the PMIC. I appreciate that would make it more challenging to
> implement a PHY driver, but there is no reason it should impact anything
> outside of the PHY.
Like Peter's example, it need to use controller register to pull up dp
to begin the secondary detection, which is not belonged to phy driver
and I don't think it is suitable we implemented these in phy driver.
>
>> Second, some controller need to detect the charger type manually which
>> USB phy did not support.
>
> "manually" is an odd term to use in this context.
Sorry for the confusing.
> I think you mean that to detect the charger type you need to issue some
> command to the hardware and wait for it to respond, then assess the
> response.
Yes.
> That isn't at all surprising. The charger type is detected by measuring
> resistance between ID and GND, which may require setting up a potential
> and activating ADCs to measure the voltage. This can all be done
> internally to the phy driver.
> Sometimes it is easy (I did https://lkml.org/lkml/2015/2/23/746 for
> twl4030, though it never got upstream).
> The code for the imx7d does look more complex, but not intrinsically
> different.
But you should implement these in every phy driver, why not one
standard framework?
>
>> Third, it did not handle what current should
>> be drawn in USB phy.
>
> The standards define that. The extcon just reports the cable type.
> Certainly it would be sensible to provide a library function to
> translate from cable type to current range. You don't need a new
> subsystem to do that, just a library function.
I don't think the extcon should handle current things. For example,
the extcon can not know the gadget speed, which is used to change the
default current values for super speed gadget.
>
>> Fourth, we need integrate all charger plugin/out
>> event in one framework, not from extcon, maybe type-c in future.
>
> Why not extcon? Given that a charger is connected by an external
> connector, extcon seems like exactly the right thing to use.
My mistake, what I mean is not only from extcon, maybe from other
places in future.
>
> Obviously extcon doesn't report the current that was negotiated, but
> that is best kept separate. The battery charger can be advised of the
> available current either via extcon or separately via the usb
> subsystem. Don't conflate the two.
>
>
>> In a
>> word, we need one standard integration of this feature we need, though
>> like you said we should do some clean up or fix to make it better.
>
> But really, I'm not the person you need to convince. I'm just a vaguely
> interested bystander who is rapidly losing interest. You need to
> convince a maintainer, but they have so far shown remarkably little
> interest. I don't know why, but I'd guess that reviewing a complex new
> subsystem isn't much fun. Reviewing and applying clear bugfixes and
> incremental improvements is much easier and more enjoyable. But that is
> just a guess.
Maybe you missed previous comments, and we had a lot of discussion
about this patchset. Also Felipe had reviewed this patchset with some
suggestion.
--
Baolin.wang
Best Regards
^ permalink raw reply
* [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-14 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110114505.17618-1-maitysanchayan@gmail.com>
Enable DMA for DSPI2 and DSPI3 on Vybrid.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Add signed-off-by missing in v1.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-14 12:37 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: stefan-XLVq0VzYD2Y,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sanchayan Maity
In-Reply-To: <20161110114505.17618-1-maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Enable DMA for DSPI2 and DSPI3 on Vybrid.
Signed-off-by: Sanchayan Maity <maitysanchayan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changes since v1:
Add signed-off-by missing in v1.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC v2 3/8] iommu/dma: Allow MSI-only cookies
From: Robin Murphy @ 2016-11-14 12:36 UTC (permalink / raw)
To: Eric Auger, eric.auger.pro, christoffer.dall, marc.zyngier,
alex.williamson, will.deacon, joro, tglx, jason, linux-arm-kernel
Cc: kvm, drjones, linux-kernel, pranav.sawargaonkar, iommu,
punit.agrawal, diana.craciun
In-Reply-To: <1478258646-3117-4-git-send-email-eric.auger@redhat.com>
On 04/11/16 11:24, Eric Auger wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> IOMMU domain users such as VFIO face a similar problem to DMA API ops
> with regard to mapping MSI messages in systems where the MSI write is
> subject to IOMMU translation. With the relevant infrastructure now in
> place for managed DMA domains, it's actually really simple for other
> users to piggyback off that and reap the benefits without giving up
> their own IOVA management, and without having to reinvent their own
> wheel in the MSI layer.
>
> Allow such users to opt into automatic MSI remapping by dedicating a
> region of their IOVA space to a managed cookie.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
OK, following the discussion elsewhere I've had a go at the less stupid,
but more involved, version. Thoughts?
Robin.
----->8-----
From: Robin Murphy <robin.murphy@arm.com>
Subject: [RFC PATCH] iommu/dma: Allow MSI-only cookies
IOMMU domain users such as VFIO face a similar problem to DMA API ops
with regard to mapping MSI messages in systems where the MSI write is
subject to IOMMU translation. With the relevant infrastructure now in
place for managed DMA domains, it's actually really simple for other
users to piggyback off that and reap the benefits without giving up
their own IOVA management, and without having to reinvent their own
wheel in the MSI layer.
Allow such users to opt into automatic MSI remapping by dedicating a
region of their IOVA space to a managed cookie, and extend the mapping
routine to implement a trivial linear allocator in such cases, to avoid
the needless overhead of a full-blown IOVA domain.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/dma-iommu.c | 118 ++++++++++++++++++++++++++++++++++++----------
include/linux/dma-iommu.h | 6 +++
2 files changed, 100 insertions(+), 24 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..33d66a8273c6 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -37,10 +37,19 @@ struct iommu_dma_msi_page {
phys_addr_t phys;
};
+enum iommu_dma_cookie_type {
+ IOMMU_DMA_IOVA_COOKIE,
+ IOMMU_DMA_MSI_COOKIE,
+};
+
struct iommu_dma_cookie {
- struct iova_domain iovad;
- struct list_head msi_page_list;
- spinlock_t msi_lock;
+ union {
+ struct iova_domain iovad;
+ dma_addr_t msi_iova;
+ };
+ struct list_head msi_page_list;
+ spinlock_t msi_lock;
+ enum iommu_dma_cookie_type type;
};
static inline struct iova_domain *cookie_iovad(struct iommu_domain *domain)
@@ -53,6 +62,19 @@ int iommu_dma_init(void)
return iova_cache_get();
}
+static struct iommu_dma_cookie *__cookie_alloc(enum iommu_dma_cookie_type type)
+{
+ struct iommu_dma_cookie *cookie;
+
+ cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
+ if (cookie) {
+ spin_lock_init(&cookie->msi_lock);
+ INIT_LIST_HEAD(&cookie->msi_page_list);
+ cookie->type = type;
+ }
+ return cookie;
+}
+
/**
* iommu_get_dma_cookie - Acquire DMA-API resources for a domain
* @domain: IOMMU domain to prepare for DMA-API usage
@@ -62,25 +84,53 @@ int iommu_dma_init(void)
*/
int iommu_get_dma_cookie(struct iommu_domain *domain)
{
- struct iommu_dma_cookie *cookie;
-
if (domain->iova_cookie)
return -EEXIST;
- cookie = kzalloc(sizeof(*cookie), GFP_KERNEL);
- if (!cookie)
+ domain->iova_cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!domain->iova_cookie)
return -ENOMEM;
- spin_lock_init(&cookie->msi_lock);
- INIT_LIST_HEAD(&cookie->msi_page_list);
- domain->iova_cookie = cookie;
return 0;
}
EXPORT_SYMBOL(iommu_get_dma_cookie);
/**
+ * iommu_get_msi_cookie - Acquire just MSI remapping resources
+ * @domain: IOMMU domain to prepare
+ * @base: Start address of IOVA region for MSI mappings
+ *
+ * Users who manage their own IOVA allocation and do not want DMA API support,
+ * but would still like to take advantage of automatic MSI remapping, can use
+ * this to initialise their own domain appropriately. Users should reserve a
+ * contiguous IOVA region, starting at @base, large enough to accommodate the
+ * number of PAGE_SIZE mappings necessary to cover every MSI doorbell address
+ * used by the devices attached to @domain.
+ */
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ struct iommu_dma_cookie *cookie;
+
+ if (domain->type != IOMMU_DOMAIN_UNMANAGED)
+ return -EINVAL;
+
+ if (domain->iova_cookie)
+ return -EEXIST;
+
+ cookie = __cookie_alloc(IOMMU_DMA_IOVA_COOKIE);
+ if (!cookie)
+ return -ENOMEM;
+
+ cookie->msi_iova = base;
+ domain->iova_cookie = cookie;
+ return 0;
+}
+EXPORT_SYMBOL(iommu_get_msi_cookie);
+
+/**
* iommu_put_dma_cookie - Release a domain's DMA mapping resources
- * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
+ * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie() or
+ * iommu_get_msi_cookie()
*
* IOMMU drivers should normally call this from their domain_free callback.
*/
@@ -92,7 +142,7 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
if (!cookie)
return;
- if (cookie->iovad.granule)
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE && cookie->iovad.granule)
put_iova_domain(&cookie->iovad);
list_for_each_entry_safe(msi, tmp, &cookie->msi_page_list, list) {
@@ -137,11 +187,12 @@ static void iova_reserve_pci_windows(struct pci_dev *dev,
int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev)
{
- struct iova_domain *iovad = cookie_iovad(domain);
+ struct iommu_dma_cookie *cookie = domain->iova_cookie;
+ struct iova_domain *iovad = &cookie->iovad;
unsigned long order, base_pfn, end_pfn;
- if (!iovad)
- return -ENODEV;
+ if (!cookie || cookie->type != IOMMU_DMA_IOVA_COOKIE)
+ return -EINVAL;
/* Use the smallest supported page size for IOVA granularity */
order = __ffs(domain->pgsize_bitmap);
@@ -644,11 +695,21 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
{
struct iommu_dma_cookie *cookie = domain->iova_cookie;
struct iommu_dma_msi_page *msi_page;
- struct iova_domain *iovad = &cookie->iovad;
+ struct iova_domain *iovad;
struct iova *iova;
int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+ size_t size;
+
+ if (cookie->type == IOMMU_DMA_IOVA_COOKIE) {
+ iovad = &cookie->iovad;
+ size = iovad->granule;
+ } else {
+ iovad = NULL;
+ size = PAGE_SIZE;
+ }
+
+ msi_addr &= ~(phys_addr_t)(size - 1);
- msi_addr &= ~(phys_addr_t)iova_mask(iovad);
list_for_each_entry(msi_page, &cookie->msi_page_list, list)
if (msi_page->phys == msi_addr)
return msi_page;
@@ -657,13 +718,18 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
if (!msi_page)
return NULL;
- iova = __alloc_iova(domain, iovad->granule, dma_get_mask(dev));
- if (!iova)
- goto out_free_page;
-
msi_page->phys = msi_addr;
- msi_page->iova = iova_dma_addr(iovad, iova);
- if (iommu_map(domain, msi_page->iova, msi_addr, iovad->granule, prot))
+ if (iovad) {
+ iova = __alloc_iova(domain, size, dma_get_mask(dev));
+ if (!iova)
+ goto out_free_page;
+ msi_page->iova = iova_dma_addr(iovad, iova);
+ } else {
+ msi_page->iova = cookie->msi_iova;
+ cookie->msi_iova += size;
+ }
+
+ if (iommu_map(domain, msi_page->iova, msi_addr, size, prot))
goto out_free_iova;
INIT_LIST_HEAD(&msi_page->list);
@@ -671,7 +737,10 @@ static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
return msi_page;
out_free_iova:
- __free_iova(iovad, iova);
+ if (iovad)
+ __free_iova(iovad, iova);
+ else
+ cookie->msi_iova -= size;
out_free_page:
kfree(msi_page);
return NULL;
@@ -716,3 +785,4 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
msg->address_lo += lower_32_bits(msi_page->iova);
}
}
+
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..d69932474576 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -27,6 +27,7 @@ int iommu_dma_init(void);
/* Domain management interface for IOMMU drivers */
int iommu_get_dma_cookie(struct iommu_domain *domain);
+int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base);
void iommu_put_dma_cookie(struct iommu_domain *domain);
/* Setup call for arch DMA mapping code */
@@ -82,6 +83,11 @@ static inline int iommu_get_dma_cookie(struct iommu_domain *domain)
return -ENODEV;
}
+static inline int iommu_get_msi_cookie(struct iommu_domain *domain, dma_addr_t base)
+{
+ return -ENODEV;
+}
+
static inline void iommu_put_dma_cookie(struct iommu_domain *domain)
{
}
--
2.10.2.dirty
^ permalink raw reply related
* [Qemu-devel] virtIO question
From: zhunxun @ 2016-11-14 12:36 UTC (permalink / raw)
To: qemu
I have a question about qemu.is it a bug in qemu version 1.2?
in qemu version 1.2 ,it set avail event by the code :
if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) {
vring_avail_event(vq, vring_avail_idx(vq));
}
and in version 2.7 the code is
if (virtio_vdev_has_feature(vdev, VIRTIO_RING_F_EVENT_IDX)) {
vring_set_avail_event(vq, vq->last_avail_idx);
}
a big difference of this is the value.vring_avail_idx(vq)is the latest value of VRingAvail.idx,and vq->last_avail_idx is not, I think it really different with the two different values,and I think the later is right,is it??
thanks a lot!!
zhunxun@gmail.com
^ permalink raw reply
* Re: [PATCH v2 00/18] Introduce DRM_FB_HELPER_DEFAULT_OPS for struct fb_ops
From: Stefan Christ @ 2016-11-14 12:37 UTC (permalink / raw)
To: Christian König; +Cc: dri-devel
In-Reply-To: <2916c677-c40c-95ab-0ea3-f4110475e6c4@vodafone.de>
Hi Christian,
On Mon, Nov 14, 2016 at 10:43:10AM +0100, Christian König wrote:
> Am 14.11.2016 um 00:03 schrieb Stefan Christ:
> > Hi,
> >
> > this is the second version of the refactoring work suggested by Daniel Vetter
> > in the email:
> >
> > https://lists.freedesktop.org/archives/dri-devel/2016-July/113237.html
> >
> > The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> > implementations for functions in struct fb_ops. A drm driver can use it like:
> >
> > static struct fb_ops drm_fbdev_cma_ops = {
> > .owner = THIS_MODULE,
> > DRM_FB_HELPER_DEFAULT_OPS,
> > /* driver specific implementations */
> > };
>
> Looks good to me in general, but I've got one question. Why didn't you
> put the owner field into the macro as well?
>
> I have strong doubts that anybody would set anything else than
> THIS_MODULE here.
>
In the initial suggestion by Daniel Vetter he also mentioned this
possibility. See email and response:
https://lists.freedesktop.org/archives/dri-devel/2016-July/114136.html
But I decided against it, since it hides even more magic behind the
helper define.
Mit freundlichen Grüßen / Kind regards,
Stefan Christ
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Qemu-devel] [QEMU PATCH v2] kvmclock: advance clock by time window between vm_stop and pre_save
From: Marcelo Tosatti @ 2016-11-11 14:23 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Dr. David Alan Gilbert, kvm, qemu-devel,
Radim Krčmář, Juan Quintela, Eduardo Habkost
In-Reply-To: <7e62defb-dcbe-492d-3c05-056b13d6699a@redhat.com>
On Thu, Nov 10, 2016 at 06:57:21PM +0100, Paolo Bonzini wrote:
>
>
> On 10/11/2016 12:48, Marcelo Tosatti wrote:
> > Destination has to run the following logic:
> >
> > If (source has KVM_CAP_ADVANCE_CLOCK)
> > use KVM_GET_CLOCK value
> > Else
> > read pvclock from guest
> >
> > To support migration from older QEMU versions which do not have
> > KVM_CAP_ADVANCE_CLOCK (or new QEMU versions running on old
> > hosts without KVM_CAP_ADVANCE_CLOCK).
> >
> > I don't see any clean way to give that information, except changing
> > the migration format to pass "host: kvm_cap_advance_clock=true/false"
> > information.
>
> If you make it only affect new machine types, you could transmit a dummy
> clock value such as -1 if the source does not have KVM_CLOCK_TSC_STABLE.
>
> Paolo
Prefer a new subsection (which is fine since migration is broken
anyway), because otherwise you have to deal with restoring
s->clock from -1 to what was read at KVM_GET_CLOCK (in case
migration fails).
^ permalink raw reply
* [Qemu-devel] [qemu patch 0/2] improve kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 12:36 UTC (permalink / raw)
To: kvm
Cc: qemu-devel, Dr. David Alan Gilbert, Paolo Bonzini, Juan Quintela,
Radim Krcmar, Eduardo Habkost
See patches for details.
^ permalink raw reply
* [Qemu-devel] [qemu patch 1/2] kvm: sync linux headers
From: Marcelo Tosatti @ 2016-11-14 12:36 UTC (permalink / raw)
To: kvm
Cc: qemu-devel, Dr. David Alan Gilbert, Paolo Bonzini, Juan Quintela,
Radim Krcmar, Eduardo Habkost, Marcelo Tosatti
In-Reply-To: <20161114123628.703911091@redhat.com>
[-- Attachment #1: sync-linux-headers.patch --]
[-- Type: text/plain, Size: 5447 bytes --]
Import KVM_CLOCK_TSC_STABLE.
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
diff --git a/include/standard-headers/linux/input.h b/include/standard-headers/linux/input.h
index 7361a16..b472b85 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -245,6 +245,7 @@ struct input_mask {
#define BUS_SPI 0x1C
#define BUS_RMI 0x1D
#define BUS_CEC 0x1E
+#define BUS_INTEL_ISHTP 0x1F
/*
* MT_TOOL types
diff --git a/include/standard-headers/linux/pci_regs.h b/include/standard-headers/linux/pci_regs.h
index 4040951..e5a2e68 100644
--- a/include/standard-headers/linux/pci_regs.h
+++ b/include/standard-headers/linux/pci_regs.h
@@ -612,6 +612,8 @@
*/
#define PCI_EXP_DEVCAP2 36 /* Device Capabilities 2 */
#define PCI_EXP_DEVCAP2_ARI 0x00000020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCAP2_ATOMIC_ROUTE 0x00000040 /* Atomic Op routing */
+#define PCI_EXP_DEVCAP2_ATOMIC_COMP64 0x00000100 /* Atomic 64-bit compare */
#define PCI_EXP_DEVCAP2_LTR 0x00000800 /* Latency tolerance reporting */
#define PCI_EXP_DEVCAP2_OBFF_MASK 0x000c0000 /* OBFF support mechanism */
#define PCI_EXP_DEVCAP2_OBFF_MSG 0x00040000 /* New message signaling */
@@ -619,6 +621,7 @@
#define PCI_EXP_DEVCTL2 40 /* Device Control 2 */
#define PCI_EXP_DEVCTL2_COMP_TIMEOUT 0x000f /* Completion Timeout Value */
#define PCI_EXP_DEVCTL2_ARI 0x0020 /* Alternative Routing-ID */
+#define PCI_EXP_DEVCTL2_ATOMIC_REQ 0x0040 /* Set Atomic requests */
#define PCI_EXP_DEVCTL2_IDO_REQ_EN 0x0100 /* Allow IDO for requests */
#define PCI_EXP_DEVCTL2_IDO_CMP_EN 0x0200 /* Allow IDO for completions */
#define PCI_EXP_DEVCTL2_LTR_EN 0x0400 /* Enable LTR mechanism */
@@ -671,7 +674,8 @@
#define PCI_EXT_CAP_ID_PMUX 0x1A /* Protocol Multiplexing */
#define PCI_EXT_CAP_ID_PASID 0x1B /* Process Address Space ID */
#define PCI_EXT_CAP_ID_DPC 0x1D /* Downstream Port Containment */
-#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_DPC
+#define PCI_EXT_CAP_ID_PTM 0x1F /* Precision Time Measurement */
+#define PCI_EXT_CAP_ID_MAX PCI_EXT_CAP_ID_PTM
#define PCI_EXT_CAP_DSN_SIZEOF 12
#define PCI_EXT_CAP_MCAST_ENDPOINT_SIZEOF 40
@@ -964,4 +968,13 @@
#define PCI_EXP_DPC_SOURCE_ID 10 /* DPC Source Identifier */
+/* Precision Time Measurement */
+#define PCI_PTM_CAP 0x04 /* PTM Capability */
+#define PCI_PTM_CAP_REQ 0x00000001 /* Requester capable */
+#define PCI_PTM_CAP_ROOT 0x00000004 /* Root capable */
+#define PCI_PTM_GRANULARITY_MASK 0x0000FF00 /* Clock granularity */
+#define PCI_PTM_CTRL 0x08 /* PTM Control */
+#define PCI_PTM_CTRL_ENABLE 0x00000001 /* PTM enable */
+#define PCI_PTM_CTRL_ROOT 0x00000002 /* Root select */
+
#endif /* LINUX_PCI_REGS_H */
diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index 541268c..2fb7859 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -84,6 +84,13 @@ struct kvm_regs {
#define KVM_VGIC_V2_DIST_SIZE 0x1000
#define KVM_VGIC_V2_CPU_SIZE 0x2000
+/* Supported VGICv3 address types */
+#define KVM_VGIC_V3_ADDR_TYPE_DIST 2
+#define KVM_VGIC_V3_ADDR_TYPE_REDIST 3
+
+#define KVM_VGIC_V3_DIST_SIZE SZ_64K
+#define KVM_VGIC_V3_REDIST_SIZE (2 * SZ_64K)
+
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
diff --git a/linux-headers/asm-x86/unistd_32.h b/linux-headers/asm-x86/unistd_32.h
index abeaf40..d45ea28 100644
--- a/linux-headers/asm-x86/unistd_32.h
+++ b/linux-headers/asm-x86/unistd_32.h
@@ -377,5 +377,8 @@
#define __NR_copy_file_range 377
#define __NR_preadv2 378
#define __NR_pwritev2 379
+#define __NR_pkey_mprotect 380
+#define __NR_pkey_alloc 381
+#define __NR_pkey_free 382
#endif /* _ASM_X86_UNISTD_32_H */
diff --git a/linux-headers/asm-x86/unistd_64.h b/linux-headers/asm-x86/unistd_64.h
index 73c3d1f..e22db91 100644
--- a/linux-headers/asm-x86/unistd_64.h
+++ b/linux-headers/asm-x86/unistd_64.h
@@ -330,5 +330,8 @@
#define __NR_copy_file_range 326
#define __NR_preadv2 327
#define __NR_pwritev2 328
+#define __NR_pkey_mprotect 329
+#define __NR_pkey_alloc 330
+#define __NR_pkey_free 331
#endif /* _ASM_X86_UNISTD_64_H */
diff --git a/linux-headers/asm-x86/unistd_x32.h b/linux-headers/asm-x86/unistd_x32.h
index e5aea76..84e58b2 100644
--- a/linux-headers/asm-x86/unistd_x32.h
+++ b/linux-headers/asm-x86/unistd_x32.h
@@ -283,6 +283,9 @@
#define __NR_membarrier (__X32_SYSCALL_BIT + 324)
#define __NR_mlock2 (__X32_SYSCALL_BIT + 325)
#define __NR_copy_file_range (__X32_SYSCALL_BIT + 326)
+#define __NR_pkey_mprotect (__X32_SYSCALL_BIT + 329)
+#define __NR_pkey_alloc (__X32_SYSCALL_BIT + 330)
+#define __NR_pkey_free (__X32_SYSCALL_BIT + 331)
#define __NR_rt_sigaction (__X32_SYSCALL_BIT + 512)
#define __NR_rt_sigreturn (__X32_SYSCALL_BIT + 513)
#define __NR_ioctl (__X32_SYSCALL_BIT + 514)
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 4806e06..bb0ed71 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -972,12 +972,19 @@ struct kvm_irqfd {
__u8 pad[16];
};
+/* For KVM_CAP_ADJUST_CLOCK */
+
+/* Do not use 1, KVM_CHECK_EXTENSION returned it before we had flags. */
+#define KVM_CLOCK_TSC_STABLE 2
+
struct kvm_clock_data {
__u64 clock;
__u32 flags;
__u32 pad[9];
};
+/* For KVM_CAP_SW_TLB */
+
#define KVM_MMU_FSL_BOOKE_NOHV 0
#define KVM_MMU_FSL_BOOKE_HV 1
^ permalink raw reply related
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.