[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] update_va_mapping() question
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |