On Sat, 23 Jan 2021 at 00:27, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
>
> + xen-devel, Roman,
>
>
> On Fri, 22 Jan 2021, Jukka Kaartinen wrote:
> > Hi Stefano,
> > I'm Jukka Kaartinen a SW developer working on enabling hypervisors on mobile platforms. One of our HW that we use on development is
> > Raspberry Pi 4B. I wonder if you could help me a bit :).
> >
> > I'm trying to enable the GPU with Xen + Raspberry Pi for dom0. https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323#p1797605
> >
> > I got so far that GPU drivers are loaded (v3d & vc4) without errors. But now Xen returns error when X is starting:
> > (XEN) traps.c:1986:d0v1 HSR=0x93880045 pc=0x00007f97b14e70 gva=0x7f7f817000 gpa=0x0000401315d000
> > I tried to debug what causes this and looks like find_mmio_handler cannot find handler.
> > (See more here: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=232323&start=25#p1801691 )
> >
> > Any ideas why the handler is not found?
>
>
> Hi Jukka,
>
> I am glad to hear that you are interested in Xen on RaspberryPi :-) I
> haven't tried the GPU yet, I have been using the serial only.
> Roman, did you ever get the GPU working?
>
>
> The error is a data abort error: Linux is trying to access an address
> which is not mapped to dom0. The address seems to be 0x401315d000. It is
> a pretty high address; I looked in device tree but couldn't spot it.
>
> From the HSR (the syndrom register) it looks like it is a translation
> fault at EL1 on stage1.
Hmmm.... We don't trap stage 1 faults to Xen, instead they are
received by the OS directly.
In fact the ESR_El1, indicates that it is a translation fault at level
1 when walking the stage-2 page-table. So it means the guest physical
address is not mapped in the P2M. But...
> As if the Linux address mapping was wrong.
... I think the GPA is bogus. So I agree Linux may have configured the
stage-1 page-tables incorrectly.
>
> Anyone has any ideas how this could happen? Maybe a reserved-memory
> misconfiguration?
It looks like to me both the PC and the GVA points to user memory.
Normally, Xen will inject a data abort into Linux and will usually
dump some information (e.g. the task running).
I observed that when xen outputs this:
(XEN) traps.c:1983:d0v1 HSR=0x93830045 pc=0x00007fa9df9684 gva=0x7faa26b000 gpa=0x0000401207f000
vc4_bo_create is called with this size:
[ 44.449287] vc4_bo_create size: 4096
@Jukka, would it be possible to provide the console out for both Xen and Linux?
I hope you can access them.
Would you also be able to confirm if the same setup is working when
Linux is running directly on the HW? This would give us an idea
whether the issue is specific to Xen.
Yes, the same setup works when running directly on the HW. I even boot the linux using u-boot and the same device tree.
There is one change that bothers me and that is the swiotlb size. I had to increase its size:
20 * Maximum allowable number of contiguous slabs to map,
21 * must be a power of 2. What is the appropriate value ?
22 * The complexity of {map,unmap}_single is linearly dependent on this value.
23 */
24 //#define IO_TLB_SEGSIZE▸▸▸▸▸▸▸▸128
25 #define IO_TLB_SEGSIZE▸▸4096
without this change I get this error:
[ 79.444987] v3d fec00000.v3d: swiotlb buffer is full (sz: 8294400 bytes), total 32768 (slots), used 1 (slots)
