Xen devel - May 2013 - [PATCH] xen/arm: Don't start a QEMU for backend

/usr/lib/xen/bin/qemu-system-i386 doesn''t exist on ARM. We need to
check
if the file exists/is executable and starts it.

Signed-off-by: Julien Grall <julien.grall@linaro.org>
---
 tools/hotplug/Linux/init.d/xencommons |   11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xencommons
b/tools/hotplug/Linux/init.d/xencommons
index a2e633b..bd15bd4 100644
--- a/tools/hotplug/Linux/init.d/xencommons
+++ b/tools/hotplug/Linux/init.d/xencommons
@@ -115,11 +115,14 @@ do_start () {
 	echo Starting xenconsoled...
 	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
--log=$XENCONSOLED_TRACE"
 	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
-	echo Starting QEMU as disk backend for dom0
 	test -z "$QEMU_XEN" &&
QEMU_XEN="${LIBEXEC}/qemu-system-i386"
-	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize \
-		-monitor /dev/null -serial /dev/null -parallel /dev/null \
-		-pidfile $QEMU_PIDFILE
+	if [ -x "$QEMU_XEN" ]; then
+		echo Starting QEMU as disk backend for dom0
+		$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic \
+			-M xenpv -daemonize -monitor /dev/null		 \
+			-serial /dev/null -parallel /dev/null		 \
+			-pidfile $QEMU_PIDFILE
+	fi
 }
 do_stop () {
         echo Stopping xenconsoled
-- 
1.7.10.4

On Wed, 8 May 2013, Julien Grall wrote:
> /usr/lib/xen/bin/qemu-system-i386 doesn''t exist on ARM. We need to
check
> if the file exists/is executable and starts it.
> 
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
Good idea but we should actually do that only on ARM: we don''t want to
hide bad configurations on x86.

You can check for HOSTTYPE or MACHTYPE, not sure which one is better.

>  tools/hotplug/Linux/init.d/xencommons |   11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xencommons
b/tools/hotplug/Linux/init.d/xencommons
> index a2e633b..bd15bd4 100644
> --- a/tools/hotplug/Linux/init.d/xencommons
> +++ b/tools/hotplug/Linux/init.d/xencommons
> @@ -115,11 +115,14 @@ do_start () {
>  	echo Starting xenconsoled...
>  	test -z "$XENCONSOLED_TRACE" || XENCONSOLED_ARGS="
--log=$XENCONSOLED_TRACE"
>  	${SBINDIR}/xenconsoled --pid-file=$XENCONSOLED_PIDFILE $XENCONSOLED_ARGS
> -	echo Starting QEMU as disk backend for dom0
>  	test -z "$QEMU_XEN" &&
QEMU_XEN="${LIBEXEC}/qemu-system-i386"
> -	$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv
-daemonize \
> -		-monitor /dev/null -serial /dev/null -parallel /dev/null \
> -		-pidfile $QEMU_PIDFILE
> +	if [ -x "$QEMU_XEN" ]; then
> +		echo Starting QEMU as disk backend for dom0
> +		$QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic \
> +			-M xenpv -daemonize -monitor /dev/null		 \
> +			-serial /dev/null -parallel /dev/null		 \
> +			-pidfile $QEMU_PIDFILE
> +	fi
>  }
>  do_stop () {
>          echo Stopping xenconsoled
> -- 
> 1.7.10.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm: Don''t
start a QEMU for backend"):
> On Wed, 8 May 2013, Julien Grall wrote:
> > /usr/lib/xen/bin/qemu-system-i386 doesn''t exist on ARM. We
need to check
> > if the file exists/is executable and starts it.
> > 
> > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> 
> Good idea but we should actually do that only on ARM: we don''t
want to
> hide bad configurations on x86.
Are you sure ?  This seems wrong to me.  The purpose of our global
qemu is to provide disk backends when we select qdev as the backend,
right ?

I don''t understand why this doesn''t apply on ARM.  Perhaps we
should
be running a different executable ?

Ian.

On Wed, 8 May 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm:
Don''t start a QEMU for backend"):
> > On Wed, 8 May 2013, Julien Grall wrote:
> > > /usr/lib/xen/bin/qemu-system-i386 doesn''t exist on ARM.
We need to check
> > > if the file exists/is executable and starts it.
> > > 
> > > Signed-off-by: Julien Grall <julien.grall@linaro.org>
> > 
> > Good idea but we should actually do that only on ARM: we
don''t want to
> > hide bad configurations on x86.
> 
> Are you sure ?  This seems wrong to me.  The purpose of our global
> qemu is to provide disk backends when we select qdev as the backend,
> right ?
> 
> I don''t understand why this doesn''t apply on ARM. 
Perhaps we should
> be running a different executable ?
It does apply to ARM, but we haven''t had the time to enable the QEMU
build and make sure it works for this release.

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm: Don''t
start a QEMU for backend"):
> It does apply to ARM, but we haven''t had the time to enable the
QEMU
> build and make sure it works for this release.
So the error message you get from the unmodified script is in fact
correct ? :-)

Does xl on ARM try to use qdisk backends ?

Ian.

On Wed, 8 May 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm:
Don''t start a QEMU for backend"):
> > It does apply to ARM, but we haven''t had the time to enable
the QEMU
> > build and make sure it works for this release.
> 
> So the error message you get from the unmodified script is in fact
> correct ? :-)
> 
> Does xl on ARM try to use qdisk backends ?
Yes, we don''t have any "protections" in xl from trying to
setup qdisk or
using QEMU.
The user needs to be aware that blkback is the only block backend
working right now.
Given that setting up Xen on ARM is non-trivial right now, I think is a
reasonable assumption if we document it properly on the wiki.

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm: Don''t
start a QEMU for backend"):
> Given that setting up Xen on ARM is non-trivial right now, I think is a
> reasonable assumption if we document it properly on the wiki.
OK, so perhaps we should document this qemu-system-i386 invocation
error too, rather than polishing a workaround which will become wrong
when we fix the underlying problem ?

Ian.

On Wed, 8 May 2013, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm:
Don''t start a QEMU for backend"):
> > Given that setting up Xen on ARM is non-trivial right now, I think is
a
> > reasonable assumption if we document it properly on the wiki.
> 
> OK, so perhaps we should document this qemu-system-i386 invocation
> error too, rather than polishing a workaround which will become wrong
> when we fix the underlying problem ?
Given that the error is non-fatal, you might have a point.

However in case of xl, the user needs to ask for a file backend in order
to trigger a QEMU invocation. While in xencommons it is done
unconditionally.  One might know what is doing and might want to
configure a system without QEMU (on ARM or x86), and at the moment there
is no way to prevent xencommons from spawning it anyway.
Given the code freeze is probably not the right time to introduce
such a config option though.

On 05/08/2013 05:15 PM, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm:
Don''t start a QEMU for backend"):
>> Given that setting up Xen on ARM is non-trivial right now, I think is a
>> reasonable assumption if we document it properly on the wiki.
> 
> OK, so perhaps we should document this qemu-system-i386 invocation
> error too, rather than polishing a workaround which will become wrong
> when we fix the underlying problem ?

Where can I document this error? in docs? on the wiki?

-- 
Julien

On Wed, 2013-05-08 at 17:41 +0100, Julien Grall wrote:
> On 05/08/2013 05:15 PM, Ian Jackson wrote:
> 
> > Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xen/arm:
Don''t start a QEMU for backend"):
> >> Given that setting up Xen on ARM is non-trivial right now, I think
is a
> >> reasonable assumption if we document it properly on the wiki.
> > 
> > OK, so perhaps we should document this qemu-system-i386 invocation
> > error too, rather than polishing a workaround which will become wrong
> > when we fix the underlying problem ?
> 
> 
> Where can I document this error? in docs? on the wiki?
http://wiki.xen.org/wiki/Xen_ARM_TODO should have an entry for fixing
it.

Otherwise I think the Xen on ARM w/ virtualisation wiki page is the
right place, perhaps in an "known issues" section.