With one worker we will always send the scsi cmd responses then send the
TMF rsp, because LIO will always complete the scsi cmds first then call
into us to send the TMF response.
With multiple workers, one of the IO vq threads could be run after the
TMF is queued, so this has us flush all the IO
This patch allows userspace to create workers and bind them to vqs. You
can have N workers per dev and also share N workers with M vqs.
Signed-off-by: Mike Christie
---
drivers/vhost/vhost.c| 99
drivers/vhost/vhost.h| 2 +-
This patch separates the scsi cmd completion code paths so we can complete
cmds based on their vq instead of having all cmds complete on the same
worker/CPU. This will be useful with the next patches that allow us to
create mulitple worker threads and bind them to different vqs, so we can
have
vhost_work_queue and vhost_work_dev_flush are no longer used, so drop
them.
Signed-off-by: Mike Christie
---
drivers/vhost/vhost.c | 12
drivers/vhost/vhost.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index
Convert from vhost dev based helpers to vq ones.
Signed-off-by: Mike Christie
---
drivers/vhost/scsi.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
index 0d85ddb68420..08beba73ada4 100644
---
Convert from vhost dev based helpers to vq ones.
Signed-off-by: Mike Christie
---
drivers/vhost/vsock.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 938aefbc75ec..c50c60d0955e 100644
--- a/drivers/vhost/vsock.c
This patch has the core work flush function take a worker for when we
support multiple workers. It also adds a helper that takes a vq during
flushing so modules can control which vq/worker to flush.
This temp leaves vhost_work_dev_flush. It will be removed when the drivers
are converted in the
This patch has the core work queueing function take a worker for when we
support multiple workers. It also adds a helper that takes a vq during
queueing so modules can control which vq/worker to queue work on.
This temp leaves vhost_work_queue. It will be removed when the drivers
are converted in
This adds a helper to check if a vq has work pending and converts
vhost-net to use it.
Signed-off-by: Mike Christie
---
drivers/vhost/net.c | 2 +-
drivers/vhost/vhost.c | 6 +++---
drivers/vhost/vhost.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git
This has the drivers pass in their poll to vq mapping and then converts
the core poll code to use the vq based helpers.
Signed-off-by: Mike Christie
---
drivers/vhost/net.c | 6 --
drivers/vhost/vhost.c | 10 ++
drivers/vhost/vhost.h | 4 +++-
3 files changed, 13 insertions(+),
The following patches apply over linus's tree and this patchset
https://lore.kernel.org/all/20211007214448.6282-1-michael.chris...@oracle.com/
which allows us to check the vhost owner thread's RLIMITs:
It looks like that patchset has been ok'd by all the major parties
and just needs a small
This patch adds support for the proposed ioctl that allows userspace
to create virtqueue workers. For vhost-scsi you can set virtqueue_workers
to:
0: default behavior where we have 1 worker for all vqs.
-1: create a worker per vq.
>0: create N workers and allow the vqs to share them.
TODO:
-
This patchset allows userspace to map vqs to different workers. This
patch adds a worker pointer to the vq so we can store that info.
Signed-off-by: Mike Christie
---
drivers/vhost/vhost.c | 24 +---
drivers/vhost/vhost.h | 1 +
2 files changed, 14 insertions(+), 11
On Thu, Oct 21, 2021 at 4:52 AM Gerd Hoffmann wrote:
>
> On Thu, Oct 21, 2021 at 11:55:47AM +0200, Maksym Wezdecki wrote:
> > I get your point. However, we need to make resource_create ioctl,
> > in order to create corresponding resource on the host.
>
> That used to be the case but isn't true
From: Eli Cohen
Add rules to forward packets to the net device's TIR only if the
destination MAC is equal to the configured MAC. This is required to
prevent the netdevice from receiving traffic not destined to its
configured MAC.
Signed-off-by: Eli Cohen
Reviewed-by: Parav Pandit
---
Cited patch in the fixes tag clears the features bit during reset.
mlx5 vdpa device feature bits are static decided by device capabilities.
Clearing features bit cleared the VIRTIO_NET_F_MAC. Due to this MAC address
provided by the device is not honored.
Fix it by not clearing the static feature
From: Eli Cohen
Add code to accept MAC configuration through vdpa tool. The MAC is
written into the config struct and later can be retrieved through
get_config().
Examples:
1. Configure MAC while adding a device:
$ vdpa dev add mgmtdev pci/:06:00.2 name vdpa0 mac 00:11:22:33:44:55
2. Show
Enable user to set the mac address and mtu so that each vdpa device
can have its own user specified mac address and mtu.
This is done by implementing the management device's configuration
layout fields setting callback routine.
Now that user is enabled to set the mac address, remove the module
$ vdpa dev add name bar mgmtdev vdpasim_net mac 00:11:22:33:44:55 mtu 9000
$ vdpa dev config show
bar: mac 00:11:22:33:44:55 link up link_announce false mtu 9000
$ vdpa dev config show -jp
{
"config": {
"bar": {
"mac": "00:11:22:33:44:55",
"link ": "up",
As subsequent patch adds new structure field with comment, move the
structure comment to follow kernel coding style.
Signed-off-by: Parav Pandit
Reviewed-by: Eli Cohen
---
include/linux/vdpa.h | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/linux/vdpa.h
Introduce a command to query a device config layout.
An example query of network vdpa device:
$ vdpa dev add name bar mgmtdev vdpasim_net
$ vdpa dev config show
bar: mac 00:35:09:19:48:05 link up link_announce false mtu 1500
$ vdpa dev config show -jp
{
"config": {
"bar": {
Currently user cannot view the vdpa device config space. Also user
cannot set the mac address and mtu of the vdpa device.
This patchset enables users to set the mac address and mtu of the vdpa
device once the device is created.
If a vendor driver supports such configuration user can set it
Subsequent patches enable get and set configuration either
via management device or via vdpa device' config ops.
This requires synchronization between multiple callers to get and set
config callbacks. Features setting also influence the layout of the
configuration fields endianness.
To avoid
On Thu, Oct 21, 2021 at 06:51:11AM +, cgel@gmail.com wrote:
From: Ye Guojin
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot
On Thu, Oct 21, 2021 at 11:55:47AM +0200, Maksym Wezdecki wrote:
> I get your point. However, we need to make resource_create ioctl,
> in order to create corresponding resource on the host.
That used to be the case but isn't true any more with the new
blob resources. virglrenderer allows to
This patch adds IRQ support for the virtio GPIO driver. Note that this
uses the irq_bus_lock/unlock() callbacks, since those operations over
virtio may sleep.
Reviewed-by: Linus Walleij
Signed-off-by: Viresh Kumar
---
Bartosz,
The spec changes are close to merging now, I will let you know once
On 21-10-21, 13:02, Geert Uytterhoeven wrote:
> Exactly. And on CRIS (no longer supported by Linux), there won't
> be any padding.
>
> So I recommend to always add explicit padding, to make sure all
> members are aligned naturally on all systems.
Right.
--
viresh
Hi Viresh,
On Thu, Oct 21, 2021 at 12:49 PM Viresh Kumar wrote:
> On 21-10-21, 12:07, Geert Uytterhoeven wrote:
> > On Thu, Oct 21, 2021 at 11:52 AM Viresh Kumar
> > wrote:
> > > The structure will get aligned to the size of largest element and each
> > > element will be aligned to itself. I
On 21-10-21, 12:07, Geert Uytterhoeven wrote:
> On Thu, Oct 21, 2021 at 11:52 AM Viresh Kumar wrote:
> > The structure will get aligned to the size of largest element and each
> > element will be aligned to itself. I don't see how this will break
> > even in case of 32/64 bit communication.
>
>
Hi Viresh,
On Thu, Oct 21, 2021 at 11:52 AM Viresh Kumar wrote:
> The structure will get aligned to the size of largest element and each
> element will be aligned to itself. I don't see how this will break
> even in case of 32/64 bit communication.
Structures are not aligned to the size of the
On 21-10-21, 12:58, Andy Shevchenko wrote:
> I admit I haven't looked into the specification, but in the past we
> had had quite an issue exactly in GPIO on kernel side because of this
> kind of design mistake.
> The problem here if in the future one wants to
> supply more than one item at a
On Thu, Oct 21, 2021 at 12:52 PM Viresh Kumar wrote:
> On 21-10-21, 12:42, Andy Shevchenko wrote:
> > On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar
> > wrote:
> > > On 20-10-21, 18:10, Andy Shevchenko wrote:
...
> > > > > struct virtio_gpio_config {
> > > > > __le16 ngpio;
> > > > >
On 21-10-21, 12:42, Andy Shevchenko wrote:
> On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar wrote:
> > On 20-10-21, 18:10, Andy Shevchenko wrote:
> > > IIRC you add dead code. IRQ framework never calls this if type is not set.
> >
> > Yes, but it is allowed to call
> >
> > irq_set_irq_type(irq,
The virtio specification received a new mandatory feature
(VIRTIO_I2C_F_ZERO_LENGTH_REQUEST) for zero length requests. Fail if the
feature isn't offered by the device.
For each read-request, set the VIRTIO_I2C_FLAGS_M_RD flag, as required
by the VIRTIO_I2C_F_ZERO_LENGTH_REQUEST feature.
This
On Thu, Oct 21, 2021 at 7:34 AM Viresh Kumar wrote:
> On 20-10-21, 18:10, Andy Shevchenko wrote:
> > On Wednesday, October 20, 2021, Viresh Kumar
> > wrote:
...
> > > + case IRQ_TYPE_NONE:
> > > + type = VIRTIO_GPIO_IRQ_TYPE_NONE;
> > > + break;
> >
> > IIRC
On Thu, 2021-10-21 at 06:51 +, cgel@gmail.com wrote:
> From: Ye Guojin
>
> coccicheck complains about the use of snprintf() in sysfs show
> functions:
> WARNING use scnprintf or sprintf
>
> Use sysfs_emit instead of scnprintf or sprintf makes more sense.
[]
> diff --git
On Thu, Oct 21, 2021 at 09:44:45AM +0200, Maksym Wezdecki wrote:
> From: mwezdeck
>
> The idea behind the commit:
> 1. when resource is created, let user space decide
> if resource should be pinned or not
> 2. transfer_*_host needs pinned memory. If it is not
> pinned, then pin it.
On Thu, Oct 21, 2021 at 12:08:23AM -0700, Joe Perches wrote:
> On Thu, 2021-10-21 at 06:51 +, cgel@gmail.com wrote:
> > From: Ye Guojin
> >
> > coccicheck complains about the use of snprintf() in sysfs show
> > functions:
> > WARNING use scnprintf or sprintf
> >
> > Use sysfs_emit
On Thu, Oct 21, 2021 at 06:51:11AM +, cgel@gmail.com wrote:
> From: Ye Guojin
>
> coccicheck complains about the use of snprintf() in sysfs show
> functions:
> WARNING use scnprintf or sprintf
>
> Use sysfs_emit instead of scnprintf or sprintf makes more sense.
>
> Reported-by: Zeal
Repalce kthread_create/wake_up_process() with kthread_run()
to simplify the code.
Signed-off-by: Cai Huoqing
---
drivers/vhost/vhost.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 59edb5a1ffe2..e67bd5603b5f 100644
On Fri, Oct 15, 2021 at 10:46:55AM +0800, Xianting Tian wrote:
> Dear all,
>
> This patch series make hvc framework pass DMA capable memory to
> put_chars() of hvc backend(eg, virtio-console), and revert commit
> c4baad5029 ("virtio-console: avoid DMA from stack”)
Thanks for sticking with this,
On Thu, Oct 21, 2021 at 11:29 AM Xie Yongji wrote:
>
> Commit 1018722ef0b7 ("vduse: Fix race condition between resetting and
> irq injecting") tries to fix a race condition like:
>
> CPU0 CPU1
>
>
From: Joerg Roedel
When code running on the VC2 stack causes a nested VC exception, the
handler will not handle it as expected but goes again into the error
path.
The result is that the panic() call happening when the VC exception
was raised in an invalid context is called recursively. Fix this
From: Joerg Roedel
The value of STACK_TYPE_EXCEPTION_LAST points to the last _valid_
exception stack. Reflect that in the check done in the
vc_switch_off_ist() function.
Reported-by: Tom Lendacky
Fixes: a13644f3a53de ("x86/entry/64: Add entry code for #VC handler")
Signed-off-by: Joerg Roedel
From: Joerg Roedel
Hi,
here are two fixes for recently discovered issues in the handling of
VC handler stack.
Please review.
Thanks,
Joerg
Joerg Roedel (2):
x86/sev: Fix stack type check in vc_switch_off_ist()
x86/sev: Allow #VC exceptions on the VC2 stack
From: mwezdeck
The idea behind the commit:
1. when resource is created, let user space decide
if resource should be pinned or not
2. transfer_*_host needs pinned memory. If it is not
pinned, then pin it.
3. during execbuffer, decide which bo handles should
be pinned based on
> From: Jean-Philippe Brucker
> Sent: Wednesday, October 13, 2021 8:11 PM
>
> Support identity domains, allowing to only enable IOMMU protection for a
> subset of endpoints (those assigned to userspace, for example). Users
> may enable identity domains at compile time
>
> From: Jean-Philippe Brucker
> Sent: Monday, October 18, 2021 11:24 PM
>
> On Thu, Oct 14, 2021 at 03:00:38AM +, Tian, Kevin wrote:
> > > From: Jean-Philippe Brucker
> > > Sent: Wednesday, October 13, 2021 8:11 PM
> > >
> > > Support identity domains, allowing to only enable IOMMU
> From: j...@8bytes.org
> Sent: Monday, October 18, 2021 7:38 PM
>
> On Thu, Oct 14, 2021 at 03:00:38AM +, Tian, Kevin wrote:
> > I saw a concept of deferred attach in iommu core. See iommu_is_
> > attach_deferred(). Currently this is vendor specific and I haven't
> > looked into the exact
49 matches
Mail list logo
