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


Re: [Xen-devel] update_va_mapping() question

To: Goswin von Brederlow <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] update_va_mapping() question
From: Goswin von Brederlow <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Sep 2007 13:06:01 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 25 Sep 2007 04:06:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <87bqbryizj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx> (Goswin von Brederlow's message of "Mon, 24 Sep 2007 21:13:36 +0200")
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <87bqbryizj.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
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.



Xen-devel mailing list

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