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

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.

>> 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.