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

[Brett Stahlman <brettstahlman@xxxxxxxxx>]

On Fri, Oct 27, 2017 at 3:22 PM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> 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
>> 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?

The intent was to map fixed "guest physical" addresses corresponding to
(e.g) the "zero page" of a guest's running kernel. Up until today, I'd
assumed that a PV guest's kernel would be loaded at a known "guest
physical" address (like 0x100000 on i386), and that such addresses
corresponded to the gfn's expected by xenforeignmemory_map(). But now I
suspect this was an incorrect assumption, at least for the PV case. I've
had trouble finding relevant documentation on the Xen site, but I did
find a presentation earlier today suggesting that for PV's, gfn == mfn,
which IIUC, would effectively preclude the use of fixed addresses in a
PV guest. IOW, unlike an HVM's kernel, a PV's kernel cannot be loaded at
a "known" address (e.g., 0x100000 on i386).

Perhaps my use case (reading a guest kernel's code/data from dom0) makes
sense for an HVM, but not a PV? Is it not possible for dom0 to use the
foreignmemory interface to map PV guest pages read-only, without knowing
in advance what, if anything, those pages represent in the guest? Or is
the problem that the very concept of "guest physical" doesn't exist in a
PV? I guess it would help if I had a better understanding of what sort
of frame numbers are expected by xenforeignmemory_map() when the target
VM is a PV. Is the Xen code the only documentation for this sort of
thing, or is there some place I could get a high-level overview?

Thanks,
Brett S.

>
>
>
>> > 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