WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 6/7] xen-gntdev: Support mapping in HVM domains

To: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 6/7] xen-gntdev: Support mapping in HVM domains
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Mon, 10 Jan 2011 17:41:54 -0500
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian.Campbell@xxxxxxxxxx
Delivery-date: Mon, 10 Jan 2011 14:44:58 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1292545063-32107-7-git-send-email-dgdegra@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1292545063-32107-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <1292545063-32107-7-git-send-email-dgdegra@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
> @@ -284,8 +304,25 @@ static void unmap_grant_pages(struct grant_map *map, int 
> offset, int pages)
>               goto out;
>  
>       for (i = 0; i < pages; i++) {
> +             uint32_t check, *tmp;
>               WARN_ON(unmap_ops[i].status);
> -             __free_page(map->pages[offset+i]);
> +             if (!map->pages[i])
> +                     continue;
> +             /* XXX When unmapping, Xen will sometimes end up mapping the GFN
> +              * to an invalid MFN. In this case, writes will be discarded and
> +              * reads will return all 0xFF bytes. Leak these unusable GFNs
> +              * until a way to restore them is found.
> +              */
> +             tmp = kmap(map->pages[i]);
> +             tmp[0] = 0xdeaddead;
> +             mb();
> +             check = tmp[0];
> +             kunmap(map->pages[i]);
> +             if (check == 0xdeaddead)
> +                     __free_page(map->pages[i]);
> +             else if (debug)
> +                     printk("%s: Discard page %d=%ld\n", __func__,
> +                             i, page_to_pfn(map->pages[i]));

Whoa. Any leads to when the "sometimes" happens? Does the status report an
error or is it silent?

>               map->pages[offset+i] = NULL;
>               map->pginfo[offset+i].handle = 0;
>       }

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel