On 28.09.20 03:14, Peng Fan wrote:
>> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration files
>>
>> On 27.09.20 03:13, Peng Fan wrote:
>>>> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration files
>>>>
>>>> On 25.09.20 09:55, Jan Kiszka wrote:
>>>>> On 25.09.20 09:30, Peng Fan wrote:
>>>>>>> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration
>>>>>>> files
>>>>>>>
>>>>>>> On 22.09.20 08:45, Alice Guo wrote:
>>>>>>>> + .platform_info = {
>>>>>>>> + /*
>>>>>>>> + * .pci_mmconfig_base is fixed; if you change it,
>>>>>>>> + * update the value in mach.h
>>>>>>>> + * (PCI_CFG_BASE) and regenerate the inmate
>>>> library
>>>>>>>> + */
>>>>>>>> + .pci_mmconfig_base = 0xfd700000,
>>>>>>>> + .pci_mmconfig_end_bus = 0x0,
>>>>>>>> + .pci_is_virtual = 1,
>>>>>>>> + .pci_domain = 0,
>>>>>>>> +
>>>>>>>> + .iommu_units = {
>>>>>>>> + {
>>>>>>>> + .type =
>>>> JAILHOUSE_IOMMU_ARM_MMU500,
>>>>>>>> + .base = 0x51400000,
>>>>>>>> + .size = 0x40000,
>>>>>>>> + .arm_mmu500.sid_mask = 0x7f80,
>>>>>>>
>>>>>>> How is the sid_mask of a platform retrieved? Can this be derived
>>>>>>> from information in a normal device tree?
>>>>>>
>>>>>> This could be get from device tree, to i.MX8QM, iommus = <&smmu
>>>>>> 0x12
>>>>>> 0x7f80>;
>>>>>> 0x12 is sid, 0x7f80 is sid mask.
>>>>>>
>>>>>> Sid mask is use to get the extract the exact sid from SOC internal
>>>>>> BUS, You could think as below:
>>>>>> Bus signal & 0x7f80 = 0x12
>>>>>>
>>>>>
>>>>> Understood - but there seems to be nothing like this on zynqmp, so I
>>>>> tried both 0 and ~0, so far without any sids assigned to the cell. I
>>>>> would have expected that something breaks then, MMC e.g. There is no
>>>>> error reporting in the SMMU code so, thus I will simply see stuck
>>>>> DMA requests?
>>>>>
>>>>> I guess I need to study that SoC to understand what can be expected
>>>>> there, i.e. which devices are under SMMU regime. Unfortunately, I do
>>>>> not have the MX8QM running here yet to check your setup.
>>>>>
>>>>
>>>> I do understand now how the 14-bit IDs on the zynqmp look like and
>>>> that they cover all units, including the SD interfaces that I'm
>>>> currently using for mmc and wifi. But leaving those stream IDs out
>> generates no apparent error.
>>>>
>>>> The SMMU seems to initialize fine (I've already cleaned up the output):
>>>>
>>>> [...]
>>>> Initializing unit: ARM SMMU
>>>> ARM MMU500 at 0xfd800000 with:
>>>> stream matching with 48 SMR groups
>>>> 16 context banks (0 stage 2 only)
>>>> supported page sizes: 0x61311000
>>>> stage-2: 40-bit IPA -> 48-bit PA
>>>> Initializing unit: PVU IOMMU
>>>> Initializing unit: PCI
>>>> Adding virtual PCI device 00:00.0 to cell "Ultra96"
>>>> Adding virtual PCI device 00:01.0 to cell "Ultra96"
>>>> Page pool usage after late setup: mem 63/991, remap 37/131072
>>>> Activating hypervisor
>>>>
>>>> But that's it. DMA is still happily flowing. What could that mean?
>>>> What do you get on the imx8qm when dropping the sids from the root cell?
>>>
>>> I am not sure how zynqmp use SMMU and how their bus signal looks like.
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
>> xilinx.com%2Fsupport%2Fdocumentation%2Fuser_guides%2Fug1085-zynq-ult
>> rascale-trm.pdf&data=02%7C01%7Cpeng.fan%40nxp.com%7C7d10728c
>> 715d4d712a0908d862d2bebb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
>> 0%7C1%7C637368004563253765&sdata=kD0%2BEz%2Bavbv6YUM0hvx
>> kcSoDGqZarTmIngdHLVbehcg%3D&reserved=0,
>> Figure 1-1: There are 6 Translation Buffer Units (TBUs), managed by the
>> Translation Control Unit. Those TBUs seems to intercept all interesting DMA
>> transfers, including the SDIOs I was testing.
>>
>>>
>>> To i.MX8QM, if the IP DMA has SID, but without SMMU context
>>> programmed, the smmu will bypass the translation per the configuration
>>> is bypass in smmu driver, so if dropping the sids from the root cell, it
>>> will
>> work well, no error.
>>> Same to inmate cell.
>>
>> If I take your configs/arm64/imx8qm.c, remove SID 0x13 e.g., will DMA
>> requests from that source be blocked with the current setup?
>
> No.
>
> And if I remove
>> all SIDs, will nothing work? That would be my expectation. If that is not the
>> case, we have an issue. How to isolate a device from a cell or the complete
>> system then?
>
> Ok, then we need to think of change s2cr_init_val to default FAULT or
> translate.
>
Indeed, we have to. This is the key purpose of the SMMU in Jailhouse:
isolation. We can also use it to avoid 1:1 mapping for non-root cells,
but that is secondary.
Nikhil, Lokesh, as I didn't have the time yet to play with the SMMUv3
and the TI-PVU: I hope your defaults is "blocked", not "bypass", right?
>>
>>>
>>> You could try to not bypass SMMU transition in smmu driver, then the
>>> system might not work well.
>>
>> Where is this bypass controlled? In the SMMU settings? Or is that
>> platform-specific?
>
> S2CR_TYPE_BYPASS, smmu settings currently.
Just flipping the type does not seem to be enough. Could you tell me
what is needed to switch to "block what is is not permitted"?
Jan
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/59ce287e-bcc8-16f4-ead3-ff4bf8211628%40web.de.
