similar to: [PATCH v2 09/13] vdpa net: block migration if the device has CVQ

On Fri, Mar 3, 2023 at 4:01?PM Eugenio Perez Martin <eperezma at redhat.com> wrote: > > On Fri, Mar 3, 2023 at 4:32 AM Jason Wang <jasowang at redhat.com> wrote: > > > > > > ? 2023/3/1 15:01, Eugenio Perez Martin ??: > > > On Mon, Feb 27, 2023 at 8:04 AM Jason Wang <jasowang at redhat.com> wrote: > > >> > > >> ? 2023/2/24

On Fri, Mar 3, 2023 at 4:58?PM Eugenio Perez Martin <eperezma at redhat.com> wrote: > > On Fri, Mar 3, 2023 at 4:48 AM Jason Wang <jasowang at redhat.com> wrote: > > > > > > ? 2023/3/2 03:32, Eugenio Perez Martin ??: > > > On Mon, Feb 27, 2023 at 9:20 AM Jason Wang <jasowang at redhat.com> wrote: > > >> On Mon, Feb 27, 2023 at 4:15?PM

? 2023/2/8 17:42, Eugenio P?rez ??: > This allows net to restart the device backend to configure SVQ on it. > > Ideally, these changes should not be net specific. However, the vdpa net > backend is the one with enough knowledge to configure everything because > of some reasons: > * Queues might need to be shadowed or not depending on its kind (control > vs data). > *

? 2023/2/22 22:25, Eugenio Perez Martin ??: > On Wed, Feb 22, 2023 at 5:05 AM Jason Wang <jasowang at redhat.com> wrote: >> >> ? 2023/2/8 17:42, Eugenio P?rez ??: >>> Next patches enable devices to be migrated even if vdpa netdev has not >>> been started with x-svq. However, not all devices are migratable, so we >>> need to block migration if we

On Thu, Apr 13, 2023 at 10:04?PM Jakub Kicinski <kuba at kernel.org> wrote: > > On Thu, 13 Apr 2023 14:40:25 +0800 Jason Wang wrote: > > 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

On Fri, Dec 20, 2019 at 01:22:07PM -0800, Alistair Delva wrote: > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not tainted

On Fri, Dec 20, 2019 at 01:22:07PM -0800, Alistair Delva wrote: > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not tainted

On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > On devices without control virtqueue support, such as the virtio_net > > implementation in crosvm[1], attempting to configure LRO will panic the > > kernel: > > > > kernel BUG at

On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Fri, Dec 20, 2019 at 10:08:41PM -0500, Willem de Bruijn wrote: > > > On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > > > > > > > On devices without

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 Sun, Dec 22, 2019 at 10:54:23AM -0500, Willem de Bruijn wrote: > On Sun, Dec 22, 2019 at 9:57 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > On Sun, Dec 22, 2019 at 09:21:43AM -0500, Willem de Bruijn wrote: > > > On Sun, Dec 22, 2019 at 8:11 AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > > > On Fri, Dec 20, 2019

On Fri, Dec 20, 2019 at 1:22 PM Alistair Delva <adelva at google.com> wrote: > > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: If you'd like to try using the control virtqueue, I have a WIP patch at crrev.com/c/1968200 The downside there is that when enabling IP

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

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

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. Note that,

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

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, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not

On Fri, Dec 20, 2019 at 4:22 PM Alistair Delva <adelva at google.com> wrote: > > On devices without control virtqueue support, such as the virtio_net > implementation in crosvm[1], attempting to configure LRO will panic the > kernel: > > kernel BUG at drivers/net/virtio_net.c:1591! > invalid opcode: 0000 [#1] PREEMPT SMP PTI > CPU: 1 PID: 483 Comm: Binder:330_1 Not

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