From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A33B9388371 for ; Mon, 20 Apr 2026 23:01:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776726103; cv=none; b=ia9QIjeuaBQskXQNisWwTLnjr9xSJF/bNbHWwjz3h/YdaTKITvqhGV6knkvdbqeVRG4Is8ddpv/F7rkH4D5wH40m9o4LKupQzMu/Q8vUBdJcYfNP/ny3Exf9q1RIIXic/+/tpJzGfdarUvkgZ+qvX6CoxwG5390E+kvjnk7mUks= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776726103; c=relaxed/simple; bh=vlC9NwXY9DCpD35y1NpvGBMnXFQwzvq4hoA7tHHLiH0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dRnv/uaQkLYh9sWnZTqHzbkKs9x5BovC2uORQuYjCDfpcr6+8SrQ0uKBp+xi/AQ4NguBPFQ9ikREqFPdX+CySocKpXXt15pAW0ZLokECDamjkPYLhrgmKaO/Dl1L6+AUGql7aZO+ehPe4AD30CkMC7SZkEdbEq+1vmXU4ei+qbk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=dQKc4ilJ; arc=none smtp.client-ip=209.85.161.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="dQKc4ilJ" Received: by mail-oo1-f47.google.com with SMTP id 006d021491bc7-69486849135so515532eaf.2 for ; Mon, 20 Apr 2026 16:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1776726099; x=1777330899; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PW4xQG7nqF+lf+D3IisD78kFapb+PoH04igJOs6rmhM=; b=dQKc4ilJjORmOC++60nFeG8SaZIJ94mZIFb/epsPMzhdahw2ifIXKkhQUqo0470XYl VaYt0INUOmYkpFcgvc4T6ks6cceR4YaxbVltp/gWBT/EJtea+fJa+OoQAJ3AtLNgB1RR jvKq3bFltFlRS8LYhbBOcaXgCOhgluLl2Lq1I7xdMxZDCEhzIh2unkUBdKZ+XB2U5O+u 4KOAKeTYk60hHWU8ftSXbbjDKmaMQq26A1dRPFaJd/GIjJ2Evnhpn70gGUkEpJQeYC5W h1Pwr9WuiVOS7gNKVyV5CRROnTCozZq0en0eMa3cb6mECpzaviOZQwNyE09GKSdJEjJR d+Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776726099; x=1777330899; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PW4xQG7nqF+lf+D3IisD78kFapb+PoH04igJOs6rmhM=; b=XXhQfB6XA8PkDF1wshua5g+1vmOZ1ye4tTV7Tq4fO/wp30B3eAJI1yGfLTuLLon3XP LYzge5H/rnqYjpSK13EgbqL306KEHoDZP3hVktIgdDj2SB/b2R7JKQ2T73x1E+Rm/iXp pxASD+9C/ooM7aCUCMOaUma6NfnyJk/Q4dESRRDo4gPty5YYetc5wqxhgWk6UQayVjdW CdDHUXZuWxm3OMEYvkDT+kiqgK86fTkUw19ZEZK3y1l1KCAL8N9C7kIIegMxwKi/XYBI 75OuP+KztfhVnljotgTdFMUzs9GGIwBQTd/BQxl9G921RViShoCBkpkDy9FImSxrN9YG mXXA== X-Forwarded-Encrypted: i=1; AFNElJ+YKL56enumNTlAdHbSoyfnpqB0SDzzyCwXBmN8xQUK/AxKhcxd3rS1F6z9XCmSpMRHZOBGTtxJGdLm97g=@vger.kernel.org X-Gm-Message-State: AOJu0YwSOoHSvAJEMwhlxnNhdOIJgX38eJ7dvpiGn4+FLeIDYxGSnSh3 KmmoAH1ltT9bmAr3UqAOl7dqF3iRjKdKJDLlRGqeJx3ygw6JUIOsuoytJTkmilYgjoQ= X-Gm-Gg: AeBDievqYYU7A2v1XaPc5hRzKop5Q6ZjpFHaEqJGte20YUB9ttNUrsH9lnPxBqHj5b2 7UYS0IMPZMMGg2by7UmU3loleNncdQmHHcBCYhR9lWea1cmRzErN6HOky9JE18KFWngdBD5j05q R0VJhXg2efgMbn1PBQQFIOiWdFYrVobH0Mnfl6QGQC5PUGPpQRHnUi17UXtn5kynaDCk3m8U8KI 6dtzzE3ZgFxdEyRXW9Do7Rq/OBJz4xPJ/+s1cN5FIyulKsxg/g8NjnKTTdz0yHfsIOU99/I+xam oEdV4PZfQwJFQwYUGd3hMWMjXigLWCV7C4opQu/OdWsIS1MKXr2d4ZA0xh+vaiAhuyM+8ugNdej OKBjtSWU4CGy8sgqPRLgQ06xvz6MRX2fWbUTJBXqa+mTHz15HWViYaezCzahTw1OTkAwEgtwG7V l/wXmzZWBN X-Received: by 2002:a05:6820:1508:b0:694:9840:843a with SMTP id 006d021491bc7-69498408649mr135366eaf.7.1776726099292; Mon, 20 Apr 2026 16:01:39 -0700 (PDT) Received: from ziepe.ca ([130.41.10.202]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-69493183021sm916652eaf.13.2026.04.20.16.01.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 16:01:38 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wExcX-0000000F9El-2c2Z; Mon, 20 Apr 2026 20:01:37 -0300 Date: Mon, 20 Apr 2026 20:01:37 -0300 From: Jason Gunthorpe To: "Peng Fan (OSS)" Cc: Juergen Gross , Stefano Stabellini , Oleksandr Tyshchenko , xen-devel@lists.xenproject.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Peng Fan Subject: Re: [PATCH RFC] xen/swiotlb: avoid arch_sync_dma_* on per-device DMA memory Message-ID: <20260420230137.GQ2577880@ziepe.ca> References: <20260415-xen-swiotlb-v1-1-de24eda3c0fd@nxp.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260415-xen-swiotlb-v1-1-de24eda3c0fd@nxp.com> On Wed, Apr 15, 2026 at 11:08:36PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan > > On ARM64, arch_sync_dma_for_{cpu,device}() assumes that the > physical address passed in refers to normal RAM that is part of the > kernel linear(direct) mapping, as it unconditionally derives a CPU > virtual address via phys_to_virt(). > > With Xen swiotlb, devices may use per-device coherent DMA memory, > such as reserved-memory regions described by 'shared-dma-pool', > which are assigned to dev->dma_mem. These regions may be marked > no-map in DT and therefore are not part of the kernel linear map. > In such cases, pfn_valid() still returns true, but phys_to_virt() > is not valid and cache maintenance via arch_sync_dma_* will fault. > > Prevent this by excluding devices with a private DMA memory pool > (dev->dma_mem) from the arch_sync_dma_* fast path, and always > fall back to xen_dma_sync_* for those devices to avoid invalid > phys_to_virt() conversions for no-map DMA memory while preserving the > existing fast path for normal, linear-mapped RAM. I think this is the same sort of weirdness the other two CC threads are dealing with.. We already have two different flags indicating the cache flush should be skipped, it would make more sense to have the swiotlb mangle the flags, just like for cc. https://lore.kernel.org/r/20260420061415.3650870-1-aneesh.kumar@kernel.org Then you know that the swiotlb was used and it should flow down to here. > * physical address to use is returned. > @@ -262,7 +267,8 @@ static dma_addr_t xen_swiotlb_map_phys(struct device *dev, phys_addr_t phys, > > done: > if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC)) { > - if (pfn_valid(PFN_DOWN(dma_to_phys(dev, dev_addr)))) { > + if (pfn_valid(PFN_DOWN(dma_to_phys(dev, dev_addr))) && > + !dev_has_private_dma_pool(dev)) { Also this pfn_valid() is totally bogus. Unless DMA_ATTR_MMIO the phys must have a struct page, be pfn_valid, etc. This is why you are getting into trouble here, beacuse swiotlb created a non-struct page address and passed it to lower layers without setting something like DMA_ATTR_MMIO.. Jason