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

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



On Tue, 31 Mar 2020, Andrei Cherechesu wrote:
> > On Thu, 13 Feb 2020, Andrei Cherechesu wrote:
> > >  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.

Great to hear!


> However, I am encountering another problem now: in Dom0 and in 
> dom0less-booted DomUs,
> I cannot use /dev/hvc0.

For dom0less-booted DomUs it is normal because they don't get a PV
console, they get an emulated PL011 UART instead.  Make sure to have a
"vpl011" tag in device tree to enable it (ImageBuilder generates it by
default.) The device name is usually ttyAMA0.


> 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.

It looks like there is some kind of interference between the dom0 ttyLF0
driver and the Xen serial driver.

Is your Xen UART driver marking the device as "used by Xen"? See for
instance the pl011 driver, at the end of
xen/drivers/char/pl011.c:pl011_dt_uart_init:

    dt_device_set_used_by(dev, DOMID_XEN);

Devices that are marked as "used by Xen" are not exposed to dom0, so you
shouldn't see the ttyLF0 device come up in Linux at all.



 


Rackspace

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