Combining Stage 1 and Stage 2 attributes
When virtualization is used, a virtual address goes through two Stages of translation. One stage under control of the OS and a second stage under the control of the hypervisor. Both Stage 1 and Stage 2 tables include attributes. How are these combined?
This next diagram shows an example where Stage 1 has marked a location as Device, but the corresponding Stage 2 translation is marked as Normal. What should the resulting type be?
The default in the Arm architecture is to use the most restrictive type. In this example, Device is more restrictive than Normal. Therefore, the resulting type is Device.
For the type and Cacheability, an additional control (
HCR_EL2.FWB) allows this behavior to be overridden. When
FWB is set, Stage 2 can override the Stage 1 type and cacheability settings, instead of the combining behavior.
HCR_EL2.FWB was introduced in Armv8.4-A.
Consider these two cases:
In both of these examples, the resulting attribute is RO (read-only). If software were to write the location, a fault (permission fault) would be generated. But, in the first case this is a Stage 1 fault and the second case it would be a Stage 2 fault. In the example, the Stage 1 fault would have gone to the OS at EL1. While the Stage 2 fault would have gone to EL2 and be handled by a hypervisor.
Finally, let’s consider the case where Stage 1 and Stage 2 attributes are the same:
Here, the resulting attribute is simple, it is R0. But if software writes to the location, is a Stage 1 or Stage 2 fault generated? The answer is Stage 1. This would also be true if Stage 1 and Stage 2 would raise different fault types. Stage 1 faults always take precedence over Stage 2 faults.