From: Stefan Bader <stefan.bader@canonical.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: libvir-list@redhat.com, xen-devel@lists.xensource.com
Subject: Re: [libvirt] libvirt: [PATCH] libxl: Check for control_d string to decide about dom0
Date: Wed, 12 Mar 2014 13:20:30 +0100 [thread overview]
Message-ID: <5320510E.4050406@canonical.com> (raw)
In-Reply-To: <1394626131.21145.44.camel@kazak.uk.xensource.com>
[-- Attachment #1.1: Type: text/plain, Size: 3434 bytes --]
On 12.03.2014 13:08, Ian Campbell wrote:
> On Wed, 2014-03-12 at 13:03 +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.
>
> This seems consistent with the xencommons initscript which does:
> # run this script only in dom0:
> # no capabilities file in xenlinux domU kernel
> # empty capabilities file in pv_ops domU kernel
> if test -f /proc/xen/capabilities && \
> ! grep -q "control_d" /proc/xen/capabilities ; then
> exit 0
> fi
>
>>
>> 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);
>
> Is this "." supposed to be a ","?
Darn, I thought I had fixed that. Unfortunately in the wrong place. Yes, that
should be a ",". Sorry
-Stefan
>
>> + 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");
>>
>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2014-03-12 12:20 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
2014-03-12 12:08 ` Ian Campbell
2014-03-12 12:20 ` Stefan Bader [this message]
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=5320510E.4050406@canonical.com \
--to=stefan.bader@canonical.com \
--cc=Ian.Campbell@citrix.com \
--cc=libvir-list@redhat.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).