From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (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 3D1A147CC64 for ; Tue, 16 Jun 2026 18:45:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781635505; cv=none; b=BWh08intCDsJYBbZOvHSXcLPUc8pZFf0Wlk/l9bleI3b5eGvbHFBe5K8gH8R94h7PLX/GwqrjZKQMSluzTAAlRvjYUm+XZOpG2PSCxx0wi0b2Co/5xskGbUINvwHTy0WrXEHihx8DyzjNmuOnMvFOYsBIr2am/NfpgpmY/HjKvM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781635505; c=relaxed/simple; bh=R33LmJr8q6kqHkYQWLGz7MbJ2uGNUERbltu0/vzmAZA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UWiSvcadZGu4B9IBohuPeGT9AXA3/Jq6TNRWgaWpDbWPpbVA2io3fl081+YRNQO6xo+UtyAY2nbS9UmQDVpxAculTyKCNT7x7Hspw++z/ygB7Q/ldPrK882zDQRzlunJijW8430V8ZLf8dm5sr5JF5blURQxUxYcscHKZcRtN98= 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=T4JfqicZ; arc=none smtp.client-ip=209.85.222.179 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="T4JfqicZ" Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-91591f19716so566337885a.3 for ; Tue, 16 Jun 2026 11:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781635502; x=1782240302; 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=G18mYJrcuFPmmxraU/yFJy+0YudgzW+4bZ7GypMnwpM=; b=T4JfqicZzZGAd3Iq0AI/QoklaZe8luHmOlnlWw8FumCX0CnemK9mWP39FdQgvdfiuD 5eEYoPjXGJvHFpeAHX5OJUI/e+PO6wNfX4PQJuXK/QMAVGNPa79A5og1u6oEl7n/9K/r fZWzRRhkIg3P9q2bN7zTvLXND1puINA3RHda9yG0ZmfYNgqsxk6q1EgMwfrMJ8G6L3sV 1gf+Vm7gk3HC9mva9dPx1luQ7ve9eo9ND4xU0pD45mQrKPr5elRZKtQke9HyshRHkAxF PnVy01T/NjO3rfUCzKQQPC/Cgmt4xzLJJB9e5L+KvIaDLO+O26x37TSf/Jr1X/8ZZiA4 8CKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781635502; x=1782240302; 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=G18mYJrcuFPmmxraU/yFJy+0YudgzW+4bZ7GypMnwpM=; b=nZDpp3T/8GecuyFocoqn4FkxuhPjmP5ZA9sUsP2I+H5hyx2SKBCLWnZELsfembUxBn EFEAEKE3dHYMFDZl4SaWYoIe39Jk4rpzST3YfBTDrkuMh60YLA7txZ8Js1MeNRxoTFnk /2NdprMdL2MpvjXnzNR1k5osBC3MPKoQg03zzx0blV6K9ZeOTYurHo5TDNmePgIn8AUF 6vrTPeXXroWJQFp6bUSnaklLQMs6FMWnYlMtYXAXD/8OWybNsRDeNTJIAkplNyfGsYt9 Cz/TCGnSPW3Ut7/eTFC2jZqfj6DLMxO+u3t4qokMRC0UACn5kqeO3X8/jTMzZeVL6L1j O6dA== X-Forwarded-Encrypted: i=1; AFNElJ+CLym7RluGmS/qCqOXrgTpIAr1Ss0Prhav+Q9b8EPfP/q+LxXOT86XVKKaMI9mk+GxPByymJ7xYLiinJ0=@vger.kernel.org X-Gm-Message-State: AOJu0YzFGu6YJIBBaC5TtMOJ3EL5elDtzNb0pg7nkrmdJdrGah/RVyKL 5d9B2uD5te3efSQiFRq9vrUD8j/wlOpnEAUQHhQI4907sGLQ2kG5ey8eO5wcpqSND14= X-Gm-Gg: Acq92OFELwGYkXi0bDJEtbDQji2NV5HjAvU6kKctx3PxwfBmMRb5xzsBMcN4ZiaLFIN eadBtj75tR4GjfqcbWDKPMfucN1dCbPbf5vmzC8ZRbKCGtIqHeYTIOFwkj4WUaLOolPieMuVIK8 fcWx5eLOuZAw0MERmFMDMbQygzerysmQZlAKK55BuTQY5DDfyCjqY8a+h6Cp54D2FoMz8fTB34N 1lV85yOEpkSApSgTn85a9N6wcttezgblu+VzQle5EGV44GrHrfc/pF54fRr7jPkS4QY5f1A4JBs xKt2rZ3x/vXyY6ycRhgxCLYYhSARJGlXGaQQFT4YXGCC+MvEd/Wao9vv9FBQg56v+R/uh5uFnlY eTnmx+kDSobU0vQb9v8mRQoYB8FXjgNzzyzplp7nd+FIIslfUk6n0tPx+Z5DZfxvWaqpCZTOwVz QpMWBSuI5nzJssCqhK+YGJOTU41M9iSSRU6WgxG495ojr4ahmvvMrCrj792Mh7ivj7kdFsh3o8N uN7BQ== X-Received: by 2002:a05:620a:2908:b0:915:d32a:1cba with SMTP id af79cd13be357-91dbc52c4damr20136485a.27.1781635502015; Tue, 16 Jun 2026 11:45:02 -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 af79cd13be357-9161a00af50sm1669672285a.30.2026.06.16.11.45.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Jun 2026 11:45:01 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wZYmS-0000000GgQZ-3dnI; Tue, 16 Jun 2026 15:45:00 -0300 Date: Tue, 16 Jun 2026 15:45:00 -0300 From: Jason Gunthorpe To: Catalin Marinas Cc: Christoph Hellwig , Kameron Carr , akpm@linux-foundation.org, urezki@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, mhklinux@outlook.com, linux-coco@lists.linux.dev, Suzuki K Poulose Subject: Re: [RFC PATCH] mm/vmalloc: add vmalloc_decrypted() and vzalloc_decrypted() Message-ID: <20260616184500.GD3577091@ziepe.ca> References: <20260521205834.1012925-1-kameroncarr@linux.microsoft.com> <20260611114954.GC1066031@ziepe.ca> <20260612181807.GP1066031@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 Tue, Jun 16, 2026 at 07:17:33PM +0100, Catalin Marinas wrote: > > The entry point is dma_alloc_noncontiguous() and you get a scatterlist > > back. > > Yes but not scattered pages unless there's an iommu behind. Anyway, > that's an implementation detail, something like > dma_alloc_noncontiguous_vmap() could allocate scattered pages as a > fallback. Oh I never noticed it deliberately returns only a single dma entry. I think that could be optionally weakened without alot of trouble There is also dma_vmap_noncontiguous() already, so I think the main framework is there, though it seems like it needs a a bit mmore features. > Currently, something like netvsc_init_buf() just does a vzalloc() and > passes it down to vmbus_establish_gpadl() which knows how to interpret > the channel encryption status. I assume with the vzalloc_decrypted() > API, that info needs to be interpreted at the netvsc_init_buf() level to > know which allocation to call. But it doesn't end at alloc does it? hyperv will still have to reach into the vmap and convert it into an appropriate IPA to pass to the hypervisor. That really needs to use the arch helpers the DMA API has and those should not be called by any sort of driver environment like hyperv. > If we move towards a dma_alloc_noncontiguous_vmap() API we need vmbus to > encode the encryption requirement in the hv_device::device somehow so > that force_dma_unencrypted() knows what do return. Yes, they would have to act like PCI and mark in-TEE and out of-TEE struct devices properly so the DMA API knows what to do instead of open coding a copy of all this logic in hyperv. > We have the DMA_ATTR_CC_SHARED but that's not interpreted on the DMA > alloc path, It is to describe memory that was deliberately allocated as decrypted, not to control allocation choices. > so there's a bit more work needed on the DMA API I think (not sure > whether Aneesh's series covers any of this). I don't think it does directly. It largely sets the stage to properly allow a struct device to opt out of force_dma_unencrypted() so we get support a T=1 PCI device. Jason