[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 2/8] xen/x86: Improvements to build-time pagetable generation
>>> On 24.02.16 at 17:14, <andrew.cooper3@xxxxxxxxxx> wrote: > On 24/02/16 15:48, Jan Beulich wrote: >>>>> On 24.02.16 at 16:22, <andrew.cooper3@xxxxxxxxxx> wrote: >>> On 24/02/16 15:18, Jan Beulich wrote: >>>>>>> On 24.02.16 at 15:58, <andrew.cooper3@xxxxxxxxxx> wrote: >>>>> On 24/02/16 14:15, Jan Beulich wrote: >>>>>>>>> On 24.02.16 at 14:57, <andrew.cooper3@xxxxxxxxxx> wrote: >>>>>>> On 24/02/16 11:24, Jan Beulich wrote: >>>>>>>> >>> On 23.02.16 at 17:31, <andrew.cooper3@xxxxxxxxxx> 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |