qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] detecting seccomp sandbox capability via QMP


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] detecting seccomp sandbox capability via QMP
Date: Tue, 4 Dec 2012 19:50:48 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Dec 04, 2012 at 01:13:46PM -0600, Anthony Liguori wrote:
> "Daniel P. Berrange" <address@hidden> writes:
> 
> > On Tue, Dec 04, 2012 at 03:42:32PM +0100, Ján Tomko wrote:
> >> On 12/04/12 12:46, Luiz Capitulino wrote:
> >> > On Mon, 03 Dec 2012 16:55:35 +0100
> >> > Ján Tomko <address@hidden> wrote:
> >> > 
> >> >> Hello,
> >> >>
> >> >> is there a way to check if QEMU was compiled with --enable-seccomp via 
> >> >> QMP?
> >> > 
> >> > Not that I'm aware of. Could you describe your use-case?
> >> 
> >> It's for libvirt. The detection is broken since the switch from parsing
> >> -help output to QMP and I wanted to fix it.
> >> 
> >> Assuming it's supported if we do capabilities detection via QMP (since
> >> 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 was
> >> 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 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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]