Messages in this thread | | | Date | Fri, 18 Sep 2009 22:11:17 +0200 | From | Gerd Hoffmann <> | Subject | Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication |
| |
On 09/18/09 19:55, Anthony Liguori wrote: >> So you need break, parity ... no be serious please > > Sure, why not? > > In QEMU, we have the ability to hook our devices directly to a physical > serial device and we pass through break, parity, and the other serial > device properties.
Yes for a emulated 16550. No for virtio-console.
If you want the guest drive some silly piece of hardware which wants a serial mode != 8N1 or needs breaks you can't use virtio-console.
> Again, this is paravirtual serial device and I think it's entirely > reasonable for people to hook up these ports in the guest directly to > physical serial devices in the host.
Except that the paravirtual device named 'virtio-console' simply doesn't allow to set serial parameters such as parity, data bits and stop bits.
It is *really* just a (single) byte stream piped over a virtio ring.
The guest side happens to be connected to hvc, so you can use that as console, thus the name 'virtio-console'.
The plan is to extend that to multiple byte streams. The streams can be hooked up to hvc (and one stream allways will be for backward compatibility reasons), giving you a text console. Or they can be linked to a character device with a name tag (aka sysfs attribute), providing a named bidirectional byte stream for guest<->host communication.
> From my perspective, this is a paravirtual serial device and nothing > more.
It simply isn't, see above.
> All the discussion of things like guest copy/paste support is a > bit silly.
Implementing transparent copy/paste support needs some communication channel between guest and host. The multiport virtio console driver provides just that.
> This is the wrong way to approach that sort of thing because > it's not something that belongs in the kernel at all.
Who claimed the copy/paste bits should go into the kernel? They will not of course.
> Furthermore, the > current proposal doesn't handle anything like save/restore which is > needed for live migration.
That is something the host side (i.e. qemu) has to solve. The guest will not care about it at all ;)
cheers, Gerd
| |