On 16.05.25 11:31, Teddy Astie wrote:
Hello,This series introduce support for confidential computing along with a AMD SEV implementation. It also bundles some of the functional requirements (ASID scheme, ABI, ...) which could be separated if needed. (I bundled everything in this serie to have a complete coherent serie) This work receives funding by the Hyper Open X consortium (France 2030). # Concepts A confidential guest is a bit special as : - its memory is by default encrypted or not directly accessible by the hypervisor, thus other domains/dom0 as well; it must be explicitely shared by the guest itself - so its page-tables are also not accessible # Implementation Confidential computing is exposed in a uniform way regardless of actual implementation (SEV, TDX, RME, ...) through the coco_op hypercall (mostly for use by the Dom0 toolstack). This interface provides a way to query informations on the coco platform (support status, features (un)safety, ...), and prepare initial guest memory. Only HVM domains have support for confidential computing. (in the future, we may want to have attestation support) In order to create a confidential computing domain, the process is follow : - create a HVM/PVH domain with XEN_DOMCTL_CDF_coco - populate initial memory as usual - apply coco_prepare_initial_mem on all initial pages (under SEV, this will encrypt memory) Under xl, it is exposed through the `coco` parameter ("coco = 1").
Wouldn't it make sense to allow specifying the kind of domain (SEV, SEV-ES, SEV-SNP, TDX) like KVM does? It might not be needed right now, but in future this could be needed (e.g. when allowing migration between hosts with different SEV features). I don't think this is important during RFC phase, but the final configuration and hypervisor interfaces of this series should allow that. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
