From patchwork Wed Oct 22 12:13:56 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Stefano Stabellini X-Patchwork-Id: 39283 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ee0-f69.google.com (mail-ee0-f69.google.com [74.125.83.69]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id B308D20341 for ; Wed, 22 Oct 2014 12:18:10 +0000 (UTC) Received: by mail-ee0-f69.google.com with SMTP id b57sf1564955eek.8 for ; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:date:from:to:in-reply-to:message-id :references:user-agent:mime-version:cc:subject:precedence:list-id :list-unsubscribe:list-post:list-help:list-subscribe:sender :errors-to:x-original-sender:x-original-authentication-results :mailing-list:list-archive:content-type; bh=Qtv7g4VY2Su4PCzMNjEL2oOu8rjsNN2RyGfwB5s++so=; b=CrvXWvedCG6kvEMrP4fc9PDDb42vtVMtRA4CofMIH5Px6iP/4/bTmqsGhV+oOCvxaH 0AjIGfIiIS9ThvWNz7oDYYmW9urYDP6KPSD3OyFYDM2I0nGqmx0Z0TArf2ypNOk/ogV0 0C4pw9+yqDwzYdxtQ9YnQemmmnAKmZpdIvLYYLKzSzRNUxlhOrDU2vAQd97BJr6FJGrG Oc+hX6b3g3DyUaCdN+x2mS0jwlDB9ZnwPxlBeMeFOpQeiH21vz0QyyQJ7F9zLFETcK+q cG8phTgUyLURwa3H1qBOidxhyVwzE1PEv8EIac71lYngzTQJKAcXlOoqWIGbRVjomfya PCbA== X-Gm-Message-State: ALoCoQkKkLkI2NcUdJ7PcDZPnWhEcaVj7jYkfsr7Gxf4vPLBU2CouYlfRpgZxHGm8qa1wGTTV9AM X-Received: by 10.152.21.170 with SMTP id w10mr424736lae.6.1413980289842; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.7.230 with SMTP id m6ls203833laa.89.gmail; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) X-Received: by 10.112.180.198 with SMTP id dq6mr40627881lbc.56.1413980289669; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com. [209.85.217.177]) by mx.google.com with ESMTPS id xm7si23082513lbb.97.2014.10.22.05.18.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Oct 2014 05:18:09 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.217.177 as permitted sender) client-ip=209.85.217.177; Received: by mail-lb0-f177.google.com with SMTP id w7so2743931lbi.36 for ; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) X-Received: by 10.152.116.102 with SMTP id jv6mr30100619lab.40.1413980289284; Wed, 22 Oct 2014 05:18:09 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.84.229 with SMTP id c5csp59657lbz; Wed, 22 Oct 2014 05:18:08 -0700 (PDT) X-Received: by 10.224.74.135 with SMTP id u7mr9043190qaj.41.1413980287822; Wed, 22 Oct 2014 05:18:07 -0700 (PDT) Received: from lists.xen.org (lists.xen.org. [50.57.142.19]) by mx.google.com with ESMTPS id u106si12935977qgd.112.2014.10.22.05.18.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 Oct 2014 05:18:07 -0700 (PDT) Received-SPF: none (google.com: xen-devel-bounces@lists.xen.org does not designate permitted sender hosts) client-ip=50.57.142.19; Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xguq5-0000KQ-5h; Wed, 22 Oct 2014 12:16:29 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Xguq4-0000KL-0s for xen-devel@lists.xen.org; Wed, 22 Oct 2014 12:16:28 +0000 Received: from [193.109.254.147:7971] by server-14.bemta-14.messagelabs.com id D0/50-18345-B10A7445; Wed, 22 Oct 2014 12:16:27 +0000 X-Env-Sender: Stefano.Stabellini@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1413980185!11809976!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n X-StarScan-Received: X-StarScan-Version: 6.12.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18375 invoked from network); 22 Oct 2014 12:16:26 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Oct 2014 12:16:26 -0000 X-IronPort-AV: E=Sophos;i="5.04,768,1406592000"; d="scan'208";a="183807471" Received: from ukmail1.uk.xensource.com (10.80.16.128) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.3.181.6; Wed, 22 Oct 2014 08:16:22 -0400 Received: from kaball.uk.xensource.com ([10.80.2.59]) by ukmail1.uk.xensource.com with esmtp (Exim 4.69) (envelope-from ) id 1Xgupy-0002W9-GH; Wed, 22 Oct 2014 13:16:22 +0100 Date: Wed, 22 Oct 2014 13:13:56 +0100 From: Stefano Stabellini X-X-Sender: sstabellini@kaball.uk.xensource.com To: Ian Campbell In-Reply-To: <1413979542.19198.14.camel@citrix.com> Message-ID: References: <544678FE.2000801@crc.id.au> <5446CF1D.6030307@crc.id.au> <1413968436.20604.53.camel@citrix.com> <20141022095906.GG3659@type.bordeaux.inria.fr> <1413974439.18118.1.camel@citrix.com> <1413979542.19198.14.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 X-DLP: MIA2 Cc: Anthony Perard , Samuel Thibault , xen-devel@lists.xen.org, Steven Haigh , Stefano Stabellini Subject: Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0 X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Post: , List-Help: , List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: stefano.stabellini@eu.citrix.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.217.177 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Archive: On Wed, 22 Oct 2014, Ian Campbell wrote: > On Wed, 2014-10-22 at 12:57 +0100, Stefano Stabellini wrote: > > On Wed, 22 Oct 2014, Ian Campbell wrote: > > > On Wed, 2014-10-22 at 11:59 +0200, Samuel Thibault wrote: > > > > Ian Campbell, le Wed 22 Oct 2014 10:00:36 +0100, a écrit : > > > > > On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote: > > > > > > As a side note to this - if I use pygrub as a bootloader vs using > > > > > > pvgrub, then VNC works perfectly. > > > > > > > > > > > > So, what options exist to make pvgrub behave properly for booting with > > > > > > VNC enabled? > > > > > > > > > > ISTR (vaguely) that way back when the backends needed to be modified to > > > > > cope with kexec (which is effectively what pvgrub does) by not exiting > > > > > when the frontend disconnects, instead sticking around waiting for a new > > > > > frontend, this relates somehow to the "online" key in xenstore. > > > > > > > > > > Perhaps the pvfb backend never got that treatment, which would explain > > > > > #2? > > > > > > > > Probably, yes. > > > > > > Adding Stefano and Anthony, since the backend in this case is in qemu. > > > > > > When the frontend disconnects and the online node == 1 then the backend > > > is supposed to go from Closed back to InitWait and wait for a new > > > connection, as opposed to shutting down. This is needed for kexec (which > > > pvgrub uses). > > > > > > I can see some handling of the online node in hw/xen/xen_backend.c but > > > it doesn't look like it would do what is needed here. I also don't see > > > any handling in either hw/block/xen_disk.c or hw/display/xenfb.c. Which > > > makes me suspect that as well as pvfb not working with kexec/pvgrub > > > neither does the qdisk backend, which would be unfortunate. > > > > Looking at the code in xen_backend.c, it seems that on XenbusStateClosed > > xen_backend is going to try to reset to XenbusStateInitialising, unless > > the frontend state is XenbusStateInitialising (no idea why). See: > > xen_be_try_reset and xen_be_check_state. > > > > Maybe it should go to XenbusStateInitWait instead? > > Possibly? > > Doesn't xen_be_check_state do that though, i.e. once you hit > XenbusStateInitialising you have: > case XenbusStateInitialising: > rc = xen_be_try_init(xendev); > which will push on to XenbusStateInitWait? > > There's quite a few xen_be_printf surrounding these state transitions, > which ought to be printed at level >= 2. How can Steven control the > loglevel and where would they go (/var/log/xen/qemu-dm-$domname.log?) I think that this should do: diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c index b2cb22b..d1d5d8e 100644 --- a/hw/xen/xen_backend.c +++ b/hw/xen/xen_backend.c @@ -50,7 +50,7 @@ const char *xen_protocol; /* private */ static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = QTAILQ_HEAD_INITIALIZER(xendevs); -static int debug = 0; +static int debug = 9; /* ------------------------------------------------------------- */