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

Re: Xen data from meta-virtualization layer





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



 


Rackspace

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