arch/powerpc/kvm-nested.rst

12 hypervisor has implemented them. The terms L0, L1, and L2 are used to
14 that would normally be called the "host" or "hypervisor". L1 is a
17 and controlled by L1 acting as a hypervisor.
22 Linux/KVM has had support for Nesting as an L0 or L1 since 2018
31 The L1 code was added::
39 call made by the L1 to tell the L0 to start an L2 vCPU with the given
42 the L1 by the L0. The full L2 vCPU state is always transferred from
43 and to L1 when the L2 is run. The L0 doesn't keep any state on the L2
44 vCPU (except in the short sequence in the L0 on L1 -> L2 entry and L2
45 -> L1 exit).
47 The only state kept by the L0 is the partition table. The L1 registers
52 The L1 may run any L2 or vCPU without first informing the L0. It
66 be called the L1 must explicitly create the L2 using h_guest_create()
71 The basic execution flow is for an L1 to create an L2, run it, and
74 - L1 and L0 negotiate capabilities with H_GUEST_{G,S}ET_CAPABILITIES()
75   (normally at L1 boot time).
77 - L1 requests the L0 create an L2 with H_GUEST_CREATE() and receives a token
79 - L1 requests the L0 create an L2 vCPU with H_GUEST_CREATE_VCPU()
81 - L1 and L0 communicate the vCPU state using the H_GUEST_{G,S}ET() hcall
83 - L1 requests the L0 runs the vCPU running H_GUEST_VCPU_RUN() hcall
85 - L1 deletes L2 with H_GUEST_DELETE()
94 an L1 or L0. Latest version of PAPR can be referred to for more details.
96 All these HCALLs are made by the L1 to the L0.
117 This is called to inform the L0 of the capabilities of the L1
123 L1 to negotiate an agreed set of capabilities::
165 L1::
195 The L1 provides a pointer to the GSB as a parameter to this call. Also
198 The L1 writes only the IDs and sizes in the GSB.  L0 writes the
217       dataBuffer: A L1 real address of the GSB.
242 The L1 provides a pointer to the GSB as a parameter to this call. Also
245 The L1 writes all values in the GSB and the L0 only reads the GSB for
263       dataBuffer: A L1 real address of the GSB.
281 H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
301 needed, H_GUEST_GET_STATE() may be called by the L1.
304 the L1 may set a flag (as a hcall parameter) and the L0 will
305 synthesize the interrupt in the L2. Alternatively, the L1 may
325       R4: If R3 = H_Success: The reason L1 VCPU exited (ie. NIA)
363 about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
420 | 0x0004 | 0x08  | RW |   G    | TB Offset (L1 relative)          |
438 |        |       |    |        | for an L1-Lpar.                  |
442 |        |       |    |        | an L1-Lpar                       |
446 |        |       |    |        | Space for an L1-Lpar             |
450 |        |       |    |        | Space for an L1-Lpar             |
621 the vector register and some SPRs. For the L1 to set this state for
622 the L2, the L1 loads up these hardware registers before the
628 L1 Implementation details: Caching state
631 In the v1 API, all state is sent from the L1 to the L0 and vice versa
638 it's vCPUs are no longer running. This means that the L1 only needs to
643 When a vCPU exits from a H_GUEST_RUN_VCPU() call, the L1 internally
644 marks all L2 state as invalid. This means that if the L1 wants to know
647 valid in L1 until the L2 is run again.
649 Also, when an L1 modifies L2 vcpu state, it doesn't need to write it
650 to the L0 until that L2 vcpu runs again. Hence when the L1 updates
651 state (say via a kvm_set_one_reg() call), it writes to an internal L1
655 This lazy updating of state by the L1 avoids unnecessary