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

VMSAv8-64 - How to change 2-stage translation table descriptors of a given VMID and do invalidation afterwards?

Hello everyone,

Basically, I have a setup in which an hypervisor is running in EL2 and two guestOS running in EL1/EL0, being one a special guest (able to perform requests to the hypervisor), and the other one a limited guestOS. In ARMv8, each guest OS can have its own gmmu configuration for 2-stage translation.

For each request performed by the special guestOS, the hypervisor changes the gmmu configuration of the limited guestOS. Still, when the special guest requests a change in the gmmu configuration of the limited guest, we have to do any kind of invalidation in order to get the results reflected properly. I have checked in ARM ARM and nearly all instructions for TLB maintenance are regarding to the current VMID, there is other which affects all translation table entries of any VMID (and probably it gets a performance loss significantly in comparison with the other ones). All instruction for TLB maintenance are described in the section - A64 system instructions for TLB maintenance- of ARM ARM.

So, and in order to implement it correctly and trying to minimize the performance costs, two questions are worrying me all the time:

1- Is there anyway to change temporarily the current VMID to the one which belongs to the limited guestOS, performing the respective invalidation and then restore the initial VMID (to special guest) afterwards? If so, is a written in the VTTBR enough or you need some memory fences after that to ensure its completion?

2- I guess that some barriers are needed, I am not sure. If so, what kind of memory barriers (isb, dsb or dmb) should I use to ensure that the modification of VMID was completed and all invalidations are regarding to the new VMID?

Thanks in advance.

  • Hi,

    I think changing the VMID value in VTTBR is the only way to do what you want.  To make that change observable you need a context synchronization event, applicable ones are executing an ISB or taking/returning from an exception.


    Section K9.5.3 in the Arm ARM litmus tests appendix covers most of the common scenarios but I suspect you will want something like:

    Update VTTBR
    ISB


    <do whatever you are doing>

    DSB?? // barrier to force completion of thing



    TLBI VMALLE1

    DSB ISH

    ISB



    RE-update VTTBR

    ISB or ERET ;eret-ing back to EL1 will synchronise the update

  • Hi Peter,

    Ok, I will implement it in a similar way.

    Thank you so much for your prompt replay and help.

    Cheers.