Lines Matching full:l1

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
211          Bit 1: takeOwnershipOfVcpuState Indicate the L1 is taking
221       dataBuffer: A L1 real address of the GSB.
246 The L1 provides a pointer to the GSB as a parameter to this call. Also
249 The L1 writes all values in the GSB and the L0 only reads the GSB for
267       dataBuffer: A L1 real address of the GSB.
285 H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
305 needed, H_GUEST_GET_STATE() may be called by the L1.
308 the L1 may set a flag (as a hcall parameter) and the L0 will
309 synthesize the interrupt in the L2. Alternatively, the L1 may
329       R4: If R3 = H_Success: The reason L1 VCPU exited (ie. NIA)
367 about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
423 | 0x0004 | 0x08  | RW |   G    | TB Offset (L1 relative)          |
601 the vector register and some SPRs. For the L1 to set this state for
602 the L2, the L1 loads up these hardware registers before the
608 L1 Implementation details: Caching state
611 In the v1 API, all state is sent from the L1 to the L0 and vice versa
618 it's vCPUs are no longer running. This means that the L1 only needs to
623 When a vCPU exits from a H_GUEST_RUN_VCPU() call, the L1 internally
624 marks all L2 state as invalid. This means that if the L1 wants to know
627 valid in L1 until the L2 is run again.
629 Also, when an L1 modifies L2 vcpu state, it doesn't need to write it
630 to the L0 until that L2 vcpu runs again. Hence when the L1 updates
631 state (say via a kvm_set_one_reg() call), it writes to an internal L1
635 This lazy updating of state by the L1 avoids unnecessary