linux-kernel - Re: [PATCH] virtio_console: Add support for multiple ports for generic guest and host communication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AB3E965.10300@redhat.com>
Date:	Fri, 18 Sep 2009 22:11:17 +0200
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	Alan Cox <alan@...ux.intel.com>, Amit Shah <amit.shah@...hat.com>,
	rusty@...tcorp.com.au, virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/