[Differential] D7185: Add virtio-console support to bhyve

[Jakub Klama]

> Wiadomość napisana przez Paul Vixie <paul at redbarn.org> w dniu 12.07.2016, o godz. 02:39:
> 
> Jakub Klama wrote:
> 
>> It doesn't speak any protocol. virtio-console is a pipe. it pushes
>> bytes back and forth. Name is indeed unfortunate, it should have
>> been called virtio-pipe, but virtio-console is how the virtio
>> specification calls it.
> 
> if it's never going to appear as /dev/console or any other tty-like
> device to the guest, then i won't care what it looks like on the host.
> however, you said it could carry resize events, which leads me to
> believe that the name (vertio-console) is not wrong, and it is a tty to the guest, and in my view that means it should be a tty to the host.
> 

Well, it *can* be a tty to the host, but doesn't need to be. Driver supports multiple ports, and every port can be marked as a "console" port. Linux guests create regular character devices for "normal" virtio-console ports and ttys for "console" ports. My code doesn't support "console" ports yet at all.

I agree that the console port should be a tty on the host. But there are some things to consider:
* There can be more than one - how do we receive resize events from every pty? polling? fork per pty?
* It doesn't necessarily need to be connected to bhyve process stdin/stdout
* If bhyve opens pty(s), how would it communicate ptsname() back to the user?

> please explain how your proposed addition to bhyve handles resize events but is not actually related to tty use by either the guest or host.
> 

It doesn't, that's just not supported yet :)

>> If we were to use virtio-console as a system console, then using a
>> pseudo tty and forwarding pty resize notifications as resize control
>> events to the guest is totally fine and desired (at least as one of
>> the options). However, as I said, unix domain socket is perfect fit
>> for using is at a regular bidirectional pipe.
> 
> if that pipe has resize events encoded in it, as you said earlier, then it has to have a protocol, and it is not just a bidirectional pipe.
> 

Pipe itself doesn't have resize events. Resize events are transmitted out of band, in a separate control queue. That out of band communication is not visible to the unix domain socket consumer. It could be made visible in two ways: a) by implementing multiplexing in the unix domain socket protocol b) by using pseudo tty, connecting pty data stream to the pipe and handing resizes separately.

> please explain more about your use case. what will this device look like to the guest, and what application do you expect to have running on the host to talk to this unix domain socket?

We're using it in freenas-vm-tools, a "guest additions" package that would allow host-guest interactions, such as automatic mounting of the shared 9P storage when being added in the hypervisor GUI, synchronizing time, potentially also suspending the I/O while snapshotting the VM datasets, and so on. In the guest, virtio-console is visible as a regular character device (/dev/virtio-ports/org.freenas.vm-tools). On the host side, FreeNAS 10 middleware talks to it.

Jakub