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

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

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".

In the example of an HVMLite guest, It is entirely reasonable (and
indeed preferable) to avoid shattered superpages (both guest and host)
for mapping gfn 0.  The best case is that an HVMLite guest ends up as an
exact multiple of 1GB, and uses 1GB HAP superpages.

~Andrew