[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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] https://pastebin.com/BSHVFQiK
> 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 (looking at
https://pastebin.com/j0NS4x5Z) 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! :-)

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.