On Thu, Mar 4, 2010 at 11:55 PM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Mar 04, 2010 at 02:47:58PM +0530, Arvind R wrote:
>> On Wed, Mar 3, 2010 at 11:43 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@xxxxxxxxxx> wrote:
>> >> > aio-write -
>> >>
>> >> which triggers do_page_fault, handle_mm_fault, do_linear_fault, __do_fault
>> >> and finally ttm_bo_vm_fault.
>>
>> > I've attached a simple patch I wrote some time ago to get the real MFNs
>> Have patched - did not apply clean. Will compile and get some info.
> take the print_data function and just jam it in the tt_bo_vm_fault code
Linking problems. But compiled and run
!!! CANNOT lookup_address()!!! Returns NULL on bare AND Xen
Before AND After vm_insert/remap_pfn. Address looked_up is what
fault_handler passes in. Had to add a NULL check in print_data.
Bare-boot log.
[TTM] ttm_bo_vm_fault: faulting-in pages, TTM_PAGE_FLAGS=0x0
[ Before:]PFN: Failed lookup_address of 0x7fd82e9aa000
[ After :]PFN: Failed lookup_address of 0x7fd82e9aa000
Ring any bells?
>> > There is an extra flag that the PTE can have when running under Xen:
>> > _PAGE_IOMAP.
>> > This signifies that the PFN is actually the MFN. In this case thought
>> > it sholdn't be enabled b/c the memory is actually gathered from
>> > alloc_page. But if it is, it might be the culprit.
>> I think the problem lies in the vm_insert_pfn/page/mixed family of functions.
>> These are only used (grep'ed kernel tree) and invariably for mmaping.
>> Scsi-tgt, mspec, some media/video, poch,android in staging and ttm
>> - and, surprise - xen/blktap/ring.c and device.c
>> - which both check XENFEAT_auto_translated_physmap
>>
>> Pls. look at xen/blktap/ring.c - it looks to be what we need
>
> Let me take a look at it tomorrow. Bit swamped.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|