Set the newly added register(KVM_REG_PPC_ONLINE) to indicate if the vcpu is
online(1) or offline(0)

KVM will use this information to set the RWMR register, which controls the PURR
and SPURR accumulation.

CC: paulus@samba.org
Signed-off-by: Nikunj A Dadhania <nikunj@linux.vnet.ibm.com>
Signed-off-by: Ricardo M. Matinata <rmm@br.ibm.com>

Add helper fucnctions for counting physical cores and chips,
from the underlying host (KVM only).

These functions will be used by later patches.

Signed-off-by: Ricardo M. Matinata <rmm@br.ibm.com>

Modify RTAS_SYSPARM_SPLPAR_CHARACTERISTICS from rtas_get_sysparm()
call in qemu so MaxEntCap, DesProcs and MaxPlatProcs key returns values as
per specified in the PAPR.

Linux does not actually make use of these values, currently, but other
OSes depend on the correct interpretation of these values.

As for DesProcs, the PAPR says "The desired number of virtual
processors set by the system administrator in the partition definition.
The desired number of processors can change without a reboot of the
partition. ". The PAPR uses the term "virtual processors" a bit
loosely, but in practice, this should be equal to the number of virtual
cores assigned to the guest.

According to PAPR, MaxEntCap should be "The maximum entitled capacity
currently that can be assigned to the partition through DLPAR/WLM. The
capacity is expressed as a percentage of a physical processor. The
Maximum entitled capacity is set up by the system administrator in the
partition definition. A change in the maximum entitled capacity maximum
takes effect on the next reboot of the partition (...) The maximum
numeric value of Maximum Entitled Capacity is the number of processors
on the platform multiplied by 100". To be consistent with the
interpretation of "processor" as being core, this should be set as the
max. number of virtual cores set for the VM multiplied by 100.

Now regarding MaxPlatProcs, the PAPR says "The maximum number of
processors that can be active on the platform. A change in the maximum
platform processors takes effect on the next reboot of the partition.".
When KVM is running, this is the number of actual cores from the host.

Signed-off-by: Ricardo M. Matinata <rmm@br.ibm.com>

Implement RTAS_SYSPARM_PROCESSOR_MODULE_INFO parameter to rtas_get_sysparm()
call in qemu. This call returns the processor module (socket), chip and core
information as specified in the PAPR.

Currently, number of modules types is set to one (since in practice it is
the case)

Signed-off-by: Ricardo M. Matinata <rmm@br.ibm.com>