On Mon, Aug 01, 2016 at 10:25:22AM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Aug 01, 2016 at 04:15:10PM +0200, Petr Tesarik wrote: > > On Mon, 1 Aug 2016 15:47:58 +0200
[...] > I wonder if Xen should do that - as in 'fix' the bootparams to not have it. > Or perhaps Linux code during bootup can sanitze this.. It should but I am not sure it does. Or at least it should display warning that dom0 crashkernel argument does not make sense and is not supported. > > > And then trying to invoke a locally loaded crash kernel which won't > > > work is bad > > > > Without actually knowing whether a PV kernel can kexec another PV > > kernel, this discussion is somewhat moot... > > > > But let me repeat: if PV kexec works, then it has always had priority > > over the hypercall. If it doesn't work, then it has always been broken. > > For the latter case, I agree that the kernel should not even allow to > > load the kexec image, but that's unrelated to my patch. > > > > Has anyone here tried booting up a PV domain and performing kexec(2)? > > Yes. Daniel (CC-ed) did it. He had it working but only for one CPU > and then Greg KH picked up the patchset .. and not sure what happend. Greg had it in https://git.kernel.org/ some time ago, however, it looks that it vanished. Anyway, IIRC, the problem was that kdump must be started with one processor and this is not easy due to various constraints. Later, PV guest have to be restarted to regain full functionality. > The underlaying issue was the PV guest could not re-initialize the grants, > events, etc - but now with Vitaly's 'reset' hypercall it would be possible. > Except the 'reset' hypercall is only for HVM guests. I think that it is for PVHVM. Hence, making it work on PV should not be very difficult. I hope... Daniel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
