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. > > [1] https://libvirt.org/formatdomain.html#elementsCPU > > > > 4. QEMU emits a SEV_MEASURE event containing the measurement > > blob > > > > 5. Libvirt catches the QEMU event and emits its own > > VIR_CONNECT_DOMAIN_EVENT_SEV_MEASURE event containing > > the measurement blob > > > > 6. GO does its validation of the measurement > > > > 7a If validation failed, then virDomainDestroy() to stop QEMU > > > > 7b If validation succeeed > > > > Optionally call > > > > virDomainSetSEVSecret() > > > > providing the optional secret, then > > > > virDomainResume() > > > > to let QEMU continue > > > > > > > > > > Regards, > > Daniel > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
