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