This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] [qemu] xen_be_init under stubdom

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] [qemu] xen_be_init under stubdom
From: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
Date: Thu, 20 Jan 2011 11:02:16 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 20 Jan 2011 08:03:17 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FxrLnRH4toNv2Ul71TCpMqTA+wiUTTL55vCTzhwh0bE=; b=kBMefuM81cI23s3neImPYcGJHkjY2/ajexMb3V2kbo7aD8PcIKq7Auk1n1DoGuz/Lp 0VcP0rPZOxZL1aCU0Qg6Zx1RgPIR/vTv21iPdjO16eBp/VIA2MRuou4LfHZp2oJFnN9T FIfOLcfpFVLBKN1EPsPyXUHXOhbbT4S2vGYdA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jEKXIpAOkJjLZo1p3g82dgoHweex3KPI3bOxRkVKu/B5M6XCuIHNurVDRsB71bEvj9 l/Kv/pL/gFjfyejtlK6T7iW6gZ68Ky+2u+YRH4fXPSGiRqKLL3oYri7pclQDJxp79TXJ ONQBYW70q+8OHbSQmU3vt2QzUCwly2x8EZEds=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1101201028040.7277@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTikFbHCUmSceFR=byYRV+q5j9TnN8_bab6LKUSpe@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1101201028040.7277@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> I think it would be better if we actually return an error from
> xen_be_init and we just print a warning in hw/xen_machine_fv.c if the
> backends fail to initialize instead of exit.
> It is OK to just call exit in hw/xen_machine_pv.c, because nothing is
> running in qemu apart from backends in that case.

I did give it some thought and my rationale for returning success was
that we shouldn't be calling it in the first place if that code is not
configured to run in stubdom mode and if we do chose to go with the
call we should do nothing and return success.  But I didn't feel
strongly either way and I don't know much about pv/fv code in that
area and you know all about it.  So, I will go with your choice and
send a revised patch momentarily.

> Also having another #ifdef CONFIG_STUBDOM might be OK in qemu-xen, but
> in qemu upstream we can get away without it implementing a function
> like:
> int xen_qemu_is_a_stubdom();
> that returns 1 in case qemu is running in a stubdom and 0 otherwise.
> I would make domid_s a global int variable (see vl.c:5827) so that
> xen_qemu_is_a_stubdom can be implemented like this:
> return domid_s;

Definitely.  This patch is specific to qemu unstable and I should have
been specific.  If we didn't fail the way we do (in an irrelevant
place by corrupting something which was hard to debug) I wouldn't even
have bothered with this patch.  I will go per your suggestion for
upstream qemu.


Xen-devel mailing list