All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 6 Dec 2012 09:11:01 +0000	[thread overview]
Message-ID: <20121206091101.GC29942@redhat.com> (raw)
In-Reply-To: <87vcchijah.fsf@codemonkey.ws>

On Tue, Dec 04, 2012 at 03:44:54PM -0600, Anthony Liguori wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
> 
> > On Tue, Dec 04, 2012 at 01:13:46PM -0600, Anthony Liguori wrote:
> >> "Daniel P. Berrange" <berrange@redhat.com> 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 :|

  reply	other threads:[~2012-12-06  9:12 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
2012-12-04 21:44           ` Anthony Liguori
2012-12-06  9:11             ` Daniel P. Berrange [this message]
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=20121206091101.GC29942@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.