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=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 4FA30C4338F for ; Fri, 13 Aug 2021 10:52:05 +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 07CB960EFE for ; Fri, 13 Aug 2021 10:52:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 07CB960EFE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.166738.304338 (Exim 4.92) (envelope-from ) id 1mEUn2-0001Rb-1W; Fri, 13 Aug 2021 10:51:52 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 166738.304338; Fri, 13 Aug 2021 10:51:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mEUn1-0001RU-TS; Fri, 13 Aug 2021 10:51:51 +0000 Received: by outflank-mailman (input) for mailman id 166738; Fri, 13 Aug 2021 10:51:50 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mEUn0-0001RO-Oq for xen-devel@lists.xenproject.org; Fri, 13 Aug 2021 10:51:50 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mEUmz-0003wt-Ni; Fri, 13 Aug 2021 10:51:49 +0000 Received: from 54-240-197-224.amazon.com ([54.240.197.224] helo=a483e7b01a66.ant.amazon.com) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mEUmz-0006U2-HK; Fri, 13 Aug 2021 10:51:49 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=+tMzSgNzRjFy+PDaDtEDQ0moqHqk5fHbOx92koaUkrg=; b=dT0tjP8yR4hND1RbtKOQBWuX/O 45yjlP1Aqpjud2ddzbOoVGUKgmLUcGY+Btl8JNh6RsoqVpNx4l4FgiRQ4nS8d3Yy82W2NXrN8KXow r4YuGiZMVFAuQQncRO6NJbF4qPPW7eDVa6kC90EFJ2ryriE9bM69lyAaSeEFwgovKAdA=; Subject: Re: Disable swiotlb for Dom0 To: Roman Skakun , "sstabellini@kernel.org" Cc: Bertrand Marquis , Andrii Anisov , Volodymyr Babchuk , Oleksandr Tyshchenko , Oleksandr Andrushchenko , "xen-devel@lists.xenproject.org" , Roman Skakun , Jan Beulich References: <060b5741-922c-115c-7e8c-97d8aa5f46f4@xen.org> <691e31db-c79b-9196-53e1-cbbdc9bd3a54@xen.org> From: Julien Grall Message-ID: Date: Fri, 13 Aug 2021 11:51:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit On 13/08/2021 10:38, Roman Skakun wrote: > Hi Julien, Hi Roman, >> So 0xb6000000 is most likely the GFN used to mapped the grant from the domU. >> >> swiotlb-xen on Arm will convert it to the MFN because it is not aware >> whether the device is behind an IOMMU. > > If I'm understand right, it seems like that swiotlb-xen is not ready to > work properly in case > when we retrieved MFN instead of proper GFN mapped to Dom0 memory. > Maybe you know some ideas to overcome this condition? swiotlb-xen work as intended. You have a DMA buffer at an address that your device cannot deal with. So it will try to bounce it. > >> As the address is too high to be handled by the device, swiotlb will try >> to bounce it. I think it is correct to bounce the page but I am not sure >> why it can't. What the size of the DMA transaction? > > The DMA map size is 3686400 bytes. So that's a 3MB buffer. I am slightly confused because in an earlier message you wrote that the memory is coming from the guest. How did you map it? > > I've added several logs to swiotlb map_single() and see: > [  151.298455] swiotlb_tbl_map_single() origin_addr: > 64af97000, needed: 708, > avail: 7fc0, stride: 2, index: 4160 I am not sure how to read the logs... Are the number in hexadecimal or decimal? It might be useful if you post the diff of your changes. [...] > Swiotlb did not fit requested slots because the maximum slot size equals > IO_TLB_SEGSIZE=128 by default. Ok. So it sounds like your problem is the have a DMA buffer that is too large for the default swiotlb. Did you try to bump the value from the command line? > But I think, we cannot use64af97000 address in the swiotlb_bounce() > directly. I am not sure to understand what you mean. Can you clarify? Cheers, [...] -- Julien Grall