Re: move hyperv CHANNELMSG_UNLOAD from crashed kernel to kdump kernel
From: Vitaly Kuznetsov
Date: Thu Dec 15 2016 - 05:36:39 EST
Olaf Hering <olaf@xxxxxxxxx> writes:
> 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?