Re: [Xen-devel] [PATCH v1 2/8]: PVH mmu changes

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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