From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk8q1-0007Ba-GQ for qemu-devel@nongnu.org; Wed, 14 Sep 2016 07:58:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bk8px-000874-CP for qemu-devel@nongnu.org; Wed, 14 Sep 2016 07:58:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bk8px-00086K-4m for qemu-devel@nongnu.org; Wed, 14 Sep 2016 07:58:45 -0400 Date: Wed, 14 Sep 2016 12:58:39 +0100 From: "Daniel P. Berrange" Message-ID: <20160914115839.GK28399@redhat.com> Reply-To: "Daniel P. Berrange" References: <147377800565.11859.4411044563640180545.stgit@brijesh-build-machine> <147377806784.11859.11149856529336910514.stgit@brijesh-build-machine> <20160913155807.GA2850@thinpad.lan.raisama.net> <6411b07f-4edd-390c-acca-5342ab1187ba@amd.com> <20160913220044.GY24695@thinpad.lan.raisama.net> <20160914083051.GC28399@redhat.com> <20160914115412.GA24695@thinpad.lan.raisama.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160914115412.GA24695@thinpad.lan.raisama.net> Subject: Re: [Qemu-devel] [RFC PATCH v1 06/22] sev: add initial SEV support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Brijesh Singh , crosthwaite.peter@gmail.com, armbru@redhat.com, mst@redhat.com, p.fedin@samsung.com, qemu-devel@nongnu.org, lcapitulino@redhat.com, pbonzini@redhat.com, rth@twiddle.net 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 :|