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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3C4BAC433FE for ; Tue, 18 Oct 2022 14:33:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 320B610E62E; Tue, 18 Oct 2022 14:33:32 +0000 (UTC) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by gabe.freedesktop.org (Postfix) with ESMTPS id 21F1A10E243; Tue, 18 Oct 2022 14:33:25 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id A17A968C7B; Tue, 18 Oct 2022 16:33:20 +0200 (CEST) Date: Tue, 18 Oct 2022 16:33:20 +0200 From: Christoph Hellwig To: Jan Beulich Message-ID: <20221018143320.GA19106@lst.de> References: <20221018082413.GA25785@lst.de> <20221018110243.GA4655@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [Intel-gfx] i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment" X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Stefano Stabellini , regressions@lists.linux.dev, dri-devel@lists.freedesktop.org, Anshuman Khandual , intel-gfx@lists.freedesktop.org, Konrad Rzeszutek Wilk , Marek =?iso-8859-1?Q?Marczykowski-G=F3recki?= , Oleksandr Tyshchenko , iommu@lists.linux.dev, Matthew Auld , Rodrigo Vivi , xen-devel@lists.xenproject.org, Christoph Hellwig Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Oct 18, 2022 at 04:21:43PM +0200, Jan Beulich wrote: > Leaving the "i915 abuses" part aside (because I can't tell what exactly the > abuse is), but assuming that "can't cope with bounce buffering" means they > don't actually use the allocated buffers, I'd suggest this: Except for one odd place i915 never uses dma_alloc_* but always allocates memory itself and then maps it, but then treats it as if it was a dma_alloc_coherent allocations, that is never does ownership changes. > I've dropped the TDX related remark because I don't think it's meaningful > for PV guests. This remark is for TDX in general, not Xen related. With TDX and other confidentatial computing schemes, all DMA must be bounce buffered, and all drivers skipping dma_sync* calls are broken. > Otoh I've left the "abuses ignores" word sequence as is, no > matter that it reads odd to me. Plus, as hinted at before, I'm not > convinced the IS_ENABLED() use is actually necessary or warranted here. If we don't need the IS_ENABLED is not needed I'm all for dropping it. But unless I misread the code, on arm/arm64 even PV guests are 1:1 mapped so that all Linux physically contigous memory also is Xen contigous, so we don't need the hack.