On Sat, Jan 23, 2021 at 6:48 PM Julien Grall <[email protected]> wrote:
> On Sat, 23 Jan 2021 at 00:27, Stefano Stabellini <[email protected]> > 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? > Here are the logs: https://drive.google.com/drive/folders/1fhcwpsf6SfPYrk0QR6zexGia0v1XysUr?usp=sharing 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) -- Br, Jukka Kaartinen
