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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4145C4338F for ; Fri, 20 Aug 2021 12:34:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BCC31610CA for ; Fri, 20 Aug 2021 12:34:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240617AbhHTMet (ORCPT ); Fri, 20 Aug 2021 08:34:49 -0400 Received: from ozlabs.org ([203.11.71.1]:43873 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240538AbhHTMeo (ORCPT ); Fri, 20 Aug 2021 08:34:44 -0400 Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4Grgzv3Qhxz9sWq; Fri, 20 Aug 2021 22:34:03 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1629462845; bh=RvSoZj9qGbuGPBLusBDgZESowYHwhMMiBJyC8aIMk60=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mtQUVDWVN21fl7CB8Gv+bXzF4FyNyW44mL2BYz7qsbt/eYeNT69e584cR6zMVbxqO ynl5XZWnLQ45izhHFGBbzG1riwSDXF5HxR7P6MYnAHHiOX2/bE53XIUnaRqRJMDFAm P8zAFSBs7KWapWa9nTnuKg/KNnO3bZ2mOUawCw+CDy+9UnJXlCv1wJXqDWlnNolPaB rXl1Ck3kKrE+EXgUNuoH0szMYFn4EqkJTs0hQNEXiHpEp16L82OBAnWkCq19clUSEG 6/9GTOU9oqC5kGb9R5dOO/Mh4wDbKHUsiboA1eolxLil/INGfzViLXj4lvJnbxaRGw 0qe92o3jgy8cw== From: Michael Ellerman To: Daniel Axtens , Xianting Tian , gregkh@linuxfoundation.org, jirislaby@kernel.org, amit@kernel.org, arnd@arndb.de, osandov@fb.com Cc: Xianting Tian , shile.zhang@linux.alibaba.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars() In-Reply-To: <87pmu8ehkk.fsf@linkitivity.dja.id.au> References: <20210818082122.166881-1-xianting.tian@linux.alibaba.com> <20210818082122.166881-3-xianting.tian@linux.alibaba.com> <87pmu8ehkk.fsf@linkitivity.dja.id.au> Date: Fri, 20 Aug 2021 22:34:02 +1000 Message-ID: <87pmu8cn2d.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Daniel Axtens writes: > Xianting Tian writes: > >> As well known, hvc backend driver(eg, virtio-console) can register its >> operations to hvc framework. The operations can contain put_chars(), >> get_chars() and so on. >> >> Some hvc backend may do dma in its operations. eg, put_chars() of >> virtio-console. But in the code of hvc framework, it may pass DMA >> incapable memory to put_chars() under a specific configuration, which >> is explained in commit c4baad5029(virtio-console: avoid DMA from stack): > > We could also run into issues on powerpc where Andrew is working on > adding vmap-stack but the opal hvc driver assumes that it is passed a > buffer which is not in vmalloc space but in the linear mapping. The right fix for that is our code that calls opal has to be careful that it's not passing vmalloc addresses. We have many cases where we pass stack variables to opal, they'll all have to be fixed to pass the underlying phyiscal/linear map address. The opal hvc code will just be one more case of that. cheers