From: "Daniel P. Berrange" <berrange@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Luiz Capitulino" <lcapitulino@redhat.com>,
"Ján Tomko" <jtomko@redhat.com>,
qemu-devel@nongnu.org, otubo@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] detecting seccomp sandbox capability via QMP
Date: Tue, 4 Dec 2012 19:50:48 +0000 [thread overview]
Message-ID: <20121204195048.GA29929@redhat.com> (raw)
In-Reply-To: <87liddsk9h.fsf@codemonkey.ws>
On Tue, Dec 04, 2012 at 01:13:46PM -0600, Anthony Liguori wrote:
> "Daniel P. Berrange" <berrange@redhat.com> 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 <jtomko@redhat.com> 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 :|
next prev parent reply other threads:[~2012-12-04 19:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-03 15:55 [Qemu-devel] detecting seccomp sandbox capability via QMP Ján Tomko
2012-12-04 11:46 ` Luiz Capitulino
2012-12-04 14:42 ` Ján Tomko
2012-12-04 15:17 ` Luiz Capitulino
2012-12-04 15:23 ` Daniel P. Berrange
2012-12-04 19:13 ` Anthony Liguori
2012-12-04 19:50 ` Daniel P. Berrange [this message]
2012-12-04 21:44 ` Anthony Liguori
2012-12-06 9:11 ` Daniel P. Berrange
2012-12-06 14:00 ` Anthony Liguori
2012-12-06 14:07 ` Daniel P. Berrange
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121204195048.GA29929@redhat.com \
--to=berrange@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jtomko@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=otubo@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).