From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CB2541DDC33 for ; Fri, 10 Apr 2026 21:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775857006; cv=none; b=bxdCe3/MU/FKjzLNGAKUN5uGzQixGb+cZvSa+dqKvtgN5jNSSkULk6SHqZsp+rAkKsiW/1DdSIprNHkAEmj5kaTb2ewKVGRPqC+auK/w9bFCT5qrB8AOVIdywupcnHvmt/liZEGvwXgNVaQ5I756aJQnqFn+PywZ7jNKQubzbuk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775857006; c=relaxed/simple; bh=U0qPGiP06/FJyuhmS2u9RGZ3nvbtn35FKMvhoZt6Of0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=LA4hWfUb3zNBTy51A8AFOtTWqVdgCTUcb15iOoTFttxWyt0H174NkOLKzXzeXTZfZgJoRrSMjpRK42nVCMldEM5skn9sjgZCCHWOboyply5erZjPXseDFpPF+IjNbZ6CZnuzmufHc50ZOEv4MmysTvn8d3R33n1yHnvGSQLky7w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=PbQfq9X2; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="PbQfq9X2" Received: from DairyQueen (unknown [52.148.171.5]) by linux.microsoft.com (Postfix) with ESMTPSA id 4A00B20B710C; Fri, 10 Apr 2026 14:36:45 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4A00B20B710C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1775857005; bh=U0qPGiP06/FJyuhmS2u9RGZ3nvbtn35FKMvhoZt6Of0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=PbQfq9X2IkH3uKdwQ0U9n40tSHha2wO/HIbnFwCziRNXkQy5dH/q97g/ozBnQtk7l mYDKTNwkZ759hTDcYvMWl+aSk5VuMNbE0WS9tG7Es4FTjZAFUUzBUF7wD/J/uUDkx8 E/Fi+MzGNChm2+RKfXvQAYr12OPPASNnQ2wyBfN4= From: "Kameron Carr" To: "'Catalin Marinas'" Cc: , , , , , , , , , References: <20260406213317.216171-1-kameroncarr@linux.microsoft.com> In-Reply-To: Subject: RE: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses Date: Fri, 10 Apr 2026 14:36:42 -0700 Message-ID: <001301dcc932$21cb6d80$65624880$@linux.microsoft.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-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDZ5dKfOR6ho5ixVw3NahcWfi2iMwMH8E/Gt8YywzA= Content-Language: en-us On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote: > Could you give more details about the user of set_memory_decrypted() on > vmalloc()'ed addresses? I think this came up in the past and I wondered > whether something like GFP_DECRYPTED would be simpler to implement (even > posted a hack but without vmalloc() support). If it is known upfront > that the memory will be decrypted, it's easier/cheaper to do this on the > page allocation time to change the linear map and just use > pgprot_decrypted() for vmap(). No need to rewrite the page table after > mapping the pages. Thank you for the review. I understand that my approach is not ideal in terms of speed / cost. For my use case it was not an issue since the memory is typically only initialized once during device initialization, but I understand there could be a larger performance impact in other uses. The use case I am interested in is Hyper-V netvsc (drivers/net/hyperv/netvsc.c). The network driver allocates large send and receive buffers (typically 16MB+) with vzalloc(), then registers them as Guest Physical Address Descriptor Lists (GPADLs) via vmbus_establish_gpadl(). Inside __vmbus_establish_gpadl() (drivers/hv/channel.c), set_memory_decrypted() is called on the buffer so the hypervisor can access the shared memory. In this use case, whether to decrypt the memory can always be known at time of allocation, so a solution like GFP_DECRYPTED is an option. I think I found the hack you mentioned (https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The feedback in Michael Kelley's reply covers the key considerations well. He likely had netvsc's use of vmalloc in mind when he made the point "GFP_DECRYPTED should work for the three memory allocation interfaces and their variants: alloc_pages(), kmalloc(), and vmalloc()." His other points already cover the concerns I had in mind around handling errors from set_memory_decrypted()/encrypted(), etc. What is the current status of your proposed GFP_DECRYPTED implementation? Is this something you are actively working on? I'd be happy to work on an RFC following the GFP_DECRYPTED approach if you think that's the right direction. Regards, Kameron Carr