Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1537616 > unrolled thread

move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

Back to article view | Back to linux.kernel

Contents

  move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-07 10:00 +0100
    RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-07 16:10 +0100
      RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-07 17:00 +0100
        Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-07 17:20 +0100
          RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-07 17:30 +0100
            Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-07 17:50 +0100
              RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-07 21:50 +0100
        RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-07 17:20 +0100

#1537616 — move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel

[Multipart message — attachments visible in raw view] — view raw

KY,

if a hyperv VM crashes alot of work must be done to prepare the
environment for the kdump kernel. This approach is different compared to
all the other VM types, or baremetal. Since the just crashed kernel is
per definition unreliable all that work should be done within the kdump
kernel because I think a reliable environment exists only there.

Was it ever considered to do the CHANNELMSG_UNLOAD /
CHANNELMSG_UNLOAD_RESPONSE work during boot, instead of doing it before
starting the kexec/kdump kernel?

What would it take to prepare the runtime environment during boot?
Does the newly booted kernel need any info from the previous kernel,
something that cant be determined during boot? If yes, how can such info
be passed from the old kernel to the new kernel?

Olaf

[toc] | [next] | [standalone]

#1537801

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, December 7, 2016 12:51 AM
> To: KY Srinivasan <kys@microsoft.com>; vkuznets@redhat.com
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> KY,
> 
> if a hyperv VM crashes alot of work must be done to prepare the
> environment for the kdump kernel. This approach is different compared to
> all the other VM types, or baremetal. Since the just crashed kernel is
> per definition unreliable all that work should be done within the kdump
> kernel because I think a reliable environment exists only there.
> 
> Was it ever considered to do the CHANNELMSG_UNLOAD /
> CHANNELMSG_UNLOAD_RESPONSE work during boot, instead of doing it
> before
> starting the kexec/kdump kernel?
> 
> What would it take to prepare the runtime environment during boot?
> Does the newly booted kernel need any info from the previous kernel,
> something that cant be determined during boot? If yes, how can such info
> be passed from the old kernel to the new kernel?

Yes; I had played with this approach a while ago. The issue is that the host knows about a 
bunch of in memory state that will be different in the kexec kernel. For instance if we did all
the cleanup as part of the boot sequence, we will need access to all the interrupt/messaging 
infrastructure that was set up in the previous kernel.

K. Y
> 
> Olaf

[toc] | [prev] | [next] | [standalone]

#1537863

Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan <kys@microsoft.com>:

>Yes; I had played with this approach a while ago. The issue is that the
>host knows about a 
>bunch of in memory state that will be different in the kexec kernel.
>For instance if we did all
>the cleanup as part of the boot sequence, we will need access to all
>the interrupt/messaging 
>infrastructure that was set up in the previous kernel.


Where is that stored?  Perhaps it should be put into one place,  so that the new kernel can find and use it. 

Olaf 

[toc] | [prev] | [next] | [standalone]

#1537876

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 07, KY Srinivasan wrote:

> Is there a mechanism for stashing away state that can be retrieved in
> the context of the execed kernel.

I have to find out. To simplify things the new approach may only be used
in the kdump case, which already passes various info in cmdline. Most
likely there is a way to preserve a few gpfns with the relevant data.

Olaf

[toc] | [prev] | [next] | [standalone]

#1537880

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, December 7, 2016 8:19 AM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: vkuznets@redhat.com; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> On Wed, Dec 07, KY Srinivasan wrote:
> 
> > Is there a mechanism for stashing away state that can be retrieved in
> > the context of the execed kernel.
> 
> I have to find out. To simplify things the new approach may only be used
> in the kdump case, which already passes various info in cmdline. Most
> likely there is a way to preserve a few gpfns with the relevant data.

May be a better solution might be to have a new mechanism to indicate to the
host that all state of the previous incarnation of the kernel needs to be cleaned up.
This will be close to what we have on hardware.

K. Y 
> 
> Olaf

[toc] | [prev] | [next] | [standalone]

#1537899

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 07, KY Srinivasan wrote:

> May be a better solution might be to have a new mechanism to indicate
> to the host that all state of the previous incarnation of the kernel
> needs to be cleaned up.  This will be close to what we have on
> hardware.

That would be cool, but until this appears and until its deployed in
Azure and elsewhere I will likely lose the remaining hairs.

Olaf

[toc] | [prev] | [next] | [standalone]

#1538070

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, December 7, 2016 8:40 AM
> To: KY Srinivasan <kys@microsoft.com>
> Cc: vkuznets@redhat.com; gregkh@linuxfoundation.org; linux-
> kernel@vger.kernel.org; devel@linuxdriverproject.org
> Subject: Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> On Wed, Dec 07, KY Srinivasan wrote:
> 
> > May be a better solution might be to have a new mechanism to indicate
> > to the host that all state of the previous incarnation of the kernel
> > needs to be cleaned up.  This will be close to what we have on
> > hardware.
> 
> That would be cool, but until this appears and until its deployed in
> Azure and elsewhere I will likely lose the remaining hairs.

I think the code we have upstream works; I have not seen any issues reported.
I will try to get the host guys to implement this - hopefully it won't be too late!

K. Y
> 
> Olaf

[toc] | [prev] | [next] | [standalone]

#1537877

> -----Original Message-----
> From: Olaf Hering [mailto:olaf@aepfle.de]
> Sent: Wednesday, December 7, 2016 7:47 AM
> To: KY Srinivasan <kys@microsoft.com>; vkuznets@redhat.com
> Cc: gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org;
> devel@linuxdriverproject.org
> Subject: RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to
> kdump kernel
> 
> Am 7. Dezember 2016 16:04:29 MEZ, schrieb KY Srinivasan
> <kys@microsoft.com>:
> 
> >Yes; I had played with this approach a while ago. The issue is that the
> >host knows about a
> >bunch of in memory state that will be different in the kexec kernel.
> >For instance if we did all
> >the cleanup as part of the boot sequence, we will need access to all
> >the interrupt/messaging
> >infrastructure that was set up in the previous kernel.
> 
> 
> Where is that stored?  Perhaps it should be put into one place,  so that the
> new kernel can find and use it.

All the state required to handle interrupts is needed as well as the state needed
to issue unload. Look at vmbus_isr() for the needed interrupt handling state. The entire
code path from the isr routine will have to be executed. Is there a mechanism for stashing away state
that can be retrieved in the context of the execed kernel.

K. Y
> 
> Olaf

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web