Re: [PATCH v4 14/14] tty: gunyah: Add tty console driver for RM Console Services

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

 





On 10/10/2022 1:23 PM, Greg Kroah-Hartman wrote:
On Sun, Oct 09, 2022 at 01:59:21PM -0700, Elliot Berman wrote:


On 10/7/2022 12:40 AM, Greg Kroah-Hartman wrote:
On Thu, Oct 06, 2022 at 10:59:51PM -0700, Elliot Berman wrote:

"GH" is the shorthand we've been using for "Gunyah". I didn't find
documentation for dynamically assigned char devices, but if it exists, I can
add entry for ttyGH.

Why use a new name at all?  Why not stick with the existing tty names
and device numbers?


I can use hvc framework, although driver-level buffering is needed on
both the get_chars/put_chars paths because:

I'm not asking about the framework (although that is a good question,
you need to document why this has to be new.)  I'm asking why pick a new
name?  You will not have a name conflict in your system with this device
with any other tty name right?


That's correct, I didn't see any other instances of "ttyGH" in kernel.

  - get_chars wants to poll for characters, but Gunyah will push
    characters to Linux
  - put_chars can be called in atomic context in the printk console path.
    Gunyah RM calls can sleep, so we add to buffer and queue work to
    write the characters.

I also chose to use new tty driver because the Gunyah hypervisor call to
open the console (gh_rm_console_open) can only be done after starting the
VM. Gunyah will only forward characters sent from the other VM to Linux
after the gh_rm_console_open call is made. When launching a VM, users would
want to open console before VM starts so they can get startup messages from
the VM. I planned to use the carrier_raised() to hold
tty_port_block_until_ready until the VM is started and the
gh_rm_console_open() happens.

I'm sorry, but I don't understand this.

Why is this all a new api at all?  What about the virtio api?  Why not
just use that instead?

We want to support virtual machines and Virtual Machine Managers (the userspace component) that don't support virtio. Qualcomm has some lightweight VMs that have a Gunyah driver stack but no virtio stack. Further, implementing a simple userspace VMM to launch a Linux kernel is much easier with the Gunyah console as no device paravirtualization is needed to get some output from Linux. I don't anticipate these VMs to be commonplace, but they do exist.

Thanks,
Elliot



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux