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>
2016-10-25 06:47:27 +02:00
|
|
|
/*
|
|
|
|
* QEMU SPAPR Option/Architecture Vector Definitions
|
|
|
|
*
|
|
|
|
* Each architecture option is organized/documented by the following
|
|
|
|
* in LoPAPR 1.1, Table 244:
|
|
|
|
*
|
|
|
|
* <vector number>: the bit-vector in which the option is located
|
|
|
|
* <vector byte>: the byte offset of the vector entry
|
|
|
|
* <vector bit>: the bit offset within the vector entry
|
|
|
|
*
|
|
|
|
* where each vector entry can be one or more bytes.
|
|
|
|
*
|
|
|
|
* Firmware expects a somewhat literal encoding of this bit-vector
|
|
|
|
* structure, where each entry is stored in little-endian so that the
|
|
|
|
* byte ordering reflects that of the documentation, but where each bit
|
|
|
|
* offset is from "left-to-right" in the traditional representation of
|
|
|
|
* a byte value where the MSB is the left-most bit. Thus, each
|
|
|
|
* individual byte encodes the option bits in reverse order of the
|
|
|
|
* documented bit.
|
|
|
|
*
|
|
|
|
* These definitions/helpers attempt to abstract away this internal
|
|
|
|
* representation so that we can define/set/test for individual option
|
|
|
|
* bits using only the documented values. This is done mainly by relying
|
|
|
|
* on a bitmap to approximate the documented "bit-vector" structure and
|
|
|
|
* handling conversations to-from the internal representation under the
|
|
|
|
* covers.
|
|
|
|
*
|
|
|
|
* Copyright IBM Corp. 2016
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
|
|
|
#ifndef _SPAPR_OVEC_H
|
|
|
|
#define _SPAPR_OVEC_H
|
|
|
|
|
|
|
|
#include "cpu.h"
|
2016-11-18 02:40:27 +01:00
|
|
|
#include "migration/vmstate.h"
|
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>
2016-10-25 06:47:27 +02:00
|
|
|
|
|
|
|
typedef struct sPAPROptionVector sPAPROptionVector;
|
|
|
|
|
|
|
|
#define OV_BIT(byte, bit) ((byte - 1) * BITS_PER_BYTE + bit)
|
|
|
|
|
2016-10-25 06:47:28 +02:00
|
|
|
/* option vector 5 */
|
|
|
|
#define OV5_DRCONF_MEMORY OV_BIT(2, 2)
|
2016-10-25 06:47:30 +02:00
|
|
|
#define OV5_FORM1_AFFINITY OV_BIT(5, 0)
|
2016-10-27 04:20:26 +02:00
|
|
|
#define OV5_HP_EVT OV_BIT(6, 5)
|
2016-10-25 06:47:28 +02:00
|
|
|
|
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>
2016-10-25 06:47:27 +02:00
|
|
|
/* interfaces */
|
|
|
|
sPAPROptionVector *spapr_ovec_new(void);
|
|
|
|
sPAPROptionVector *spapr_ovec_clone(sPAPROptionVector *ov_orig);
|
|
|
|
void spapr_ovec_intersect(sPAPROptionVector *ov,
|
|
|
|
sPAPROptionVector *ov1,
|
|
|
|
sPAPROptionVector *ov2);
|
|
|
|
bool spapr_ovec_diff(sPAPROptionVector *ov,
|
|
|
|
sPAPROptionVector *ov_old,
|
|
|
|
sPAPROptionVector *ov_new);
|
|
|
|
void spapr_ovec_cleanup(sPAPROptionVector *ov);
|
|
|
|
void spapr_ovec_set(sPAPROptionVector *ov, long bitnr);
|
|
|
|
void spapr_ovec_clear(sPAPROptionVector *ov, long bitnr);
|
|
|
|
bool spapr_ovec_test(sPAPROptionVector *ov, long bitnr);
|
|
|
|
sPAPROptionVector *spapr_ovec_parse_vector(target_ulong table_addr, int vector);
|
|
|
|
int spapr_ovec_populate_dt(void *fdt, int fdt_offset,
|
|
|
|
sPAPROptionVector *ov, const char *name);
|
|
|
|
|
2016-11-18 02:40:27 +01:00
|
|
|
/* migration */
|
|
|
|
extern const VMStateDescription vmstate_spapr_ovec;
|
|
|
|
|
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>
2016-10-25 06:47:27 +02:00
|
|
|
#endif /* !defined (_SPAPR_OVEC_H) */
|