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/
Home Products Support Community News


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

To: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 6/7] xen-gntdev: Support mapping in HVM domains
From: Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>
Date: Tue, 11 Jan 2011 08:15:08 -0500
Cc: jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian.Campbell@xxxxxxxxxx
Delivery-date: Tue, 11 Jan 2011 05:15:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20110110224154.GH15016@xxxxxxxxxxxx>
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>
Organization: National Security Agency
References: <1292545063-32107-1-git-send-email-dgdegra@xxxxxxxxxxxxx> <1292545063-32107-7-git-send-email-dgdegra@xxxxxxxxxxxxx> <20110110224154.GH15016@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Thunderbird/3.1.7
On 01/10/2011 05:41 PM, Konrad Rzeszutek Wilk wrote:
>> @@ -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?

Status is silent in this case. I can produce it quite reliably on my
test system where I am mapping a framebuffer (1280 pages) between two
HVM guests - in this case, about 2/3 of the released pages will end up
being invalid. It doesn't seem to be size-related as I have also seen
it on the small 3-page page index mapping. There is a message on xm
dmesg that may be related:

(XEN) sh error: sh_remove_all_mappings(): can't find all mappings of mfn 7cbc6: 
c=8000000000000004 t=7400000000000002

This appears about once per page, with different MFNs but the same c/t.
One of the two HVM guests (the one doing the mapping) has the PCI
graphics card forwarded to it.

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

Xen-devel mailing list