[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.