similar to: [PATCH] virtio_console: initialize vtermno value for ports

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Those symbols only used within this file, and should be static. Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> --- drivers/char/virtio_console.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 13ad9b1..f73ad64 100644 ---

From: Wei Yongjun <yongjun_wei at trendmicro.com.cn> Those symbols only used within this file, and should be static. Signed-off-by: Wei Yongjun <yongjun_wei at trendmicro.com.cn> --- drivers/char/virtio_console.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c index 13ad9b1..f73ad64 100644 ---

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Use virtio device index for creating unique device port names. Current index allocation in virtio is based on a monotonically increasing variable "index". A better handling of this is to use device index which is allocated by ida. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Use virtio device index for creating unique device port names. Current index allocation in virtio is based on a monotonically increasing variable "index". A better handling of this is to use device index which is allocated by ida. Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

Amit Shah <amit.shah at redhat.com> writes: > The removal functions act on the vqs, and the vq operations need to be > locked. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> How can userspace access the port now? By the time we are cleaning up buffers, there should be no possibility of such accesses. The number of bugfixes here is deeply disturbing. I wonder if

Amit Shah <amit.shah at redhat.com> writes: > The removal functions act on the vqs, and the vq operations need to be > locked. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> How can userspace access the port now? By the time we are cleaning up buffers, there should be no possibility of such accesses. The number of bugfixes here is deeply disturbing. I wonder if

Amit Shah <amit.shah at redhat.com> writes: > On (Mon) 22 Jul 2013 [15:26:22], Rusty Russell wrote: >> Amit Shah <amit.shah at redhat.com> writes: >> > The removal functions act on the vqs, and the vq operations need to be >> > locked. >> > >> > Signed-off-by: Amit Shah <amit.shah at redhat.com> >> >> How can userspace

Amit Shah <amit.shah at redhat.com> writes: > On (Mon) 22 Jul 2013 [15:26:22], Rusty Russell wrote: >> Amit Shah <amit.shah at redhat.com> writes: >> > The removal functions act on the vqs, and the vq operations need to be >> > locked. >> > >> > Signed-off-by: Amit Shah <amit.shah at redhat.com> >> >> How can userspace

The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") deffered detaching of unused buffer to virtio device unplug time. This causes unplug/replug of single port in virtio device with an error "Error allocating inbufs\n". As we don't free the unused buffers attached with the port. Re-plug the same port tries to allocate new buffers in virtqueue

The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") deffered detaching of unused buffer to virtio device unplug time. This causes unplug/replug of single port in virtio device with an error "Error allocating inbufs\n". As we don't free the unused buffers attached with the port. Re-plug the same port tries to allocate new buffers in virtqueue

Hello Michael, Thanks for your reply. > > On Mon, Mar 04, 2019 at 06:35:11PM +0530, Pankaj Gupta wrote: > > The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") > > deffered detaching of unused buffer to virtio device unplug time. > > > > This causes unplug/replug of single port in virtio device with an > > error "Error

Hello Michael, Thanks for your reply. > > On Mon, Mar 04, 2019 at 06:35:11PM +0530, Pankaj Gupta wrote: > > The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") > > deffered detaching of unused buffer to virtio device unplug time. > > > > This causes unplug/replug of single port in virtio device with an > > error "Error

On Mon, Mar 04, 2019 at 06:35:11PM +0530, Pankaj Gupta wrote: > The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") > deffered detaching of unused buffer to virtio device unplug time. > > This causes unplug/replug of single port in virtio device with an > error "Error allocating inbufs\n". As we don't free the unused buffers >

> > The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") > deffered detaching of unused buffer to virtio device unplug time. > > This causes unplug/replug of single port in virtio device with an > error "Error allocating inbufs\n". As we don't free the unused buffers > attached with the port. Re-plug the same port tries to

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not

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> > --- >

On Tue, Mar 05, 2019 at 02:09:06AM -0500, Pankaj Gupta wrote: > > Hello Michael, > > Thanks for your reply. > > > > > On Mon, Mar 04, 2019 at 06:35:11PM +0530, Pankaj Gupta wrote: > > > The commit a7a69ec0d8e4 ("virtio_console: free buffers after reset") > > > deffered detaching of unused buffer to virtio device unplug time. > >

On (Mon) 22 Jul 2013 [15:26:22], Rusty Russell wrote: > Amit Shah <amit.shah at redhat.com> writes: > > The removal functions act on the vqs, and the vq operations need to be > > locked. > > > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > > How can userspace access the port now? By the time we are cleaning up > buffers, there should be no

(Amit pointed out that the patches never went out. This is a resend of the series meant to go out on 11/2/2011; I've marked it "v2".) This patchset applies to linux-next/next-20111102. This series implements support for multiple virtio_consoles using KVM. This patchset addresses several issues associated with trying to establish multiple virtio consoles. I'm trying to