From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) (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 6FD0E3D75AD for ; Fri, 24 Apr 2026 13:44:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777038258; cv=none; b=dIDXAdFxLgqoix0Ran2oQ8X+FRZ0ZBDyjr5uW15RMSDOIqRAi9PgoZm2jHKFCoiCNeAgusd6jUn0Dd7e/fEzVFjNAotgiSPrnNlgMEPY4/vOiC5US5GeB4L098piQwRfNbT5AY5hrbUfN0EKysbA/FAGZ0n9L+WzavyRTrwWeWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777038258; c=relaxed/simple; bh=i1i2c485F0Qe0xpZ3iilWtVCakNDvIIadcOceyICV/Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MNCYqLu2ruU/jdg27K+k8sY/f/5FWtWlWqKIG1fDO1zJMNtFrvl0tc9hNVFQyA+PCOQ1+BJCl2Hj1rEUn/VVt/9NN6vyBiekTnB39/71CVmXee4gNGaHyzDV6HB3MQgAOqvByM40ci3Mr9Bhltj+Smxdqw5/wGGIAburAKf55nM= 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=eWXvk47f; arc=none smtp.client-ip=209.85.219.52 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="eWXvk47f" Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-8a016799d2cso87075686d6.1 for ; Fri, 24 Apr 2026 06:44:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1777038256; x=1777643056; 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=Zv88UvTgiwZqXaUOezK9Ft5EGGZMSyJ0Ff2r4iX0Lmc=; b=eWXvk47fQSUz9e2q2NeLxCyuEZt2gUmMOnGpL2tcRX8l9aozIK1ofWLt2Er64Gb7FL +F/tGJR3t33ebdRYus7eaRwq2JRYthcNpY+F/oOgepV3K8k1Qz/HPJHQpWoNHsspa39E dslmDJ9ZkvIDdyBYtm8VBG0kdJN6eQKvE90VyEy/0vMyW4Lmi5KWntKTN8Vno82jey2N MB9xG1J9CENM64Sh1H/kmTTPQMH1HlKNe10qDQVic2GBNKZbzYJDmmSegjP5XDrNKUR3 9DsgsXSNpSHE8bS2t9275fmZ8OGwZk9HRaZ05tmHF6lJDcLbfr40gJhcI1YhjS35S/5/ Wbqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777038256; x=1777643056; 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=Zv88UvTgiwZqXaUOezK9Ft5EGGZMSyJ0Ff2r4iX0Lmc=; b=KquWAihJ8+Xrzy5wxzoeAkLMl6te5s3Wwj0YaRVZBbX9LBfZUn4bsdTUOawyNlN/d6 KqJoBfcZnSHRbWMBp6d639/WYsog98puWINvjBP/88WL1pcZ9HuiWbiVcJqqeZEZr3Jk 8MczeptvK4OAGxGYbVMryik9LgO6RO6LJiBRXARYkL8cL9pR5K/heKAJFvjoWF9C4YWt 3UqtHDf2NXq1dzMjxDIH4GBMLuYXIsIklGvpkFfSH9p3MzQMu5vfP+dk8jOXdwqB2GAR Qw/LBKhxYJQgZlcNaU7wEbTMiGAUMn5S/afWMnFv7hONVax58U3C5qQxHmCzSOFyo3yj y9hQ== X-Forwarded-Encrypted: i=1; AFNElJ/c7jedXphWc+y8gmhFeNB//dmI3lLLzp+gYSQI+a3Yfu37eEvX+vJyA0/+WNXOuQkNwoI9kL/KY8CdWZ4=@vger.kernel.org X-Gm-Message-State: AOJu0Yziow2lde9BkzeOT4lHAC8E63YrvSNpvwkrS5LVOIRAs/3YiW4D BU7gZUCpaRzTGesdYGwx6P6wLwiGTf90Dh8xLB4s8cSSIw1TVz2LIZV7FxkYvbgQkhU= X-Gm-Gg: AeBDiets98yhxMRH43TJXaS0VL4TNEfhWlLJA2ax7bKSjk2uMDnoUIiTPTH8OYjhCFh sgHcJjowwv/rKQK251R4fwhVxYQ6m1KLV6Mibquk/b9wjrgPWzFEGvpj5VwhlEomoA+4PB5xLDh PskDwkhrNBvOCGylNgr6/7ZhBYRO3oUt31gwZlucgn3/vBGxB8+T9QhGf3XCeqJDdCudoj0iRRe l9I6Mho64O2naL4xfDsw6kryE5iP6EydTewr6gTKP4KYAWvoUAKuIO8JXhMHwUXzDqsgCWzYZkh gdbm97OOs4PqvYfZRtz35WGoIplBTLiBaz7l2ggSOJZRewVCFszzwAdkw+y4EjjjY+FJWxUJ2iH 4qJoc721HXzjYS9hlSlVtgWTti1LMZcP9h7KVHF8c8TkJp4sciBzxml9jZ9yhTYvccjdxIexA4O bw3Bf5DoBjho6Zu2/g0qjUYMakNw0e/0NoLmnrJm3xLm7PHhNbKd7Uiog0QaTaQUWwhVJuhYdlY A9ax+id495PCpGxpG6e/v+j7FI= X-Received: by 2002:a05:6214:20a8:b0:8ac:a914:c2cd with SMTP id 6a1803df08f44-8b0280808cfmr513452986d6.20.1777038256324; Fri, 24 Apr 2026 06:44:16 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b02ac6c3e7sm188611786d6.13.2026.04.24.06.44.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 06:44:15 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wGGpL-00000002Zm3-0EMP; Fri, 24 Apr 2026 10:44:15 -0300 Date: Fri, 24 Apr 2026 10:44:15 -0300 From: Jason Gunthorpe To: Peng Fan 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: <20260424134415.GZ3611611@ziepe.ca> References: <20260415-xen-swiotlb-v1-1-de24eda3c0fd@nxp.com> <20260420230137.GQ2577880@ziepe.ca> 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: On Fri, Apr 24, 2026 at 02:57:19PM +0800, Peng Fan wrote: > Hi Jason, > > On Mon, Apr 20, 2026 at 08:01:37PM -0300, Jason Gunthorpe wrote: > >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. > > Xen fully implements dev->dma_ops and does not leak hypervisor-specific > semantics outside of it. It may have its own re-implementation but the same remarks apply. The flags in attrs should be correct and you should not be putting random boolean checks all over the place to make up for incorrect flags. Jason