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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux