WARNING - OLD ARCHIVES

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

xen-devel

Re: [Xen-devel] grant table interface addition?

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] grant table interface addition?
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Mon, 03 Nov 2008 12:13:17 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 03 Nov 2008 04:13:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C52F71F5.2896A%keir.fraser@xxxxxxxxxxxxx>
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: <4909CD8F.76E4.0078.0@xxxxxxxxxx> <C52F71F5.2896A%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 30.10.08 15:15 >>>
>On 30/10/08 14:06, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> In order to be able to set some of the available bits in the pte resulting
>> from
>> gnttab_set_map_op() (in particular PAGE_SPECIAL and possibly PAGE_IO),
>> it would seem necessary to extend the set of flags that can be passed to
>> that function. While the addition by itself is a simple operation, the
>> question
>> is how to deal with backward compatibility here: Is there anything
>> preventing the guest kernel from setting the flags it wants manually after
>> Xen established the mapping, i.e. would Xen either disallow any modification
>> to such pte-s, or get confused by the pte not being identical to what it set
>> it to?
>
>I think mod_l1_entry() would allow this since it does no validation unless
>the mapping or PRESENT/RW change. Direct page-table writing won't work as it
>happens since it will want to get_page() which of course won't work on a
>foreign page. It could be given the same fast path as mod_l1_entry(), of
>course.

This turns out more difficult than I first thought: Since neither the virtual
address for which a mapping is to be updated nor the machine address of
the page table entry allow to simply update that entry (because I don't
have a virtual address for the pte at hand to read what Xen wrote), I'm
pretty much lost. Due to Xen built with debug=y setting _PAGE_GNTTAB
I also cannot easily reconstruct the pte from map->dev_bus_addr
(leaving aside the fact that the flag is included in L1_DISALLOW_MASK).
Otoh Xen apparently doesn't keep a guest from clearing that flag...

While looking in more detail into how all this fits together, I realized that
there appears to be a race condition in blktap: Since fast_flush_area()
and dispatch_rw_block_io() call create_lookup_pte_addr() without holding
mm->mmap_sem, there's nothing preventing the just verified (or
created) page table structures to go away again before
HYPERVISOR_grant_table_op() is able to finish (or even begin) its job.
Am I missing something here?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

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