xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xensource.com,
	Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [libvirt] libvirt: [PATCH] libxl: Check for control_d string to decide about dom0
Date: Wed, 12 Mar 2014 12:07:48 +0000	[thread overview]
Message-ID: <20140312120748.GI30676@redhat.com> (raw)
In-Reply-To: <1394625806-21089-1-git-send-email-stefan.bader@canonical.com>

On Wed, Mar 12, 2014 at 01:03:26PM +0100, Stefan Bader wrote:
> I have been looking into a bug report (see BugLink) which reported
> libvirt to fail starting inside a Xen guest. Upon further investigation
> I found that some tools that help monitoring Xen guests will mount
> xenfs to /proc/xen. This will create a capabilities files there even
> if the guest is not dom0. However it will return nothing when reading
> from it.
> 
> Ian, just to sanity check myself. I looked at the xenfs code and to
> me there only seem to be those two outcomes (either "control_d" for
> running in dom0 or notrhing if not).
> 
> With the following patch applied, libvirt starts up correctly in
> the normal guests (with xenfs mounted) without initializing libxl.
> And also in dom0 where it still enables the libxl driver (if the
> xl toolstack is selected).
> 
> -Stefan
> 
> >From f11949caca6dfe1a802472a2a6d4fe760115ccc6 Mon Sep 17 00:00:00 2001
> From: Stefan Bader <stefan.bader@canonical.com>
> Date: Wed, 12 Mar 2014 11:37:16 +0100
> Subject: [PATCH] libxl: Check for control_d string to decide about dom0
> 
> As soon as any guest mounts xenfs to /proc/xen, there is a capabilities
> file in that directory. However it returns nothing when reading from it.
> Change the test to actually check the contents of the file.
> 
> BugLink: http://bugs.launchpad.net/bugs/1248025
> 
> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
> ---
>  src/libxl/libxl_driver.c |   14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
> index 65d80a2..844e828 100644
> --- a/src/libxl/libxl_driver.c
> +++ b/src/libxl/libxl_driver.c
> @@ -944,6 +944,7 @@ libxlDriverShouldLoad(bool privileged)
>      bool ret = false;
>      virCommandPtr cmd;
>      int status;
> +    char *output = NULL;
>  
>      /* Don't load if non-root */
>      if (!privileged) {
> @@ -951,8 +952,17 @@ libxlDriverShouldLoad(bool privileged)
>          return ret;
>      }
>  
> -    /* Don't load if not running on a Xen control domain (dom0) */
> -    if (!virFileExists("/proc/xen/capabilities")) {
> +    /*
> +     * Don't load if not running on a Xen control domain (dom0). It is not
> +     * sufficient to check for the file to exist as any guest can mount
> +     * xenfs to /proc/xen.
> +     */
> +    status = virFileReadAll("/proc/xen/capabilities", 10. &output);
> +    if (status >= 0) {
> +        status = strncmp(output, "control_d", 9);
> +    }
> +    VIR_FREE(output);
> +    if (status) {
>          VIR_INFO("No Xen capabilities detected, probably not running "
>                   "in a Xen Dom0.  Disabling libxenlight driver");

This looks reasonable to me. I recall that the initscripts for the old
XenD daemon would also check for this file to decide whether to start
or not.

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:[~2014-03-12 12:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-12 12:03 [libvirt] libvirt: [PATCH] libxl: Check for control_d string to decide about dom0 Stefan Bader
2014-03-12 12:07 ` Daniel P. Berrange [this message]
2014-03-12 12:08 ` Ian Campbell
2014-03-12 12:20   ` Stefan Bader
2014-03-13  0:58     ` [libvirt] [Xen-devel] " Jim Fehlig

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=20140312120748.GI30676@redhat.com \
    --to=berrange@redhat.com \
    --cc=ian.campbell@citrix.com \
    --cc=libvir-list@redhat.com \
    --cc=stefan.bader@canonical.com \
    --cc=xen-devel@lists.xensource.com \
    /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).