Re: [Xen-users] Error accessing memory mapped by xenforeignmemory_map()

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

CC'ing the tools Maintainers and Paul

On Fri, 27 Oct 2017, Brett Stahlman wrote:
> On Fri, Oct 27, 2017 at 9:31 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > Adding the ARM maintainers.
> >
> > On Wed, Oct 25, 2017 at 11:54:59AM -0500, Brett Stahlman wrote:
> >> I'm trying to use the "xenforeignmemory" library to read arbitrary
> >> memory ranges from a Xen domain. The code performing the reads is
> >> designed to run in dom0 on a Zynq ultrascale MPSoC (ARM64), though I'm
> >> currently testing in QEMU. I constructed a simple test program, which
> >> reads an arbitrary domid/address pair from the command line, converts
> >> the address (assumed to be physical) to a page frame number, and uses
> >> xenforeignmemory_map() to map the page into the test app's virtual
> >> memory space. Although xenforeignmemory_map() returns a non-NULL
> >> pointer, my attempt to dereference it fails with the following error:
> >>
> >> (XEN) traps.c:2508:d0v1 HSR=0x93810007 pc=0x400a20 gva=0x7f965f7000
> >> gpa=0x00000030555000
> >>
> >> [   74.361735] Unhandled fault: ttbr address size fault (0x92000000)
> >> at 0x0000007f965f7000
> >> Bus error
> >
> > I'm not sure what a Bus error means on ARM, have you tried to look
> > at traps.c:2508 to see if there's some comment explaining why this
> > fault is triggered?
> 
> I believe the fault is occurring because mmap() failed to map the page.
> Although xenforeignmemory_map() is indeed returning a non-NULL pointer,
> code comments indicate that this does not imply success: page-level
> errors might still be returned in the provided "err" array. In my case,
> it appears that an EINVAL is produced by mmap(): specifically, I believe
> it's coming from privcmd_ioctl_mmap_batch() (drivers/xen/privcmd.c), but
> there are a number of conditions that can produce this error code, and I
> haven't yet determined which is to blame...
> 
> So although I'm not sure why I would get an "address size" fault, it
> makes sense that the pointer dereference would generate some sort of
> paging-related fault, given that the page mapping was unsuccessful.
> Hopefully, ARM developers will be able to explain why it was
> unsuccessful, or at least give me an idea of what sorts of things could
> cause a mapping attempt to fail... At this point, I'm not particular
> about what address I map. I just want to be able to read known data at a
> fixed (non-paged) address (e.g., kernel code/data), so I can prove to
> myself that the page is actually mapped.

The fault means "Data Abort from a lower Exception level". It could be
an MMU fault or an alignment fault, according to the ARM ARM.

I guess that the address range is not good. What DomU addresses are you
trying to map?



> > I'm not sure the xenforeigmemory library is used on ARM, since IIRC on
> > x86 that's mainly used for QEMU device emulation, which is not done
> > for ARM. There are examples of guest memory mappings on tools/libxc/,
> > for example xc_dom_boot.c, although that's using the
> > xc_map_foreign_ranges interface.
> 
> Thanks. I'll have a look at this...
> Brett S.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users