Re: Xen data from meta-virtualization layer

From: Julien Grall <julien@xen.org>
To: Michael Walle <michael@walle.cc>
Cc: Stefano Stabellini <stefano.stabellini@xilinx.com>,
	Bertrand Marquis <Bertrand.Marquis@arm.com>,
	Zhiqiang.Hou@nxp.com, brucea@xilinx.com,
	cornelia.bruelhart@zal.aero, leo.krueger@zal.aero,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>,
	Peng Fan <peng.fan@nxp.com>,
	xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Xen data from meta-virtualization layer
Date: Sat, 5 Feb 2022 12:41:42 +0000	[thread overview]
Message-ID: <dfe15bd7-8816-2b7a-2193-6ec4efaccded@xen.org> (raw)
In-Reply-To: <CAJ=z9a0GX31E-yQRO3BpOujOCX09yOeeROkC57PzAUTUm3HV6g@mail.gmail.com>

On 04/02/2022 23:29, Julien Grall wrote:
> This message is harmless. This is printed because Xen on Arm
> doesn't hypercall the hypercall to add a PCI device. On Arm,

I meant "doesn't need the hypercall...".

> we don't need it yet (it might be necessary for PCI passthrough) and
> MSI/MSI-X are handled/registered the same way as on bare-metal
> (for your case through the ITS)
> 
>>
>> Not sure if it should work nonetheless.
> 
> I looked through the log and couldn't spot anything obvious. However,
> skimming through Linux, I noticed there are some changes in the
> ITS for freescale (now NXP) such as:
> 
> drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c
> 
> Is it something that might be used on the board you are using?
> 
> If the answer is yes, then my suggestion would be to look
> how this is meant to interact with the ITS. It might be possible
> that we are missing some pieces in Xen to properly support it.

Another tree you might want to look at is 
https://source.codeaurora.org/external/imx/imx-xen. It contains a bunch 
of patches for NXP SoC that was never upstreamed.

> 
>>
>>> It is possible that someone in CC to this email might already have a
>>> patch to introduce parsing of iommu-map in Xen.
> 
> Pass. I don't have any and couldn't find any submission on the ML.
> 
> 
>>
>> I guess they've used the old mmu-masters property.
>>
>> Btw. I don't know if it matters, but the SMARC-sAL28 normally doesn't
>> use TF-A and runs without it. Nonetheless, I've booted the board with
>> the bl31 from NXP and it doesn't help either. There is still a
>> difference between the NXP bootflow which uses bl1/bl2/bl31/u-boot
>> and this board which uses u-boot-spl/u-boot or u-boot-spl/bl31/u-boot.
>>
>> I just found GIC setup code in the bl31. I'll also have a look there.
>>
>> -michael
>>
>> [1] https://pastebin.com/raw/XMjE3BvG

Cheers,

-- 
Julien Grall