Re: [PATCH v2 2/8] xen/x86: Improvements to build-time pagetable generation

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 24/02/16 16:59, Jan Beulich wrote:
>>>> On 24.02.16 at 17:14, <andrew.cooper3@citrix.com> wrote:
>> On 24/02/16 15:48, Jan Beulich wrote:
>>>>>> On 24.02.16 at 16:22, <andrew.cooper3@citrix.com> wrote:
>>>> On 24/02/16 15:18, Jan Beulich wrote:
>>>>>>>> On 24.02.16 at 15:58, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 24/02/16 14:15, Jan Beulich wrote:
>>>>>>>>>> On 24.02.16 at 14:57, <andrew.cooper3@citrix.com> wrote:
>>>>>>>> On 24/02/16 11:24, Jan Beulich wrote:
>>>>>>>>>  >>> On 23.02.16 at 17:31, <andrew.cooper3@citrix.com> wrote:
>>>>>>>>>>  GLOBAL(l1_identmap)
>>>>>>>>>> -        pfn = 0
>>>>>>>>>> +        idx = 0
>>>>>>>>>>          .rept L1_PAGETABLE_ENTRIES
>>>>>>>>>>          /* VGA hole (0xa0000-0xc0000) should be mapped UC. */
>>>>>>>>>> -        .if pfn >= 0xa0 && pfn < 0xc0
>>>>>>>>>> -        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE | MAP_SMALL_PAGES
>>>>>>>>>> +        .if idx >= 0xa0 && idx < 0xc0
>>>>>>>>>> +        .quad (idx << PAGE_SHIFT) | PAGE_HYPERVISOR_NOCACHE
>>>>>>>>>>          .else
>>>>>>>>>> -        .long (pfn << PAGE_SHIFT) | PAGE_HYPERVISOR | MAP_SMALL_PAGES
>>>>>>>>>> +        .quad (idx << PAGE_SHIFT) | PAGE_HYPERVISOR
>>>>>>>>> Please don't eliminate the MAP_SMALL_PAGES here, they serve an
>>>>>>>>> (at least documentation) purpose.
>>>>>>>> How?  Its in a l1 so are necessarily small pages, and the other l1's
>>>>>>>> don't use the constant.
>>>>>>> MAP_SMALL_PAGES documents (and enforces) that the mappings
>>>>>>> shouldn't be re-combined into 2M ones, even if - after adjustments
>>>>>>> to the other attributes - they could be.
>>>>>> In which case, is actively wrong.  Were the cacheabilities to change
>>>>>> (e.g. booting HVMLite and knowing that there was no legacy VGA hole),
>>>>>> the mappings should be recombined into a 2M superpage.
>>>>> No, I think there are reasons (to do with fixed range MTRRs and
>>>>> errata)
>>>> Any idea about which generation this might apply to?
>>> Just read the SDM sub-section "Large Page Size Considerations"
>>> inside the section on MTRRs.
>> Right, and all that says is "don't accidentally mix cacheabilities
>> between paging and MTRRs".
> Exactly. But we don't check back with the MTRRs when deciding
> whether to re-combine a large page. Hence that flag to prevent
> any such attempt.
>
> Plus it also says something about a performance impact when
> nevertheless using a large page for the first 2 or 4 MB.

The performance impact is only noted in relation to using "the most
conservative caching options".

I.e. if you use a 2M superpage and set UC because of mixed MTRRs, this
is a performance impact as the tradeoff against avoiding undefined
behaviour.

I will reinstate the bits for now, but I do intend them to be removed
longterm.

~Andrew