Re: [Xen-devel] [PATCH 3 of 3] KEXEC: Allocate crash structures in low memory

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 31/12/11 07:38, Jan Beulich wrote:
>>>> Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 12/31/11 1:12 AM >>>
>> The register contents of the pcpus which were running will be available
>> in the PR_STATUS notes which are also deliberately allocated in low
>> memory by this patch.  To the best of my understanding; to get to the
>> dom0 vcpu state, the crashkernel needs access to the domain structs and
>> vcpu structs (which I believe are actually allocated below 4GiB) and the
> The vCPU ones are, while the domain one isn't.

Right - that is useful to know.

>> Xen page tables which dom0 uses (which inspecting CR3 from the crash
>> notes is certainly not in lower memory).  I suspect that there is also
>> more which needs to be allocated in lower memory to get a full register
>> dump, stack dump, stack trace etc.
>>
>> The plan is to also have the "all" option from the command line which
>> will also allocate the page tables (and other structures where relevant)
>> in lower memory, but this is rather more of an overhead than just the
>> console ring and crash notes, which will have a more visible impact to
>> customers running 32bit PV guests.  This is the reason for separating
>> the two via a command line argument.
> I'm wondering whether, with much less impact on existing code, and as
> already pointed out, restricting the allocation range of
> alloc_xenheap_pages() (by way of a command line option) wouldn't get
> you what you want.
>
> Jan

Assuming that all relevant structures do in fact get allocated by
alloc_xenheap_pages() (which is probably a safe assumption looking at
the code, but I am not certain) then yes, it would have much less impact
on the existing code.  However, it would have a much bigger impact on
the other memory restricted items.  It might be possible (and perhaps a
good idea when extreme debugging is needed) to have a 3rd command line
option for low_crashinfo= which does this, but I dont like it as the
general solution to this problem.

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel