[PATCH 0/3] cpu: idle state framework for offline CPUs.

[Dipankar Sarma]

On Sun, Aug 16, 2009 at 11:53:22PM +0200, Peter Zijlstra wrote:
> On Mon, 2009-08-17 at 01:14 +0530, Balbir Singh wrote:
> > Agreed, I've tried to come with a little ASCII art to depict your
> > scenairos graphically
> > 
> > 
> >         +--------+ don't need (offline)
> >         |  OS    +----------->+------------+
> >         +--+-----+            | hypervisor +-----> Reuse CPU
> >            |                  |            |       for something
> >            |                  |            |       else
> >            |                  |            |   (visible to users)
> >            |                  |            |    as resource changed
> >            |                  +----------- +
> >            V (needed, but can cede)
> >        +------------+
> >        | hypervisor | Don't reuse CPU
> >        |            |  (CPU ceded)
> >        |            | give back to OS
> >        +------------+ when needed.
> >                         (Not visible to
> >                         users as so resource
> >                         binding changed)
> 
> I still don't get it... _why_ should this be exposed in the guest
> kernel? Why not let the hypervisor manage a guest's offline cpus in a
> way it sees fit?

For most parts, we do. The guest kernel doesn't manage the offline
CPU state. That is typically done by the hypervisor. However, offline
operation as defined now always result in a VM resize in some hypervisor
systems (like pseries) - it would be convenient to have a non-resize
offline operation which lets the guest cede the cpu to hypervisor
with the hint that the VM shouldn't be resized and the guest needs the guarantee
to get the cpu back any time. The hypervisor can do whatever it wants
with the ceded CPU including putting it in a low power state, but
not change the physical cpu shares of the VM. The pseries hypervisor,
for example, clearly distinguishes between the two - "rtas-stop-self" call
to resize VM vs. H_CEDE hypercall with a hint. What I am suggesting
is that we allow this with an extension to existing interfaces because it 
makes sense to allow sort of "hibernation" of the cpus without changing any
configuration of the VMs.

Thanks
Dipankar