similar to: Potential hang in virtnet_send_command

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so it's in theory (on extreme memory pressure) possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers into a separate structure. Reported-by: Mikulas

Hi Jason, On 4/13/23 08:40, Jason Wang wrote: > Hi all: > > The code used to busy poll for cvq command which turns out to have > several side effects: > > 1) infinite poll for buggy devices > 2) bad interaction with scheduler > > So this series tries to use sleep instead of busy polling. In this > version, I take a step back: the hardening part is not implemented

On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > On 7/20/23 1:38 AM, Jason Wang wrote: > > > > Adding cond_resched() to the command waiting loop for a better > > co-operation with the scheduler. This allows to give CPU a breath to > > run other task(workqueue) instead of busy looping when preemption is > > not allowed on a device whose CVQ might

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so in theory (on extreme memory pressure) it's possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers out into a separate structure. Reported-by:

On 7/20/23 23:02, Michael S. Tsirkin wrote: > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: >> On 7/20/23 1:38 AM, Jason Wang wrote: >>> >>> Adding cond_resched() to the command waiting loop for a better >>> co-operation with the scheduler. This allows to give CPU a breath to >>> run other task(workqueue) instead of busy looping when

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep instead of busy polling. In this version, I take a step back: the hardening part is not implemented and leave for future investigation. We use to aggree to use interruptible sleep but it

On Fri, Jul 21, 2023 at 04:37:00PM +0200, Maxime Coquelin wrote: > > > On 7/20/23 23:02, Michael S. Tsirkin wrote: > > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > > > On 7/20/23 1:38 AM, Jason Wang wrote: > > > > > > > > Adding cond_resched() to the command waiting loop for a better > > > > co-operation with the

On 7/21/23 16:45, Michael S. Tsirkin wrote: > On Fri, Jul 21, 2023 at 04:37:00PM +0200, Maxime Coquelin wrote: >> >> >> On 7/20/23 23:02, Michael S. Tsirkin wrote: >>> On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: >>>> On 7/20/23 1:38 AM, Jason Wang wrote: >>>>> >>>>> Adding cond_resched() to the command

On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > We used to busy waiting on the cvq command this tends to be > problematic since there no way for to schedule another process which > may serve for the control virtqueue. This might be the case when the > control virtqueue is emulated by software. This patch switches to use > completion to allow

On Fri, Jul 21, 2023 at 04:58:04PM +0200, Maxime Coquelin wrote: > > > On 7/21/23 16:45, Michael S. Tsirkin wrote: > > On Fri, Jul 21, 2023 at 04:37:00PM +0200, Maxime Coquelin wrote: > > > > > > > > > On 7/20/23 23:02, Michael S. Tsirkin wrote: > > > > On Thu, Jul 20, 2023 at 01:26:20PM -0700, Shannon Nelson wrote: > > > > >

On Thu, Apr 13, 2023 at 3:31?PM Xuan Zhuo <xuanzhuo at linux.alibaba.com> wrote: > > On Thu, 13 Apr 2023 14:40:27 +0800, Jason Wang <jasowang at redhat.com> wrote: > > We used to busy waiting on the cvq command this tends to be > > problematic since there no way for to schedule another process which > > may serve for the control virtqueue. This might be the case

On Tue, Jul 04, 2023 at 10:43:07AM +0200, Maxime Coquelin wrote: > > > On 7/3/23 23:45, Michael S. Tsirkin wrote: > > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > > > > > On 7/3/23 08:44, Jason Wang wrote: > > > > On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > >

On 7/3/23 23:45, Michael S. Tsirkin wrote: > On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: >> >> On 7/3/23 08:44, Jason Wang wrote: >>> On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at redhat.com> wrote: >>>> >>>> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>>>> This small series

On Mon, Jul 03, 2023 at 09:43:49AM +0200, Maxime Coquelin wrote: > > On 7/3/23 08:44, Jason Wang wrote: > > On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > > > This small series enables virtio-net device type in VDUSE. > > > >

On 7/3/23 08:44, Jason Wang wrote: > On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at redhat.com> wrote: >> >> On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: >>> This small series enables virtio-net device type in VDUSE. >>> With it, basic operation have been tested, both with >>> virtio-vdpa and vhost-vdpa using DPDK Vhost

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use sleep + timeout instead of busy polling. Please review. Thanks Changes since RFC: - switch to use BAD_RING in virtio_break_device() - check virtqueue_is_broken() after being woken up - use

On Sun, Jul 2, 2023 at 9:37?PM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Tue, Jun 27, 2023 at 01:36:50PM +0200, Maxime Coquelin wrote: > > This small series enables virtio-net device type in VDUSE. > > With it, basic operation have been tested, both with > > virtio-vdpa and vhost-vdpa using DPDK Vhost library series > > adding VDUSE support using

Hi all: The code used to busy poll for cvq command which turns out to have several side effects: 1) infinite poll for buggy devices 2) bad interaction with scheduler So this series tries to use cond_resched() in the waiting loop. Before doing this we need first make sure the cvq command is not executed in atomic environment, so we need first convert rx mode handling to a workqueue. Please