From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8ACFC433FE for ; Wed, 12 Oct 2022 06:54:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229527AbiJLGyo (ORCPT ); Wed, 12 Oct 2022 02:54:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229490AbiJLGyk (ORCPT ); Wed, 12 Oct 2022 02:54:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CE7E8DCA; Tue, 11 Oct 2022 23:54:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EE15C6143F; Wed, 12 Oct 2022 06:54:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D20C0C433C1; Wed, 12 Oct 2022 06:54:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1665557678; bh=07544IyluCqQFbZ6NhjfAsCj/GMjAj2uXv4G4GnQgo0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jHaasYph0Rv0oQDVh9RCvdB7C3uVY/726M2EM4fiJ8JofAJG2WY1pX+OXcP45+Bs7 QcHzyj5wQFv4So6S8rBhGsnuNJ3WUpZ4/1REKgJzwr2OvO2FDhoZdfskZTTSV0qYvH rokhHfhx0M5Zh3WF1J38E/Dn0BxrB5P63++JeybU= Date: Wed, 12 Oct 2022 08:55:22 +0200 From: Greg Kroah-Hartman To: Elliot Berman Cc: Arnd Bergmann , Jiri Slaby , Bjorn Andersson , Murali Nalajala , Trilok Soni , Srivatsa Vaddagiri , Carl van Schaik , Prakruthi Deepak Heragu , Andy Gross , Dmitry Baryshkov , Jassi Brar , linux-arm-kernel@lists.infradead.org, Mark Rutland , Lorenzo Pieralisi , Sudeep Holla , Marc Zyngier , Rob Herring , Krzysztof Kozlowski , Jonathan Corbet , Will Deacon , Catalin Marinas , devicetree@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 13/13] tty: gunyah: Add tty console driver for RM Console Services Message-ID: References: <20221011000840.289033-1-quic_eberman@quicinc.com> <20221011000840.289033-14-quic_eberman@quicinc.com> <7438406d-b446-201e-0ec3-5cf0a5b9f32c@kernel.org> <85ca7eb4-3e0c-4ffb-8bac-a435594ca0f7@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. greg k-h