* Re: [PATCH net-next v6 0/4] bpf: add two helpers to read perf event enabled/running time
From: Peter Zijlstra @ 2017-10-05 8:34 UTC (permalink / raw)
To: David Miller; +Cc: yhs, rostedt, ast, daniel, netdev, kernel-team
In-Reply-To: <20171004.160056.801262768847050741.davem@davemloft.net>
On Wed, Oct 04, 2017 at 04:00:56PM -0700, David Miller wrote:
> From: Yonghong Song <yhs@fb.com>
> Date: Mon, 2 Oct 2017 15:42:14 -0700
>
> > [Dave, Peter,
> >
> > Previous communcation shows that this patch may potentially have
> > merge conflict with upcoming tip changes in the next merge window.
> >
> > Could you advise how this patch should proceed?
> >
> > Thanks!
> > ]
>
> Indeed, Peter how do you want to handle this?
I think Alexei suggested that we merge the one patch in two branches and
let git sort it out. I _think_ I've done something similar before and it
worked.
^ permalink raw reply
* [PATCH v4] btrfs: Remove received_uuid during received snapshot ro->rw switch
From: Nikolay Borisov @ 2017-10-05 8:22 UTC (permalink / raw)
To: dsterba; +Cc: linux-btrfs, Nikolay Borisov
In-Reply-To: <20171004150039.GE3521@twin.jikos.cz>
Currently when a read-only snapshot is received and subsequently its ro property
is set to false i.e. switched to rw-mode the received_uuid of that subvol remains
intact. However, once the received volume is switched to RW mode we cannot
guaranteee that it contains the same data, so it makes sense to remove the
received uuid. The presence of the received_uuid can also cause problems when
the volume is being send.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Suggested-by: David Sterba <dsterba@suse.cz>
---
v4:
* Put the uuid tree removal code after the lightweight 'send in progress'
check and don't move btrfs_start_transaction as suggested by David
v3:
* Rework the patch considering latest feedback from David Sterba i.e.
explicitly use btrfs_end_transaction
fs/btrfs/ioctl.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ee4ee7cbba72..9328c091854b 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1775,6 +1775,7 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
struct btrfs_trans_handle *trans;
u64 root_flags;
u64 flags;
+ bool clear_received_uuid = false;
int ret = 0;
if (!inode_owner_or_capable(inode))
@@ -1824,6 +1825,7 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
btrfs_set_root_flags(&root->root_item,
root_flags & ~BTRFS_ROOT_SUBVOL_RDONLY);
spin_unlock(&root->root_item_lock);
+ clear_received_uuid = true;
} else {
spin_unlock(&root->root_item_lock);
btrfs_warn(fs_info,
@@ -1840,6 +1842,24 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
goto out_reset;
}
+ if (clear_received_uuid) {
+ if (!btrfs_is_empty_uuid(root->root_item.received_uuid)) {
+ ret = btrfs_uuid_tree_rem(trans, fs_info,
+ root->root_item.received_uuid,
+ BTRFS_UUID_KEY_RECEIVED_SUBVOL,
+ root->root_key.objectid);
+
+ if (ret && ret != -ENOENT) {
+ btrfs_abort_transaction(trans, ret);
+ btrfs_end_transaction(trans);
+ goto out_reset;
+ }
+
+ memset(root->root_item.received_uuid, 0,
+ BTRFS_UUID_SIZE);
+ }
+ }
+
ret = btrfs_update_root(trans, fs_info->tree_root,
&root->root_key, &root->root_item);
if (ret < 0) {
--
2.7.4
^ permalink raw reply related
* Re: [GIT PULL for-4.9 00/96] Commits for v4.9 LTS
From: gregkh @ 2017-10-05 8:35 UTC (permalink / raw)
To: Levin, Alexander (Sasha Levin); +Cc: stable@vger.kernel.org
In-Reply-To: <20171003130253.GA8501@kroah.com>
On Tue, Oct 03, 2017 at 03:02:53PM +0200, gregkh@linuxfoundation.org wrote:
> On Mon, Oct 02, 2017 at 08:33:09AM +0200, gregkh@linuxfoundation.org wrote:
> > On Mon, Oct 02, 2017 at 12:39:29AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > > Ping?
> > >
> > > I was planning on doing weekly batches (~50 commits) for the foreseeable future, is there a schedule that'll work better with yours?
> >
> > Due to travel/conferences over the past few weeks, I'm a bit behind on
> > stable patches, so give me a chance to catch up :)
> >
> > Yes, weekly batches is fine, as long as I can keep on top of them...
>
> I've caught up with everything else, so these three series will go into
> the next release, after the ones that come out in a few days.
All now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH] epoll: account epitem and eppoll_entry to kmemcg
From: Michal Hocko @ 2017-10-05 8:21 UTC (permalink / raw)
To: Shakeel Butt
Cc: Alexander Viro, Vladimir Davydov, Johannes Weiner, Greg Thelen,
Andrew Morton, Linux MM, linux-fsdevel, LKML
In-Reply-To: <CALvZod6w99KoNNp_DNQegDCYqWvY1ihnnGXnRL7ufiMOkaTyxw@mail.gmail.com>
On Wed 04-10-17 12:33:14, Shakeel Butt wrote:
> >
> > I am not objecting to the patch I would just like to understand the
> > runaway case. ep_insert seems to limit the maximum number of watches to
> > max_user_watches which should be ~4% of lowmem if I am following the
> > code properly. pwq_cache should be bound by the number of watches as
> > well, or am I misunderstanding the code?
> >
>
> You are absolutely right that there is a per-user limit (~4% of total
> memory if no highmem) on these caches. I think it is too generous
> particularly in the scenario where jobs of multiple users are running
> on the system and the administrator is reducing cost by overcomitting
> the memory. This is unaccounted kernel memory and will not be
> considered by the oom-killer. I think by accounting it to kmemcg, for
> systems with kmem accounting enabled, we can provide better isolation
> between jobs of different users.
Thanks for the clarification. For some reason I didn't figure that the
limit is per user, even though the name suggests so.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] examples/l3fwd: pass flow arguments when start app
From: Wu, Jingjing @ 2017-10-05 8:35 UTC (permalink / raw)
To: Stephen Hemminger, Li, Xiaoyun; +Cc: dev@dpdk.org
In-Reply-To: <20171001102410.3c928ad5@xeon-e3>
> -----Original Message-----
> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> Sent: Monday, October 2, 2017 1:24 AM
> To: Li, Xiaoyun <xiaoyun.li@intel.com>
> Cc: Wu, Jingjing <jingjing.wu@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] examples/l3fwd: pass flow arguments when start app
>
> On Sat, 30 Sep 2017 09:59:08 +0800
> Xiaoyun Li <xiaoyun.li@intel.com> wrote:
>
> > To make the performance can be tuning on different NICs or platforms. We
> > need to make the number of descriptors and Rx/TX threshold as arguments
> > when starting l3fwd application.
> >
> > Signed-off-by: Xiaoyun Li <xiaoyun.li@intel.com>
>
> Not sure about this. The point of l3fwd is to make it as simple
> an application as possible to help users.
>
> Given that drivers can now supply default values for thresholds, I think
> the l3fwd sample should get rid of all the special descriptor values it
> is setting. Then if the values are not right for best performance that should
> be pushed back to the driver writer to fix.
But now what the driver using are the arguments passed from l3fwd application,
such as RTE_TEST_RX_DESC_DEFAULT. About the threshold, I guess it is already
done by driver to use default value. For number of descriptors, any ideas? Diver to
provide a suggestion one?
^ permalink raw reply
* Re: [PATCH 3/5] KVM: arm/arm64: factor out common wfe/wfi emulation code
From: Marc Zyngier @ 2017-10-05 8:36 UTC (permalink / raw)
To: Andrew Jones, kvmarm; +Cc: cdall
In-Reply-To: <20170929113041.24371-4-drjones@redhat.com>
On 29/09/17 12:30, Andrew Jones wrote:
> Before we add more common code to the wfi emulation, let's first
> factor out everything common.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> arch/arm/include/asm/kvm_host.h | 2 ++
> arch/arm/kvm/handle_exit.c | 14 +++++---------
> arch/arm64/include/asm/kvm_host.h | 2 ++
> arch/arm64/kvm/handle_exit.c | 14 +++++---------
> virt/kvm/arm/arm.c | 13 +++++++++++++
> virt/kvm/arm/psci.c | 15 +++++++--------
> 6 files changed, 34 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 85f3c20b9759..964320825372 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -231,6 +231,8 @@ void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> void kvm_arm_vcpu_power_on(struct kvm_vcpu *vcpu);
> void kvm_arm_halt_guest(struct kvm *kvm);
> void kvm_arm_resume_guest(struct kvm *kvm);
> +void kvm_arm_emulate_wfe(struct kvm_vcpu *vcpu);
> +void kvm_arm_emulate_wfi(struct kvm_vcpu *vcpu);
>
> int kvm_arm_copy_coproc_indices(struct kvm_vcpu *vcpu, u64 __user *uindices);
> unsigned long kvm_arm_num_coproc_regs(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm/kvm/handle_exit.c b/arch/arm/kvm/handle_exit.c
> index cf8bf6bf87c4..e40466577c87 100644
> --- a/arch/arm/kvm/handle_exit.c
> +++ b/arch/arm/kvm/handle_exit.c
> @@ -57,22 +57,18 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
> * @run: the kvm_run structure pointer
> *
> * WFE: Yield the CPU and come back to this vcpu when the scheduler
> - * decides to.
> - * WFI: Simply call kvm_vcpu_block(), which will halt execution of
> - * world-switches and schedule other host processes until there is an
> - * incoming IRQ or FIQ to the VM.
> + * decides to.
> + * WFI: Halt execution of world-switches and schedule other host
> + * processes until there is an incoming IRQ or FIQ to the VM.
> */
> static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
> {
> if (kvm_vcpu_get_hsr(vcpu) & HSR_WFI_IS_WFE) {
> trace_kvm_wfx(*vcpu_pc(vcpu), true);
> - vcpu->stat.wfe_exit_stat++;
> - kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> + kvm_arm_emulate_wfe(vcpu);
> } else {
> trace_kvm_wfx(*vcpu_pc(vcpu), false);
> - vcpu->stat.wfi_exit_stat++;
> - kvm_vcpu_block(vcpu);
> - kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> + kvm_arm_emulate_wfi(vcpu);
> }
>
> kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 25545a87de11..a774f6b30474 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -332,6 +332,8 @@ void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> void kvm_arm_vcpu_power_on(struct kvm_vcpu *vcpu);
> void kvm_arm_halt_guest(struct kvm *kvm);
> void kvm_arm_resume_guest(struct kvm *kvm);
> +void kvm_arm_emulate_wfe(struct kvm_vcpu *vcpu);
> +void kvm_arm_emulate_wfi(struct kvm_vcpu *vcpu);
>
> u64 __kvm_call_hyp(void *hypfn, ...);
> #define kvm_call_hyp(f, ...) __kvm_call_hyp(kvm_ksym_ref(f), ##__VA_ARGS__)
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 7debb74843a0..7ba50a296d10 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -74,22 +74,18 @@ static int handle_no_fpsimd(struct kvm_vcpu *vcpu, struct kvm_run *run)
> * @vcpu: the vcpu pointer
> *
> * WFE: Yield the CPU and come back to this vcpu when the scheduler
> - * decides to.
> - * WFI: Simply call kvm_vcpu_block(), which will halt execution of
> - * world-switches and schedule other host processes until there is an
> - * incoming IRQ or FIQ to the VM.
> + * decides to.
> + * WFI: Halt execution of world-switches and schedule other host
> + * processes until there is an incoming IRQ or FIQ to the VM.
> */
> static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
> {
> if (kvm_vcpu_get_hsr(vcpu) & ESR_ELx_WFx_ISS_WFE) {
> trace_kvm_wfx_arm64(*vcpu_pc(vcpu), true);
> - vcpu->stat.wfe_exit_stat++;
> - kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> + kvm_arm_emulate_wfe(vcpu);
> } else {
> trace_kvm_wfx_arm64(*vcpu_pc(vcpu), false);
> - vcpu->stat.wfi_exit_stat++;
> - kvm_vcpu_block(vcpu);
> - kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> + kvm_arm_emulate_wfi(vcpu);
> }
>
> kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 954e77608d29..220a3dbda76c 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -573,6 +573,19 @@ void kvm_arm_resume_guest(struct kvm *kvm)
> }
> }
>
> +void kvm_arm_emulate_wfe(struct kvm_vcpu *vcpu)
> +{
> + vcpu->stat.wfe_exit_stat++;
> + kvm_vcpu_on_spin(vcpu, vcpu_mode_priv(vcpu));
> +}
> +
> +void kvm_arm_emulate_wfi(struct kvm_vcpu *vcpu)
> +{
> + vcpu->stat.wfi_exit_stat++;
> + kvm_vcpu_block(vcpu);
> + kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> +}
> +
> static void vcpu_req_sleep(struct kvm_vcpu *vcpu)
> {
> struct swait_queue_head *wq = kvm_arch_vcpu_wq(vcpu);
> diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
> index a7bf152f1247..755c415304ea 100644
> --- a/virt/kvm/arm/psci.c
> +++ b/virt/kvm/arm/psci.c
> @@ -50,20 +50,19 @@ static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu)
> * This means for KVM the wakeup events are interrupts and
> * this is consistent with intended use of StateID as described
> * in section 5.4.1 of PSCI v0.2 specification (ARM DEN 0022A).
> - *
> - * Further, we also treat power-down request to be same as
> - * stand-by request as-per section 5.4.2 clause 3 of PSCI v0.2
> - * specification (ARM DEN 0022A). This means all suspend states
> - * for KVM will preserve the register state.
> */
> - kvm_vcpu_block(vcpu);
> - kvm_clear_request(KVM_REQ_UNHALT, vcpu);
> -
> + kvm_arm_emulate_wfi(vcpu);
> return PSCI_RET_SUCCESS;
> }
>
> static void kvm_psci_vcpu_off(struct kvm_vcpu *vcpu)
> {
> + /*
> + * We treat a power-off request the same as a stand-by request,
> + * as-per section 5.4.2 clause 3 of PSCI v0.2* specification
> + * (ARM DEN 0022A). This means all suspend states for KVM will
> + * preserve the register state.
> + */
> kvm_arm_vcpu_power_off(vcpu);
> }
>
>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v3 14/19] vhost: don't dereference invalid dev pointer after its reallocation
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin, stable
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
numa_realloc() reallocates the virtio_net device structure and
updates the vhost_devices[] table with the new pointer if the rings
are allocated different NUMA node.
Problem is that vhost_user_msg_handler() still dereferences old
pointer afterward.
This patch prevents this by fetching again the dev pointer in
vhost_devices[] after messages have been handled.
Cc: stable@dpdk.org
Fixes: af295ad4698c ("vhost: realloc device and queues to same numa node as vring desc")
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost_user.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 8aca7ef7e..f495dd36e 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -1198,6 +1198,12 @@ vhost_user_msg_handler(int vid, int fd)
}
+ /*
+ * The virtio_net struct might have been reallocated on a different
+ * NUMA node, so dev pointer might no more be valid.
+ */
+ dev = get_device(vid);
+
if (msg.flags & VHOST_USER_NEED_REPLY) {
msg.payload.u64 = !!ret;
msg.size = sizeof(msg.payload.u64);
--
2.13.6
^ permalink raw reply related
* [PATCH] lightnvm: pblk: remove spinlock when freeing line metadata
From: Hans Holmberg @ 2017-10-05 8:35 UTC (permalink / raw)
To: Matias Bjorling
Cc: linux-block, linux-kernel, Javier Gonzales, Andrey Ryabinin,
Hans Holmberg
From: Hans Holmberg <hans.holmberg@cnexlabs.com>
Lockdep complains about being in atomic context while freeing line
metadata - and rightly so as we take a spinlock and end up calling
vfree that might sleep(in pblk_mfree).
There is no need for holding the line manager free_lock while
freeing line metadata, so remove the lock.
Signed-off-by: Hans Holmberg <hans.holmberg@cnexlabs.com>
---
This patch is for:
https://github.com/OpenChannelSSD/linux branch for-4.15/pblk
drivers/lightnvm/pblk-init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
index c452478..a645117 100644
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -393,13 +393,11 @@ static void pblk_line_meta_free(struct pblk *pblk)
kfree(l_mg->bb_aux);
kfree(l_mg->vsc_list);
- spin_lock(&l_mg->free_lock);
for (i = 0; i < PBLK_DATA_LINES; i++) {
kfree(l_mg->sline_meta[i]);
pblk_mfree(l_mg->eline_meta[i]->buf, l_mg->emeta_alloc_type);
kfree(l_mg->eline_meta[i]);
}
- spin_unlock(&l_mg->free_lock);
kfree(pblk->lines);
}
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] qdev: Check for the availability of a hotplug controller before adding a device
From: Igor Mammedov @ 2017-10-05 8:36 UTC (permalink / raw)
To: Eduardo Habkost
Cc: Thomas Huth, Paolo Bonzini, qemu-devel, Dr. David Alan Gilbert,
Markus Armbruster
In-Reply-To: <20171003184946.GR17385@localhost.localdomain>
On Tue, 3 Oct 2017 15:49:46 -0300
Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Tue, Oct 03, 2017 at 06:46:02PM +0200, Thomas Huth wrote:
> > The qdev_unplug() function contains a g_assert(hotplug_ctrl) statement,
> > so QEMU crashes when the user tries to device_add + device_del a device
> > that does not have a corresponding hotplug controller. This could be
> > provoked for a couple of devices in the past (see commit 4c93950659487c7ad
> > or 84ebd3e8c7d4fe955 for example). So devices clearly need a hotplug
> > controller when they are suitable for device_add.
> > The code in qdev_device_add() already checks whether the bus has a proper
> > hotplug controller, but for devices that do not have a corresponding bus,
> > there is no appropriate check available. In that case we should check
> > whether the machine itself provides a suitable hotplug controller and
> > refuse to plug the device if none is available.
> >
> > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > ---
> > This is the follow-up patch from my earlier try "hw/core/qdev: Do not
> > allow hot-plugging without hotplug controller" ... AFAICS the function
> > qdev_device_add() is now the right spot to do the check.
> >
> > hw/core/qdev.c | 28 ++++++++++++++++++++--------
> > include/hw/qdev-core.h | 1 +
> > qdev-monitor.c | 9 +++++++++
> > 3 files changed, 30 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/core/qdev.c b/hw/core/qdev.c
> > index 606ab53..a953ec9 100644
> > --- a/hw/core/qdev.c
> > +++ b/hw/core/qdev.c
> > @@ -253,19 +253,31 @@ void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
> > dev->alias_required_for_version = required_for_version;
> > }
> >
> > +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev)
> > +{
> > + MachineState *machine;
> > + MachineClass *mc;
> > + Object *m_obj = qdev_get_machine();
> > +
> > + if (object_dynamic_cast(m_obj, TYPE_MACHINE)) {
> > + machine = MACHINE(m_obj);
> > + mc = MACHINE_GET_CLASS(machine);
> > + if (mc->get_hotplug_handler) {
> > + return mc->get_hotplug_handler(machine, dev);
> > + }
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev)
> > {
> > - HotplugHandler *hotplug_ctrl = NULL;
> > + HotplugHandler *hotplug_ctrl;
> >
> > if (dev->parent_bus && dev->parent_bus->hotplug_handler) {
> > hotplug_ctrl = dev->parent_bus->hotplug_handler;
> > - } else if (object_dynamic_cast(qdev_get_machine(), TYPE_MACHINE)) {
> > - MachineState *machine = MACHINE(qdev_get_machine());
> > - MachineClass *mc = MACHINE_GET_CLASS(machine);
> > -
> > - if (mc->get_hotplug_handler) {
> > - hotplug_ctrl = mc->get_hotplug_handler(machine, dev);
> > - }
> > + } else {
> > + hotplug_ctrl = qdev_get_machine_hotplug_handler(dev);
> > }
> > return hotplug_ctrl;
> > }
> > diff --git a/include/hw/qdev-core.h b/include/hw/qdev-core.h
> > index 0891461..5aa536d 100644
> > --- a/include/hw/qdev-core.h
> > +++ b/include/hw/qdev-core.h
> > @@ -285,6 +285,7 @@ DeviceState *qdev_try_create(BusState *bus, const char *name);
> > void qdev_init_nofail(DeviceState *dev);
> > void qdev_set_legacy_instance_id(DeviceState *dev, int alias_id,
> > int required_for_version);
> > +HotplugHandler *qdev_get_machine_hotplug_handler(DeviceState *dev);
> > HotplugHandler *qdev_get_hotplug_handler(DeviceState *dev);
> > void qdev_unplug(DeviceState *dev, Error **errp);
> > void qdev_simple_device_unplug_cb(HotplugHandler *hotplug_dev,
> > diff --git a/qdev-monitor.c b/qdev-monitor.c
> > index 8fd6df9..2891dde 100644
> > --- a/qdev-monitor.c
> > +++ b/qdev-monitor.c
> > @@ -626,6 +626,15 @@ DeviceState *qdev_device_add(QemuOpts *opts, Error **errp)
> > return NULL;
> > }
> >
> > + /* In case we don't have a bus, there must be a machine hotplug handler */
> > + if (qdev_hotplug && !bus && !qdev_get_machine_hotplug_handler(dev)) {
> > + error_setg(errp, "Device '%s' can not be hotplugged on this machine",
> > + driver);
> > + object_unparent(OBJECT(dev));
>
> Isn't it better to check qdev_get_machine_hotplug_handler()
> earlier (before the qdev_set_parent_bus() and qdev_set_id()
> lines), so object_unparent() isn't necessary?
>
> (We probably don't need to call object_unparent() here, already,
> because bus is NULL. But moving the check before the "if (bus)
> qdev_set_parent_bus()" statement would make this more obvious).
it might be bus or bus-less device, so making check before
qdev_set_parent_bus() should be simpler.
> I would prefer to eventually make
> MachineClass::get_hotplug_handler() get a typename or
> DeviceClass* argument instead of DeviceState*, so we don't even
> create the device object. But I don't think it's a requirement
> for this bug fix.
choice of hotplug handler might theoretically depend on plugged
device instance (over-engineered? as far as I recall none does it so far)
>
>
> > + object_unref(OBJECT(dev));
> > + return NULL;
> > + }
wrt error exit path, I'd rework error path in qdev_device_add() in separate patch first
to look like it is in device_set_realized() and then just jump to appropriate label
from here.
> > +
> > dev->opts = opts;
> > object_property_set_bool(OBJECT(dev), true, "realized", &err);
> > if (err != NULL) {
> > --
> > 1.8.3.1
> >
>
^ permalink raw reply
* Why is NFS using a_ops->freepage?
From: Jan Kara @ 2017-10-05 8:36 UTC (permalink / raw)
To: linux-nfs, linux-mm; +Cc: Trond Myklebust, Anna Schumaker
Hello,
I'm doing some work in page cache handling and I have noticed that NFS is
the only user of mapping->a_ops->freepage callback. From a quick look I
don't see why isn't NFS using ->releasepage / ->invalidatepage callback as
all other filesystems do? I agree you would have to set PagePrivate bit for
those to get called for the directory mapping however that would seem like
a cleaner thing to do anyway - in fact you do have private data in the
page. Just they are not pointed to by page->private but instead are stored
as page data... Am I missing something?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH v3 00/19] Vhost-user: Implement device IOTLB support
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
This v3 lists the feature in the release note, and fixes the bug in
is_vring_iotlb_update() reported by Yuanhan.
The purpose of this series is to add support for
VIRTIO_F_IOMMU_PLATFORM feature, by implementing device IOTLB in the
vhost-user backend. It improves the guest safety by enabling the
possibility to isolate the Virtio device.
It makes possible to use Virtio PMD in guest with using VFIO driver
without enable_unsafe_noiommu_mode parameter set, so that the DPDK
application on guest can only access memory its has been allowed to,
and preventing malicious/buggy DPDK application in guest to make
vhost-user backend write random guest memory. Note that Virtio-net
Kernel driver also support IOMMU.
The series depends on Qemu's "vhost-user: Specify and implement
device IOTLB support" [0], available upstream and which will be part
of Qemu v2.10 release.
Performance-wise, even if this RFC has still room for optimizations,
no performance degradation is noticed with static mappings (i.e. DPDK
on guest) with PVP benchmark:
Traffic Generator: Moongen (lua-trafficgen)
Acceptable Loss: 0.005%
Validation run time: 1 min
Guest DPDK version/commit: v17.05
QEMU version/commit: master (6db174aed1fd)
Virtio features: default
CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
NIC: 2 x X710
Page size: 1G host/1G guest
Results (bidirectional, total of the two flows):
- base: 18.8Mpps
- base + IOTLB series, IOMMU OFF: 18.8Mpps
- base + IOTLB series, IOMMU ON: 18.8Mpps (14.5Mpps w/o PATCH 21/21)
This is explained because IOTLB misses, which are very costly, only
happen at startup time. Indeed, once used, the buffers are not
invalidated, so if the IOTLB cache is large enough, there will be only
cache hits. Also, the use of 1G huge pages improves the IOTLB cache
searching time by reducing the number of entries.
With 2M hugepages, a performance degradation is seen with IOMMU on:
Traffic Generator: Moongen (lua-trafficgen)
Acceptable Loss: 0.005%
Validation run time: 1 min
Guest DPDK version/commit: v17.05
QEMU version/commit: master (6db174aed1fd)
Virtio features: default
CPU: Intel(R) Xeon(R) CPU E5-2667 v4 @ 3.20GHz
NIC: 2 x X710
Page size: 2M host/2M guest
Results (bidirectional, total of the two flows):
- base: 18.8Mpps
- base + IOTLB series, IOMMU OFF: 18.8Mpps
- base + IOTLB series, IOMMU ON: 13.5Mpps (12.4Mpps wo PATCH 21/21)
A possible improvement would be to merge contiguous IOTLB entries sharing
the same permissions. A very rough patch implementing this idea fixes
the performance degradation (18.8Mpps), but the required work to clean
it would delay this series after v17.11.
With dynamic mappings (i.e. Virtio-net kernel driver), this is another
story. The performance is so poor it makes it almost unusable. Indeed,
since the Kernel driver unmaps the buffers as soon as they are handled,
almost all descriptors buffers addresses translations result in an IOTLB
miss. There is not much that can be done on DPDK side, except maybe
batching IOTLB miss requests no to break bursts, but it would require
a big rework. In Qemu, we may consider enabling IOMMU MAP notifications,
so that DPDK receives the IOTLB updates without having to send IOTLB miss
request.
Regarding the design choices:
- I initially intended to use userspace RCU library[1] for the cache
implementation, but it would have added an external dependency, and the
lib is not available in all distros. Qemu for example got rid of this
dependency by copying some of the userspace RCU lib parts into Qemu tree,
but this is not possible with DPDK due to licensing issues (RCU lib is
LGPL v2). Thanks to Jason advice, I implemented the cache using rd/wr
locks.
- I initially implemented a per-device IOTLB cache, but the concurrent
acccesses on the IOTLB lock had huge impact on performance (~-40% in
bidirectionnal, expect even worse with multiqueue). I move to a per-
virtqueue IOTLB design, which prevents this concurrency.
- The slave IOTLB miss request supports reply-ack feature in spec, but
this version doesn't block or busy-wait for the corresponding update so
that other queues sharing the same lcore can be processed in the meantime.
For those who would like to test the series, I made it available on
gitlab[2] (vhost_user_iotlb_v1 tag). The guest kernel command line requires
the intel_iommu=on parameter, and the guest should be started with and
iommu device attached to the virtio-net device. For example:
./qemu-system-x86_64 \
-enable-kvm -m 4096 -smp 2 \
-M q35,kernel-irqchip=split \
-cpu host \
-device intel-iommu,device-iotlb=on,intremap \
-device ioh3420,id=root.1,chassis=1 \
-chardev socket,id=char0,path=/tmp/vhost-user1 \
-netdev type=vhost-user,id=hn2,chardev=char0 \
-device virtio-net-pci,netdev=hn2,id=v0,mq=off,mac=$MAC,bus=root.1,disable-modern=off,disable-legacy=on,iommu_platform=on,ats=on \
...
[0]: https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg00520.html
[1]: http://liburcu.org/
[2]: https://gitlab.com/mcoquelin/dpdk-next-virtio/commits/vhost_user_iotlb_v2
Changes since v1:
=================
- Add feature support in release note (Yuanhan)
- Fix return value in is_vring_iotlb_update() (Yuanhan)
Changes since v1:
=================
- Implement random cache entry eviction instead of removing all entries
when cache is full (Yuanhan)
- Adds bounds check on vring_idx (Remy)
- Initialize slave_req_fd to -1 (Tiwei)
- Remove virtio-net device lock (Tiwei)
- Simplify vhost_user_iotlb_cache_remove() (Tiwei)
- Squash iotlb lock usage optimization patch
- Inline noiommu part of vhost_iova_to_vva to remove performance
regressions with IOMMU=off
- Reworked iotlb files copyrights
Changes since RFC:
==================
- Fix memory leak in error patch reported by Jens
- Rework wait for IOTLB update by stopping the burst to let other
queues to be processed, if any. It implies the introduction an
iotlb_pending_list, so that iotlb miss requests aren't sent multiple
times for a same address.
- Optimize iotlb lock usage to recover to same as IOMMU off performance
- Fix device locking issue in rte_vhost_dequeue_burst() error path
- Change virtio_dev_rx error handling for consistency with mergeable rx,
and to ease returning in case of IOTLB misses.
- Fix checkpatch warnings reported by checkpatch@dpdk.org
Maxime Coquelin (19):
Revert "vhost: workaround MQ fails to startup"
vhost: make error handling consistent in rx path
vhost: prepare send_vhost_message() to slave requests
vhost: add support to slave requests channel
vhost: declare missing IOMMU-related definitions for old kernels
vhost: add iotlb helper functions
vhost: iotlb: add pending miss request list and helpers
vhost-user: add support to IOTLB miss slave requests
vhost: initialize vrings IOTLB caches
vhost-user: handle IOTLB update and invalidate requests
vhost: introduce guest IOVA to backend VA helper
vhost: use the guest IOVA to host VA helper
vhost: enable rings at the right time
vhost: don't dereference invalid dev pointer after its reallocation
vhost: postpone rings addresses translation
vhost-user: translate ring addresses when IOMMU enabled
vhost-user: iommu: postpone device creation until ring are mapped
vhost: iommu: Invalidate vring in case of matching IOTLB invalidate
vhost: enable IOMMU support
doc/guides/rel_notes/release_17_11.rst | 4 +
lib/librte_vhost/Makefile | 4 +-
lib/librte_vhost/iotlb.c | 352 +++++++++++++++++++++++++++++++++
lib/librte_vhost/iotlb.h | 76 +++++++
lib/librte_vhost/vhost.c | 115 +++++++++--
lib/librte_vhost/vhost.h | 61 +++++-
lib/librte_vhost/vhost_user.c | 312 +++++++++++++++++++++++++----
lib/librte_vhost/vhost_user.h | 20 +-
lib/librte_vhost/virtio_net.c | 96 +++++++--
9 files changed, 962 insertions(+), 78 deletions(-)
create mode 100644 lib/librte_vhost/iotlb.c
create mode 100644 lib/librte_vhost/iotlb.h
--
2.13.6
^ permalink raw reply
* Why is NFS using a_ops->freepage?
From: Jan Kara @ 2017-10-05 8:36 UTC (permalink / raw)
To: linux-nfs, linux-mm; +Cc: Trond Myklebust, Anna Schumaker
Hello,
I'm doing some work in page cache handling and I have noticed that NFS is
the only user of mapping->a_ops->freepage callback. From a quick look I
don't see why isn't NFS using ->releasepage / ->invalidatepage callback as
all other filesystems do? I agree you would have to set PagePrivate bit for
those to get called for the directory mapping however that would seem like
a cleaner thing to do anyway - in fact you do have private data in the
page. Just they are not pointed to by page->private but instead are stored
as page data... Am I missing something?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v3 01/19] Revert "vhost: workaround MQ fails to startup"
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
This reverts commit 04d81227960b5c1cf2f11f492100979ead20c526.
As agreed when this workaround was introduced, it can be reverted
as Qemu v2.10 that fixes the issue is now out.
The reply-ack feature is required for vhost-user IOMMU support.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost_user.h | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index 35ebd7190..2ba22dbb0 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -49,14 +49,10 @@
#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3
#define VHOST_USER_PROTOCOL_F_NET_MTU 4
-/*
- * disable REPLY_ACK feature to workaround the buggy QEMU implementation.
- * Proved buggy QEMU includes v2.7 - v2.9.
- */
#define VHOST_USER_PROTOCOL_FEATURES ((1ULL << VHOST_USER_PROTOCOL_F_MQ) | \
(1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD) |\
(1ULL << VHOST_USER_PROTOCOL_F_RARP) | \
- (0ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK) | \
+ (1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK) | \
(1ULL << VHOST_USER_PROTOCOL_F_NET_MTU))
typedef enum VhostUserRequest {
--
2.13.6
^ permalink raw reply related
* [U-Boot] [PATCH] usb: kbd: Don't fail with iomux
From: Peter Robinson @ 2017-10-05 8:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20170927011939.6610-1-robdclark@gmail.com>
On Wed, Sep 27, 2017 at 2:19 AM, Rob Clark <robdclark@gmail.com> wrote:
> stdin might not be set, which would cause iomux_doenv() to fail
> therefore causing probe_usb_keyboard() to fail. Furthermore if we do
> have iomux enabled, the sensible thing (in terms of user experience)
> would be to simply add ourselves to the list of stdin devices.
>
> This fixes an issue with usbkbd on dragonboard410c with distro-
> bootcmd, where stdin is not set (so stdinname is null).
>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Tested on RPi3 and a couple of other devices.
> ---
> Somehow this patch was dropped on the floor. I don't remember
> which version # this is up to, search the list if you care. But
> this is the latest. I only noticed it was missing because u-boot
> crashes when you boot with usb-keyboard plugged in (at least on
> db410c) without it. So someone please apply this patch before it
> gets lost again.
>
> common/usb_kbd.c | 46 +++++++++++++++++++++++++++++++---------------
> include/console.h | 2 --
> 2 files changed, 31 insertions(+), 17 deletions(-)
>
> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> index a323d72a36..4c3ad95fca 100644
> --- a/common/usb_kbd.c
> +++ b/common/usb_kbd.c
> @@ -516,23 +516,39 @@ static int probe_usb_keyboard(struct usb_device *dev)
> return error;
>
> stdinname = env_get("stdin");
> -#if CONFIG_IS_ENABLED(CONSOLE_MUX)
> - error = iomux_doenv(stdin, stdinname);
> - if (error)
> - return error;
> -#else
> - /* Check if this is the standard input device. */
> - if (strcmp(stdinname, DEVNAME))
> - return 1;
> + if (CONFIG_IS_ENABLED(CONSOLE_MUX)) {
> + char *devname = DEVNAME;
> + char *newstdin = NULL;
> + /*
> + * stdin might not be set yet.. either way, with console-
> + * mux the sensible thing to do is add ourselves to the
> + * list of stdio devices:
> + */
> + if (stdinname && !strstr(stdinname, DEVNAME)) {
> + newstdin = malloc(strlen(stdinname) +
> + strlen(","DEVNAME) + 1);
> + sprintf(newstdin, "%s,"DEVNAME, stdinname);
> + stdinname = newstdin;
> + } else if (!stdinname) {
> + stdinname = devname;
> + }
> + error = iomux_doenv(stdin, stdinname);
> + free(newstdin);
> + if (error)
> + return error;
> + } else {
> + /* Check if this is the standard input device. */
> + if (strcmp(stdinname, DEVNAME))
> + return 1;
>
> - /* Reassign the console */
> - if (overwrite_console())
> - return 1;
> + /* Reassign the console */
> + if (overwrite_console())
> + return 1;
>
> - error = console_assign(stdin, DEVNAME);
> - if (error)
> - return error;
> -#endif
> + error = console_assign(stdin, DEVNAME);
> + if (error)
> + return error;
> + }
>
> return 0;
> }
> diff --git a/include/console.h b/include/console.h
> index cea29ed6dc..7dfd36d7d1 100644
> --- a/include/console.h
> +++ b/include/console.h
> @@ -57,8 +57,6 @@ int console_announce_r(void);
> /*
> * CONSOLE multiplexing.
> */
> -#ifdef CONFIG_CONSOLE_MUX
> #include <iomux.h>
> -#endif
>
> #endif
> --
> 2.13.5
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply
* [PATCH v3 02/19] vhost: make error handling consistent in rx path
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
In the non-mergeable receive case, when copy_mbuf_to_desc()
call fails the packet is skipped, the corresponding used element
len field is set to vnet header size, and it continues with next
packet/desc. It could be a problem because it does not know why it
failed, and assume the desc buffer is large enough.
In mergeable receive case, when copy_mbuf_to_desc_mergeable()
fails, packets burst is simply stopped.
This patch makes the non-mergeable error path to behave as the
mergeable one, as it seems the safest way. Also, doing this way
will simplify pending IOTLB miss requests handling.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/virtio_net.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index f8732dfec..59ff6c875 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -374,11 +374,8 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
err = copy_mbuf_to_desc(dev, vq, descs, pkts[i], desc_idx, sz);
if (unlikely(err)) {
- used_idx = (start_idx + i) & (vq->size - 1);
- vq->used->ring[used_idx].len = dev->vhost_hlen;
- vhost_log_used_vring(dev, vq,
- offsetof(struct vring_used, ring[used_idx]),
- sizeof(vq->used->ring[used_idx]));
+ count = i;
+ break;
}
if (i + 1 < count)
--
2.13.6
^ permalink raw reply related
* [U-Boot] [PATCH] usb: kbd: Fix dangling pointers on probe fail
From: Peter Robinson @ 2017-10-05 8:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20171003173118.32645-1-robdclark@gmail.com>
On Tue, Oct 3, 2017 at 6:31 PM, Rob Clark <robdclark@gmail.com> wrote:
> If probe fails, we should unregister the stdio device, else we leave
> dangling pointers to the parent 'struct usb_device'.
>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Tested on RPi3 and a couple of other devices.
> ---
> I finally got around to debugging why things explode so badly without
> fixing usb_kbd vs. iomux[1] (which this patch applies on top of).
>
> [1] https://patchwork.ozlabs.org/patch/818881/
>
> common/usb_kbd.c | 30 ++++++++++++++++++++++++------
> 1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> index 4c3ad95fca..82ad93f6ca 100644
> --- a/common/usb_kbd.c
> +++ b/common/usb_kbd.c
> @@ -535,22 +535,40 @@ static int probe_usb_keyboard(struct usb_device *dev)
> error = iomux_doenv(stdin, stdinname);
> free(newstdin);
> if (error)
> - return error;
> + goto unregister_stdio;
> } else {
> /* Check if this is the standard input device. */
> - if (strcmp(stdinname, DEVNAME))
> - return 1;
> + if (strcmp(stdinname, DEVNAME)) {
> + error = -1;
> + goto unregister_stdio;
> + }
>
> /* Reassign the console */
> - if (overwrite_console())
> - return 1;
> + if (overwrite_console()) {
> + error = -1;
> + goto unregister_stdio;
> + }
>
> error = console_assign(stdin, DEVNAME);
> if (error)
> - return error;
> + goto unregister_stdio;
> }
>
> return 0;
> +
> +unregister_stdio:
> + /*
> + * If probe fails, the device will be removed.. leaving dangling
> + * pointers if the stdio device is not unregistered. If u-boot
> + * is built without stdio_deregister(), just pretend to succeed
> + * in order to avoid dangling pointers.
> + */
> +#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)
> + stdio_deregister(DEVNAME, 1);
> + return error;
> +#else
> + return 0;
> +#endif
> }
>
> #ifndef CONFIG_DM_USB
> --
> 2.13.5
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs
From: Igor Mammedov @ 2017-10-05 8:38 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Alistair Francis, qemu-devel@nongnu.org Developers,
Eduardo Habkost, Marcel Apfelbaum
In-Reply-To: <01e129b3-cd06-0a6b-59a1-7a01b95de879@amsat.org>
On Wed, 4 Oct 2017 19:21:09 -0300
Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >>> +const char *netduino_valid_cpus[] = { ARM_CPU_TYPE_NAME("cortex-m3"),
> >> style nit, ^^^ put entries on new line with typical 4 space alignment
> >
> > Do you mean like this?
> >
> > const char *netduino_valid_cpus[] = {
> > ARM_CPU_TYPE_NAME("cortex-m3"),
> > ARM_CPU_TYPE_NAME("cortex-m4"),
> > NULL };
>
> I suppose he meant:
>
> static const char *netduino_valid_cpus[] = {
> ARM_CPU_TYPE_NAME("cortex-m3"),
> ARM_CPU_TYPE_NAME("cortex-m4"),
> NULL
> };
Thanks,
that's exactly what I've meant.
^ permalink raw reply
* Re: [PATCH v4 2/9] lib/librte_power: add extra msg type for policies
From: Hunt, David @ 2017-10-05 8:38 UTC (permalink / raw)
To: santosh, dev
Cc: konstantin.ananyev, jingjing.wu, Nemanja Marjanovic, Rory Sexton
In-Reply-To: <eb73493c-52c1-1637-8088-d7bc96f1432b@caviumnetworks.com>
Hi Santosh,
On 4/10/2017 4:36 PM, santosh wrote:
> Hi David,
>
>
> On Wednesday 04 October 2017 02:45 PM, David Hunt wrote:
>> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
>> Signed-off-by: Rory Sexton <rory.sexton@intel.com>
>> Signed-off-by: David Hunt <david.hunt@intel.com>
>> ---
> my 2cent:
> General comment on implementation approach:
> IMO, we should avoid PMD details in common lib area.
> example: file channel_commons.h has ifdef clutter referencing
> i40e pmds all over.
>
> Perhaps we should introduce opaque handle example void * or introduce pmd
> specific callback/handle which points to PMD specific metadata in power library.
>
> Example:
> struct channel_packet {
> void *pmd_specific_metadata;
> }
>
> Or someway via callback (I'm not sure at the moment)
> so that we could hide PMD details in common area.
>
> Thanks.
I would agree that PMD specific details are good left to the PMDs,
however I think that the initial
example should be OK as is, and as new PMDs are added, we can find
commonality between them
which stays in the example, and any really specific stuff can be pushed
back behind an opaque.
What about the v5 I submitted (without the #ifdef's)? Are you OK with
that for this release, and we can
fine tune as other PMDS are added in future releases?
Regards,
Dave.
^ permalink raw reply
* [PATCH v3 03/19] vhost: prepare send_vhost_message() to slave requests
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
send_vhost_message() is currently only used to send
replies, so it modifies message flags to perpare the
reply.
With upcoming channel for backend initiated request,
this function can be used to send requests.
This patch introduces a new send_vhost_reply() that
does the message flags modifications, and makes
send_vhost_message() generic.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost_user.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index b62e3828b..a068d8651 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -919,8 +919,16 @@ read_vhost_message(int sockfd, struct VhostUserMsg *msg)
static int
send_vhost_message(int sockfd, struct VhostUserMsg *msg)
{
- int ret;
+ if (!msg)
+ return 0;
+
+ return send_fd_message(sockfd, (char *)msg,
+ VHOST_USER_HDR_SIZE + msg->size, NULL, 0);
+}
+static int
+send_vhost_reply(int sockfd, struct VhostUserMsg *msg)
+{
if (!msg)
return 0;
@@ -929,10 +937,7 @@ send_vhost_message(int sockfd, struct VhostUserMsg *msg)
msg->flags |= VHOST_USER_VERSION;
msg->flags |= VHOST_USER_REPLY_MASK;
- ret = send_fd_message(sockfd, (char *)msg,
- VHOST_USER_HDR_SIZE + msg->size, NULL, 0);
-
- return ret;
+ return send_vhost_message(sockfd, msg);
}
/*
@@ -1024,7 +1029,7 @@ vhost_user_msg_handler(int vid, int fd)
case VHOST_USER_GET_FEATURES:
msg.payload.u64 = vhost_user_get_features(dev);
msg.size = sizeof(msg.payload.u64);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
break;
case VHOST_USER_SET_FEATURES:
vhost_user_set_features(dev, msg.payload.u64);
@@ -1033,7 +1038,7 @@ vhost_user_msg_handler(int vid, int fd)
case VHOST_USER_GET_PROTOCOL_FEATURES:
msg.payload.u64 = VHOST_USER_PROTOCOL_FEATURES;
msg.size = sizeof(msg.payload.u64);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
break;
case VHOST_USER_SET_PROTOCOL_FEATURES:
vhost_user_set_protocol_features(dev, msg.payload.u64);
@@ -1055,7 +1060,7 @@ vhost_user_msg_handler(int vid, int fd)
/* it needs a reply */
msg.size = sizeof(msg.payload.u64);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
break;
case VHOST_USER_SET_LOG_FD:
close(msg.fds[0]);
@@ -1075,7 +1080,7 @@ vhost_user_msg_handler(int vid, int fd)
case VHOST_USER_GET_VRING_BASE:
vhost_user_get_vring_base(dev, &msg);
msg.size = sizeof(msg.payload.state);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
break;
case VHOST_USER_SET_VRING_KICK:
@@ -1094,7 +1099,7 @@ vhost_user_msg_handler(int vid, int fd)
case VHOST_USER_GET_QUEUE_NUM:
msg.payload.u64 = VHOST_MAX_QUEUE_PAIRS;
msg.size = sizeof(msg.payload.u64);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
break;
case VHOST_USER_SET_VRING_ENABLE:
@@ -1117,7 +1122,7 @@ vhost_user_msg_handler(int vid, int fd)
if (msg.flags & VHOST_USER_NEED_REPLY) {
msg.payload.u64 = !!ret;
msg.size = sizeof(msg.payload.u64);
- send_vhost_message(fd, &msg);
+ send_vhost_reply(fd, &msg);
}
if (!(dev->flags & VIRTIO_DEV_RUNNING) && virtio_is_ready(dev)) {
--
2.13.6
^ permalink raw reply related
* Re: Patch "spi: pxa2xx: Add support for Intel Gemini Lake" has been added to the 4.9-stable tree
From: Mark Brown @ 2017-10-05 8:39 UTC (permalink / raw)
To: gregkh; +Cc: david.e.box, alexander.levin, jarkko.nikula, stable,
stable-commits
In-Reply-To: <1507192239101116@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 315 bytes --]
On Thu, Oct 05, 2017 at 10:30:39AM +0200, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> spi: pxa2xx: Add support for Intel Gemini Lake
Hrm, not a great problem with this but this is the first I heard of this
being proposed for stable?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 4/8] ethdev: add GTP items to support flow API
From: Wu, Jingjing @ 2017-10-05 8:39 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Sean Harte, Xing, Beilei, Chilikin, Andrey, dev@dpdk.org
In-Reply-To: <20171005083019.GY3871@6wind.com>
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Thursday, October 5, 2017 4:30 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Sean Harte <seanbh@gmail.com>; Xing, Beilei <beilei.xing@intel.com>; Chilikin,
> Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 4/8] ethdev: add GTP items to support flow API
>
> On Thu, Oct 05, 2017 at 08:06:38AM +0000, Wu, Jingjing wrote:
> >
> >
> > > -----Original Message-----
> > > From: Sean Harte [mailto:seanbh@gmail.com]
> > > Sent: Tuesday, October 3, 2017 4:57 PM
> > > To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > > Cc: Xing, Beilei <beilei.xing@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>;
> Chilikin,
> > > Andrey <andrey.chilikin@intel.com>; dev@dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v6 4/8] ethdev: add GTP items to support flow API
> > >
> > > On 2 October 2017 at 13:27, Adrien Mazarguil <adrien.mazarguil@6wind.com>
> wrote:
> > > > On Fri, Sep 29, 2017 at 10:29:55AM +0100, Sean Harte wrote:
> > > >> On 29 September 2017 at 09:54, Xing, Beilei <beilei.xing@intel.com> wrote:
> > > > <snip>
> > > >> >> > /**
> > > >> >> > + * RTE_FLOW_ITEM_TYPE_GTP.
> > > >> >> > + *
> > > >> >> > + * Matches a GTPv1 header.
> > > >> >> > + */
> > > >> >> > +struct rte_flow_item_gtp {
> > > >> >> > + /**
> > > >> >> > + * Version (3b), protocol type (1b), reserved (1b),
> > > >> >> > + * Extension header flag (1b),
> > > >> >> > + * Sequence number flag (1b),
> > > >> >> > + * N-PDU number flag (1b).
> > > >> >> > + */
> > > >> >> > + uint8_t v_pt_rsv_flags;
> > > >> >> > + uint8_t msg_type; /**< Message type. */
> > > >> >> > + rte_be16_t msg_len; /**< Message length. */
> > > >> >> > + rte_be32_t teid; /**< Tunnel endpoint identifier. */ };
> > > >> >>
> > > >> >> In future, you might add support for GTPv2 (which is used since LTE).
> > > >> >> Maybe this structure should have v1 in its name to avoid confusion?
> > > >> >
> > > >> > I considered it before. But I think we can modify it when we support GTPv2 in
> future,
> > > and keep concise 'GTP' currently:) since I have described it matches v1 header.
> > > >> >
> > > >>
> > > >> You could rename v_pt_rsv_flags to version_flags to avoid some future
> > > >> code changes to support GTPv2. There's still the issue that not all
> > > >> GTPv2 messages have a TEID though.
> > > >
> > > > Although they have the same size, the header of these two protocols
> > > > obviously differs. My suggestion would be to go with a separate GTPv2
> > > > pattern item using its own dedicated structure instead.
> > > >
> > > > --
> > > > Adrien Mazarguil
> > > > 6WIND
> > >
> > > The 1st four bytes are the same (flags in first byte have different
> > > meanings, but the bits indicating the version are in the same
> > > location). After that, different fields in each version are optional,
> > > and the headers have variable size. A single structure could be used
> > > if the first field is renamed to something like "version_flags", and
> > > then check that the teid field in item->mask is not set if
> > > ((version_flags >> 5 == 2) && ((version_flags >> 4) & 1) == 1). If
> > > there's going to be two structures, it would be good to put v1 and v2
> > > in the names, in my opinion.
> >
> > I think the name GTP is OK for now. Due to v1 and v2 are different, why not rename
> them
> > when the v2 supporting are introduced?
>
> In any case I'd rather avoid renaming and modifying existing items and
> structure contents once part of the API to avoid API/ABI breakage that
> require deprecation notices, user applications updates and so on; rte_flow
> has been created as a kind of append-only API for this reason (of course
> there are exceptions, such as a bad design choice for the VLAN item I intend
> to fix at some point).
>
> I'm fine with the name "GTP" as defined now and documented as matching
> GTPv1. We can add "GTPv2"-themed definitions later when some implementation
> provides the ability to match this version. If you want to append the "v1"
> suffix right now to be more explicit, I'm also fine with that. Your call.
>
Got your point, I'm also fine with the name now for GTPv1, and add "GTPv2" when
It is supported.
Thanks
Jingjing
^ permalink raw reply
* [PATCH v3 04/19] vhost: add support to slave requests channel
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
Currently, only QEMU sends requests, the backend sends
replies. In some cases, the backend may need to send
requests to QEMU, like IOTLB miss events when IOMMU is
supported.
This patch introduces a new channel for such requests.
QEMU sends a file descriptor of a new socket using
VHOST_USER_SET_SLAVE_REQ_FD.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost.c | 1 +
lib/librte_vhost/vhost.h | 2 ++
lib/librte_vhost/vhost_user.c | 27 +++++++++++++++++++++++++++
lib/librte_vhost/vhost_user.h | 10 +++++++++-
4 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 474b6e493..2d30f14c4 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -207,6 +207,7 @@ vhost_new_device(void)
vhost_devices[i] = dev;
dev->vid = i;
+ dev->slave_req_fd = -1;
return i;
}
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 74df74717..8405f879b 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -209,6 +209,8 @@ struct virtio_net {
uint32_t nr_guest_pages;
uint32_t max_guest_pages;
struct guest_page *guest_pages;
+
+ int slave_req_fd;
} __rte_cache_aligned;
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index a068d8651..0ba66e193 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -76,6 +76,7 @@ static const char *vhost_message_str[VHOST_USER_MAX] = {
[VHOST_USER_SET_VRING_ENABLE] = "VHOST_USER_SET_VRING_ENABLE",
[VHOST_USER_SEND_RARP] = "VHOST_USER_SEND_RARP",
[VHOST_USER_NET_SET_MTU] = "VHOST_USER_NET_SET_MTU",
+ [VHOST_USER_SET_SLAVE_REQ_FD] = "VHOST_USER_SET_SLAVE_REQ_FD",
};
static uint64_t
@@ -122,6 +123,11 @@ vhost_backend_cleanup(struct virtio_net *dev)
munmap((void *)(uintptr_t)dev->log_addr, dev->log_size);
dev->log_addr = 0;
}
+
+ if (dev->slave_req_fd >= 0) {
+ close(dev->slave_req_fd);
+ dev->slave_req_fd = -1;
+ }
}
/*
@@ -886,6 +892,23 @@ vhost_user_net_set_mtu(struct virtio_net *dev, struct VhostUserMsg *msg)
return 0;
}
+static int
+vhost_user_set_req_fd(struct virtio_net *dev, struct VhostUserMsg *msg)
+{
+ int fd = msg->fds[0];
+
+ if (fd < 0) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "Invalid file descriptor for slave channel (%d)\n",
+ fd);
+ return -1;
+ }
+
+ dev->slave_req_fd = fd;
+
+ return 0;
+}
+
/* return bytes# of read on success or negative val on failure. */
static int
read_vhost_message(int sockfd, struct VhostUserMsg *msg)
@@ -1113,6 +1136,10 @@ vhost_user_msg_handler(int vid, int fd)
ret = vhost_user_net_set_mtu(dev, &msg);
break;
+ case VHOST_USER_SET_SLAVE_REQ_FD:
+ ret = vhost_user_set_req_fd(dev, &msg);
+ break;
+
default:
ret = -1;
break;
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index 2ba22dbb0..98f6e6f37 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -48,12 +48,14 @@
#define VHOST_USER_PROTOCOL_F_RARP 2
#define VHOST_USER_PROTOCOL_F_REPLY_ACK 3
#define VHOST_USER_PROTOCOL_F_NET_MTU 4
+#define VHOST_USER_PROTOCOL_F_SLAVE_REQ 5
#define VHOST_USER_PROTOCOL_FEATURES ((1ULL << VHOST_USER_PROTOCOL_F_MQ) | \
(1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD) |\
(1ULL << VHOST_USER_PROTOCOL_F_RARP) | \
(1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK) | \
- (1ULL << VHOST_USER_PROTOCOL_F_NET_MTU))
+ (1ULL << VHOST_USER_PROTOCOL_F_NET_MTU) | \
+ (1ULL << VHOST_USER_PROTOCOL_F_SLAVE_REQ))
typedef enum VhostUserRequest {
VHOST_USER_NONE = 0,
@@ -77,9 +79,15 @@ typedef enum VhostUserRequest {
VHOST_USER_SET_VRING_ENABLE = 18,
VHOST_USER_SEND_RARP = 19,
VHOST_USER_NET_SET_MTU = 20,
+ VHOST_USER_SET_SLAVE_REQ_FD = 21,
VHOST_USER_MAX
} VhostUserRequest;
+typedef enum VhostUserSlaveRequest {
+ VHOST_USER_SLAVE_NONE = 0,
+ VHOST_USER_SLAVE_MAX
+} VhostUserSlaveRequest;
+
typedef struct VhostUserMemoryRegion {
uint64_t guest_phys_addr;
uint64_t memory_size;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH] mm: readahead: Increase maximum readahead window
From: Jan Kara @ 2017-10-05 8:39 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: Jan Kara, Andrew Morton, linux-fsdevel, linux-mm
In-Reply-To: <20171004174151.GA6497@magnolia>
On Wed 04-10-17 10:41:51, Darrick J. Wong wrote:
> On Wed, Oct 04, 2017 at 11:12:05AM +0200, Jan Kara wrote:
> > Increase default maximum allowed readahead window from 128 KB to 512 KB.
> > This improves performance for some workloads (see below for details) where
> > ability to scale readahead window to larger sizes allows for better total
> > throughput while chances for regression are rather low given readahead
> > window size is dynamically computed based on observation (and thus it never
> > grows large for workloads with a random read pattern).
> >
> > Note that the same tuning can be done using udev rules or by manually setting
> > the sysctl parameter however we believe the new value is a better default most
> > users will want to use. As a data point we carry this patch in SUSE kernels
> > for over 8 years.
> >
> > Some data from the last evaluation of this patch (on 4.4-based kernel, I can
> > rerun those tests on a newer kernel but nothing has changed in the readahead
> > area since 4.4). The patch was evaluated on two machines
>
> This is purely speculating, but I think this is worth at least a quick
> retry on 4.14 to see what's changed in the past 10 kernel release. For
> one thing, ext3 no longer exists, and XFS' file IO path has changed
> quite a lot since then.
ext3 in this test is actually using ext4 driver already, so that has not
changed. I agree XFS has changed quite a bit so results might differ there.
I can rerun it with current kernel to see whether XFS behavior changed.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v4 07/15] x86: implement set value flow for MBA
From: Roger Pau Monné @ 2017-10-05 8:39 UTC (permalink / raw)
To: Yi Sun; +Cc: andrew.cooper3, wei.liu2, xen-devel, Jan Beulich, chao.p.peng
In-Reply-To: <20171005044812.GH11006@yi.y.sun>
On Thu, Oct 05, 2017 at 04:48:12AM +0000, Yi Sun wrote:
> On 17-10-03 23:59:46, Jan Beulich wrote:
> > >>> Yi Sun <yi.y.sun@linux.intel.com> 09/29/17 4:58 AM >>>
> > >On 17-09-28 05:36:11, Jan Beulich wrote:
> > >> >>> On 23.09.17 at 11:48, <yi.y.sun@linux.intel.com> wrote:
> > >> > - feat->cos_reg_val[cos * cos_num + i] = info->val[i];
> > >> > - props->write_msr(cos, info->val[i], props->type[i]);
> > >> > + if ( feat->cos_reg_val[cos * cos_num + j] != val_array[index + j] )
> > >> > + feat->cos_reg_val[cos * cos_num + j] =
> > >> > + props->write_msr(cos, val_array[index + j], props->type[j]);
> > >>
> > >> This renders partly useless the check: If hardware can alter the
> > >> value, repeatedly requesting the same value to be written will
> > >> no longer guarantee the MSR write to be skipped. If hardware
> > >> behavior can't be predicted you may want to consider recording
> > >> both the value in found by reading back the register written and
> > >> the value that was written - a match with either would eliminate
> > >> the need to do the write.
> > >>
> > >The hardware behavior is explicitly defined by SDM and mentioned in
> > >'xl-psr.markdown' and 'intel_psr_mba.pandoc'. User should know that HW
> > >can alter MBA value if the value is not valid.
> >
> > So if hardware behavior is fully defined, why don't you pre-adjust what is
> > to be written to the value hardware would alter it to?
> >
> In previous version of MBA patch set, I pre-adjust the value in 'mba_check_thrtl'.
> But Roger did not like that. So, the pre-adjust codes are removed.
IMHO it's quite pointless to do such adjustments when the hardware
performs them already. Also, I fear that our adjustments might get
out-of-sync in the future with what hardware actually does.
Maybe the result read back from the hardware (ie: adjusted) can be
stored and used in order to check whether a new value should be
written or not when switching? (I think this is the same that Jan
suggested above).
Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH v3 05/19] vhost: declare missing IOMMU-related definitions for old kernels
From: Maxime Coquelin @ 2017-10-05 8:36 UTC (permalink / raw)
To: dev, remy.horton, tiwei.bie, yliu
Cc: mst, jfreiman, vkaplans, jasowang, Maxime Coquelin
In-Reply-To: <20171005083627.27828-1-maxime.coquelin@redhat.com>
These defines and enums have been introduced in upstream kernel v4.8,
and backported to RHEL 7.4.
Signed-off-by: Maxime Coquelin <maxime.coquelin@redhat.com>
---
lib/librte_vhost/vhost.h | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 8405f879b..94bee4c8d 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -145,6 +145,37 @@ struct vhost_virtqueue {
#define VIRTIO_NET_F_MTU 3
#endif
+/* Declare IOMMU related bits for older kernels */
+#ifndef VIRTIO_F_IOMMU_PLATFORM
+
+#define VIRTIO_F_IOMMU_PLATFORM 33
+
+struct vhost_iotlb_msg {
+ __u64 iova;
+ __u64 size;
+ __u64 uaddr;
+#define VHOST_ACCESS_RO 0x1
+#define VHOST_ACCESS_WO 0x2
+#define VHOST_ACCESS_RW 0x3
+ __u8 perm;
+#define VHOST_IOTLB_MISS 1
+#define VHOST_IOTLB_UPDATE 2
+#define VHOST_IOTLB_INVALIDATE 3
+#define VHOST_IOTLB_ACCESS_FAIL 4
+ __u8 type;
+};
+
+#define VHOST_IOTLB_MSG 0x1
+
+struct vhost_msg {
+ int type;
+ union {
+ struct vhost_iotlb_msg iotlb;
+ __u8 padding[64];
+ };
+};
+#endif
+
/*
* Define virtio 1.0 for older kernels
*/
--
2.13.6
^ 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.