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=-2.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 B2058C433E1 for ; Mon, 29 Jun 2020 23:49:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8E4FC20780 for ; Mon, 29 Jun 2020 23:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474552; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:List-ID:From; b=RStC7jknPsr4QyhsRhHxHylJX6mRUqCpakzPo5v8ybvRp9jshf4etJeQQ+LgMTYV9 oiLS88EvMwaDrbnf2tkuIckI5BPqL8YswZP6DSlax/md+xF6X6fpTIYhqo7kmRQG3h oAvGL/Tr1qdfTsovP+/wX4avKNAVs6Y4KQ5nwqEQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728422AbgF2XtL (ORCPT ); Mon, 29 Jun 2020 19:49:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:50466 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728226AbgF2XtI (ORCPT ); Mon, 29 Jun 2020 19:49:08 -0400 Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7889C20780; Mon, 29 Jun 2020 23:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474548; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oupK0XZKr1tf9ZlB/vvhwl1g6l2FOT5EFgGIhASbYWQH4kL3mAqIIY0pFydyMp7AX ofoJ8l5Iy8Aj26eVYnf5X4wsVYL6+cyWfbFqp0keEtaF2uTu23UBwDyP6etUS+vytZ X2bXG5S9JLED91Z9FLDjXkzy6mkStrMTTdctv8GQ= Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Peng Fan cc: "Michael S. Tsirkin" , Stefano Stabellini , "boris.ostrovsky@oracle.com" , "jgross@suse.com" , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "xen-devel@lists.xenproject.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "virtualization@lists.linux-foundation.org" , dl-linux-imx Subject: RE: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical? 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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 5EC87C433E0 for ; Mon, 29 Jun 2020 23:49:11 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2C1A320781 for ; Mon, 29 Jun 2020 23:49:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oupK0XZK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C1A320781 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 016AD8687B; Mon, 29 Jun 2020 23:49:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD5m-reMuIBk; Mon, 29 Jun 2020 23:49:10 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [140.211.9.56]) by fraxinus.osuosl.org (Postfix) with ESMTP id 3452486A9D; Mon, 29 Jun 2020 23:49:10 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 18490C08A2; Mon, 29 Jun 2020 23:49:10 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id E584FC016E; Mon, 29 Jun 2020 23:49:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id E0D2588C43; Mon, 29 Jun 2020 23:49:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-sDnkKMg5wT; Mon, 29 Jun 2020 23:49:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by hemlock.osuosl.org (Postfix) with ESMTPS id 47E0488C33; Mon, 29 Jun 2020 23:49:08 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7889C20780; Mon, 29 Jun 2020 23:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474548; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oupK0XZKr1tf9ZlB/vvhwl1g6l2FOT5EFgGIhASbYWQH4kL3mAqIIY0pFydyMp7AX ofoJ8l5Iy8Aj26eVYnf5X4wsVYL6+cyWfbFqp0keEtaF2uTu23UBwDyP6etUS+vytZ X2bXG5S9JLED91Z9FLDjXkzy6mkStrMTTdctv8GQ= Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Peng Fan Subject: RE: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "Michael S. Tsirkin" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "virtualization@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical? _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: RE: [PATCH] xen: introduce xen_vring_use_dma Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Peng Fan Cc: "Michael S. Tsirkin" , Stefano Stabellini , "boris.ostrovsky@oracle.com" , "jgross@suse.com" , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "x86@kernel.org" , "xen-devel@lists.xenproject.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , "virtualization@lists.linux-foundation.org" , dl-linux-imx List-Id: virtualization@lists.linuxfoundation.org On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical? 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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 38139C433E0 for ; Mon, 29 Jun 2020 23:50:39 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 06D7F20786 for ; Mon, 29 Jun 2020 23:50:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Fq1+3I8m"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oupK0XZK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 06D7F20786 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:Message-ID:In-Reply-To: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=69/HOU3nRdfN0qJ+Rj5eBdDFr64rCouTimRQl7dTa8c=; b=Fq1+3I8mwq254iGsInjOfbpHR cxSFQExdlRA53foQ/bFqf0CmTzSLYuCaLbrLUMHlvmYx0SCaSfG24DuGJ9i8UvN/Ez2xIx4A85AAg LeK/65wqxG/U9TvbaBXcFDG2V10c9OgzJtEdZ6b+/BGZCvMxcngFVLXm0rx9V8TO024/22mzUmXYI zIgeHUBhsuBaio+Vg9pij+/Oft5AmnO8VXVwTl0gmOLFylHgqowJVnkqrs0bbyFUkvBZFFaUMcjpa E7YdC8r1ZQdDMBxA+lojDjZt2p603NhRBnCZRhn4NKB/HioTDscNDuF37soKD4Mt00R+1LXeA9687 TIF2cEJ7A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jq3WR-00005Q-T1; Mon, 29 Jun 2020 23:49:11 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jq3WO-000055-SO for linux-arm-kernel@lists.infradead.org; Mon, 29 Jun 2020 23:49:09 +0000 Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7889C20780; Mon, 29 Jun 2020 23:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474548; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oupK0XZKr1tf9ZlB/vvhwl1g6l2FOT5EFgGIhASbYWQH4kL3mAqIIY0pFydyMp7AX ofoJ8l5Iy8Aj26eVYnf5X4wsVYL6+cyWfbFqp0keEtaF2uTu23UBwDyP6etUS+vytZ X2bXG5S9JLED91Z9FLDjXkzy6mkStrMTTdctv8GQ= Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Peng Fan Subject: RE: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "Michael S. Tsirkin" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "virtualization@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 03F9AC433DF for ; Mon, 29 Jun 2020 23:49:23 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C982E20780 for ; Mon, 29 Jun 2020 23:49:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="oupK0XZK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C982E20780 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3WQ-0008IN-NF; Mon, 29 Jun 2020 23:49:10 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jq3WP-0008IH-Vs for xen-devel@lists.xenproject.org; Mon, 29 Jun 2020 23:49:10 +0000 X-Inumbo-ID: 1f989b3e-ba63-11ea-85a8-12813bfff9fa Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 1f989b3e-ba63-11ea-85a8-12813bfff9fa; Mon, 29 Jun 2020 23:49:09 +0000 (UTC) Received: from localhost (c-67-164-102-47.hsd1.ca.comcast.net [67.164.102.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7889C20780; Mon, 29 Jun 2020 23:49:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1593474548; bh=YbTxDsPQ5DXse6zCMw0MuvKG3mwFGMtOfnE1ikxlpqo=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=oupK0XZKr1tf9ZlB/vvhwl1g6l2FOT5EFgGIhASbYWQH4kL3mAqIIY0pFydyMp7AX ofoJ8l5Iy8Aj26eVYnf5X4wsVYL6+cyWfbFqp0keEtaF2uTu23UBwDyP6etUS+vytZ X2bXG5S9JLED91Z9FLDjXkzy6mkStrMTTdctv8GQ= Date: Mon, 29 Jun 2020 16:49:07 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Peng Fan Subject: RE: [PATCH] xen: introduce xen_vring_use_dma In-Reply-To: Message-ID: References: <20200624091732.23944-1-peng.fan@nxp.com> <20200624050355-mutt-send-email-mst@kernel.org> <20200624163940-mutt-send-email-mst@kernel.org> <20200624181026-mutt-send-email-mst@kernel.org> <20200626110629-mutt-send-email-mst@kernel.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "jgross@suse.com" , Stefano Stabellini , "konrad.wilk@oracle.com" , "jasowang@redhat.com" , "Michael S. Tsirkin" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "iommu@lists.linux-foundation.org" , dl-linux-imx , "xen-devel@lists.xenproject.org" , "boris.ostrovsky@oracle.com" , "virtualization@lists.linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On Mon, 29 Jun 2020, Peng Fan wrote: > > > If that is the case, how is it possible that virtio breaks on ARM > > > using the default dma_ops? The breakage is not Xen related (except > > > that Xen turns dma_ops on). The original message from Peng was: > > > > > > vring_map_one_sg -> vring_use_dma_api > > > -> dma_map_page > > > -> __swiotlb_map_page > > > ->swiotlb_map_page > > > ->__dma_map_area(phys_to_virt(dma_to_phys(dev, > > dev_addr)), size, dir); > > > However we are using per device dma area for rpmsg, phys_to_virt > > > could not return a correct virtual address for virtual address in > > > vmalloc area. Then kernel panic. > > > > > > I must be missing something. Maybe it is because it has to do with RPMesg? > > > > I think it's an RPMesg bug, yes > > rpmsg bug is another issue, it should not use dma_alloc_coherent for reserved area, > and use vmalloc_to_page. > > Anyway here using dma api will also trigger issue. Is the stack trace above for the RPMesg issue or for the Trusty issue? If it is the stack trace for RPMesg, can you also post the Trusty stack trace? Or are they indentical?