[libvirt] [Qemu-devel] libvirt/QEMU/SEV interaction

[Brijesh Singh]

On 09/08/2017 10:51 AM, Daniel P. Berrange wrote:
> On Fri, Sep 08, 2017 at 10:48:10AM -0500, Brijesh Singh wrote:
>>> So I could see a flow like the following:
>>
>>
>> The flow looks good
>>
>>>
>>>
>>>     1. mgmt tool calls  virConnectGetCapabilities. This returns an XML
>>>        document that includes the following
>>>
>>>         <host>
>>>            ...other bits...
>>>           <sev>
>>> 	  <platform-key>...hex encoded PDH key...</platform-key>
>>> 	</sev>
>>>         </host>
>>>
>>>     2. mgmt tool requests to start a guest calling virCreateXML(),
>>>        passing VIR_DOMAIN_START_PAUSED. The XML would include
>>>
>>>         <sev>
>>>           <owner-key>...hex encode DH key...</owner-key>
>>> 	<session-info>..hex encode info...</session-info>
>>> 	<policy>...int32 value..</policy>
>>>         </sev>
>>>
>>>
>>>        if <sev> is provided and VIR_DOMAIN_START_PAUSED is missing,
>>>        libvirt would report an error and refuse to start the guest
>>>
>>
>>
>> One thing which is not clear to me is, how do we know that we are asked
>> to launch SEV guest? Are you thinking that <sev> tag in the XML will
>> hint libvirt that GO has asked to launch a SEV guest?
> 
> Yes, the existance of the <sev> tag is the indicator that informs
> libvirt that SEV *must* be used for the guest.


Thanks for confirming.


> 
>>>     3. Libvirt generates the QEMU cli arg to enable SEV using
>>>        the XML data and starts QEMU, leaving CPUs paused
>>>
>>
>>
>> I am looking at [1] to get the feel for how do we model it in the XML.
>> As you can see I am using ad-hoc <qemu:args> to create the sev-guest
>> object. Currently, sev-guest object accepts the following properties:
>>
>> dh-cert-file: <file containing the GO DH key>
>> session-info-file: <file contain the GO session info>
>> policy: <int32 GO policy>
>>
>> I believe the new XML model will influence the property input type,
>> Any recommendation on how do model this part ? thank you so much.
> 
> That looks ok to me - even if QEMU wants the data provided in
> files on disk, libvirt can just create the files on the fly
> from the data it has in the <sev> element in the XML file.
> Since they're only needed during startup, libvirt can then
> easily delete the files the moment QEMU has completed its
> startup.
> 

Perfect! works well with me.