Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1542623
| From | Vitaly Kuznetsov <vkuznets@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel |
| Date | 2016-12-15 11:40 +0100 |
| Message-ID | <sOBC9-4DI-1@gated-at.bofh.it> (permalink) |
| References | <sLGf0-6eS-33@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Olaf Hering <olaf@aepfle.de> writes: > 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? Sorry guys I missed the discussion, I was on vacation. I see a number of minor but at least one major issue against such move: At least for some Hyper-V versions (2012R2 for example) CHANNELMSG_UNLOAD_RESPONSE is delivered to the CPU which initially sent CHANNELMSG_REQUESTOFFERS and on kdump we may not have this CPU up as we usually do kdump with nr_cpus=1 (and on the CPU which crashed). Minor issue is the necessity preserve the information about message/events pages across kexec. > > 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 > -- Vitaly
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 11:40 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 11:40 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 11:40 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 12:00 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 12:00 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 14:00 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 14:30 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 15:00 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-12-15 15:40 +0100
RE: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel KY Srinivasan <kys@microsoft.com> - 2016-12-16 02:00 +0100
Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel Olaf Hering <olaf@aepfle.de> - 2016-12-15 16:20 +0100
csiph-web