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

[Daniel P . Berrangé]

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 ?

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 ?

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 ?



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|