Re: [Xen-devel] [PATCH 3/4] x86: provide build time option to support up to 123Tb of memory

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.01.15 at 13:10, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 28/01/15 08:11, Jan Beulich wrote:
>> As this requires growing struct page_info from 32 to 48 bytes as well
>> as shrinking the always accessible direct mapped memory range from 5Tb
>> to 3.5Tb, this isn't being introduced as a general or default enabled
>> feature.
>>
>> For now setting "bigmem=y" implies "shadow-paging=n", as the shadow
>> paging code otherwise fails to build (see
>> http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg03165.html).
> 
> I presume that once the linked list issues are sorted, bigmem and
> shadow-paging will no longer be mutually exclusive?

Of course.

>> A side effect of the change to x86's mm.h is that asm/mm.h may no
>> longer be included directly. Hence in the few places where this was done,
>> xen/mm.h is being substituted (indirectly in the hvm/mtrr.h case).
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> 
> The changes look surprisingly uninvasive.  Have you got a 123TB machine
> to hand?

Haha.

> On a separate tact, I wonder whether it might be an idea about setting
> about stealing some virtual address space back from 64bit PV guests.  If
> we make a start now, in a couple of years time, it might be a plausible
> ABI breakage that vendors would choose to take, as current operating
> systems start falling out of support.

Making such a change would need to start on the OS side though, and
the hypervisor wouldn't be able to make use of that until in a couple of
(or really, many) years time. Furthermore, with OSes using 1:1
mappings like Linux does, shrinking their VA space isn't going to be
nice (the more that at least currently the same VA layout gets used
for native x86 kernels too, i.e. the shrinking would affect them at
once). I'd much rather hope for a 5th page table level in the not too
distant future...

>> --- a/xen/arch/x86/setup.c
>> +++ b/xen/arch/x86/setup.c
>> @@ -386,8 +386,13 @@ static void __init setup_max_pdx(unsigne
>>      if ( max_pdx > FRAMETABLE_NR )
>>          max_pdx = FRAMETABLE_NR;
>>  
>> +    if ( max_pdx > MPT_VIRT_SIZE / sizeof(unsigned long) )
>> +        max_pdx = MPT_VIRT_SIZE / sizeof(unsigned long);
>> +
>> +#ifdef PAGE_LIST_NULL
> 
> Why does PAGE_LIST_NULL become conditional?  It looks to be
> unconditionally available from xen/mm.h.

It sits inside a "#ifndef page_list_entry" conditional, i.e. gets
#define-d only when not using normal struct list_head for linking.

Jan


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