Re: problem running on rcar gen3 board (iommu?)

[stsp <stsp2@xxxxxxxxx>]

Hello,

12.10.2022 02:07, Oleksandr Tyshchenko пишет:
> I didn’t find the 211d8419ef revision in vanilla Xen.
Here it is:
https://github.com/xen-project/xen/commit/211d8419ef8d8a237ff914fd8304b8fefc3ff2cc
Seems to have a failed CI.


> > > But why would it then insist on me
> > > adding "iommu=0"?
> Good question. Well, the IOMMUs initialization failed because that SoCs
> revision (r8a77951 ES2.0) does not support P2M sharing so cannot be used
> (and this is reported by the driver).
> I assume, Xen was built with CONFIG_IPMMU_VMSA option explicitly enabled
> (this option is disabled by default)
True but it is selected by CONFIG_RCAR3.


>   although config IPMMU_VMSA mentions
> the following:
>
>         "Say Y here if you are using newest R-Car Gen3 SoCs revisions
>         (H3 ES3.0, M3-W+, etc) or Gen4 SoCs which IPMMU hardware supports
> stage 2
>         translation table format and is able to use CPU's P2M table as is."
>
> So, the CONFIG_IPMMU_VMSA just shouldn’t be enabled if target H/W
> doesn’t match.
platforms/Kconfig should be fixed
then. It forces that option for rcar3.

> Or, if we indeed want/need to relax the behavior (do not panic and
> continue to operate with I/O virtualization disabled) if such a case happens
> (I mean when driver honestly reports it cannot work due to objective
> reason(s)), the code should be updated (fixed?) a bit.
I realize that silently disabling IOMMU
even with 1:1 mapping, may lead to the
security problems, so I won't add any
wishes here. But what always helps is
the verbose error messages. You could
suggest in an error msg to explicitly set
iommu=0 in the config, accept the risk
and continue.

By the way, do you really need the
level2 translation even for identity
mapping?

> > > Any suggestions?
> As you mentioned that "entire system hangs" I assume that Xen "hangs" as
> well (not only the Dom0), so the one thing which comes to mind is to
> re-check whether the "clk_ignore_unused" property is indeed passed via
> xen,dom0-bootargs to Linux.
It probably wasn't.
At least not in the cfg file I created.
If xen adds that to "chosen" node
automatically then perhaps...

> Otherwise, the SCIF clock which supplies UART H/W used for Xen console
> will be disabled by Linux as unused, so the Xen console won't be
> functional afterwards and that may create the impression that system hangs.
This is likely to be the case.
When I disabled the rcar3 support
in linux kernel, I got lots of errors
about missing clocks, but no hang.
So it might be that.
But unfortunately your reply came
too late (almost a month late), I
already swapped the board...
I won't be helpful in testing any
patches or suggestions, unfortunately. :(