search for: virtconsole

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?

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

...ame' 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_alloc(). We could as + * well pass on the minor number of the char device but to correctly + * map an initial c...

...ame' 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_alloc(). We could as + * well pass on the minor number of the char device but to correctly + * map an initial c...

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. 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

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. 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

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

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

(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

I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm with these options: -chardev null,id=hvc0,signal=off -device virtio-serial-pci -device virtconsole,chardev=hvc0,name=virtme_console -append console=hvc0 console=ttyS0 -nographic (There are more, but these are the interesting ones, I think.) Note that virtio_console is modular, which might be a problem. It blows up like this: [ 0.443591] kernel tried to execute NX-protected page - exploit...

I'm running a Fedora distro kernel (3.13.7-200.fc20.x86_64) in kvm with these options: -chardev null,id=hvc0,signal=off -device virtio-serial-pci -device virtconsole,chardev=hvc0,name=virtme_console -append console=hvc0 console=ttyS0 -nographic (There are more, but these are the interesting ones, I think.) Note that virtio_console is modular, which might be a problem. It blows up like this: [ 0.443591] kernel tried to execute NX-protected page - exploit...

This call was disabled as hot-unplugging one virtconsole port led to another virtconsole port freezing. Upon testing it again, this now works, so enable it. In addition, a bug was found in qemu wherein removing a port of one type caused the guest output from another port to stop working. I doubt it was just this bug that caused it (since disabling the...

This call was disabled as hot-unplugging one virtconsole port led to another virtconsole port freezing. Upon testing it again, this now works, so enable it. In addition, a bug was found in qemu wherein removing a port of one type caused the guest output from another port to stop working. I doubt it was just this bug that caused it (since disabling the...

...: Error allocating inbufs qemu error: virtio-serial-bus: Guest failure in adding port 2 for device \ virtio-serial0.0 This happens because buffers for the in_vq are allocated when the port is added but are not released when the port is unplugged. They are only released when virtconsole is removed (see a7a69ec0d8e4) To avoid the problem and to be symmetric, we could allocate all the buffers in init_vqs() as they are released in remove_vqs(), but it sounds like a waste of memory. Rather than that, this patch changes add_port() logic to only allocate the buffers if the in_vq has a...

...: Error allocating inbufs qemu error: virtio-serial-bus: Guest failure in adding port 2 for device \ virtio-serial0.0 This happens because buffers for the in_vq are allocated when the port is added but are not released when the port is unplugged. They are only released when virtconsole is removed (see a7a69ec0d8e4) To avoid the problem and to be symmetric, we could allocate all the buffers in init_vqs() as they are released in remove_vqs(), but it sounds like a waste of memory. Rather than that, this patch changes add_port() logic to only allocate the buffers if the in_vq has a...