Re: [PATCH v5 13/13] tty: gunyah: Add tty console driver for RM Console Services

[Elliot Berman]

On 10/11/2022 11:55 PM, Greg Kroah-Hartman wrote:
> On Tue, Oct 11, 2022 at 03:04:47PM -0700, Elliot Berman wrote:
> > On 10/11/2022 4:09 AM, Arnd Bergmann wrote:
> > > On Tue, Oct 11, 2022, at 8:02 AM, Jiri Slaby wrote:
> > > > On 11. 10. 22, 2:08, Elliot Berman wrote:
> > > > > +
> > > > > +	/* below are for printk console.
> > > > > +	 * gh_rm_console_* calls will sleep and console_write can be called from
> > > > > +	 * atomic ctx. Two xmit buffers are used. The active buffer is tracked with
> > > > > +	 * co_xmit_idx. Writes go into the co_xmit_buf[co_xmit_idx] buffer.
> > > > > +	 * A work is scheduled to flush the bytes. The work will swap the active buffer
> > > > > +	 * and write out the other buffer.
> > > > > +	 */
> > > >
> > > > Ugh, why? This is too ugly and unnecessary. What about passing the kfifo
> > > > to gh_rm_console_write() instead? You do memcpy() there anyway.
> > >
> > > Another problem here is that you really want the console output to be
> > > printed from atomic context, otherwise one would never see e.g. the
> > > output of a panic() call. Having a deferred write is probably fine for
> > > normal tty operations, but you probably want a different device for the
> > > console here, e.g. the hvc_dcc driver.
> >
> > Yes, that is our perspective on the RM console driver as well. I'll make
> > this more explicit in the Kconfig/commit text. We expect most VMs
> > (especially Linux) to use some other console mechanism provided by their
> > VMM. I'm submitting here because we are presently using RM console on some
> > of our VMs where we have other ways to collects logs on panic. It also makes
> > it easier to implement a simple virtual machine manager that does not want
> > to virtualize a serial device or have a virtio stack.
>
> The whole goal of virtio was so that we would not have all of these
> random custom drivers for new hypervisors all over the place, requiring
> custom userspace interaction with them.
>
> Please use virtio, that's what it is there for, don't create a new
> console device if you do not have to.

We have a lightweight VM product use case today that doesn't want to 
support an entire virtio stack just for a console. This VM already has a 
Gunyah stack present, and to facilitate their console needs, we want to 
give them the Gunyah console.

There are a few other hypervisors that also provide a console facility 
in Linux: Xen, ePAPR hypervisor and z/VM.

Thanks,
Elliot