Re: [PATCH v1 0/2] Starting AMD SEV work

[Andrei Semenov <andrei.semenov@xxxxxxxxxx>]

Yes, actually a PSP device and all its interfaces come as unique PCI device (one BDF). So, yes we will need to export 

other interfaces  as a paravirtualized operations for dom0. Actual PSP design feet very well for KVM, but for "type 1" 

hypervisors it oblige to export all other potential PSP interfaces for priveleged guests.

Best regards,

Andrei Semenov

Le jeudi 11/04/2024 02:50, Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx> a écrit :

On Wed, Apr 10, 2024 at 05:36:34PM +0200, Andrei Semenov wrote:
 This patch series initiate work on AMD SEV technology implementation in Xen.
 SEV stands for "Secure Encrypted Virtualization" and allows the memory contents
 of a VM to be encrypted with a key unique to this VM. In this way the neither
 other VMs nor hypervisor can't read the memory content of this "encrypted"
 VM.

 In order to create and to run such a VM different layers of software must
 interact (bascally Xen hypevisor, Xen toolstack in dom0 and the encrypted VM
 itself).

 In this work we start with discovering and enabling SEV feature on the platform.
 The second patch ports AMD Secure Processor driver on Xen. This AMD Secure
 Processor device (a.k.a PSP) is the way the different software layers interact
 with AMD firmware/hardware to manage and run the encrypted VM.

How will that interact with the PSP driver in dom0? AFAIK amdgpu driver
uses PSP for loading the GPU firmware. Does it mean one need to choose
either GPU in dom0 or encrypted VMs, or is it going to work somehow
together?

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab