From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH 6/7] xen-gntdev: Support mapping in HVM domains Date: Mon, 10 Jan 2011 17:41:54 -0500 Message-ID: <20110110224154.GH15016@dumpdata.com> References: <1292545063-32107-1-git-send-email-dgdegra@tycho.nsa.gov> <1292545063-32107-7-git-send-email-dgdegra@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1292545063-32107-7-git-send-email-dgdegra@tycho.nsa.gov> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Daniel De Graaf Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Ian.Campbell@citrix.com List-Id: xen-devel@lists.xenproject.org > @@ -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; > }