Re: [Qemu-devel] [PATCH 01/11] spapr_ovec: initial implementation of option vector helpers

2016-10-14 Thread Michael Roth
Quoting David Gibson (2016-10-13 21:39:19)
> On Wed, Oct 12, 2016 at 06:13:49PM -0500, Michael Roth wrote:
> > 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.
> 
> Heh.. pity qemu doesn't use the ccan bitmap module
> (http://ccodearchive.net/info/bitmap.html).  By design it always
> stores the bitmaps in IBM bit number ordering, because that's most
> obvious to a human reading a memory dump (for the purpose of bit
> vectors - in most situations the IBM numbering is dumb).
> 
> > 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 
> > Signed-off-by: Michael Roth 
> 
> A handful of small nits.
> 
> > ---
> >  hw/ppc/Makefile.objs|   2 +-
> >  hw/ppc/spapr_ovec.c | 244 
> > 
> >  include/hw/ppc/spapr_ovec.h |  62 +++
> >  3 files changed, 307 insertions(+), 1 deletion(-)
> >  create mode 100644 hw/ppc/spapr_ovec.c
> >  create mode 100644 include/hw/ppc/spapr_ovec.h
> > 
> > diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> > index 99a0d4e..2e0b0c9 100644
> > --- a/hw/ppc/Makefile.objs
> > +++ b/hw/ppc/Makefile.objs
> > @@ -4,7 +4,7 @@ obj-y += ppc.o ppc_booke.o fdt.o
> >  obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
> >  obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
> >  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
> > -obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
> > +obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o
> >  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
> >  obj-y += spapr_pci_vfio.o
> >  endif
> > diff --git a/hw/ppc/spapr_ovec.c b/hw/ppc/spapr_ovec.c
> > new file mode 100644
> > index 000..ddc19f5
> > --- /dev/null
> > +++ b/hw/ppc/spapr_ovec.c
> > @@ -0,0 +1,244 @@
> > +/*
> > + * QEMU SPAPR Architecture Option Vector Helper Functions
> > + *
> > + * Copyright IBM Corp. 2016
> > + *
> > + * Authors:
> > + *  Bharata B Rao 
> > + *  Michael Roth  
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or 
> > later.
> > + * See the COPYING file in the top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/ppc/spapr_ovec.h"
> > +#include "qemu/bitmap.h"
> > +#include "exec/address-spaces.h"
> > +#include "qemu/error-report.h"
> > +#include 
> > +
> > +/* #define DEBUG_SPAPR_OVEC */
> > +
> > +#ifdef DEBUG_SPAPR_OVEC
> > +#define DPRINTFN(fmt, ...) \
> > +do { fprintf(stderr, fmt "\n", ## __VA_ARGS__); } while (0)
> > +#else
> > +#define DPRINTFN(fmt, ...) \
> > +do { } while (0)
> > +#endif
> > +
> > +#define OV_MAXBYTES 256 /* not including length byte */
> > +#define OV_MAXBITS (OV_MAXBYTES * BITS_PER_BYTE)
> > +
> > +/* we *could* work with bitmaps directly, but handling the bitmap privately
> > + * allows us to more safely make assumptions about the bitmap size and
> > + * simplify the calling code somewhat
> > + */
> > +struct sPAPROptionVector {
> > +unsigned long *bitmap;
> > +};
> > +
> > +static sPAPROptionVector *spapr_ovec_from_bitmap(unsigned long *bitmap)
> > +{
> > +sPAPROptionVector *ov;
> > +
> > +g_assert(bitmap);
> > +
> > +ov = g_new0(sPAPROptionVector, 1);
> > +ov->bitmap = bitmap;
> > +
> > +return ov;
> > +}
> > +
> > +sPAPROptionVector *spapr_ovec_new(void)
> > +{
> > +return spapr_ovec_from_bitmap(bitmap_new(OV_MAXBITS));
> > +}
> > +
> > +sPAPROptionVector *spapr_ovec_clone(sPAPROptionVector *ov_orig)
> > +{
> > +sPAPROptionVector *ov;
> > +
> > +g_assert(ov_orig);
> > +
> > +ov = spapr_ovec_new();
> > +bitmap_copy(ov->bitmap, ov_orig->bitmap, OV_MAXBITS);
> > +
> > +return ov;
> > +}
> 

Re: [Qemu-devel] [PATCH 01/11] spapr_ovec: initial implementation of option vector helpers

2016-10-13 Thread David Gibson
On Wed, Oct 12, 2016 at 06:13:49PM -0500, Michael Roth wrote:
> 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.

Heh.. pity qemu doesn't use the ccan bitmap module
(http://ccodearchive.net/info/bitmap.html).  By design it always
stores the bitmaps in IBM bit number ordering, because that's most
obvious to a human reading a memory dump (for the purpose of bit
vectors - in most situations the IBM numbering is dumb).

> 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 
> Signed-off-by: Michael Roth 

A handful of small nits.

> ---
>  hw/ppc/Makefile.objs|   2 +-
>  hw/ppc/spapr_ovec.c | 244 
> 
>  include/hw/ppc/spapr_ovec.h |  62 +++
>  3 files changed, 307 insertions(+), 1 deletion(-)
>  create mode 100644 hw/ppc/spapr_ovec.c
>  create mode 100644 include/hw/ppc/spapr_ovec.h
> 
> diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
> index 99a0d4e..2e0b0c9 100644
> --- a/hw/ppc/Makefile.objs
> +++ b/hw/ppc/Makefile.objs
> @@ -4,7 +4,7 @@ obj-y += ppc.o ppc_booke.o fdt.o
>  obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
>  obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
>  obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
> -obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
> +obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o
>  ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
>  obj-y += spapr_pci_vfio.o
>  endif
> diff --git a/hw/ppc/spapr_ovec.c b/hw/ppc/spapr_ovec.c
> new file mode 100644
> index 000..ddc19f5
> --- /dev/null
> +++ b/hw/ppc/spapr_ovec.c
> @@ -0,0 +1,244 @@
> +/*
> + * QEMU SPAPR Architecture Option Vector Helper Functions
> + *
> + * Copyright IBM Corp. 2016
> + *
> + * Authors:
> + *  Bharata B Rao 
> + *  Michael Roth  
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "hw/ppc/spapr_ovec.h"
> +#include "qemu/bitmap.h"
> +#include "exec/address-spaces.h"
> +#include "qemu/error-report.h"
> +#include 
> +
> +/* #define DEBUG_SPAPR_OVEC */
> +
> +#ifdef DEBUG_SPAPR_OVEC
> +#define DPRINTFN(fmt, ...) \
> +do { fprintf(stderr, fmt "\n", ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTFN(fmt, ...) \
> +do { } while (0)
> +#endif
> +
> +#define OV_MAXBYTES 256 /* not including length byte */
> +#define OV_MAXBITS (OV_MAXBYTES * BITS_PER_BYTE)
> +
> +/* we *could* work with bitmaps directly, but handling the bitmap privately
> + * allows us to more safely make assumptions about the bitmap size and
> + * simplify the calling code somewhat
> + */
> +struct sPAPROptionVector {
> +unsigned long *bitmap;
> +};
> +
> +static sPAPROptionVector *spapr_ovec_from_bitmap(unsigned long *bitmap)
> +{
> +sPAPROptionVector *ov;
> +
> +g_assert(bitmap);
> +
> +ov = g_new0(sPAPROptionVector, 1);
> +ov->bitmap = bitmap;
> +
> +return ov;
> +}
> +
> +sPAPROptionVector *spapr_ovec_new(void)
> +{
> +return spapr_ovec_from_bitmap(bitmap_new(OV_MAXBITS));
> +}
> +
> +sPAPROptionVector *spapr_ovec_clone(sPAPROptionVector *ov_orig)
> +{
> +sPAPROptionVector *ov;
> +
> +g_assert(ov_orig);
> +
> +ov = spapr_ovec_new();
> +bitmap_copy(ov->bitmap, ov_orig->bitmap, OV_MAXBITS);
> +
> +return ov;
> +}
> +
> +void spapr_ovec_intersect(sPAPROptionVector *ov,
> +  sPAPROptionVector *ov1,
> +  sPAPROptionVector *ov2)
> +{
> +g_assert(ov);
> +g_assert(ov1);
> +g_assert(ov2);
> +
> +bitmap_and(ov->bitmap, ov1->bitmap, ov2->bitmap, OV_MAXBITS);
> +}
> +
> 

[Qemu-devel] [PATCH 01/11] spapr_ovec: initial implementation of option vector helpers

2016-10-12 Thread Michael Roth
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 
Signed-off-by: Michael Roth 
---
 hw/ppc/Makefile.objs|   2 +-
 hw/ppc/spapr_ovec.c | 244 
 include/hw/ppc/spapr_ovec.h |  62 +++
 3 files changed, 307 insertions(+), 1 deletion(-)
 create mode 100644 hw/ppc/spapr_ovec.c
 create mode 100644 include/hw/ppc/spapr_ovec.h

diff --git a/hw/ppc/Makefile.objs b/hw/ppc/Makefile.objs
index 99a0d4e..2e0b0c9 100644
--- a/hw/ppc/Makefile.objs
+++ b/hw/ppc/Makefile.objs
@@ -4,7 +4,7 @@ obj-y += ppc.o ppc_booke.o fdt.o
 obj-$(CONFIG_PSERIES) += spapr.o spapr_vio.o spapr_events.o
 obj-$(CONFIG_PSERIES) += spapr_hcall.o spapr_iommu.o spapr_rtas.o
 obj-$(CONFIG_PSERIES) += spapr_pci.o spapr_rtc.o spapr_drc.o spapr_rng.o
-obj-$(CONFIG_PSERIES) += spapr_cpu_core.o
+obj-$(CONFIG_PSERIES) += spapr_cpu_core.o spapr_ovec.o
 ifeq ($(CONFIG_PCI)$(CONFIG_PSERIES)$(CONFIG_LINUX), yyy)
 obj-y += spapr_pci_vfio.o
 endif
diff --git a/hw/ppc/spapr_ovec.c b/hw/ppc/spapr_ovec.c
new file mode 100644
index 000..ddc19f5
--- /dev/null
+++ b/hw/ppc/spapr_ovec.c
@@ -0,0 +1,244 @@
+/*
+ * QEMU SPAPR Architecture Option Vector Helper Functions
+ *
+ * Copyright IBM Corp. 2016
+ *
+ * Authors:
+ *  Bharata B Rao 
+ *  Michael Roth  
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/ppc/spapr_ovec.h"
+#include "qemu/bitmap.h"
+#include "exec/address-spaces.h"
+#include "qemu/error-report.h"
+#include 
+
+/* #define DEBUG_SPAPR_OVEC */
+
+#ifdef DEBUG_SPAPR_OVEC
+#define DPRINTFN(fmt, ...) \
+do { fprintf(stderr, fmt "\n", ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTFN(fmt, ...) \
+do { } while (0)
+#endif
+
+#define OV_MAXBYTES 256 /* not including length byte */
+#define OV_MAXBITS (OV_MAXBYTES * BITS_PER_BYTE)
+
+/* we *could* work with bitmaps directly, but handling the bitmap privately
+ * allows us to more safely make assumptions about the bitmap size and
+ * simplify the calling code somewhat
+ */
+struct sPAPROptionVector {
+unsigned long *bitmap;
+};
+
+static sPAPROptionVector *spapr_ovec_from_bitmap(unsigned long *bitmap)
+{
+sPAPROptionVector *ov;
+
+g_assert(bitmap);
+
+ov = g_new0(sPAPROptionVector, 1);
+ov->bitmap = bitmap;
+
+return ov;
+}
+
+sPAPROptionVector *spapr_ovec_new(void)
+{
+return spapr_ovec_from_bitmap(bitmap_new(OV_MAXBITS));
+}
+
+sPAPROptionVector *spapr_ovec_clone(sPAPROptionVector *ov_orig)
+{
+sPAPROptionVector *ov;
+
+g_assert(ov_orig);
+
+ov = spapr_ovec_new();
+bitmap_copy(ov->bitmap, ov_orig->bitmap, OV_MAXBITS);
+
+return ov;
+}
+
+void spapr_ovec_intersect(sPAPROptionVector *ov,
+  sPAPROptionVector *ov1,
+  sPAPROptionVector *ov2)
+{
+g_assert(ov);
+g_assert(ov1);
+g_assert(ov2);
+
+bitmap_and(ov->bitmap, ov1->bitmap, ov2->bitmap, OV_MAXBITS);
+}
+
+/* returns true if options bits were removed, false otherwise */
+bool spapr_ovec_diff(sPAPROptionVector *ov,
+ sPAPROptionVector *ov_old,
+ sPAPROptionVector *ov_new)
+{
+unsigned long *change_mask = bitmap_new(OV_MAXBITS);
+unsigned long *removed_bits = bitmap_new(OV_MAXBITS);
+bool bits_were_removed = false;
+
+g_assert(ov);
+g_assert(ov_old);
+g_assert(ov_new);
+
+bitmap_xor(change_mask, ov_old->bitmap, ov_new->bitmap, OV_MAXBITS);
+bitmap_and(ov->bitmap, ov_new->bitmap, change_mask, OV_MAXBITS);
+bitmap_and(removed_bits, ov_old->bitmap, change_mask, OV_MAXBITS);
+
+if