From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v2 2/8] xen/x86: Improvements to build-time pagetable generation Date: Wed, 24 Feb 2016 15:22:58 +0000 Message-ID: <56CDCAD2.7030609@citrix.com> References: <1456245085-2302-1-git-send-email-andrew.cooper3@citrix.com> <1456245085-2302-3-git-send-email-andrew.cooper3@citrix.com> <56CDA11102000078000D5935@prv-mh.provo.novell.com> <56CDB6BF.8040701@citrix.com> <56CDC91E02000078000D5B5A@prv-mh.provo.novell.com> <56CDC502.5060006@citrix.com> <56CDD7ED02000078000D5C62@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56CDD7ED02000078000D5C62@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org On 24/02/16 15:18, Jan Beulich wrote: >>>> On 24.02.16 at 15:58, wrote: >> On 24/02/16 14:15, Jan Beulich wrote: >>>>>> On 24.02.16 at 14:57, wrote: >>>> On 24/02/16 11:24, Jan Beulich wrote: >>>>> >>> On 23.02.16 at 17:31, 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? > which require us to keep these as small pages even if they > could be recombined. In the HVMLite case, MTRRs can be sensibly be disable in the guest which would also allow the host EPT mappings to recombine back to a superpage. ~Andrew