[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH 11/11] xen/hvm kdump: reset PV devices in crash kernel
- To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
- From: Olaf Hering <olaf@xxxxxxxxx>
- Date: Mon, 1 Aug 2011 14:58:10 +0200
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 01 Aug 2011 06:02:19 -0700
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1312203549; l=2456; s=domk; d=aepfle.de; h=In-Reply-To:Content-Type:MIME-Version:References:Subject:Cc:To:From: Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=b0FMsNegWOCPjrju0GQ6kJmuxp0=; b=R/GAnlsZQilWoy3oJsaThctLT3l3tg5w83AlsW6LLxIAWwYUjfXEgG5Nm/PWocnPJ4d UKUPT9INbQfakaDOOsM5yXvv9xuW698OUnTeNKn0BUbQAo3tLBYCd4ricM/0DI/cjtndn zBzosrtT52xNSWyKjjO1XtLjwi6YYDHW8FI=
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
On Fri, Jul 29, Stefano Stabellini wrote:
> 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.
This is for a kdump boot, its added as additional kernel cmdline option
for the kdump kernel.
> 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
> kexec_is_loaded.
To allow the kdump kernel to store the /proc/vmcore file somewhere, it
has to get either storage or network access. But the kdump kernel finds
all devices in the Connected state, because the to-be-debugged kernel
just crashed. So it has to reset the connection to the backend.
Olaf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel