This is probably the most interesting bit of the whole NV adventure. So far, everything else has been a walk in the park, but this one is where the real fun takes place. With FEAT_NV2, most of the NV support revolves around tricking a guest into accessing memory while it tries to access system registers. The hypervisor's job is to handle the context switch of the actual registers with the state in memory as needed. This memory (which we call the VNCR page) lives at an EL2 VA, and is therefore accessed out of context by the EL1 guest hypervisor. So far, so good. But what does it mean to virtualise VNCR itself? It means that when L1 has a prepared a VNCR page for L2, we must map it in the L0 EL2, and allow L2 to magically access it. Isn't that fun? To some extent. But there's more! Having that L0 mapping on behalf of L1 comes with strings attached. It means that we must be prepared for this page to become inaccessible, which can happen for a variety of reasons: - paged out from the host (MMU notifiers) - unmapped from L1 EL2 stage-1 - permission changes in L1 EL2 stage-1 And in case you're wondering, yes, all of these have TLB invalidation in common. That's because performing this mapping is akin to allocating a "SW managed" TLB for L1's VNCR page. This is what the bulk of this series is about: TLB management for VNCR pages, and making sure we have the correct page at the right time.
