Xen devel - Sep 2007 - update_va_mapping() question

Hi,

two little questions about update_va_mapping():

The Xen Interface Manual says the following:

| Regardless of which page table update mode is being used, however,
| there are some occasions (notably handling a demand page fault)
| where a guest OS will wish to modify exactly one PTE rather than a
| batch, and where that PTE is mapped into the current address
| space. This is catered for by the following:
|
|    update_va_mapping(unsigned long va, uint64_t val, unsigned long flags) 
|
| Update the currently installed PTE that maps virtual address va to
| new value val. As with mmu_update, Xen checks the modification is
| safe before applying it. The flags determine which kind of TLB
| flush, if any, should follow the update.

What does "where that PTE is mapped into the current address space"?

Does that mean it must be in the Page table tree, i.e. the virtual
address must be mapped or mappable without adding Page tables?

Or does the actual Page Table that will be changed have to be mapped
into the domains virtual space?

I''m hoping for the former so I don''t have to map all my page
tables.


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

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

Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> 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@lists.xensource.com
http://lists.xensource.com/xen-devel