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.