|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH] SUPPORT.md: Mark Renesas IPMMU-VMSA (Arm) as supported
On Wed, Sep 16, 2020 at 8:02 PM Julien Grall <julien@xxxxxxx> wrote: Hi Oleksandr, Hi Julien [sorry for the possible format issues]
I think, yes. At least I am not aware of any remaining issues which prevent us from using Xen driver normally these days. There was one important issue related to the known R-Car Gen3 IPMMU-VMSA limitation to handle maximum 40-bit IPA only (so 4-level translation table is not supported) and this issue didn't allow us to have the Xen driver *completely* functional. Hopefully, we have already found a proper way to handle this in Xen on Arm [1]: - Can it work on all known platforms with IPMMU VMSA? I don't think Xen driver will work on all known platforms with the IPMMU-VMSA. Xen driver is supposed to be used with newest R-Car Gen3 SoC revisions only (H3 ES3.0, M3-W+, etc.) which IPMMU H/W supports stage 2 translation table format (to be able to share the P2M with the CPU). On older SoC revisions it won't work (driver performs a special check at the initialization time to see whether the P2M sharing is supported in current SoC revision). Being honest, the R-Car Gen3 family is not limited by these 3 SoCs (H3, M3-W+, M3N) the driver is looking for. There are other SoCs: E3, D3, V3H, V3M, etc, which are quite new and likely have a *proper* IPMMU H/W to be used in Xen. But, I don't have a possibility to check them in order to be 100% sure and extend a number of supported SoCs in the driver. - Is there any plan to smoke (manually or automatically) test the driver? Yes, there is a plan to perform manual tests. Actually, this is what we usually do in the context of our development. After all, device passthrough is one of the important features and keeping this driver in a functional state is our target. Regards, Oleksandr Tyshchenko
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |