Date: Mon, 11 Jul 2016 23:25:17 -0700 From: Paul Vixie <paul@redbarn.org> To: Jakub Klama <jakub.klama@uj.edu.pl> Cc: freebsd-virtualization@freebsd.org Subject: Re: [Differential] D7185: Add virtio-console support to bhyve Message-ID: <57848D4D.8040906@redbarn.org> In-Reply-To: <EB985B8F-1A88-4EE1-AEE6-622F117931A2@uj.edu.pl> References: <differential-rev-PHID-DREV-h346qsj6dfo524z3qnfy-req@FreeBSD.org> <5783D6FF.7010107@redbarn.org> <FCF5C7E6-2BCF-4729-BC2B-788E1FE74BCE@uj.edu.pl> <5783E2FE.1040309@redbarn.org> <EDFB1E4C-755F-4D2F-808C-E45A31C3EE2C@uj.edu.pl> <5783E64B.9010608@redbarn.org> <6B5AEBF8-98B0-4031-A3E3-A1EBC8B4B763@uj.edu.pl> <57841572.7060903@redbarn.org> <577FFDDF-7EC5-4143-AA1B-858BA8C3287F@uj.edu.pl> <57843C3D.80102@redbarn.org> <EB985B8F-1A88-4EE1-AEE6-622F117931A2@uj.edu.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
Jakub Klama wrote:
>> 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.
that's madness. i'd like bhyve to remain for all time as clean as it is
now. so if you want a flat clean bidirectional channel for your "guest
additions" on the guest to talk to your "middleware" on the host, that's
fine by me, but don't let either end look like a tty to anybody. in
fact, it would be better for bhyve for you to implement both host and
guest drivers for virtio_vsock than to use the non-tty features of
virtio_console.
> 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.
your initial mention of resize events up-thread gets harder and harder
for me to understand as we continue down-thread.
please don't implement "console" ports at all unless the host side of
such a port has to talk to a pts, pty, or nmdm. separately, let's work
together to get TIOC{S|G}WINSZ support working in nmdm. this means,
please don't let a guest tty talk to a host unix-domain socket that has
to have a second control channel for carrying tty events like window
size. just don't do that. make the guest tty talk to a host nmdm, pty,
or pts.
> 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?
generally you let all the pts/pty/nmdm devices have the same pgrp and
when you get a SIGWINCH you poll all of your devices with TIOCGWINSZ.
the SIGWINCH event is rare enough and the number of devices is low
enough that this polling is not a performance problem.
> * It doesn't necessarily need to be connected to bhyve process
> stdin/stdout
bhyve should never connect its stdin/stdout to the guest. that's bad
design. let's work together to stamp it out, starting by never letting
any of your virtio_console ports (should you implement the kind that
appear to the guest as tty devices) to bhyve stdin/stdout.
> * If bhyve opens pty(s), how would it communicate ptsname() back to
> the user?
that would be a fine thing to send to stdout at bhyve initialization time.
>> 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.
if you say "we will never multiplex the unix domain socket" and you say
"pts, pty, or nmdm" rather than "pseudo tty", then we're in agreement.
> 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.
i would prefer to see this as a virtio_vsock.
thank you for explaining.
--
P Vixie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57848D4D.8040906>