Olaf Hering <olaf@xxxxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
