similar to: [PATCH 0/2] virtio: console: add locking around control out-vq

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. v2: * Use spin_lock instead of spin_lock_irq.

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. v2: * Use spin_lock instead of spin_lock_irq.

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\

When we hot unplug a virtserialport and then try to hot plug again, it fails: (qemu) chardev-add socket,id=serial0,path=/tmp/serial0,server,nowait (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\ chardev=serial0,id=serial0,name=serial0 (qemu) device_del serial0 (qemu) device_add virtserialport,bus=virtio-serial0.0,nr=2,\

Hey Rusty, These updated patches in the series return -EFAULT on copy_xx_user errors and also move the copy_from_user into fops_write() instead of it being in send_buf. This enables send_buf to just read from kernel buffers, making it simpler. This also allows write()s to write more to the host in one go, removingthe 4k limitation. I do limit the writes to 32k at once to not put too much

Hey Rusty, These updated patches in the series return -EFAULT on copy_xx_user errors and also move the copy_from_user into fops_write() instead of it being in send_buf. This enables send_buf to just read from kernel buffers, making it simpler. This also allows write()s to write more to the host in one go, removingthe 4k limitation. I do limit the writes to 32k at once to not put too much

Turns out virtio console tries to take a buffer out of an active vq. Works by sheer luck, and is explicitly forbidden by spec. And while going over it I saw that error handling is also broken - failure is easy to trigger if I force allocations to fail. Lightly tested. Michael S. Tsirkin (6): virtio_console: don't tie bufs to a vq virtio: add ability to iterate over vqs virtio_console:

Turns out virtio console tries to take a buffer out of an active vq. Works by sheer luck, and is explicitly forbidden by spec. And while going over it I saw that error handling is also broken - failure is easy to trigger if I force allocations to fail. Lightly tested. Michael S. Tsirkin (6): virtio_console: don't tie bufs to a vq virtio: add ability to iterate over vqs virtio_console:

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. This is needed for using virtio_console from the remoteproc framework. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Rusty Russell <rusty

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. This is needed for using virtio_console from the remoteproc framework. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> cc: Rusty Russell <rusty

Hello, The first patch here fixes the race seen by Miche. He hasn't yet reported back if this fixes the races he saw, but Joy Pu from Red Hat tested this patch with hot-plugging/unplugging ports in a loop. Before this patch, he saw some freezes as well as sysfs warnings. After applying the patch, all was well. The second patch can be folded into the series fixing S4 for virtio-console. It

Hello, The first patch here fixes the race seen by Miche. He hasn't yet reported back if this fixes the races he saw, but Joy Pu from Red Hat tested this patch with hot-plugging/unplugging ports in a loop. Before this patch, he saw some freezes as well as sysfs warnings. After applying the patch, all was well. The second patch can be folded into the series fixing S4 for virtio-console. It

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. If the device requests the feature VIRTIO_CONSOLE_F_DMA_MEM, but the architecture don't support DMA the driver's probe function will fail. This is needed for using

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add feature VIRTIO_CONSOLE_F_DMA_MEM. If the architecture has DMA support and this feature bit is set, the virtio data buffers will be allocated from DMA memory. If the device requests the feature VIRTIO_CONSOLE_F_DMA_MEM, but the architecture don't support DMA the driver's probe function will fail. This is needed for using

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (0xB) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

Hello, This series reworks the ABI to allow port discovery (only) via the control queue and enable multiport again. In addition, it adds support for non-blocking write() support, which means no spinning. This works fine with the recent patches that are on qemu-devel. Also included is removal of hvc_remove() as removing one such console port causes other console ports (registered with hvc) to

Hello, This series reworks the ABI to allow port discovery (only) via the control queue and enable multiport again. In addition, it adds support for non-blocking write() support, which means no spinning. This works fine with the recent patches that are on qemu-devel. Also included is removal of hvc_remove() as removing one such console port causes other console ports (registered with hvc) to