From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBI4-0003rE-4Y for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:12:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnBHy-00022V-3i for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:12:19 -0400 Received: from mail-dm3nam03on0063.outbound.protection.outlook.com ([104.47.41.63]:21464 helo=NAM03-DM3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnBHx-00021G-RG for qemu-devel@nongnu.org; Thu, 22 Sep 2016 17:12:14 -0400 References: <147455590865.8519.11191009507297313736.stgit@brijesh-build-machine> <147455596937.8519.6403549430047219068.stgit@brijesh-build-machine> <69f9cab5-e2dd-0461-8857-64cfa4bb7e8e@redhat.com> From: Brijesh Singh Message-ID: Date: Thu, 22 Sep 2016 16:12:04 -0500 MIME-Version: 1.0 In-Reply-To: <69f9cab5-e2dd-0461-8857-64cfa4bb7e8e@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v2 06/16] sev: add Secure Encrypted Virtulization (SEV) support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , ehabkost@redhat.com, crosthwaite.peter@gmail.com, armbru@redhat.com, mst@redhat.com, p.fedin@samsung.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, rth@twiddle.net Cc: brijesh.singh@amd.com Hi, On 09/22/2016 10:12 AM, Paolo Bonzini wrote: > > >> >> to use encrypted guest launch >> # $QEMU \ >> -object sev-receive-info,id=launch0 \ >> -object sev-send-info,id=send0 \ >> -object sev-guest-info,id=sev0,launch=launch0,send=send0 \ >> ..... >> > > References to other objects should be implemented as link properties > (e.g. with type 'link'). Then QOM takes care of filling > in a QSEVGuestInfo* with the pointer to an object with the right id. > > There is some redundancy (e.g. "flags.ks" in launch/receive vs. "ks" in > policy). Can you document the full model in > docs/amd-memory-encryption.txt? It's not necessary to include the > kernel API documentation. > The flags.ks means that hypervisor requested the key-sharing. The policy.ks means that key-sharing is allowed by guest owner. The values in sev-policy should be provided by the guest owner. The content of policy field is used during the measurement calculation. If hypervisor changes anything into policy field without guest owners permission then measurement value will not match. I can think of one case where flag.ks may be used. e.g lets say guest policy allows key sharing and this is first SEV guest in the system then hypervisor will set flags.ks=0. In next guest launch it can set flags.ks=1 and use the SEV handle from previous guest. I will add some more text to clarify it in doc and property description. > Paolo >