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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 1 Oct 2012, Mukesh Rathor wrote:
> On Mon, 1 Oct 2012 14:32:44 -0700
> Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> 
> > 
> > > > +       struct pvh_remap_data *remapp = data;
> > > > +       struct xen_pvh_pfn_info *pvhp = remapp->pvhinfop;
> > > > +       unsigned long pfn =
> > > > page_to_pfn(pvhp->pi_paga[pvhp->pi_next_todo++]);
> > > > +       pte_t pteval = pte_mkspecial(pfn_pte(pfn, remapp->prot));
> > > > +
> > > > +       if ((rc=pvh_add_to_xen_p2m(pfn, remapp->fgmfn,
> > > > remapp->domid)))
> > > > +               return rc;
> > > > +       native_set_pte(ptep, pteval);
> > > 
> > > Do we actually need the pte to be "special"?
> > > I would think that being in the guest p2m, it is actually quite a
> > > normal page.
> > 
> > Hmm... well, doesn't like removing "special":
> > 
> > 
> > BUG: Bad page map in process xl  pte:800000027b57b467 pmd:2b408d067
> > page:ffffea0008afb2e8 count:1 mapcount:-1 mapping:          (null)
> > index:0x0 page flags: 0x40000000000414(referenced|dirty|reserved)
> > addr:00007fb4345b0000 vm_flags:000a44fb anon_vma:          (null)
> > mapping:ffff88003911a3d0 index:4 vma->vm_ops->fault:
> > privcmd_fault+0x0/0x40 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x30
> > Pid: 2737, comm: xl Tainted: G    B        3.6.0-rc6-merge+ #17
> > Call Trace:
> >  [<ffffffff8113dabc>] print_bad_pte+0x1dc/0x250
> >  [<ffffffff8113e57e>] zap_pte_range+0x45e/0x4c0
> >  [<ffffffff8113f30e>] unmap_page_range+0x1ae/0x310
> >  [<ffffffff8113f4d1>] unmap_single_vma+0x61/0xe0
> >  [<ffffffff8113f5a4>] unmap_vmas+0x54/0xa0
> >  [<ffffffff8114514b>] unmap_region+0xab/0x120
> >  [<ffffffff81313263>] ? privcmd_ioctl+0x93/0x100
> >  [<ffffffff8114733d>] do_munmap+0x25d/0x380
> > 
> > This from:
> >                         if (unlikely(page_mapcount(page) < 0))
> >                                 print_bad_pte(vma, addr, ptent, page);
> > 
> > 
> > So, the mapcount must be not be getting set in "normal" case properly
> > it appears. Marking it special causes it so skip few things.
> > Debugging...
> 
> Shall I just leave it special for now, and come back and revisit 
> this later?
 
special is going to create troubles if somebody starts using these pages
in unexpected ways (for example dma from hardware ot gupf).

Also I fail to see how this case is any different from mapping pages
using gntdev (see gntdev_mmap) that works fine without special.

Maybe we are not setting some vm_flags that we are supposed to set
(VM_RESERVED | VM_IO | VM_DONTCOPY)?
I see that we are setting them in privcmd_mmap but not in
privcmd_ioctl_mmap_batch...

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel