From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgXUx-0004nd-Tf for qemu-devel@nongnu.org; Thu, 06 Dec 2012 04:12:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TgXUn-0000SP-Us for qemu-devel@nongnu.org; Thu, 06 Dec 2012 04:12:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TgXUn-0000SG-NL for qemu-devel@nongnu.org; Thu, 06 Dec 2012 04:11:53 -0500 Date: Thu, 6 Dec 2012 09:11:01 +0000 From: "Daniel P. Berrange" Message-ID: <20121206091101.GC29942@redhat.com> References: <50BCCB77.1080404@redhat.com> <20121204094628.1518b973@doriath.home> <50BE0BD8.2010501@redhat.com> <20121204152356.GL8233@redhat.com> <87liddsk9h.fsf@codemonkey.ws> <20121204195048.GA29929@redhat.com> <87vcchijah.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87vcchijah.fsf@codemonkey.ws> Subject: Re: [Qemu-devel] detecting seccomp sandbox capability via QMP Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Luiz Capitulino , =?utf-8?Q?J=C3=A1n?= Tomko , qemu-devel@nongnu.org, otubo@linux.vnet.ibm.com On Tue, Dec 04, 2012 at 03:44:54PM -0600, Anthony Liguori wrote: > "Daniel P. Berrange" writes: > > > On Tue, Dec 04, 2012 at 01:13:46PM -0600, Anthony Liguori wrote: > >> "Daniel P. Berrange" writes: > >> > >> > > >> > In the absence of any way to detect it via QMP, libvirt should fallback > >> > to hardcoding it based on the version number. This presumes that QEMU was > >> > built with it enabled in configure, but we've no other option for current > >> > released 1.2/1.3 versions. > >> > >> echo quit | qemu -machine none -S -monitor stdio -vnc none -sandbox on > >> > >> A non-zero execute means QEMU doesn't support the option. This will > >> work for any new command line option introduction and can be considered > >> a "supported" way of probing for whether options are supported. > > > > One of the significant benefits to libvirt of the QMP based feature > > detection, was that we no longer have to invoke QEMU multiple times > > to query different data. I don't want to regress in this regard, > > because invoking QEMU many times has a noticable performance impact > > for some applications eg virt-sandbox were even 100ms delays are > > relevant. So while what you describe does work, I don't think it > > is a satisfactory approach for libvirt. > > Okay, so in terms of what exists today, I don't have a better option. > But we could add: > > { 'enum': 'ConfigEntryType', > 'data': [ 'number', 'string', 'bool', 'size' ] } > > { 'type': 'ConfigEntry', > 'data': { 'name': 'str', 'type': 'ConfigEntryType' } } > > { 'type': 'ConfigSection', > 'data': { 'name': 'str', 'fields': [ 'ConfigEntry' ] } } > > { 'command': 'query-config-schema', > 'returns': [ 'ConfigSection' ] } > > This technically introspects config sections but obviously could be used > to detect the availability of -sandbox. > > If it's useful, I can take a quick swing at implementing (or someone > else certainly could). I'm not sure I entirely understand what information a 'ConfigSection' would represent. By config here, do you mean any command line argument or something else ? Could you give a short example of the actual JSON you envisage returning for this schema. Your suggestion sounds good, but I want to make sure I'm not mis-understanding things :-) 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 :|