aboutsummaryrefslogtreecommitdiff
path: root/include/hw/ppc/spapr.h
diff options
context:
space:
mode:
authorMichael Roth <mdroth@linux.vnet.ibm.com>2016-10-24 23:47:27 -0500
committerDavid Gibson <david@gibson.dropbear.id.au>2016-10-28 09:38:26 +1100
commitb20b7b7adda4e2228892670a94e0a4af41c065b9 (patch)
tree2129dc9d46b801f87839f48b66709f6f186d7c76 /include/hw/ppc/spapr.h
parent398a0bd5ae7e03b5b9bdde1dc76451ff57471a55 (diff)
spapr_ovec: initial implementation of option vector helpers
PAPR guests advertise their capabilities to the platform by passing an ibm,architecture-vec structure via an ibm,client-architecture-support hcall as described by LoPAPR v11, B.6.2.3. during early boot. Using this information, the platform enables the capabilities it supports, then encodes a subset of those enabled capabilities (the 5th option vector of the ibm,architecture-vec structure passed to ibm,client-architecture-support) into the guest device tree via "/chosen/ibm,architecture-vec-5". The logical format of these these option vectors is a bit-vector, where individual bits are addressed/documented based on the byte-wise offset from the beginning of the bit-vector, followed by the bit-wise index starting from the byte-wise offset. Thus the bits of each of these bytes are stored in reverse order. Additionally, the first byte of each option vector is encodes the length of the option vector, so byte offsets begin at 1, and bit offset at 0. This is not very intuitive for the purposes of mapping these bits to a particular documented capability, so this patch introduces a set of abstractions that encapsulate the work of parsing/encoding these options vectors and testing for individual capabilities. Cc: Bharata B Rao <bharata@linux.vnet.ibm.com> Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> [dwg: Tweaked double-include protection to not trigger a checkpatch false positive] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'include/hw/ppc/spapr.h')
0 files changed, 0 insertions, 0 deletions