[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Allocating SEV C-bit-cleared pages (without relying on swiotlb)


  • To: Teddy Astie <teddy.astie@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "linux-mm@xxxxxxxxxxxxxxx" <linux-mm@xxxxxxxxxxxxxxx>
  • From: Michael Kelley <mhklinux@xxxxxxxxxxx>
  • Date: Fri, 28 Mar 2025 16:30:57 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=eKfPkJWqqtna9YgBxWWb70kH76Gv5EB8a2uCVkpzmGM=; b=xEpPeBj3yVGPrS4HjlK9JbVoQGFxsWTJeMJL/u0YKoQDpAzaixddVJz80UI5h1FMVDl2BXsdelHBhuQl+4YeSqTqL5RQ2A+e4OtTM2bQ1hx4zr9WjSc9CxZB09+KuifXVkqnjz0DVdqzW6GoKXe8fK1uDCU20lieJazFRI/CzTSsBmP7FzioirSB2dacELAhOsYM0cx0gU8pMcQcBycrhSBm9sd/b9CNnPkB2bWAe6TI6nyCN8w981gv8KZav7HpF8DsiPTJumJ7WkH9V78fNJu8DRLMsWIZdb0vxJ7YeP+q0IFaQK77SJHoU8YfyZkv/adUthZrf1vZx+0LXYixlQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=U6JmUu/Hqs+frGhi/fJ3DguzQY3OpEsdgo/1IlK+Q3XsoaspjPWB6FD2ETktWRSQ/sU0nRJNoevv1Z5YVhBxV+9ToDDHyZ1ht2siY7LKS0Hyv5CFX9u+E3AYXfHEmTeKJZYBS1x4lrM0mlUvZeodrEUqL+f89xbjYntqrX68lk8YnXz+kgaT/tmejJRuDqPTOsFRIhTKS/lpAp7t5N4ltPifgMHEtDUoEy9I5Fwm+BSvJGUot7P0Zmq0ZWT59OTncK2p9bfvM2pOjZr49nY9yejIL7X7i8PenEAqgXwDIimxbOjRo/R2awsrIxEZ1hhDTcy3CsAxRHY+Zeq9Yfhxlg==
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 28 Mar 2025 16:31:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHbnyKPeCLT8FgtS0qlE8WmAsket7OIu/hA
  • Thread-topic: Allocating SEV C-bit-cleared pages (without relying on swiotlb)

From: Teddy Astie <teddy.astie@xxxxxxxxxx> Sent: Thursday, March 27, 2025 7:12 
AM
> To: linux-kernel@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxxxxxxxx
> Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Allocating SEV C-bit-cleared pages (without relying on swiotlb)
> 
> Hello Linux mailing list !
> 
> For porting Linux code to make it work on Xen with AMD-SEV, I need to
> change the allocation of some pages to use "shared pages" (C-bit
> cleared) instead of private pages (C-bit set, which is the default kind)
> as these pages needs to be shared with the hypervisor/Dom0.
> 
> Is there a facility to allocate pages with C-bit cleared (and if not
> running under SEV, just allocate a plain page) ? Current Linux code for
> SEV seems to only rely on swiotlb as access to shared page is mostly
> made through DMA-kind devices (e.g virtio or emulated device), but I
> don't think it is the best approach.
> 

For allocating memory that can be shared with the hypervisor,
allocate memory as usual (with alloc_pages(), for example), then
call set_memory_decrypted() on that memory. This approach
works in general for Confidential Computing (CoCo) VMs,
regardless of whether the underlying hardware is AMD SEV-SNP,
Intel TDX, or ARM64 CCA.  If you are running in a non-CoCo
VM, set_memory_decrypted() is a no-op, so you can call it
without having to check whether you are in a CoCo VM.

When freeing the memory, do the reverse. Call
set_memory_encrypted() first, then free the memory as
usual. Note that if set_memory_encrypted() fails for any
reason, just leak the memory instead of freeing it because
the encrypted state is unknown after such a failure.

If you search for set_memory_decrypted() in kernel code,
you'll find several examples.  See drivers/hv/hv_connection.c
as one place where code for running on Hyper-V follows
this paradigm. There are several other examples as well.

Michael



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.