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


[Xen-devel] Re: paged granttable entries

To: Olaf Hering <olaf@xxxxxxxxx>
Subject: [Xen-devel] Re: paged granttable entries
From: Patrick Colp <pjcolp@xxxxxxxxx>
Date: Thu, 26 Aug 2010 11:17:16 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 26 Aug 2010 11:18:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100826145024.GA7338@xxxxxxxxx>
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: <20100826121355.GA6254@xxxxxxxxx> <20100826145024.GA7338@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Olaf,

Thanks for all this info. The basic idea for grant table stuff is that
if it's already been granted, then it shouldn't be paged out (this
case should be covered by reference counting). In the case where a
guest wants to grant a page that is currently paged out, then that
page should be brought back in before the grant is made. I think the
idea here would maybe be to pause the VCPU running the grant code,
page in the page, then resume the VCPU. The ip wouldn't be advanced at
all, so it should re-execute the instruction to grant causing it to
trap back into Xen and grant the (now paged in) page. The grant
interface has changed a lot since I originally worked on it, so it's
not surprising to me that there's issues here. An alternative approach
is to return an error to the guest which results in it retrying the
mapping itself (without needing to pause/unpause the VCPU). I haven't
looked at the PV driver code to know if there's already a retry
mechanism built in or not. If there is, then that could be leveraged.
If not, then either we pause the VCPU as mentioned above or code in a
new path. I'm generally in favour of approaches that don't break old
systems unless absolutely necessary (for performance reasons, say).
When I get some time I'll read over the grant mapping stuff again to
see if I can make more sense of it.


On 26 August 2010 07:50, Olaf Hering <olaf@xxxxxxxxx> wrote:
> Patrick,
> while looking for other usage of p2m_mem_paging_populate(), I found two
> calls in __gnttab_copy(). They set the error gnttab_copy_t->status to
> Should this better be something from the GNTST_* namespace? I did not
> see a check for -ENOENT "on the other side".
> At least the kernel drivers in SLES11 do only check for GNTST_okay and
> GNTST_eagain and GNTST_bad_page.
> And a quick search for op->status usage shows a mix of GNTST_* and
> status != 0. While it may not make much difference, perhaps there should
> be some translation between the granttable error namespace and other
> namespaces.
> Olaf

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>