[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> @@ -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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.