Re: [Qemu-devel] [PATCH v12 08/28] target/i386: add Secure Encrypted Virtulization (SEV) object

[Brijesh Singh]

On 3/8/18 10:49 AM, Daniel P. Berrangé wrote:
> On Thu, Mar 08, 2018 at 06:48:41AM -0600, Brijesh Singh wrote:
>> Add a new memory encryption object 'sev-guest'. The object will be used
>> to create enrypted VMs on AMD EPYC CPU. The object provides the properties
>> to pass guest owner's public Diffie-hellman key, guest policy and session
>> information required to create the memory encryption context within the
>> SEV firmware.
>>
>> e.g to launch SEV guest
>>  # $QEMU \
>>     -object sev-guest,id=sev0 \
>>     -machine ....,memory-encryption=sev0
>>
>> Cc: Paolo Bonzini <address@hidden>
>> Cc: Richard Henderson <address@hidden>
>> Cc: Eduardo Habkost <address@hidden>
>> Signed-off-by: Brijesh Singh <address@hidden>
>
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 4c280142c52c..6113bce08a8c 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4353,6 +4353,50 @@ contents of @code{iv.b64} to the second secret
>>           data=$SECRET,iv=$(<iv.b64)
>>  @end example
>>  
>> address@hidden -object 
>> sev-guest,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden,address@hidden
>> +
>> +Create a Secure Encrypted Virtualization (SEV) guest object, which can be 
>> used
>> +to provide the guest memory encryption support on AMD processors.
>> +
>> +When memory encryption is enabled, one of the physical address bit (aka the
>> +C-bit) is utilized to mark if a memory page is protected. The 
>> @option{cbitpos}
>> +is used to provide the C-bit position. The C-bit position is Host family 
>> dependent
>> +hence user must provide this value. On EPYC, the value should be 47.
>> +
>> +When memory encryption is enabled, we loose certain bits in physical 
>> address space.
>> +The @option{reduced-phys-bits} is used to provide the number of bits we 
>> loose in
>> +physical address space. Similar to C-bit, the value is Host family 
>> dependent.
>> +On EPYC, the value should be 5.
> Is it valid to specify a different value for either of these properties ?
> eg what happens if I pass cbitpos=45 instead of 47 on an EPYC host ?

On EPYC, passing anything other than 47 will trigger error during SEV
guest initialization. The value of Cbit position is host dependent, the
value is readonly and can be obtained through the host CPUID.  The
cbitpos must be same between guest and host. Please note that the pte's
in guest page table will need to use the cbitpos  information to mark
the pages as encrypted. If cbit position given to the guest is different
from the host then guest will fail to execute.

>
> In particular I thinking about possible migration scenario, where EPYC
> uses 47 by default but some $NEXT AMD CPU uses 48 by default. In that
> case we might want to use '47' on both CPUs if we need ability to live
> migrate between different host CPU generations. Would that be valid ?

We will not be able to migrate SEV guests if cbit position does not
match between the source and destination hosts. Since during migration,
the destination guest is launched with same QEMU cli as source hence
cbitpos check in QEMU will catch it and fail the new launch. Optionally,
user can call query-sev-capabilities on both source and destination to
see if cbitpos is compatible before attempting to migrate the guest.

> On the flip side, if the value really it strictly tied to the host
> CPU family and no deviation is permitted, could the kernel not just
> pick the right value automatically avoiding the config option ?
>

I think doing so will be an issue for the migration. Consider your above
use case, a SEV guest is running on EPYC with cbitpos=47 and if we
migrate to some $NEXT AMD CPU which uses need to use cbitpos=48 and we
will fail to resume the guest on destination after migrating.

>
> Regards,
> Daniel