This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Memory attribute configuration in SMMU-v3

Hi,

I am currently working on enabling SMMU-v3 in hypervisor, I notice in SMMU-v3, there are several memory attribute configuration options.

1. SMMU_CR1

a. TABLE_SH for Table access Shareability

b. TABLE_OC for Table access Outer Cacheability

c. TABLE_IC for Table access Inner Cancheability.

same configurations for queue access( QUEUE_SH, QUEUE_OC, QUEUE_IC)

I am not sure here table access by CPU or SMMU? and the cacheablity of which agent, the CPU or SMMU?
In linux smmu-v3 driver, it configures the SMMU_CR1 with code

---------------------------

/* CR1 (table and queue memory attributes) */

reg = (CR1_SH_ISH << CR1_TABLE_SH_SHIFT) |

(CR1_CACHE_WB << CR1_TABLE_OC_SHIFT) |

(CR1_CACHE_WB << CR1_TABLE_IC_SHIFT) |

(CR1_SH_ISH << CR1_QUEUE_SH_SHIFT) |

(CR1_CACHE_WB << CR1_QUEUE_OC_SHIFT) |

(CR1_CACHE_WB << CR1_QUEUE_IC_SHIFT);

writel_relaxed(reg, smmu->base + ARM_SMMU_CR1);

------------------------------

always configure the register with the dedicated value without thinking about SMMU_IDR0 COHACC, bit [4]( Coherent access supported to translations, structures and queues.), if there is one SMMU with COHACC as 0, do not support Coherent access, it can only use non-cacheable memory, but the cr1 always configured with cacheablity, does the SMMU works properly?

2. STE

a. [169:168] S2IR0 for Inner region Cacheability for stage 2 translation table access.

b. [171:170] S2OR0 for Outer region Cacheability for stage 2 translation table access.

c. [173:172] S2SH0 for Shareability for stage 2 translation table access

the same question for stage2 ttb, the configure refers to cacheablity of which side (CPU or SMMU)?
In my hypervisor, SMMU use the stage 2 ttb created by CPU, should the configure the same shareablity and cacheablity? If SMMU do not support Coherent access, how to configure the bits?

thanks

Parents

0 gchww over 1 year ago in reply to Martin Weidmann
Hi, martin,

thanks for your reply.

I checked the attributes used on the cpu for the memory, the normal non-cacheable mair value(0x44) and the right index set to pte.

After I add an cache operation, SMMU works, and the upstream device can access memory normally. All the listed tests have the same result on real silicon chip and fvp revc platform. details as

I add the cache operation( to poc, dc *vac), whatever clean, invalidate, or clean and invalidate, SMMU works

I add the cache operation just after the memory allocation, even not after the setting of STE, SMMU works

after an error occurs, event queue can receive corresponding event, if there is no cache operation, event queue will not receive new event after the secondary error occurs.

after an error occurs, event queue can receive corresponding event, add cache operation, event queue will receive secondary error corresponding event after the secondary error occurs.

base on the test above, it looks like the SMMU waiting for the CPU cache operation before it do the real memory access(access PTE or wirte event queue), and SMMU uses the cpu cache operation as the synchronizing signal.

Doing cache operation to non-cacheable memory looks wired. Can you share more detailed logic rules(similar to Pseudocode in arm arch spec) deep in the SMMU IP module? And why the SMMU take the logic rules?

Thanks
Cancel
Up 0 Down

Cancel

Reply

0 gchww over 1 year ago in reply to Martin Weidmann
Hi, martin,

thanks for your reply.

I checked the attributes used on the cpu for the memory, the normal non-cacheable mair value(0x44) and the right index set to pte.

After I add an cache operation, SMMU works, and the upstream device can access memory normally. All the listed tests have the same result on real silicon chip and fvp revc platform. details as

I add the cache operation( to poc, dc *vac), whatever clean, invalidate, or clean and invalidate, SMMU works

I add the cache operation just after the memory allocation, even not after the setting of STE, SMMU works

after an error occurs, event queue can receive corresponding event, if there is no cache operation, event queue will not receive new event after the secondary error occurs.

after an error occurs, event queue can receive corresponding event, add cache operation, event queue will receive secondary error corresponding event after the secondary error occurs.

base on the test above, it looks like the SMMU waiting for the CPU cache operation before it do the real memory access(access PTE or wirte event queue), and SMMU uses the cpu cache operation as the synchronizing signal.

Doing cache operation to non-cacheable memory looks wired. Can you share more detailed logic rules(similar to Pseudocode in arm arch spec) deep in the SMMU IP module? And why the SMMU take the logic rules?

Thanks
Cancel
Up 0 Down

Cancel

Children

No data