[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCHv11 3/9] kexec: add infrastructure for handling kexec images



>>> On 18.11.13 at 15:23, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
> On Mon, Nov 18, 2013 at 01:43:35PM +0000, Jan Beulich wrote:
>> >>> On 18.11.13 at 14:24, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
>> > On Mon, Nov 18, 2013 at 12:53:39PM +0000, Jan Beulich wrote:
>> >
>> > [...]
>> >
>> >> The issue is not a limit on mappable pages, but the fact that there's
>> >> potentially no struct page_info for some or all of the crash area.
>> >
>> > OK, are they allocated at boot time for whole system memory or just
>> > for pages owned by Xen hypervsior? What about pages owned by domains?
>>
>> Sorry, I don't understand the question.
> 
> Is struct page_info created for every page of system/machine memory?
> Are they created at Xen boot time? Is it possible to create them later
> when Xen is runnig?

No - if they aren't created, then generally because there's no
virtual address space to cover struct page_info itself or the 1:1
mapping that would also be needed for a "normal" page.

>> > As I can see we access crash region as it was owned by domain. AIUI,
>> > it was done in that way because we wanted to be in line with normal
>> > kexec case. However, I am not sure right know that this is good idea.
>> > Maybe we should do something else in crash dump case?
>> >
>> > We could establish an limit (4 GiB?) for crash region as a workaround.
>>
>> Are you taking of a size limit or an address one?
> 
> Size.

So how would limiting the size help?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.