>>> On 24.03.17 at 08:58, <jgr...@suse.com> wrote:
> On 24/03/17 08:51, Jan Beulich wrote:
>>>>> On 24.03.17 at 06:45, <jgr...@suse.com> wrote:
>>> On 23/03/17 18:35, Andrew Cooper wrote:
>>>> Would you prefer ~((uint64_t)_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1)) or
>>>> ~(_PAGE_PSE_PAT | (_PAGE_PSE_PAT - 1) | 0ULL)
>>>
>>> Wouldn't it be better to just define the _PAGE_PSE bits accordingly?
>>
>> I don't think that's a good idea, since the flags accessors deal with
>> unsigned int quantities (see {get,put}_pte_flags()), and there's no
>> need to promote these to 64 bit operations. Otherwise you'd also
>> have to e.g. ask for _PAGE_NX_BIT to be made 1ULL << 63 instead
>> of its current 1ULL << 23.
>
> Well, I came to my conclusion looking at the usage of _PAGE_PSE_PAT
> in do_recalc() (source file arch/x86/mm/p2m-pt.c). While being fine
> right now it will be a problem as soon as we support >16 TB hosts.
> And finding these kind of problems might be hard.
We do support such hosts (CONFIG_BIGMEM), so we should fix such
issues. Luckily a quick grep shows this to be the only problem of that
kind. The problem really only occurs when the flags accessors are
being bypassed (which sadly in a few cases is almost unavoidable).
I guess you'll submit a patch, else let me know if I should do so.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
