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

[Julien Grall <julien.grall@xxxxxxx>]

Hello,

On 27/10/2017 21:22, Stefano Stabellini wrote:
> 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
For Arm64 guests, when Xen is receive a data abort from the guest (i.e 
there are a problem with stage-2 mapping) and unable to handle it, then 
a "address size" fault will be injected to the guest.
I agree this is really confusing and because Xen does not populate the 
FSC (Fault Status Code Error) in HSR_EL1.
Looking at Arm32, we always inject as a debug exception. This is a bit 
better.
We at least need to improve the fault for Arm64 guest, maybe by using 
"synchronous external abort" (0b010000). I will send a patch for that.
> > 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.
Per D4.7.3 in ARM DDI 0487B.a, alignment fault will be taken as stage-1 
fault and hence not received by the Xen.
Furthermore, you can find a bit more information on the fault by 
decoding the HSR. From the logs HSR/ESR_EL2 is 0x93810007, so this is a 
translation fault level 3. Meaning the page you are trying to access is 
not mapped in stage-2.
Cheers,

--
Julien Grall

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