[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC XEN PATCH v3 05/39] x86/mm: exclude PMEM regions from initial frametable
On 11/03/17 13:58 +0800, Chao Peng wrote: > > > +#ifdef CONFIG_NVDIMM_PMEM > > +static void __init init_frametable_pmem_chunk(unsigned long s, > > unsigned long e) > > +{ > > + static unsigned long pmem_init_frametable_mfn; > > + > > + ASSERT(!((s | e) & (PAGE_SIZE - 1))); > > + > > + if ( !pmem_init_frametable_mfn ) > > + { > > + pmem_init_frametable_mfn = alloc_boot_pages(1, 1); > > + if ( !pmem_init_frametable_mfn ) > > + panic("Not enough memory for pmem initial frame table > > page"); > > + memset(mfn_to_virt(pmem_init_frametable_mfn), -1, PAGE_SIZE); > > + } > > Can zero_page be used instead? No. I intend to make the frametable entries for NVDIMM as invalid at boot time, in order to avoid/detect accidental accesses to NVDIMM pages before they are registered to Xen hypervisor later (by part 2 patches 14 - 25). > > > + > > + while ( s < e ) > > + { > > + /* > > + * The real frame table entries of a pmem region will be > > + * created when the pmem region is registered to hypervisor. > > + * Any write attempt to the initial entries of that pmem > > + * region implies potential hypervisor bugs. In order to make > > + * those bugs explicit, map those initial entries as read- > > only. > > + */ > > + map_pages_to_xen(s, pmem_init_frametable_mfn, 1, > > PAGE_HYPERVISOR_RO); > > + s += PAGE_SIZE; > > Don't know how much the impact of 4K mapping on boot time when pmem is > very large. Perhaps we need get such data on hardware. > Well, it will be very slow because the size of NVDIMM is usually very large (e.g. from hundreds of giga-bytes to several tera-bytes). I can make it to use huge page if possible. > Another question is do we really need to map it, e.g. can we just skip > the range here? Sadly, I cannot remind why I did this. Maybe I can just leave the frametable of NVDIMM unmapped and accidental access to them would just trigger page fault in hypervisor, which can makes bugs explicit as well. Haozhong _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |