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.

That's probably not needed. Since we know the (machine) address of the
pte at that point anyway, the cheapest thing to do would be to use
mmu_update here (and as honoring these new flags will need to be
advertised through another new feature flag, batching the two steps
would anyway be desirable.

Looking at that code I see some other potential issue, though:
GRANT_PTE_FLAGS include PAGE_USER for x86-64, but the generated
pte is passed through adjust_guest_l1e(), so without
GNTMAP_application_map we'd get global kernel mappings. Am I wrong
here?

Plus I would think that GRANT_PTE_FLAGS really should include PAGE_NX.

Jan


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