similar to: [PATCH 1/1] virtio: console: Serialise control work

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

Unfortunately there proved to be at least one bug which requires an ABI change, so we're best off not introducing multiport support until 2.6.35. While I generally left the multiport code paths intact, I really wanted to remove the ABI defines from the header, which meant some quite deep cuts. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at

Unfortunately there proved to be at least one bug which requires an ABI change, so we're best off not introducing multiport support until 2.6.35. While I generally left the multiport code paths intact, I really wanted to remove the ABI defines from the header, which meant some quite deep cuts. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at

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 multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Applies on top of "virtio_console: init work unconditionally" that I sent previously. drivers/char/virtio_console.c

when multiport is off, virtio console invokes config access from irq context, config access is blocking on s390. Fix this up by scheduling work from config irq - similar to what we do for multiport configs. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Applies on top of "virtio_console: init work unconditionally" that I sent previously. drivers/char/virtio_console.c

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. Amit Shah (2): virtio: console: rename cvq_lock

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. Amit Shah (2): virtio: console: rename cvq_lock

when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index fae2dbb..def736d 100644 ---

when multiport is off, we don't initialize config work, but we then cancel uninitialized control_work on freeze. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/char/virtio_console.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index fae2dbb..def736d 100644 ---

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

Console driver is out of spec. The spec says: A driver MUST NOT decrement the available idx on a live virtqueue (ie. there is no way to ?unexpose? buffers). and it does exactly that by trying to detach unused buffers without doing a device reset first. Defer detaching the buffers until device unplug. Of course this means we might get an interrupt for a vq without an attached port now. Handle

We try to disable callbacks on c_ivq even without multiport even though that vq is not initialized in this configuration. Fixes: c743d09dbd01 ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze") Suggested-by: Mike Galbraith <efault at gmx.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Mike if you like, pls send me your Signed-off-by

We try to disable callbacks on c_ivq even without multiport even though that vq is not initialized in this configuration. Fixes: c743d09dbd01 ("virtio: console: Disable callbacks for virtqueues at start of S4 freeze") Suggested-by: Mike Galbraith <efault at gmx.de> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Hi Mike if you like, pls send me your Signed-off-by

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

On Wed, Nov 13, 2019 at 04:00:56PM +0100, Laurent Vivier wrote: > 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 >