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

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

>>> 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