Re: [Xen-devel] update_va_mapping() question

[Goswin von Brederlow <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx>]

Goswin von Brederlow <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:

> Secondly is there an opposite call not mentioned in the interface or
> could we make one? Something like
>
>   /* Return the currently installed PTE that maps virtual address va. */
>   uint64_t get_va_mapping(unsigned long va) 
>
> Unmapped entries could give 0 or encode the level at which the lookup
> failed in some unused bits.
>
> Or more generaly a
>
>   /* mmu_read(): Read page table entries
>    * @req[i].ptr   : machine address to read
>    * @req[i].val   : on return value of that entry
>    * @count        : size of req[]
>    * @success_count: number of entries read
>    */
>   mmu_read(mmu_update_t *req, int count, int *success_count)
>
> MfG
>         Goswin

I've been thinking about this a bit more and come to the conclusion
that this wouldn't be too helpfull. Usualy you would have to know the
result of the first mmu_read for the second and couldn't do a multi
request call. E.g. when folloing the page tables down the tree.

Instead something like this would be more suited i think:

  /* follow_va_mapping(): Return page table entries
   * @va         : virtual address to follow
   * @entries[4] : on return page table entries for va
   * returns the number of page tables followed or error
   */ 
  int follow_va_mapping(unsigned long va, pte_t entries[4]);

That way a page fault handler (or others) could read out all 4 page
table entries required for an address in one go without having to map
page tables and without knowing their virtual addresses.

Thoughts?

MfG
        Goswin

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