On Thu, Oct 13, 2022 at 01:54:36PM -0700, Elliot Berman wrote: > > > 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. Those all pre-dated virtio. Please do not reinvent the wheel, again, this is explicitly what virtio was designed for, so that we would not have per-device/hypervisor drivers constantly being forced to be added. Learn from the past mistakes and just use the interfaces and apis we already have. You don't have to have a "heavy" VM to support just a virtio console, and in fact, all the code is already written for you! thanks, greg k-h
