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://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf,
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? 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?

>
> 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?

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/143f5a37-9cdc-d2ef-581e-7f7144b6a709%40web.de.

Reply via email to