> On Thu, 13 Feb 2020, Andrei Cherechesu wrote: > > Hello, > > > > I used the Xen from Stefano's tree and made the updates to the partial > > dtb that he specified. > > > > > This is mostly likely because Linux is trying to access a region > > > that is not mapped in stage-2. You can rebuild Xen with debug > > > enabled and you should see a message "traps.c:..." telling the exact > > > physical address accessed. > > > > > > In general I would recommend to build Xen with debug enabled during > > > development as the hypervisor will give you more information of what's > > > going on. > > > > > > Cheers, > > > > > > -- > > > Julien Grall > > > > I enabled debug config and gave it another try. But I'm still getting > > the same unhandled fault error, that seems to match what Julien > > described above. > > > > It is indeed a stage-2 abort caused by the guest. > > > > I attached the DomU1 crash log at [0]. > > > > [0] > > > > > > How should I proceed in this case? > > Looking at the logs, you can see: > > (XEN) traps.c:1973:d1v0 HSR=0x939f0046 pc=0xffffff80083ac864 > gva=0xffffff800800d048 gpa=0x000000402f0048 > > So the guest was accessing address 0x402f0048, however, the MMIO address > range of the device that you are remapping is 0x4002f000-0x40030000. > > I spotted the mistake now: looking at the partial DTB again, the address of > the device is: > > reg = <0x0 0x402f0000 0x1000>; > > but the address that you are remapping is: > > xen,reg = <0x0 0x4002f000 0x1000 0x0 0x4002f000>; > > They are not the same! :-)
Thanks, Stefano! I changed the partial DTB and it did not crash anymore. However, I am encountering another problem now: in Dom0 and in dom0less-booted DomUs, I cannot use /dev/hvc0. Even though I'm specifying "console=hvc0" in dom0-bootargs, when dom0 finishes booting, it looks like I cannot use the getty spawned on /dev/hvc0. This is the end of the boot log: [ 2.947845] random: rngd: uninitialized urandom read (4 bytes read) [ 2.958415] random: rngd: uninitialized urandom read (4 bytes read) [ 2.965452] random: rngd: uninitialized urandom read (2500 bytes read) . [ 2.972410] random: crng init done Starting OpenBSD Secure Shell server: sshd done. Starting /usr/sbin/xenstored... Setting domain 0 name, domid and JSON config... Done setting up Dom0 Starting xenconsoled... Starting QEMU as disk backend for dom0 Starting domain watchdog daemon: xenwatchdogd startup [done] Auto Linux BSP 1.0 s32g274aevb /dev/hvc0 s32g274aevb login: Auto Linux BSP 1.0 s32g274aevb /dev/ttyLF0 s32g274aevb login: ----- END ----- It seems that the getty spawned on /dev/ttyLF0 overwrites the one spawned on /dev/hvc0. Which I do not understand, since Dom0 should not have access (?) directly to ttyLF0 (the serial console device on our boards). If I remove the line which spawns the getty on ttyLF0 from /etc/inittab, the system hangs when waiting for the username, and it does not let me type in any characters. For the record, hvc0 is added to /etc/securetty. In a system where I boot DomU via xl from Dom0, I can switch to its console with xl console, and hvc0 works there. The problem that comes with this is that I can not use the CTRL-AAA command to switch between Dom0 console and DomU console in a dom0less case, and I cannot therefore test that the passthrough works. But at least Dom0 does not have an entry for it under /dev, anymore, and DomU boot prompt tells that the driver has been registered. Thank you very much again for your support, Andrei Cherechesu, NXP Semiconductors
