Re: [Qemu-devel] [RFC PATCH v1 06/22] sev: add initial SEV support

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Sep 14, 2016 at 08:54:12AM -0300, Eduardo Habkost wrote:
> On Wed, Sep 14, 2016 at 09:30:51AM +0100, Daniel P. Berrange wrote:
> > On Tue, Sep 13, 2016 at 07:00:44PM -0300, Eduardo Habkost wrote:
> > > (CCing Daniel Berrange in case he has feedback on the
> > > nonce/dh_pub_qx/dh_pub_qy loading/parsing at the end of this
> > > message)
> > > 
> > > On Tue, Sep 13, 2016 at 02:54:40PM -0500, Brijesh Singh wrote:
> > > > Hi Eduardo,
> > > > 
> > > > On 09/13/2016 10:58 AM, Eduardo Habkost wrote:
> > > > > > 
> > > > > > A typical SEV config file looks like this:
> > > > > > 
> > > > > 
> > > > > Are those config options documented somewhere?
> > > > > 
> > > > 
> > > > Various commands and parameters are documented [1]
> > > > 
> > > > [1] http://support.amd.com/TechDocs/55766_SEV-KM%20API_Spec.pdf
> > > 
> > > If I understand correctly, the docs describe the firmware
> > > interface. The interface provided by QEMU is not the same thing,
> > > and needs to be documented as well (even if it contains pointers
> > > to sections or tables in the firmware interface docs).
> > > 
> > > Some of the questions I have about the fields are:
> > > * Do we really need the user to provide all the options below?
> > >   * Can't QEMU or KVM calculate vcpu_count/vcpu_length/vcpu_mask,
> > >     for example?
> > > * Is bit 0 (KS) the only bit that can be set on flags? If so, why
> > >   not a boolean "ks" option?
> > > * Is "policy" the guest policy structure described at page 23? If
> > >   so, why exposing the raw value instead of separate fields for
> > >   each bit/field in the structure? (and only for the ones that
> > >   are supposed to be set by the user)
> > > * If vcpu_mask is a bitmap for each VCPU, should we represent it
> > >   as a list of VCPU indexes?
> > > 
> > > A good way to model this data and document it more properly is
> > > through a QAPI schema. grep for "opts_visitor_new()" in the code
> > > for examples where QEMU options are parsed according to a QAPI
> > > schema. The downside is that using a QAPI visitor is (AFAIK) not
> > > possible if using -object like I suggest below.
> > 
> > It needs to use QOM really, not QAPI, since it has to be user
> > creatable on the CLI and we don't want to invent new command
> > line arguments.
> 
> As much as I don't like not being able to use the QAPI schema to
> document -object, this is true.

FWIW, in the medium-long term there is clear scope for
adding a 'object' type to the QAPI schema, that could be
used to generate the boilerplate code for QOM, so we can
reconcile these eventually.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|