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 11/11] xen/hvm kdump: reset PV devices in crash k

To: Olaf Hering <olaf@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 29 Jul 2011 15:47:16 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 29 Jul 2011 07:45:20 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110728132303.745606789@xxxxxxxxx>
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: <20110728132300.248098023@xxxxxxxxx> <20110728132303.745606789@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Thu, 28 Jul 2011, Olaf Hering wrote:
> (this is actually a forward port of rev 1079 from 2.6.18.hg, untested because
> kdump just hangs before (or while) entering the crash kernel in 3.0)
> After triggering a crash dump in a HVM guest, the PV backend drivers
> will remain in connected state. When the kdump kernel starts the PV
> drivers will skip such devices. As a result, no root device is found and
> the vmcore cant be saved.
> With this change all frontend devices with state XenbusStateConnected
> will be reset by changing the state file to Closing/Closed/Initializing.
> This will trigger a disconnect in the backend drivers. Now the frontend
> drivers will find the backend drivers in state Initwait and can connect.
> Signed-off-by: Olaf Hering <olaf@xxxxxxxxx>
> ---
>  drivers/xen/xenbus/xenbus_comms.c          |    4 -
>  drivers/xen/xenbus/xenbus_probe_frontend.c |   97 
> +++++++++++++++++++++++++++++
>  2 files changed, 100 insertions(+), 1 deletion(-)
> Index: linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> ===================================================================
> --- linux-3.0.orig/drivers/xen/xenbus/xenbus_comms.c
> +++ linux-3.0/drivers/xen/xenbus/xenbus_comms.c
> @@ -212,7 +212,9 @@ int xb_init_comms(void)
>               printk(KERN_WARNING "XENBUS response ring is not quiescent "
>                      "(%08x:%08x): fixing up\n",
>                      intf->rsp_cons, intf->rsp_prod);
> -             intf->rsp_cons = intf->rsp_prod;
> +             /* breaks kdump */
> +             if (!reset_devices)
> +                     intf->rsp_cons = intf->rsp_prod;
>       }

Where is reset_devices coming from?
I hope is set only on a kexec reboot.

Considering that all the other patches in this series follow the
opposite strategy, that is closing stuff on shutdown, why are you trying
to close xenbus connections on boot here?
At this point I would rather be coherent and simply switch to
XenbusStateClosing or XenbusStateClosed in the shutdown path if

Xen-devel mailing list