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

Re: Xen data from meta-virtualization layer


  • To: Michael Walle <michael@xxxxxxxx>
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxx>
  • Date: Fri, 4 Feb 2022 13:11:37 -0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 149.199.62.198) smtp.rcpttodomain=walle.cc smtp.mailfrom=xilinx.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=xilinx.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8to3lxzFcc9fGY7nC5OQK6nQEmZeZxr61EA19JNvnXM=; b=BuPZ8qyMglmDKO0LQy7uo7ITruXD0DKQ1rYyx3n0jIOPuSAlmRY5XeaX4jmIQgGOYAMWMEukrDQa2YlsrAicHFRR7ZEc1ew834VlmTvNOxsLXEF0AkNDk5ZQf7N8+ib+wV2SUdYXWGJzQUha3sNekKzSxoaYzox3Q18pnOKalzodLHxOTT1z0ct08y4ltF0xGF7Sb88ZuiL+FWZSZsgiiLfGHzHSr8KNj597FTkeyP/r8HtiQwBuyYMXIWhxFNDLkTrTkfE3TvrJD114cUnmqmaLtpKk6IV7p9JKftQHT8n6qD3DyCkjgyg/f4iEAY2uQlc7pC6/z754jqiTfLziWQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=axUw5Lv6ohylH+zcN+33MWvQtd4+Firg7qYDkA57iIQZKn2XXK0WKDl0elAp5GTMmHUohTwt29kozU5R+w7tLI3R9+GxP3sZss42w5ImoiPGGfz78ARbaZbHFRiaomSnkEZhhvm4+HxvyxCGGdHMEFHOy/16l4d9AxJcyF9yoieQlWVt6Iu9+ZBBiD264JYH17J5wQs0AemOg5lqiTFBCXcpHwfDUksDMNpTFa7C921bods4y+H6nl6klHPX4yiLiJt+dKK0E6kAaBAoC2Ib8PdoHOWWPCmrLW4j/EW9rWIuGNlYgmNKk6cFIxZDINDqo3A44r8h7JVxzTkU/4vSiA==
  • Cc: <stefano.stabellini@xxxxxxxxxx>, <Bertrand.Marquis@xxxxxxx>, <Zhiqiang.Hou@xxxxxxx>, <brucea@xxxxxxxxxx>, <cornelia.bruelhart@xxxxxxxx>, <julien@xxxxxxx>, <leo.krueger@xxxxxxxx>, <oleksandr_andrushchenko@xxxxxxxx>, <peng.fan@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 04 Feb 2022 21:11:55 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, 4 Feb 2022, Michael Walle wrote:
> > In regards to the reserved-memory regions, maybe we are not seeing them
> > because Leo posted the host device tree, not the one passed at runtime
> > from u-boot to Linux?
> > 
> > If so, Leo, could you please boot Linux on native (no Xen) and get the
> > device tree from there at runtime using dtc -I fs -O dts
> > /proc/device-tree ?
> > 
> > 
> > However, the name of the reserved-memory region created by u-boot seems
> > to be "lpi_rd_table". I cannot find any mentions of lpi_rd_table in the
> > Linux kernel tree either.
> > 
> > Zhiqiang, Leo is trying to boot Xen on sAL28. Linux booting on Xen
> > throws errors in regards to GIC/ITS initialization. On other hardware
> > Xen can use and virtualize GICv3 and ITS just fine. Could you please
> > explain what is different about sAL28 and how Xen/Linux is expected to
> > use the lpi_rd_table reserved-memory region?
> 
> I actually stumbled across this thread after trying out Xen myself. I'm
> using lastest vanilla u-boot (with pending PSCI patches), vanilla kernel
> and vanilla Xen.
> 
> So far I've discovered, that xen complains that it cannot route IRQ64 to
> dom0. That is because on the LS1028A there is a dual UART (two 16550
> with one shared interrupt) and xen takes the first UART and then tries
> to map the interrupt of the second UART to linux. For now, I don't know
> how this is solved correctly. As a quick hack, I removed the second uart
> node from the device tree.

This is an interesting problem. Removing the second UART is a good
workaround for now as there is no obvious solution I think.


> But what is more severe is that the iommu isn't set up correctly. I'm
> getting the following faults:
> 
> (XEN) smmu: /soc/iommu@5000000: Unexpected global fault, this could be serious
> (XEN) smmu: /soc/iommu@5000000:       GFSR 0x80000002, GFSYNR0 0x00000000, 
> GFSYNR1 0x0000042a, GFSYNR2 0x00000000
> 
> If I decode it correctly, the streamid should be 0x2a which would be one
> of the PCI devices on the internal root complex. Probably the network
> card.

Yes there is DMA transaction with an "unknown" StreamID. I think the
StreamID is 0x42a. It means that there is a DMA master on the board with
StreamID 0x42a that is either:

- not described in device tree
- described in device tree with a different StreamID
- the right StreamID is described device tree, but it is not picked up
  by Xen


> This is the first developer experience with Xen, so please bear with me
> :) It seems that Xen doesn't add the master to the IOMMU. To me it seems
> that only devices with a 'iommus' dt property are added. But in case of
> PCI devices the parent only has a iommu-map property.
> 
> And it makes me wonder why Leo has an almost working setup. Maybe I'm
> missing some patches though.

Xen 4.16 is able to parse StreamID in the "iommus" property and also
"mmu-masters" property. But It is not able to parse the "iommu-map"
property yet. So if 0x42a is described in device tree using "iommu-map"
then the error makes sense.

A simple solution is to replace iommu-map with iommus in device tree.
It is possible that someone in CC to this email might already have a
patch to introduce parsing of iommu-map in Xen.



 


Rackspace

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