[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [RFC] KEXEC: allocate crash note buffers at boot time v2
Hello, Presented is version 2 of this patch, which uses cpu hotplug notifications to be rather safer when allocating buffers. It occurs to me that there is a bit of an API problem with it comes to combining a crashdump kernel with potential hotplug events. If dom0 does not get notification of new/removed pcpus, and if it doesn't re-evaluate /proc/iomem by recalling things like KEXEC_CMD_get_range, then subsequent calls to /sbin/kexec -p will bundle up stale information into the kdump magic bundle. Even if dom0 does get a notification of pcpu hotplug events, and it updates its iomem map, /sbin/kexec would still need to be called to bundle the new information into the kdump magic bundle. Possibly doable off a udev CPU hotplug event. Even if /sbin/kexec gets called after hotplug events, a crash before the new kexec magic bundle has been loaded will still result in the old bundle being used, with its stale information regarding the position and number of crash notes. Sadly, I don't see any easy or sensible solution to these problems. However, it is probably worth knowing as a potential limitation. I have worked around this problem by never deallocating crash notes, so even if information is stale as to the number of crash notes to be expected, the stale physical addresses still point to allocated notes buffers which have been partially initialized to have sensible note headers in. This unfortunately means that an offlined cpu which was present at boot time will have a notes section with zero'd data. It also means that a cpu onlined after boot which crashes will not have its register state presented to the kdump environment. I would like to hope that both of these cases are unlikely, but again, it is still a potential limitation. The cpu crash notes themselves (PRSTATUS and XEN_ELFNOTE_CRASH_REGS) don't contain a reference to which pcpu they represent. This is inferred by /sbin/kexec from the order in which they appear in dom0's /proc/iomem, meaning that the kdump environments idea of which pcpu is which might differ from Xen's. This depending on whether Xen allocates the notes buffer in ascending order, whether dom0 sorts memory addresses reported, and, as it currently gets it correct, whether either of these behaviors change in the future. This final issue is within my ability to fix and I will do so in the near future, along with some other additions I already need to make to the per cpu crash notes. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com Attachment:
KEXEC-setup-crash-notes-during-boot.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |