Re: [libvirt] [PATCH 3/4] conf: introduce sev element in domain

> > > + </dd> > > + <dt><code>policy</code></dt> > > + <dd>The <code>policy</code> attribute provides the guest policy which must > > + be maintained by the SEV firmware. This policy is enforced by the firmware > > + and restricts what configuration and operational commands can be performed > > + on this guest by the hypervisor. The guest policy provided during guest > > + launch is bound to the guest and cannot be changed throughout the lifetime > > + of the guest. The policy is also transmitted during snapshot and migration > > + flows and enforced on the destination platform. > > So this is a hex number. Any documentation on the possible values? I can provide the link of the complete documentation and if needed then I can document here. > > > + </dd> > > + <dt><code>dh-cert</code></dt> > > + <dd>The <code>dh-cert</code> attribute provides the guest owners public > > + Diffie-Hellman (DH) key. The key is used to negotiate a master secret > > + key between the SEV firmware and guest owner. This master secret key is > > + then used to establish a trusted channel between SEV firmware and guest > > + owner. The value must be encoded in base64. > > + </dd> > > + <dt><code>session</code></dt> > > + <dd>The <code>session</code> attribute provides the guest owners session > > + blob defined in SEV API spec. The value must be encoded in base64. > > This should also be more documented. > From x86 software point of view this is a blob of input which comes from the guest owner and must be passed as-is. The blob definition may change from one SEV firmware to another hence I don't see any reason for documenting this. I will provide link to SEV spec in case if someone want to find the details on blob and what exactly it contains etc etc. > > + </dd> > > + </dl> > > + > > + <p>Note: More information about <code>policy</code> bit definition, <code> > > + dh</code> and <code>session</code> is available in SEV API spec.</p> > > At least by providing the specification document. Preferably commiting > it to the libvirt repository so that it does not change URIs in the > future. > Will do, so far the link has been static and I am okay with putting it either in here or commit description or both.