From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfyWU-0002n5-Bj for qemu-devel@nongnu.org; Tue, 04 Dec 2012 14:51:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfyWS-0002d1-Ms for qemu-devel@nongnu.org; Tue, 04 Dec 2012 14:51:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:9224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfyWS-0002cm-E2 for qemu-devel@nongnu.org; Tue, 04 Dec 2012 14:51:16 -0500 Date: Tue, 4 Dec 2012 19:50:48 +0000 From: "Daniel P. Berrange" Message-ID: <20121204195048.GA29929@redhat.com> References: <50BCCB77.1080404@redhat.com> <20121204094628.1518b973@doriath.home> <50BE0BD8.2010501@redhat.com> <20121204152356.GL8233@redhat.com> <87liddsk9h.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87liddsk9h.fsf@codemonkey.ws> Content-Transfer-Encoding: quoted-printable 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 01:13:46PM -0600, Anthony Liguori wrote: > "Daniel P. Berrange" writes: >=20 > > On Tue, Dec 04, 2012 at 03:42:32PM +0100, J=C3=A1n Tomko wrote: > >> On 12/04/12 12:46, Luiz Capitulino wrote: > >> > On Mon, 03 Dec 2012 16:55:35 +0100 > >> > J=C3=A1n Tomko wrote: > >> >=20 > >> >> Hello, > >> >> > >> >> is there a way to check if QEMU was compiled with --enable-seccom= p via QMP? > >> >=20 > >> > Not that I'm aware of. Could you describe your use-case? > >>=20 > >> It's for libvirt. The detection is broken since the switch from pars= ing > >> -help output to QMP and I wanted to fix it. > >>=20 > >> Assuming it's supported if we do capabilities detection via QMP (sin= ce > >> libvirt 1.0.0 and QEMU 1.2) would work except for this case: > >> If seccomp sandbox was requested in /etc/libvirt/qemu.conf, but it w= as > >> compiled out from qemu, libvirt would try to run QEMU with -sandbox = on > >> instead of printing an error earlier. > > > > In the absence of any way to detect it via QMP, libvirt should fallba= ck > > 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 cur= rent > > released 1.2/1.3 versions. >=20 > echo quit | qemu -machine none -S -monitor stdio -vnc none -sandbox on >=20 > 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. Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|