From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wen Congyang <wency@cn.fujitsu.com>
Subject: Re: Problem about dump-core
Date: Wed, 17 Sep 2014 14:56:10 +0800
Message-ID: <5419308A.5020204@cn.fujitsu.com>
References: <5417A1D6.1010606@cn.fujitsu.com>		
	<5417E58C.3030906@cn.fujitsu.com>
	<1410885518.23505.11.camel@citrix.com>	
	<5418DADE.60006@cn.fujitsu.com>
	<1410916272.23505.39.camel@citrix.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: <1410916272.23505.39.camel@citrix.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: Ian Campbell <ian.campbell@citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <Ian.Jackson@eu.citrix.com>, xen devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 09/17/2014 09:11 AM, Ian Campbell wrote:
> On Wed, 2014-09-17 at 08:50 +0800, Wen Congyang wrote:
> 
>> Yes, we can check it more earlier. If the 4 error bits are set, is it a valid
>> mfn?
> 
> It doesn't really matter, since valid or not you can't pass such an mfn
> to this interface because of the error handling behaviour.

No, the user may pass more than one mfn, and part of them are ~0UL:
==============================================
    for ( i = 0; i < j; i++ )
    {
        unsigned long pfn, pagetype;
        pfn      = pagebuf->pfn_types[i + curbatch] & ~XEN_DOMCTL_PFINFO_LTAB_MASK;
        pagetype = pagebuf->pfn_types[i + curbatch] &  XEN_DOMCTL_PFINFO_LTAB_MASK;

        if ( pagetype != XEN_DOMCTL_PFINFO_XTAB
             && ctx->p2m[pfn] == (INVALID_P2M_ENTRY-1) )
        {
            /* We just allocated a new mfn above; update p2m */
            ctx->p2m[pfn] = ctx->p2m_batch[nr_mfns++]; 
            ctx->nr_pfns++; 
        }

        /* setup region_mfn[] for batch map, if necessary.
         * For HVM guests, this interface takes PFNs, not MFNs */
        if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
             || pagetype == XEN_DOMCTL_PFINFO_XALLOC )
            region_mfn[i] = ~0UL; /* map will fail but we don't care */
        else
            region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn];
    }

    /* Map relevant mfns */
    pfn_err = calloc(j, sizeof(*pfn_err));
    if ( pfn_err == NULL )
    {
        PERROR("allocation for pfn_err failed");
        return -1;
    }
    region_base = xc_map_foreign_bulk(
        xch, dom, PROT_WRITE, region_mfn, pfn_err, j);
==============================================
The above codes are the function apply_batch(). In this case, we cannot
return NULL.

I think we should check the mfn, and if it is large mfn, and some error bits
are set, pass ~0UL to ioctl(), and mark this mfn is mapped failed in err[].

Thanks
Wen Congyang

> 
> Ian.
> 
> .
>