From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: Consuming PCI device in PV kernel
Date: Fri, 25 Jul 2014 15:25:35 +0100
Message-ID: <53D268DF.6010906@citrix.com>
References: <524794479.20140703121338@gmail.com>
	<20140703180957.GD13710@konrad-lan.dumpdata.com>
	<1376452421.20140707092147@gmail.com>
	<1083121389.20140707122233@gmail.com>
	<623751089.20140718153713@gmail.com>
	<20140718190942.GG15947@laptop.dumpdata.com>
	<538610044.20140721111330@gmail.com>
	<1405940004.25022.10.camel@kazak.uk.xensource.com>
	<357303711.20140725135638@gmail.com>
	<1406293821.24842.8.camel@kazak.uk.xensource.com>
	<1035381797.20140725142116@gmail.com>
	<1406295478.24842.15.camel@kazak.uk.xensource.com>
	<53D2609A.4000802@citrix.com> <13170235.20140725152048@gmail.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: <13170235.20140725152048@gmail.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: Simon Martin <furryfuttock@gmail.com>
Cc: Ian Campbell <Ian.Campbell@citrix.com>, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On 25/07/14 15:20, Simon Martin wrote:
> Hello Andrew,
>
>>>>>> Looking at the code I can't see where bit 22 is being set!
>>>>> Without seeing you code I've no idea about this (even if I could see it,
>>>>> I dunno...)
>>>> Bit 22 is being set in Xen code.
>>> Hopefully someone who knows the x86 PV stuff can chime in then, I looked
>>> but can't see what this represents.
>> I suspect this would be:
>> /* Bit 22 of a 24-bit flag mask. This corresponds to bit 62 of a pte.*/
>> #define _PAGE_GNTTAB (1U<<22)
>> from include/asm-x86/x86_64/page.h
>> So you are attempting to update a pte which already has a granted page
>> in it.
> That's  weird  as  I have only one domU running, so nothing else could
> have claimed the PCI memory area. The PCI has been passed through as I
> see the mapping in xenstore.
>
> Should  I be using a different hypercall to gain access to this memory
> area?
>
>

Once you grant map a page from another domain, your domain no longer
owns the PTE.  You should either avoid that PTE, or grant unmap the
foreign frame first.

This indicates that you have memory management issues/corruption in
whichever domain is receiving the update_va errors.

~Andrew