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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Daniel Kiper <daniel.kiper@xxxxxxxxxx> 11/20/13 8:59 PM >>>
>I could not find any real explanation/comment/doc why 44-bit boundary.
>Could you give me a hint? I have a feeling that MFN bits 32-39 were used
>as flags somewhere? However, I could not find relevant code right now.

asm-x86/mm.h has

#define __pdx_t unsigned int

struct page_list_entry
{
    __pdx_t next, prev;
};

>> And yes, the problem _is_ kexec specific - memory not usable
>> for "normal" purposes gets ignored.
>
>What do you mean by "normal" purposes? Xen heap, domain heap, etc.

Right.

>If yes then, AIUI, it means that in general Xen will work on machines
>with so huge amount of RAM but all memory above 16 TiB will be not
>available. I suppose that sooner or later we would like to make Xen
>working with whole memory on such machines. So are there any plans
>to fix this issue? Just curious...

Sure. But the brute force approach (using 64-bit next/prev pointers) would
have the downside of growing struct page_info from 32 to 40 bytes. Not only
does that mean higher memory overhead, it also means that calculating the
entry from an MFN (which we do a lot) can't be done by a simple shift anymore.

>> > Hmmm... For what 1:1 mapping is used if same page could be mapped by
>> > map_domain_page()?
>>
>> This is purely simplification and a performance optimization:
>> Obviously you don't want e.g. each caller of xmalloc() to a
>> map/unmap operation.
>
>Right. Does it mean that whole system memory has 1:1 mapping?
>Or are there some regions deliberately omitted?

All "normal" memory has 1:1 mapping, but as you recall not all of the 1:1
mapping is available at all times. Hence the need for map_domain_page()
for anything not coming from the Xen heap.

>Do you have machine with so huge amount of RAM to do some tests?

No, I don't. When fixing issues in this area, it's generally in response to
some partner having found it, and hence being able to test it for us.

Jan


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