[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes
On Wed, 26 Sep 2012, Mukesh Rathor wrote: > > > @@ -1652,6 +1681,10 @@ static void set_page_prot(void *addr, > > > pgprot_t prot) unsigned long pfn = __pa(addr) >> PAGE_SHIFT; > > > + /* set_pte* for PCI devices to map iomem. */ > > > + if (xen_initial_domain()) { > > > + pv_mmu_ops.set_pte = native_set_pte; > > > + pv_mmu_ops.set_pte_at = > > > xen_dom0pvh_set_pte_at; > > > + } > > > + return; > > > + } > > > + > > > x86_init.mapping.pagetable_reserve = > > > xen_mapping_pagetable_reserve; > > > x86_init.paging.pagetable_setup_start = xen_pagetable_setup_start; > > > - x86_init.paging.pagetable_setup_done = > > > xen_pagetable_setup_done; pv_mmu_ops = xen_mmu_ops; > > > > > > memset(dummy_mapping, 0xff, PAGE_SIZE); > > > > I wonder whether it would make sense to have a xen_pvh_init_mmu_ops, > > given that they end up being so different... > > It's not a pv ops call. It's called from xen_start_kernel in > enlighten.c. So lets just leave it like that. I meant having a completely different initialization function in mmu.c, instead of trying to reuse xen_init_mmu_ops, because at the end of the day the two cases are very different _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |