RE: [EXT] Re: [Xen-devel] Having a DOM-U guest with 1:1 mapping in the second stage MMU.

[Andrei Cherechesu <andrei.cherechesu@xxxxxxx>]

> 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