From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) (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 6D4DB3C5527 for ; Mon, 13 Apr 2026 12:42:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776084172; cv=none; b=GyPZvAoHkpXBN5ta/QHGVfJv6WUBoMaRdjf8a5BdphBrWgvpobQ2pZaiTnDoGeFEdf9UP1lyLATi9RlmFk50LlSALsZMZbZEViwLgxiUX3HcwISvQqQDv4MohEM8fTGKD7Nru0PGl0FS8krjWeueHO158xr7ATu+e8heSs8vSIY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776084172; c=relaxed/simple; bh=90ZMP4TNlxyJ/Yeh1tSOQGp5I6K5IIQxFKoVAV2OK6E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cjpxhBZCA4ClNintryrwdPu6dqN6snV0mwYPHO4IXw7oBphrOOkgZlFETr7mWGGC19kBA0W1p5aeY+LCu9pAs/qHBVhagXXmRMD3diD4A2y9R5ANW4WFXq8AQs/8P+GIT2nC56ix2mNvpTD9b1Fj8u95HhQIx2iJ7Rg87x1Cyjo= 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=JuF34WxZ; arc=none smtp.client-ip=209.85.160.170 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="JuF34WxZ" Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-50d6b9bca48so57366431cf.2 for ; Mon, 13 Apr 2026 05:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1776084170; x=1776688970; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=XOgoRtm/p/VFr1yy216q4ryxbtSDlK7xGvp+FYzmvUk=; b=JuF34WxZTinEC+vvuU/mtDQndHUHePDIR2vObBcIFeryqRVctvVGutjk31nShbJzDl cv5lZHPsJ7L1GYEDAvKt8gueZZ8AEqf4qcACyk44Iq7FaEFCvHhnOaHudaJxum1EG9Xu HyT5Gb+mtJvuQM2K1EnopnhUK/x8qegcI0eO43AEd6nxlhxu5nY+4xlkuSRFFjyv1sev s1mXGSwYIjzhDoqKnERXKUkOA2HdsQatiaarsPPDifaZmM1JTbCHQeFJS390qI9LJcKa gZUyeED7nNB5W6oyMAaWc6Or9YXugzpa3p1B3ALO4btyYhX7JvO3gYj4sQWdu6fLd1X1 imqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776084170; x=1776688970; h=in-reply-to:content-transfer-encoding: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=XOgoRtm/p/VFr1yy216q4ryxbtSDlK7xGvp+FYzmvUk=; b=nDFvLwU2P25xXEzQPANkrxpW0dZ4G0mTFluFF9NYjivhSPYnivrmZAQX3zJ89KBn3x VFaiiLTwpeiUWcQ/rAr3vXGa1U0KPjHcUJIUb2+u3c8tXJpyVWgvCPb1LuVPrWGrhtfD WIZ+61S4UlqZzcZFy0LwdWyLJ7CdxK39yFn7dfKnTJlaG5YFJxaxB9zNIfF4KgHYYzvW nE+lzkvZCYTJe5tldAAbYzJenQ1w8KRfyWXfhk/aiTUO7dGNya6PspR/n5BJgk6XINtQ WdGRKamB0aQgtj4plQ30D0U1DrQ0+BCfiI6X3mr4yprzKSJqAq0OgKam0+zxyWg75p1G qHFg== X-Forwarded-Encrypted: i=1; AFNElJ8QUSJgi4vyUT7zKsCAk2Odrh64Dq6ttHRuNb2YS3n4AOYphyNXUWheaWomM/J2YTX35hfI8SlTP8KiKdI=@vger.kernel.org X-Gm-Message-State: AOJu0YzMZNDR6q1VyNWBfbH193uJUQbHpEusI5RKiKWoiN5EG+uvmTO4 PcqjIzPlkOFT4M4ksXagn8kQryviUHgil+sJFgqc1qeK3+pwf0hbN1CgOyxSJ7azYOo= X-Gm-Gg: AeBDieslR8xNLP+1dKt+ITISBrRyR9bz2JoUwTc2CqBMsQrkWtP1tHXjiIP9vk6GyJv g9Vu1+WG+M8461sJL1QcymXtkaH4gk0UlKUcODGcFicAJUqS/W9JqHWYXZD3soy/TpDjv9+Ia9P QmB61xXXQd3JiuiHQCxCD/lSZxbpVP7OUWMbI+BrLgPlOt2uKVl6ATnTfjgbQVBQ+JbQvtqhnSK +5TZO+L5REyQT0XzXhAhrsZ3CZOlA7ROPEiu+IhEztSlsh8dHJKxubUxmF4sFn17Ltiu5LUPUDk PP55S5+bIZD/JiNL4T83sUdEdYlvA8MLBmgkIzw1qlWUkaiNgsFVeBUfhoL7Cd0eMwI4W2OSFpZ 2TQesJLjIjWL7OyfS3ZDvz6+1ij9OJiba6sV9N7wbsN4hRohem7Jl90zxE4/+eNfI3GF6BZS8A6 y65v48407sLNhh9KbASYkCfatyo2EMrMcBlwC+GqIGAFkcTzj+HKKfral4ghBGJswWgZ+M08yeC ihdQw== X-Received: by 2002:a05:622a:1f8f:b0:50d:736a:624a with SMTP id d75a77b69052e-50dd5b95bafmr219462791cf.1.1776084169641; Mon, 13 Apr 2026 05:42:49 -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 d75a77b69052e-50dd550036fsm81771801cf.21.2026.04.13.05.42.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Apr 2026 05:42:49 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wCGcq-00000005AiQ-1fsL; Mon, 13 Apr 2026 09:42:48 -0300 Date: Mon, 13 Apr 2026 09:42:48 -0300 From: Jason Gunthorpe To: "Aneesh Kumar K.V" Cc: Mostafa Saleh , iommu@lists.linux.dev, linux-kernel@vger.kernel.org, robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us Subject: Re: [RFC PATCH v3 5/5] dma-mapping: Fix memory decryption issues Message-ID: <20260413124248.GJ3694781@ziepe.ca> References: <20260408194750.2280873-1-smostafa@google.com> <20260408194750.2280873-6-smostafa@google.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon, Apr 13, 2026 at 12:49:34PM +0530, Aneesh Kumar K.V wrote: > > 2) Using phys_to_dma_unencrypted() is not enlighted about already > > decrypted memory and will use the wrong functions for that. > > Can you split this into a separate patch? I’m finding it difficult to > understand what the issue is here. Adding the unencrypted flag multiple > times to an address is not a problem in itself. Even so, I still do not > follow when we would end up doing that. I think my comments show how to address it right.. > phys_to_dma_direct should depend on the device state. No, it depends on what state the CPU address is, which in some flows would have depended on the device state, but by the time you get to generating a dma_addr_t it should be based 100% on the current state of the phys_addr and nothing else. Assuming that a T=0 device must be presented unencrypted memory is an easy hack but it doesn't work when we get to T=1 devices that can handle both encryped and decrypted memory. Then we need to track it explicitly. The only places we we should check the device state for T=0 is at the very top when we decide if we force it to swiotlb and inside swiotlb when we decide if the allocation should be decrypted. Everything else should flow from tracking the phy's state, and be tied into the new DMA ATTR UNENCRYPTED. Jason