search for: host_connect

...e.c index 2cfd5a0..5afc8f6 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1436,7 +1436,7 @@ static int add_port(struct ports_device *portdev, u32 id) * rproc_serial does not want the console port, only * the generic port implementation. */ - port->host_connected = true; + port->host_connected = port->guest_connected = true; else if (!use_multiport(port->portdev)) { /* * If we're not using multiport support, @@ -1757,11 +1757,8 @@ static void in_intr(struct virtqueue *vq) * tty is spawned) and the host sends out data to console...

...e.c index 2cfd5a0..5afc8f6 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1436,7 +1436,7 @@ static int add_port(struct ports_device *portdev, u32 id) * rproc_serial does not want the console port, only * the generic port implementation. */ - port->host_connected = true; + port->host_connected = port->guest_connected = true; else if (!use_multiport(port->portdev)) { /* * If we're not using multiport support, @@ -1757,11 +1757,8 @@ static void in_intr(struct virtqueue *vq) * tty is spawned) and the host sends out data to console...

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

.../virtio_console.c index 8c99bf1..e3fb529 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1099,6 +1099,13 @@ static int remove_port(struct port *port) { struct port_buffer *buf; + if (port->guest_connected) { + port->guest_connected = false; + port->host_connected = false; + wake_up_interruptible(&port->waitqueue); + send_control_msg(port, VIRTIO_CONSOLE_PORT_OPEN, 0); + } + spin_lock_irq(&port->portdev->ports_lock); list_del(&port->list); spin_unlock_irq(&port->portdev->ports_lock); @@ -1120,9 +1127,6 @@ static in...

.../virtio_console.c index 8c99bf1..e3fb529 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1099,6 +1099,13 @@ static int remove_port(struct port *port) { struct port_buffer *buf; + if (port->guest_connected) { + port->guest_connected = false; + port->host_connected = false; + wake_up_interruptible(&port->waitqueue); + send_control_msg(port, VIRTIO_CONSOLE_PORT_OPEN, 0); + } + spin_lock_irq(&port->portdev->ports_lock); list_del(&port->list); spin_unlock_irq(&port->portdev->ports_lock); @@ -1120,9 +1127,6 @@ static in...

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

...e.c index e905d5f..031be0b 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1436,7 +1436,7 @@ static int add_port(struct ports_device *portdev, u32 id) * rproc_serial does not want the console port, only * the generic port implementation. */ - port->host_connected = port->guest_connected = true; + port->host_connected = true; else if (!use_multiport(port->portdev)) { /* * If we're not using multiport support, @@ -1757,8 +1757,11 @@ static void in_intr(struct virtqueue *vq) * tty is spawned) and the host sends out data to console...

...e.c index e905d5f..031be0b 100644 --- a/drivers/char/virtio_console.c +++ b/drivers/char/virtio_console.c @@ -1436,7 +1436,7 @@ static int add_port(struct ports_device *portdev, u32 id) * rproc_serial does not want the console port, only * the generic port implementation. */ - port->host_connected = port->guest_connected = true; + port->host_connected = true; else if (!use_multiport(port->portdev)) { /* * If we're not using multiport support, @@ -1757,8 +1757,11 @@ static void in_intr(struct virtqueue *vq) * tty is spawned) and the host sends out data to console...

..._port(portdev, cpkt->id); + add_port(portdev, virtio32_to_cpu(vdev, cpkt->id)); break; case VIRTIO_CONSOLE_PORT_REMOVE: unplug_port(port); @@ -1670,7 +1674,7 @@ static void handle_control_message(struct ports_device *portdev, break; } case VIRTIO_CONSOLE_PORT_OPEN: - port->host_connected = cpkt->value; + port->host_connected = virtio16_to_cpu(vdev, cpkt->value); wake_up_interruptible(&port->waitqueue); /* * If the host port got closed and the host had any @@ -1752,7 +1756,7 @@ static void control_work_handler(struct work_struct *work) buf->len = l...

..._port(portdev, cpkt->id); + add_port(portdev, virtio32_to_cpu(vdev, cpkt->id)); break; case VIRTIO_CONSOLE_PORT_REMOVE: unplug_port(port); @@ -1670,7 +1674,7 @@ static void handle_control_message(struct ports_device *portdev, break; } case VIRTIO_CONSOLE_PORT_OPEN: - port->host_connected = cpkt->value; + port->host_connected = virtio16_to_cpu(vdev, cpkt->value); wake_up_interruptible(&port->waitqueue); /* * If the host port got closed and the host had any @@ -1752,7 +1756,7 @@ static void control_work_handler(struct work_struct *work) buf->len = l...

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

...; + + /* The hvc device, if this port is associated with a console */ + struct hvc_struct *hvc; + + /* The 'name' of the port that we expose via sysfs properties */ + char *name; + + /* The 'id' to identify the port with the Host */ + u32 id; + + /* Is the host device open */ + bool host_connected; +}; -/* The hvc device */ -static struct hvc_struct *hvc; +static struct virtio_console_struct virtconsole; -/*D:310 The put_chars() callback is pretty straightforward. +/* + * This is used to keep track of the number of hvc consoles spawned. + * This number is given as first argument to hvc...

...; + + /* The hvc device, if this port is associated with a console */ + struct hvc_struct *hvc; + + /* The 'name' of the port that we expose via sysfs properties */ + char *name; + + /* The 'id' to identify the port with the Host */ + u32 id; + + /* Is the host device open */ + bool host_connected; +}; -/* The hvc device */ -static struct hvc_struct *hvc; +static struct virtio_console_struct virtconsole; -/*D:310 The put_chars() callback is pretty straightforward. +/* + * This is used to keep track of the number of hvc consoles spawned. + * This number is given as first argument to hvc...

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine*. There are a few items on my todo list but this works well. New since last send: - live migration support** - write path in the guest

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine*. There are a few items on my todo list but this works well. New since last send: - live migration support** - write path in the guest

...ck: port = filp->private_data; poll_wait(filp, &port->waitqueue, wait); if (!port->guest_connected) { /* Port got unplugged */ return POLLHUP; } ret = 0; if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; if (!port->host_connected) ret |= POLLHUP; return ret; Which is the correct way to do this. Cheers, Rusty.

...ck: port = filp->private_data; poll_wait(filp, &port->waitqueue, wait); if (!port->guest_connected) { /* Port got unplugged */ return POLLHUP; } ret = 0; if (!will_read_block(port)) ret |= POLLIN | POLLRDNORM; if (!will_write_block(port)) ret |= POLLOUT; if (!port->host_connected) ret |= POLLHUP; return ret; Which is the correct way to do this. Cheers, Rusty.