From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [PATCH v1 2/8]: PVH mmu changes
Date: Mon, 1 Oct 2012 14:44:55 -0700
Message-ID: <20121001144455.3ba7e10b@mantra.us.oracle.com>
References: <20120921121556.1a0ea8af@mantra.us.oracle.com>
	<alpine.DEB.2.02.1209241228460.29232@kaball.uk.xensource.com>
	<20121001143244.36b4c270@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <20121001143244.36b4c270@mantra.us.oracle.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Mon, 1 Oct 2012 14:32:44 -0700
Mukesh Rathor <mukesh.rathor@oracle.com> 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?

thanks
Mukesh