Lines Matching full:l2

12 hypervisor has implemented them. The terms L0, L1, and L2 are used to
16 and controlled by L0. L2 is a guest virtual machine that is initiated
39 call made by the L1 to tell the L0 to start an L2 vCPU with the given
40 state. The L0 then starts this L2 and runs until an L2 exit condition
41 is reached. Once the L2 exits, the state of the L2 is given back to
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
52 The L1 may run any L2 or vCPU without first informing the L0. It
61 The new PAPR API changes from the v1 API such that the creating L2 and
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
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()
85 - L1 deletes L2 with H_GUEST_DELETE()
140 This is called to create an L2. A unique ID of the L2 created
142 identify the L2::
162 This is called to create a vCPU associated with an L2. The L2 id
164 is a unique (for this L2) vCPUid. This vCPUid is allocated by the
185 This is called to get state associated with an L2 (Guest-wide or vCPU specific).
189 This can get either L2 wide or vcpu specific information. Examples of
190 L2 wide is the timebase offset or process scoped page table
192 parameter specifies if this call is L2 wide or vCPU specific and the
196 provided is the L2 and vCPU IDs associated with the state to set.
237 This is called to set L2 wide or vCPU specific L2 state. This info is
240 This can set either L2 wide or vcpu specific information. Examples of
241 L2 wide is the timebase offset or process scoped page table
243 parameter specifies if this call is L2 wide or vCPU specific and the
247 provided is the L2 and vCPU IDs associated with the state to set.
283 This is called to run an L2 vCPU. The L2 and vCPU IDs are passed in as
285 H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
302 type. For example, if the exit reason is the L2 doing a hcall (GPR4 =
307 To synthesize interrupts in the L2, when calling H_GUEST_RUN_VCPU()
309 synthesize the interrupt in the L2. Alternatively, the L1 may
346 This is called to delete an L2. All associated vCPUs are also
367 about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
370 State may be associated with a whole L2 (eg timebase offset) or a
371 specific L2 vCPU (eg. GPR state). Only L2 VCPU state maybe be set by
602 the L2, the L1 loads up these hardware registers before the
603 h_enter_nested() call and the L0 ensures they end up as the L2 state
617 The v2 API changes this so that the L0 retains the L2 state even when
619 communicate with the L0 about L2 state when it needs to modify the L2
624 marks all L2 state as invalid. This means that if the L1 wants to know
625 the L2 state (say via a kvm_get_one_reg() call), it needs call
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
632 copy and only flushes this copy to the L0 when the L2 runs again via