Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 13 July 2017 21:36
> To: Andrew Cooper 
> Cc: Juergen Gross ; sstabell...@kernel.org; Wei Liu
> ; xen-devel@lists.xen.org; julien.gr...@arm.com;
> Roger Pau Monne 
> Subject: Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement
> EVTCHNOP_send_imm as a companian to EVTCHNOP_send
> 
> >>> Andrew Cooper  07/13/17 9:50 AM >>>
> >RFC: is it worth converting the close, unmask, reset (and possibly
> >expand_array) as well?
> 
> I can't see close and even more so reset to be performance critical.
> Unmask otoh may be (depending on use); no sure about expand_array.
>

IIRC the unmask hypercall only needs to be made in certain circumstances when 
direct unmasking of the fifo structure might race (can't remember the detail 
offhand), but it still seems like a reasonable target for an immediate argument.

  Paul
 
> Jan
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

[Andrew Cooper]

On 13/07/17 07:42, Huang, Kai wrote:

On 7/12/2017 10:56 PM, Andrew Cooper wrote:

On 09/07/17 10:10, Kai Huang wrote:

Why do we need this hide_epc parameter?  If we aren't providing any 
epc resource to the guest, the entire sgx union should be zero and 
the SGX feature bit should be hidden.


My intention was to hide physical EPC info for pv_max_policy and 
hvm_max_policy (recalculate_sgx is also called by 
calculate_pv_max_policy and calculate_hvm_max_policy), as they are for 
guest and don't need physical EPC info. But keeping physical EPC info 
in them does no harm so I think we can simply remove hide_epc.


It is my experience that providing half the information is worse than 
providing none or all of it, because developers are notorious for taking 
shortcuts when looking for features.


Patch 1 means that a PV guest will never have p->feat.sgx set. 
Therefore, we will hit the memset() below, and zero the whole of the SGX 
union.




IMO we cannot check whether EPC is valid and zero sgx union in 
recalculate_sgx, as it is called for each CPUID. For example, it is 
called for SGX subleaf 0, and 1, and then 2, and when subleaf 0 and 1 
are called, the EPC resource is 0 (hasn't been configured).


recalculate_*() only get called when the toolstack makes updates to the 
policy.  It is an unfortunate side effect of the current implementation, 
but will be going away with my CPUID work.


The intended flow will be this:

At Xen boot:
* Calculates the raw, host and max policies (as we do today)

At domain create:
* Appropriate policy gets copied to make the default domain policy.
* Toolstack gets the whole policy at one with a new 
DOMCTL_get_cpuid_policy hypercall.
* Toolstack makes all adjustments (locally) that it wants to, based on 
configuration, etc.

* Toolstack makes a single DOMCTL_set_cpuid_policy hypercall.
* Xen audits the new policy proposed by the toolstack, resulting in a 
single yes/no decision.
** If not, the toolstack is told to try again.  This will likely result 
in xl asking the user to modify their .cfg file.

** If yes, the proposed policy becomes the actual policy.

This scheme will fix the current problem we have where the toolstack 
blindly proposes changes (one leaf at a time), and Xen has to zero the 
bits it doesn't like (because the toolstack has never traditionally 
checked the return value of the hypercall :( )








+
+/* Subleaf 2. */
+uint32_t base_valid:1, :11, base_pfn_low:20;
+uint32_t base_pfn_high:20, :12;
+uint32_t size_valid:1, :11, npages_low:20;
+uint32_t npages_high:20, :12;
+};


Are the {base,size}_valid fields correct?  The manual says the are 
4-bit fields rather than single bit fields.


They are 4 bits in SDM but actually currently only bit 1 is valid 
(other values are reserved). I think for now bool base_valid should be 
enough. We can extend when new values come out. What's your suggestion?


Ok.  That can work for now.





I would also drop the _pfn from the base names.  The fields still 
need shifting to get a sensible value.


OK. Will do.


As a further thought, what about uint64_t base:40 and size:40?  That 
would reduce the complexity of calculating the values.


~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 03/17] rbtree: empty nodes have no color

[Praveen Kumar]

From: Michel Lespinasse 

Empty nodes have no color.  We can make use of this property to simplify
the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE macros.  Also,
we can get rid of the rb_init_node function which had been introduced by
commit 88d19cf37952 ("timers: Add rb_init_node() to allow for stack
allocated rb nodes") to avoid some issue with the empty node's color not
being initialized.

I'm not sure what the RB_EMPTY_NODE checks in rb_prev() / rb_next() are
doing there, though.  axboe introduced them in commit 10fd48f2376d
("rbtree: fixed reversed RB_EMPTY_NODE and rb_next/prev").  The way I
see it, the 'empty node' abstraction is only used by rbtree users to
flag nodes that they haven't inserted in any rbtree, so asking the
predecessor or successor of such nodes doesn't make any sense.

One final rb_init_node() caller was recently added in sysctl code to
implement faster sysctl name lookups.  This code doesn't make use of
RB_EMPTY_NODE at all, and from what I could see it only called
rb_init_node() under the mistaken assumption that such initialization was
required before node insertion.

[s...@canb.auug.org.au: fix net/ceph/osd_client.c build]
Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Cc: John Stultz 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 4c199a93a2d36b277a9fd209a0f2793f8460a215]

Ported rbtree.h and rbtree.c changes which are relevant to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c  | 4 ++--
 xen/include/xen/rbtree.h | 8 +---
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index acfd34a62d..ce69000879 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -317,7 +317,7 @@ struct rb_node *rb_next(const struct rb_node *node)
 {
struct rb_node *parent;
 
-   if (rb_parent(node) == node)
+   if (RB_EMPTY_NODE(node))
return NULL;
 
/* If we have a right-hand child, go down and then left as far
@@ -346,7 +346,7 @@ struct rb_node *rb_prev(const struct rb_node *node)
 {
struct rb_node *parent;
 
-   if (rb_parent(node) == node)
+   if (RB_EMPTY_NODE(node))
return NULL;
 
/* If we have a left-hand child, go down and then right as far
diff --git a/xen/include/xen/rbtree.h b/xen/include/xen/rbtree.h
index 9496f099f8..e947e3800f 100644
--- a/xen/include/xen/rbtree.h
+++ b/xen/include/xen/rbtree.h
@@ -128,9 +128,11 @@ static inline void rb_set_color(struct rb_node *rb, int 
color)
 #define RB_ROOT(struct rb_root) { NULL, }
 #definerb_entry(ptr, type, member) container_of(ptr, type, member)
 
-#define RB_EMPTY_ROOT(root)((root)->rb_node == NULL)
-#define RB_EMPTY_NODE(node)(rb_parent(node) == node)
-#define RB_CLEAR_NODE(node)(rb_set_parent(node, node))
+#define RB_EMPTY_ROOT(root)  ((root)->rb_node == NULL)
+
+/* 'empty' nodes are nodes that are known not to be inserted in an rbree */
+#define RB_EMPTY_NODE(node)  ((node)->rb_parent_color == (unsigned long)(node))
+#define RB_CLEAR_NODE(node)  ((node)->rb_parent_color = (unsigned long)(node))
 
 extern void rb_insert_color(struct rb_node *, struct rb_root *);
 extern void rb_erase(struct rb_node *, struct rb_root *);
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Praveen Kumar]

The patch aligns the coding style of rbtree related files to Linux coding
conventions to have limited conflicts in future while porting from Linux tree.

This patch includes only the style changes.

Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c
Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c  | 633 ---
 xen/include/xen/rbtree.h | 116 +++--
 2 files changed, 413 insertions(+), 336 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index d91d651d77..167ebfdc4d 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -14,7 +14,8 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; If not, see .
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
   linux/lib/rbtree.c
 */
@@ -24,261 +25,261 @@
 
 static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *right = node->rb_right;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_right = right->rb_left))
-rb_set_parent(right->rb_left, node);
-right->rb_left = node;
-
-rb_set_parent(right, parent);
-
-if (parent)
-{
-if (node == parent->rb_left)
-parent->rb_left = right;
-else
-parent->rb_right = right;
-}
-else
-root->rb_node = right;
-rb_set_parent(node, right);
+   struct rb_node *right = node->rb_right;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_right = right->rb_left))
+   rb_set_parent(right->rb_left, node);
+   right->rb_left = node;
+
+   rb_set_parent(right, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_left)
+   parent->rb_left = right;
+   else
+   parent->rb_right = right;
+   }
+   else
+   root->rb_node = right;
+   rb_set_parent(node, right);
 }
 
 static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *left = node->rb_left;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_left = left->rb_right))
-rb_set_parent(left->rb_right, node);
-left->rb_right = node;
-
-rb_set_parent(left, parent);
-
-if (parent)
-{
-if (node == parent->rb_right)
-parent->rb_right = left;
-else
-parent->rb_left = left;
-}
-else
-root->rb_node = left;
-rb_set_parent(node, left);
+   struct rb_node *left = node->rb_left;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_left = left->rb_right))
+   rb_set_parent(left->rb_right, node);
+   left->rb_right = node;
+
+   rb_set_parent(left, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_right)
+   parent->rb_right = left;
+   else
+   parent->rb_left = left;
+   }
+   else
+   root->rb_node = left;
+   rb_set_parent(node, left);
 }
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *parent, *gparent;
-
-while ((parent = rb_parent(node)) && rb_is_red(parent))
-{
-gparent = rb_parent(parent);
-
-if (parent == gparent->rb_left)
-{
-{
-register struct rb_node *uncle = gparent->rb_right;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_right == node)
-{
-register struct rb_node *tmp;
-__rb_rotate_left(parent, root);
-tmp = parent;
-parent = node;
-node = tmp;
-}
-
-rb_set_black(parent);
-rb_set_red(gparent);
-__rb_rotate_right(gparent, root);
-} else {
-{
-register struct rb_node *uncle = gparent->rb_left;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_left == node)
-{
-register struct rb_node *tmp;
-__rb_rotate_right(parent, root);
-tmp = parent;
-parent = node

[Xen-devel] [PATCH v5 06/17] rbtree: adjust root color in rb_insert_color() only when necessary

[Praveen Kumar]

From: Michel Lespinasse 

The root node of an rbtree must always be black.  However,
rb_insert_color() only needs to maintain this invariant when it has been
broken - that is, when it exits the loop due to the current (red) node
being the root.  In all other cases (exiting after tree rotations, or
exiting due to an existing black parent) the invariant is already
satisfied, so there is no need to adjust the root node color.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 6d58452dc066db61acdff7b84671db1b11a3de1c]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 1e74ec0f65..16a1a97193 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -91,8 +91,21 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 {
struct rb_node *parent, *gparent;
 
-   while ((parent = rb_parent(node)) && rb_is_red(parent))
-   {
+   while (true) {
+   /*
+* Loop invariant: node is red
+*
+* If there is a black parent, we are done.
+* Otherwise, take some corrective action as we don't
+* want a red root or two consecutive red nodes.
+*/
+   parent = rb_parent(node);
+   if (!parent) {
+   rb_set_black(node);
+   break;
+   } else if (rb_is_black(parent))
+   break;
+
gparent = rb_parent(parent);
 
if (parent == gparent->rb_left)
@@ -142,8 +155,6 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
break;
}
}
-
-   rb_set_black(root->rb_node);
 }
 EXPORT_SYMBOL(rb_insert_color);
 
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 09/17] rbtree: optimize case selection logic in __rb_erase_color()

[Praveen Kumar]

From: Michel Lespinasse 

In __rb_erase_color(), we have to select one of 3 cases depending on the
color on the 'other' node children.  If both children are black, we flip a
few node colors and iterate.  Otherwise, we do either one or two tree
rotations, depending on the color of the 'other' child opposite to 'node',
and then we are done.

The corresponding logic had duplicate checks for the color of the 'other'
child opposite to 'node'.  It was checking it first to determine if both
children are black, and then to determine how many tree rotations are
required.  Rearrange the logic to avoid that extra check.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit e125d1471a4f8f1bf7ea9a83deb8d23cb40bd712]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 68 +++--
 1 file changed, 30 insertions(+), 38 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 249035c923..a6491e5610 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -283,28 +283,24 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
__rb_rotate_left(parent, root);
other = parent->rb_right;
}
-   if ((!other->rb_left || rb_is_black(other->rb_left)) &&
-   (!other->rb_right || rb_is_black(other->rb_right)))
-   {
-   rb_set_red(other);
-   node = parent;
-   parent = rb_parent(node);
-   }
-   else
-   {
-   if (!other->rb_right || 
rb_is_black(other->rb_right))
-   {
-   rb_set_black(other->rb_left);
+   if (!other->rb_right || rb_is_black(other->rb_right)) {
+   if (!other->rb_left ||
+   rb_is_black(other->rb_left)) {
rb_set_red(other);
-   __rb_rotate_right(other, root);
-   other = parent->rb_right;
+   node = parent;
+   parent = rb_parent(node);
+   continue;
}
-   rb_set_color(other, rb_color(parent));
-   rb_set_black(parent);
-   rb_set_black(other->rb_right);
-   __rb_rotate_left(parent, root);
-   break;
+   rb_set_black(other->rb_left);
+   rb_set_red(other);
+   __rb_rotate_right(other, root);
+   other = parent->rb_right;
}
+   rb_set_color(other, rb_color(parent));
+   rb_set_black(parent);
+   rb_set_black(other->rb_right);
+   __rb_rotate_left(parent, root);
+   break;
} else {
other = parent->rb_left;
if (rb_is_red(other))
@@ -314,28 +310,24 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
__rb_rotate_right(parent, root);
other = parent->rb_left;
}
-   if ((!other->rb_left || rb_is_black(other->rb_left)) &&
-   (!other->rb_right || rb_is_black(other->rb_right)))
-   {
-   rb_set_red(other);
-   node = parent;
-   parent = rb_parent(node);
-   }
-   else
-   {
-   if (!other->rb_left || 
rb_is_black(other->rb_left))
-   {
-   rb_set_black(other->rb_right);
+   if (!other->rb_left || rb_is_black(other->rb_left)) {
+   if (!other->rb_right ||
+   rb_is_black(other->rb_right)) {
rb_set_red(other);
-   __rb_rotate_left(other, root);
-   other = parent->rb_left;
+   node = parent;
+   parent = rb_parent(

[Xen-devel] [PATCH v5 00/17] xen: common: rbtree: ported updates from Linux tree

[Praveen Kumar]

Hi All,

The patch imports the changes and updates of the rbtree implementaiton
from Linux tree. But since, the only current implementation is with tmem.c,
which am not much aware off much and therefore, was unable to test the changes
thoroughly. Having said that, I do have plans of adding futher code changes
which will be using rb-tree more in credit2 scheduler and that will help in
further testing the same.

I have not imported augmented, rcu and patches which added new rbtree
functionality, as there was no specific requirement for current planned
implementation.

Below are the categorized Linux commit versions which are not imported :

Augmented rbtree :
14b94af0b251a2c80885b60538166fb7d04a642e
9d9e6f9703bbd642f3f2f807e6aaa642a4cbcec9
9c079add0d0f45220f4bb37febf0621137ec2d38
3cb7a56344ca45ee56d71c5f8fe9f922306bff1f
f231aebfc4cae2f6ed27a46a31e2630909513d77

Add postorder iteration functions:
9dee5c51516d2c3fff22633c1272c5652e68075a

RCU related implementation :
d72da4a4d973d8a0a0d3c97e7cdebf287fbe3a99
c1adf20052d80f776849fa2c1acb472cdeb7786c
ce093a04543c403d52c1a5788d8cb92e47453aba

Please share your inputs. Thanks in advance.

Regards,

~Praveen.

Praveen Kumar (17):
  rbtree: changes to align the coding conventions with Linux tree
  rbtree: remove redundant if()-condition in rb_erase()
  rbtree: empty nodes have no color
  rbtree: move some implementation details from rbtree.h to rbtree.c
  rbtree: break out of rb_insert_color loop after tree rotation
  rbtree: adjust root color in rb_insert_color() only when necessary
  rbtree: low level optimizations in rb_insert_color()
  rbtree: adjust node color in __rb_erase_color() only when necessary
  rbtree: optimize case selection logic in __rb_erase_color()
  rbtree: low level optimizations in __rb_erase_color()
  rbtree: coding style adjustments
  rbtree: optimize fetching of sibling node
  rbtree: add __rb_change_child() helper function
  rbtree: place easiest case first in rb_erase()
  rbtree: handle 1-child recoloring in rb_erase() instead of
rb_erase_color()
  rbtree: low level optimizations in rb_erase()
  rbtree: fix typo in comment of rb_insert_color

 xen/common/rbtree.c  | 829 +--
 xen/include/xen/rbtree.h | 132 ++--
 2 files changed, 605 insertions(+), 356 deletions(-)

-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 04/17] rbtree: move some implementation details from rbtree.h to rbtree.c

[Praveen Kumar]

From: Michel Lespinasse 

rbtree users must use the documented APIs to manipulate the tree
structure.  Low-level helpers to manipulate node colors and parenthood are
not part of that API, so move them to lib/rbtree.c

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit bf7ad8eeab995710c766df49c9c69a8592ca0216]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c  | 20 +++-
 xen/include/xen/rbtree.h | 34 +-
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index ce69000879..ecebd2746c 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -23,6 +23,24 @@
 #include 
 #include 
 
+#defineRB_RED  0
+#defineRB_BLACK1
+
+#define rb_color(r)   ((r)->__rb_parent_color & 1)
+#define rb_is_red(r)   (!rb_color(r))
+#define rb_is_black(r) rb_color(r)
+#define rb_set_red(r)  do { (r)->__rb_parent_color &= ~1; } while (0)
+#define rb_set_black(r)  do { (r)->__rb_parent_color |= 1; } while (0)
+
+static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
+{
+   rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
+}
+static inline void rb_set_color(struct rb_node *rb, int color)
+{
+   rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
+}
+
 static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
 {
struct rb_node *right = node->rb_right;
@@ -255,7 +273,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
rb_set_parent(old->rb_right, node);
}
 
-   node->rb_parent_color = old->rb_parent_color;
+   node->__rb_parent_color = old->__rb_parent_color;
node->rb_left = old->rb_left;
 
rb_set_parent(old->rb_left, node);
diff --git a/xen/include/xen/rbtree.h b/xen/include/xen/rbtree.h
index e947e3800f..1b72590e4e 100644
--- a/xen/include/xen/rbtree.h
+++ b/xen/include/xen/rbtree.h
@@ -94,36 +94,18 @@ static inline struct page * rb_insert_page_cache(struct 
inode * inode,
 #ifndef __RBTREE_H__
 #define __RBTREE_H__
 
-struct rb_node
-{
-   unsigned long  rb_parent_color;
-#defineRB_RED  0
-#defineRB_BLACK1
+struct rb_node {
+   unsigned long  __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
 } __attribute__((aligned(sizeof(long;
 /* The alignment might seem pointless, but allegedly CRIS needs it */
 
-struct rb_root
-{
+struct rb_root {
struct rb_node *rb_node;
 };
 
-#define rb_parent(r)   ((struct rb_node *)((r)->rb_parent_color & ~3))
-#define rb_color(r)   ((r)->rb_parent_color & 1)
-#define rb_is_red(r)   (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
-#define rb_set_red(r)  do { (r)->rb_parent_color &= ~1; } while (0)
-#define rb_set_black(r)  do { (r)->rb_parent_color |= 1; } while (0)
-
-static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
-{
-   rb->rb_parent_color = (rb->rb_parent_color & 3) | (unsigned long)p;
-}
-static inline void rb_set_color(struct rb_node *rb, int color)
-{
-   rb->rb_parent_color = (rb->rb_parent_color & ~1) | color;
-}
+#define rb_parent(r)   ((struct rb_node *)((r)->__rb_parent_color & ~3))
 
 #define RB_ROOT(struct rb_root) { NULL, }
 #definerb_entry(ptr, type, member) container_of(ptr, type, member)
@@ -131,8 +113,10 @@ static inline void rb_set_color(struct rb_node *rb, int 
color)
 #define RB_EMPTY_ROOT(root)  ((root)->rb_node == NULL)
 
 /* 'empty' nodes are nodes that are known not to be inserted in an rbree */
-#define RB_EMPTY_NODE(node)  ((node)->rb_parent_color == (unsigned long)(node))
-#define RB_CLEAR_NODE(node)  ((node)->rb_parent_color = (unsigned long)(node))
+#define RB_EMPTY_NODE(node)  \
+   ((node)->__rb_parent_color == (unsigned long)(node))
+#define RB_CLEAR_NODE(node)  \
+   ((node)->__rb_parent_color = (unsigned long)(node))
 
 extern void rb_insert_color(struct rb_node *, struct rb_root *);
 extern void rb_erase(struct rb_node *, struct rb_root *);
@@ -150,7 +134,7 @@ extern void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
 static inline void rb_link_node(struct rb_node * node, struct rb_node * parent,
struct rb_node ** rb_link)
 {
-   node->rb_parent_color = (unsigned long )parent;
+   node->__rb_parent_color = (unsigned long )parent;
node->rb_left = node->rb_right = NULL;
 
*rb_link = node;
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 12/17] rbtree: optimize fetching of sibling node

[Praveen Kumar]

From: Michel Lespinasse 

When looking to fetch a node's sibling, we went through a sequence of:
- check if node is the parent's left child
- if it is, then fetch the parent's right child

This can be replaced with:
- fetch the parent's right child as an assumed sibling
- check that node is NOT the fetched child

This avoids fetching the parent's left child when node is actually
that child. Saves a bit on code size, though it doesn't seem to make
a large difference in speed.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Acked-by: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 59633abf34e2f44b8e772a2c12a92132aa7c2220]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 215d4f3613..d8f1194e20 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -107,8 +107,8 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 
gparent = rb_red_parent(parent);
 
-   if (parent == gparent->rb_left) {
-   tmp = gparent->rb_right;
+   tmp = gparent->rb_right;
+   if (parent != tmp) {/* parent == gparent->rb_left */
if (tmp && rb_is_red(tmp)) {
/*
 * Case 1 - color flips
@@ -131,7 +131,8 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
continue;
}
 
-   if (parent->rb_right == node) {
+   tmp = parent->rb_right;
+   if (node == tmp) {
/*
 * Case 2 - left rotate at parent
 *
@@ -151,6 +152,7 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
RB_BLACK);
rb_set_parent_color(parent, node, RB_RED);
parent = node;
+   tmp = node->rb_right;
}
 
/*
@@ -162,7 +164,7 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 * / \
 *n   U
 */
-   gparent->rb_left = tmp = parent->rb_right;
+   gparent->rb_left = tmp;  /* == parent->rb_right */
parent->rb_right = gparent;
if (tmp)
rb_set_parent_color(tmp, gparent, RB_BLACK);
@@ -180,7 +182,8 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
continue;
}
 
-   if (parent->rb_left == node) {
+   tmp = parent->rb_left;
+   if (node == tmp) {
/* Case 2 - right rotate at parent */
parent->rb_left = tmp = node->rb_right;
node->rb_right = parent;
@@ -189,10 +192,11 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
RB_BLACK);
rb_set_parent_color(parent, node, RB_RED);
parent = node;
+   tmp = node->rb_left;
}
 
/* Case 3 - left rotate at gparent */
-   gparent->rb_right = tmp = parent->rb_left;
+   gparent->rb_right = tmp;  /* == parent->rb_left */
parent->rb_left = gparent;
if (tmp)
rb_set_parent_color(tmp, gparent, RB_BLACK);
@@ -223,8 +227,9 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
break;
} else if (!parent) {
break;
-   } else if (parent->rb_left == node) {
-   sibling = parent->rb_right;
+   }
+   sibling = parent->rb_right;
+   if (node != sibling) {  /* node == parent->rb_left */
if (rb_is_red(sibling)) {
/*
 * Case 1 - left rotate at parent
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 10/17] rbtree: low level optimizations in __rb_erase_color()

[Praveen Kumar]

From: Michel Lespinasse 

In __rb_erase_color(), we often already have pointers to the nodes being
rotated and/or know what their colors must be, so we can generate more
efficient code than the generic __rb_rotate_left() and __rb_rotate_right()
functions.

Also when the current node is red or when flipping the sibling's color,
the parent is already known so we can use the more efficient
rb_set_parent_color() function to set the desired color.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 6280d2356fd8ad0936a63c10dc1e6accf48d0c61]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 208 +---
 1 file changed, 115 insertions(+), 93 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index a6491e5610..e58336bd26 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -39,7 +39,8 @@
  *  5), then the longest possible path due to 4 is 2B.
  *
  *  We shall indicate color with case, where black nodes are uppercase and red
- *  nodes will be lowercase.
+ *  nodes will be lowercase. Unknown color nodes shall be drawn as red within
+ *  parentheses and have some accompanying text comment.
  */
 
 #defineRB_RED  0
@@ -48,17 +49,11 @@
 #define rb_color(r)   ((r)->__rb_parent_color & 1)
 #define rb_is_red(r)   (!rb_color(r))
 #define rb_is_black(r) rb_color(r)
-#define rb_set_red(r)  do { (r)->__rb_parent_color &= ~1; } while (0)
-#define rb_set_black(r)  do { (r)->__rb_parent_color |= 1; } while (0)
 
 static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
 {
rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
 }
-static inline void rb_set_color(struct rb_node *rb, int color)
-{
-   rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
-}
 
 static inline void rb_set_parent_color(struct rb_node *rb,
  struct rb_node *p, int color)
@@ -71,52 +66,6 @@ static inline struct rb_node *rb_red_parent(struct rb_node 
*red)
return (struct rb_node *)red->__rb_parent_color;
 }
 
-static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
-{
-   struct rb_node *right = node->rb_right;
-   struct rb_node *parent = rb_parent(node);
-
-   if ((node->rb_right = right->rb_left))
-   rb_set_parent(right->rb_left, node);
-   right->rb_left = node;
-
-   rb_set_parent(right, parent);
-
-   if (parent)
-   {
-   if (node == parent->rb_left)
-   parent->rb_left = right;
-   else
-   parent->rb_right = right;
-   }
-   else
-   root->rb_node = right;
-   rb_set_parent(node, right);
-}
-
-static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
-{
-   struct rb_node *left = node->rb_left;
-   struct rb_node *parent = rb_parent(node);
-
-   if ((node->rb_left = left->rb_right))
-   rb_set_parent(left->rb_right, node);
-   left->rb_right = node;
-
-   rb_set_parent(left, parent);
-
-   if (parent)
-   {
-   if (node == parent->rb_right)
-   parent->rb_right = left;
-   else
-   parent->rb_left = left;
-   }
-   else
-   root->rb_node = left;
-   rb_set_parent(node, left);
-}
-
 /*
  * Helper function for rotations:
  * - old's parent and color get assigned to new
@@ -257,7 +206,7 @@ EXPORT_SYMBOL(rb_insert_color);
 static void __rb_erase_color(struct rb_node *node, struct rb_node *parent,
 struct rb_root *root)
 {
-   struct rb_node *other;
+   struct rb_node *sibling, *tmp1, *tmp2;
 
while (true) {
/*
@@ -270,63 +219,136 @@ static void __rb_erase_color(struct rb_node *node, 
struct rb_node *parent,
 * and tree rotations as per one of the 4 cases below.
 */
if (node && rb_is_red(node)) {
-   rb_set_black(node);
+   rb_set_parent_color(node, parent, RB_BLACK);
break;
} else if (!parent) {
break;
} else if (parent->rb_left == node) {
-   other = parent->rb_right;
-   if (rb_is_red(other))
-   {
-   rb_set_black(other);
-   rb_set_red(parent);
-   __rb_rotate_left(parent, root);
-   other = parent->rb_right;
+   sibling = parent->rb_right;
+   if (rb_is_red(sibling)) {
+   /*
+  

[Xen-devel] [PATCH v5 02/17] rbtree: remove redundant if()-condition in rb_erase()

[Praveen Kumar]

From: Wolfram Strepp 

Furthermore, notice that the initial checks:

if (!node->rb_left)
child = node->rb_right;
else if (!node->rb_right)
child = node->rb_left;
else
{
...
}
guarantee that old->rb_right is set in the final else branch, therefore
we can omit checking that again.

Signed-off-by: Wolfram Strepp 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 4b324126e0c6c3a5080ca3ec0981e8766ed6f1ee]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 167ebfdc4d..acfd34a62d 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -250,15 +250,16 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
if (child)
rb_set_parent(child, parent);
parent->rb_left = child;
+
+   node->rb_right = old->rb_right;
+   rb_set_parent(old->rb_right, node);
}
 
node->rb_parent_color = old->rb_parent_color;
-   node->rb_right = old->rb_right;
node->rb_left = old->rb_left;
 
rb_set_parent(old->rb_left, node);
-   if (old->rb_right)
-   rb_set_parent(old->rb_right, node);
+
goto color;
}
 
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 07/17] rbtree: low level optimizations in rb_insert_color()

[Praveen Kumar]

From: Michel Lespinasse 

- Use the newly introduced rb_set_parent_color() function to flip the color
  of nodes whose parent is already known.
- Optimize rb_parent() when the node is known to be red - there is no need
  to mask out the color in that case.
- Flipping gparent's color to red requires us to fetch its rb_parent_color
  field, so we can reuse it as the parent value for the next loop iteration.
- Do not use __rb_rotate_left() and __rb_rotate_right() to handle tree
  rotations: we already have pointers to all relevant nodes, and know their
  colors (either because we want to adjust it, or because we've tested it,
  or we can deduce it as black due to the node proximity to a known red node).
  So we can generate more efficient code by making use of the node pointers
  we already have, and setting both the parent and color attributes for
  nodes all at once. Also in Case 2, some node attributes don't have to
  be set because we know another tree rotation (Case 3) will always follow
  and override them.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 5bc9188aa207dafd47eab57df7c4fe5b3d3f636a]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 166 +---
 1 file changed, 131 insertions(+), 35 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 16a1a97193..c3a8575ec0 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -23,6 +23,25 @@
 #include 
 #include 
 
+/*
+ * red-black trees properties:  http://en.wikipedia.org/wiki/Rbtree
+ *
+ *  1) A node is either red or black
+ *  2) The root is black
+ *  3) All leaves (NULL) are black
+ *  4) Both children of every red node are black
+ *  5) Every simple path from root to leaves contains the same number
+ * of black nodes.
+ *
+ *  4 and 5 give the O(log n) guarantee, since 4 implies you cannot have two
+ *  consecutive red nodes in a path and every red node is therefore followed by
+ *  a black. So if B is the number of black nodes on every simple path (as per
+ *  5), then the longest possible path due to 4 is 2B.
+ *
+ *  We shall indicate color with case, where black nodes are uppercase and red
+ *  nodes will be lowercase.
+ */
+
 #defineRB_RED  0
 #defineRB_BLACK1
 
@@ -41,6 +60,17 @@ static inline void rb_set_color(struct rb_node *rb, int 
color)
rb->__rb_parent_color = (rb->__rb_parent_color & ~1) | color;
 }
 
+static inline void rb_set_parent_color(struct rb_node *rb,
+ struct rb_node *p, int color)
+{
+   rb->__rb_parent_color = (unsigned long)p | color;
+}
+
+static inline struct rb_node *rb_red_parent(struct rb_node *red)
+{
+   return (struct rb_node *)red->__rb_parent_color;
+}
+
 static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
 {
struct rb_node *right = node->rb_right;
@@ -87,9 +117,30 @@ static void __rb_rotate_right(struct rb_node *node, struct 
rb_root *root)
rb_set_parent(node, left);
 }
 
+/*
+ * Helper function for rotations:
+ * - old's parent and color get assigned to new
+ * - old gets assigned new as a parent and 'color' as a color.
+ */
+static inline void
+__rb_rotate_set_parents(struct rb_node *old, struct rb_node *new,
+   struct rb_root *root, int color)
+{
+   struct rb_node *parent = rb_parent(old);
+   new->__rb_parent_color = old->__rb_parent_color;
+   rb_set_parent_color(old, new, color);
+   if (parent) {
+   if (parent->rb_left == old)
+   parent->rb_left = new;
+   else
+   parent->rb_right = new;
+   } else
+   root->rb_node = new;
+}
+
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
 {
-   struct rb_node *parent, *gparent;
+   struct rb_node *parent = rb_red_parent(node), *gparent, *tmp;
 
while (true) {
/*
@@ -99,59 +150,104 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 * Otherwise, take some corrective action as we don't
 * want a red root or two consecutive red nodes.
 */
-   parent = rb_parent(node);
if (!parent) {
-   rb_set_black(node);
+   rb_set_parent_color(node, NULL, RB_BLACK);
break;
} else if (rb_is_black(parent))
break;
 
-   gparent = rb_parent(parent);
-
-   if (parent == gparent->rb_left)
-   {
-   {
-   register struct rb_node *uncle = 
gparent->rb_right;
-   if (uncle && rb_is

[Xen-devel] [PATCH v5 13/17] rbtree: add __rb_change_child() helper function

[Praveen Kumar]

From: Michel Lespinasse 

Add __rb_change_child() as an inline helper function to replace code that
would otherwise be duplicated 4 times in the source.

No changes to binary size or speed.

Signed-off-by: Michel Lespinasse 
Reviewed-by: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 7abc704ae399fcb9c51ca200b0456f8a975a8011]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 46 +-
 1 file changed, 17 insertions(+), 29 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index d8f1194e20..9182544417 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -66,6 +66,19 @@ static inline struct rb_node *rb_red_parent(struct rb_node 
*red)
return (struct rb_node *)red->__rb_parent_color;
 }
 
+static inline void
+__rb_change_child(struct rb_node *old, struct rb_node *new,
+ struct rb_node *parent, struct rb_root *root)
+{
+   if (parent) {
+   if (parent->rb_left == old)
+   parent->rb_left = new;
+   else
+   parent->rb_right = new;
+   } else
+   root->rb_node = new;
+}
+
 /*
  * Helper function for rotations:
  * - old's parent and color get assigned to new
@@ -78,13 +91,7 @@ __rb_rotate_set_parents(struct rb_node *old, struct rb_node 
*new,
struct rb_node *parent = rb_parent(old);
new->__rb_parent_color = old->__rb_parent_color;
rb_set_parent_color(old, new, color);
-   if (parent) {
-   if (parent->rb_left == old)
-   parent->rb_left = new;
-   else
-   parent->rb_right = new;
-   } else
-   root->rb_node = new;
+   __rb_change_child(old, new, parent, root);
 }
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
@@ -375,13 +382,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
while ((left = node->rb_left) != NULL)
node = left;
 
-   if (rb_parent(old)) {
-   if (rb_parent(old)->rb_left == old)
-   rb_parent(old)->rb_left = node;
-   else
-   rb_parent(old)->rb_right = node;
-   } else
-   root->rb_node = node;
+   __rb_change_child(old, node, rb_parent(old), root);
 
child = node->rb_right;
parent = rb_parent(node);
@@ -411,13 +412,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 
if (child)
rb_set_parent(child, parent);
-   if (parent) {
-   if (parent->rb_left == node)
-   parent->rb_left = child;
-   else
-   parent->rb_right = child;
-   } else
-   root->rb_node = child;
+   __rb_change_child(node, child, parent, root);
 
 color:
if (color == RB_BLACK)
@@ -521,14 +516,7 @@ void rb_replace_node(struct rb_node *victim, struct 
rb_node *new,
struct rb_node *parent = rb_parent(victim);
 
/* Set the surrounding nodes to point to the replacement */
-   if (parent) {
-   if (victim == parent->rb_left)
-   parent->rb_left = new;
-   else
-   parent->rb_right = new;
-   } else {
-   root->rb_node = new;
-   }
+   __rb_change_child(victim, new, parent, root);
if (victim->rb_left)
rb_set_parent(victim->rb_left, new);
if (victim->rb_right)
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 08/17] rbtree: adjust node color in __rb_erase_color() only when necessary

[Praveen Kumar]

From: Michel Lespinasse 

In __rb_erase_color(), we were always setting a node to black after
exiting the main loop.  And in one case, after fixing up the tree to
satisfy all rbtree invariants, we were setting the current node to root
just to guarantee a loop exit, at which point the root would be set to
black.  However this is not necessary, as the root of an rbtree is already
known to be black.  The only case where the color flip is required is when
we exit the loop due to the current node being red, and it's easiest to
just do the flip at that point instead of doing it after the loop.

[adrian.hun...@intel.com: perf tools: fix build for another rbtree.c change]
Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Adrian Hunter 
Cc: Alexander Shishkin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit d6ff1273928ebf15466a85b7e1810cd00e72998b]

Ported only rbtree.c to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index c3a8575ec0..249035c923 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -259,10 +259,22 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
 {
struct rb_node *other;
 
-   while ((!node || rb_is_black(node)) && node != root->rb_node)
-   {
-   if (parent->rb_left == node)
-   {
+   while (true) {
+   /*
+* Loop invariant: all leaf paths going through node have a
+* black node count that is 1 lower than other leaf paths.
+*
+* If node is red, we can flip it to black to adjust.
+* If node is the root, all leaf paths go through it.
+* Otherwise, we need to adjust the tree through color flips
+* and tree rotations as per one of the 4 cases below.
+*/
+   if (node && rb_is_red(node)) {
+   rb_set_black(node);
+   break;
+   } else if (!parent) {
+   break;
+   } else if (parent->rb_left == node) {
other = parent->rb_right;
if (rb_is_red(other))
{
@@ -291,12 +303,9 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
rb_set_black(parent);
rb_set_black(other->rb_right);
__rb_rotate_left(parent, root);
-   node = root->rb_node;
break;
}
-   }
-   else
-   {
+   } else {
other = parent->rb_left;
if (rb_is_red(other))
{
@@ -325,13 +334,10 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
rb_set_black(parent);
rb_set_black(other->rb_left);
__rb_rotate_right(parent, root);
-   node = root->rb_node;
break;
}
}
}
-   if (node)
-   rb_set_black(node);
 }
 
 void rb_erase(struct rb_node *node, struct rb_root *root)
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 05/17] rbtree: break out of rb_insert_color loop after tree rotation

[Praveen Kumar]

From: Michel Lespinasse 

It is a well known property of rbtrees that insertion never requires more
than two tree rotations.  In our implementation, after one loop iteration
identified one or two necessary tree rotations, we would iterate and look
for more.  However at that point the node's parent would always be black,
which would cause us to exit the loop.

We can make the code flow more obvious by just adding a break statement
after the tree rotations, where we know we are done.  Additionally, in the
cases where two tree rotations are necessary, we don't have to update the
'node' pointer as it wouldn't be used until the next loop iteration, which
we now avoid due to this break statement.

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 1f0528653e41ec230c60f5738820e8a544731399]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index ecebd2746c..1e74ec0f65 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -109,18 +109,15 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
}
}
 
-   if (parent->rb_right == node)
-   {
-   register struct rb_node *tmp;
+   if (parent->rb_right == node) {
__rb_rotate_left(parent, root);
-   tmp = parent;
parent = node;
-   node = tmp;
}
 
rb_set_black(parent);
rb_set_red(gparent);
__rb_rotate_right(gparent, root);
+   break;
} else {
{
register struct rb_node *uncle = 
gparent->rb_left;
@@ -134,18 +131,15 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
}
}
 
-   if (parent->rb_left == node)
-   {
-   register struct rb_node *tmp;
+   if (parent->rb_left == node) {
__rb_rotate_right(parent, root);
-   tmp = parent;
parent = node;
-   node = tmp;
}
 
rb_set_black(parent);
rb_set_red(gparent);
__rb_rotate_left(gparent, root);
+   break;
}
}
 
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 16/17] rbtree: low level optimizations in rb_erase()

[Praveen Kumar]

From: Michel Lespinasse 

Various minor optimizations in rb_erase():
- Avoid multiple loading of node->__rb_parent_color when computing parent
  and color information (possibly not in close sequence, as there might
  be further branches in the algorithm)
- In the 1-child subcase of case 1, copy the __rb_parent_color field from
  the erased node to the child instead of recomputing it from the desired
  parent and color
- When searching for the erased node's successor, differentiate between
  cases 2 and 3 based on whether any left links were followed. This avoids
  a condition later down.
- In case 3, keep a pointer to the erased node's right child so we don't
  have to refetch it later to adjust its parent.
- In the no-childs subcase of cases 2 and 3, place the rebalance assigment
  last so that the compiler can remove the following if(rebalance) test.

Also, added some comments to illustrate cases 2 and 3.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 4f035ad67f4633c233cb3642711d49b4efc9c82d]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 100 +---
 1 file changed, 64 insertions(+), 36 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 43319b8f3b..8e1dd2c56e 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -47,9 +47,14 @@
 #defineRB_RED  0
 #defineRB_BLACK1
 
-#define rb_color(r)   ((r)->__rb_parent_color & 1)
-#define rb_is_red(r)   (!rb_color(r))
-#define rb_is_black(r) rb_color(r)
+#define __rb_parent(pc)((struct rb_node *)(pc & ~3))
+
+#define __rb_color(pc) ((pc) & 1)
+#define __rb_is_black(pc)  __rb_color(pc)
+#define __rb_is_red(pc)(!__rb_color(pc))
+#define rb_color(rb)   __rb_color((rb)->__rb_parent_color)
+#define rb_is_red(rb)  __rb_is_red((rb)->__rb_parent_color)
+#define rb_is_black(rb)__rb_is_black((rb)->__rb_parent_color)
 
 static inline void rb_set_black(struct rb_node *rb)
 {
@@ -378,6 +383,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 {
struct rb_node *child = node->rb_right, *tmp = node->rb_left;
struct rb_node *parent, *rebalance;
+   unsigned long pc;
 
if (!tmp) {
/*
@@ -387,53 +393,75 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 * and node must be black due to 4). We adjust colors locally
 * so as to bypass __rb_erase_color() later on.
 */
-
-   parent = rb_parent(node);
-
+   pc = node->__rb_parent_color;
+   parent = __rb_parent(pc);
__rb_change_child(node, child, parent, root);
if (child) {
-   rb_set_parent_color(child, parent, RB_BLACK);
+   child->__rb_parent_color = pc;
rebalance = NULL;
-   } else {
-   rebalance = rb_is_black(node) ? parent : NULL;
-   }
+   } else
+   rebalance = __rb_is_black(pc) ? parent : NULL;
} else if (!child) {
/* Still case 1, but this time the child is node->rb_left */
-   parent = rb_parent(node);
+   tmp->__rb_parent_color = pc = node->__rb_parent_color;
+   parent = __rb_parent(pc);
__rb_change_child(node, tmp, parent, root);
-   rb_set_parent_color(tmp, parent, RB_BLACK);
rebalance = NULL;
} else {
-   struct rb_node *old = node, *left;
-
-   node = child;
-   while ((left = node->rb_left) != NULL)
-   node = left;
-
-   __rb_change_child(old, node, rb_parent(old), root);
-
-   child = node->rb_right;
-   parent = rb_parent(node);
-
-   if (parent == old) {
-   parent = node;
+   struct rb_node *successor = child, *child2;
+   tmp = child->rb_left;
+   if (!tmp) {
+   /*
+* Case 2: node's successor is its right child
+*
+*(n)  (s)
+*/ \  / \
+*  (x) (s)  ->  (x) (c)
+*\
+*(c)
+*/
+   parent = child;
+   child2 = child->rb_right;
} else {
-   parent->rb_left = child;
-
-   node->rb_right = old->rb_right;
-   rb_set_parent(old->rb_right, node);
+   /*
+* Case 3: node's successor is leftmost under
+

[Xen-devel] [PATCH v5 14/17] rbtree: place easiest case first in rb_erase()

[Praveen Kumar]

From: Michel Lespinasse 

In rb_erase, move the easy case (node to erase has no more than
1 child) first. I feel the code reads easier that way.

Signed-off-by: Michel Lespinasse 
Reviewed-by: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 60670b8034d6e2ba860af79c9379b7788d09db73]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 35 ++-
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 9182544417..9aead2f892 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -368,17 +368,28 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
 
 void rb_erase(struct rb_node *node, struct rb_root *root)
 {
-   struct rb_node *child, *parent;
+   struct rb_node *child = node->rb_right, *tmp = node->rb_left;
+   struct rb_node *parent;
int color;
 
-   if (!node->rb_left)
-   child = node->rb_right;
-   else if (!node->rb_right)
-   child = node->rb_left;
-   else {
+   if (!tmp) {
+   case1:
+   /* Case 1: node to erase has no more than 1 child (easy!) */
+
+   parent = rb_parent(node);
+   color = rb_color(node);
+
+   if (child)
+   rb_set_parent(child, parent);
+   __rb_change_child(node, child, parent, root);
+   } else if (!child) {
+   /* Still case 1, but this time the child is node->rb_left */
+   child = tmp;
+   goto case1;
+   } else {
struct rb_node *old = node, *left;
 
-   node = node->rb_right;
+   node = child;
while ((left = node->rb_left) != NULL)
node = left;
 
@@ -403,18 +414,8 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
node->rb_left = old->rb_left;
 
rb_set_parent(old->rb_left, node);
-
-   goto color;
}
 
-   parent = rb_parent(node);
-   color = rb_color(node);
-
-   if (child)
-   rb_set_parent(child, parent);
-   __rb_change_child(node, child, parent, root);
-
-color:
if (color == RB_BLACK)
__rb_erase_color(child, parent, root);
 }
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 17/17] rbtree: fix typo in comment of rb_insert_color

[Praveen Kumar]

From: Wei Yang 

In case 1, it passes down the BLACK color from G to p and u, and maintains
the color of n.  By doing so, it maintains the black height of the sub-tree.

While in the comment, it marks the color of n to BLACK.  This is a typo
and not consistents with the code.

This patch fixs this typo in comment.

Signed-off-by: Wei Yang 
Acked-by: Michel Lespinasse 
Cc: Xiao Guangrong 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 1b9c53e849aa65776d4f611d99aa09f856518dad]

Ported to Xen for rb_insert_color API.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 8e1dd2c56e..7147481480 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -135,7 +135,7 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 *  / \  / \
 * p   u  -->   P   U
 *//
-*   nN
+*   nn
 *
 * However, since g's parent might be red, and
 * 4) does not allow this, we need to recurse
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v5 15/17] rbtree: handle 1-child recoloring in rb_erase() instead of rb_erase_color()

[Praveen Kumar]

From: Michel Lespinasse 

An interesting observation for rb_erase() is that when a node has
exactly one child, the node must be black and the child must be red.
An interesting consequence is that removing such a node can be done by
simply replacing it with its child and making the child black,
which we can do efficiently in rb_erase(). __rb_erase_color() then
only needs to handle the no-childs case and can be modified accordingly.

Signed-off-by: Michel Lespinasse 
Acked-by: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 46b6135a7402ac23c5b25f2bd79b03bab8f98278]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 102 +++-
 1 file changed, 61 insertions(+), 41 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index 9aead2f892..43319b8f3b 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -2,6 +2,7 @@
   Red Black Trees
   (C) 1999  Andrea Arcangeli 
   (C) 2002  David Woodhouse 
+  (C) 2012  Michel Lespinasse 
   
   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
@@ -50,6 +51,11 @@
 #define rb_is_red(r)   (!rb_color(r))
 #define rb_is_black(r) rb_color(r)
 
+static inline void rb_set_black(struct rb_node *rb)
+{
+   rb->__rb_parent_color |= RB_BLACK;
+}
+
 static inline void rb_set_parent(struct rb_node *rb, struct rb_node *p)
 {
rb->__rb_parent_color = rb_color(rb) | (unsigned long)p;
@@ -214,27 +220,18 @@ void rb_insert_color(struct rb_node *node, struct rb_root 
*root)
 }
 EXPORT_SYMBOL(rb_insert_color);
 
-static void __rb_erase_color(struct rb_node *node, struct rb_node *parent,
-struct rb_root *root)
+static void __rb_erase_color(struct rb_node *parent, struct rb_root *root)
 {
-   struct rb_node *sibling, *tmp1, *tmp2;
+   struct rb_node *node = NULL, *sibling, *tmp1, *tmp2;
 
while (true) {
/*
-* Loop invariant: all leaf paths going through node have a
-* black node count that is 1 lower than other leaf paths.
-*
-* If node is red, we can flip it to black to adjust.
-* If node is the root, all leaf paths go through it.
-* Otherwise, we need to adjust the tree through color flips
-* and tree rotations as per one of the 4 cases below.
+* Loop invariants:
+* - node is black (or NULL on first iteration)
+* - node is not the root (parent is not NULL)
+* - All leaf paths going through parent and node have a
+*   black node count that is 1 lower than other leaf paths.
 */
-   if (node && rb_is_red(node)) {
-   rb_set_parent_color(node, parent, RB_BLACK);
-   break;
-   } else if (!parent) {
-   break;
-   }
sibling = parent->rb_right;
if (node != sibling) {  /* node == parent->rb_left */
if (rb_is_red(sibling)) {
@@ -268,17 +265,22 @@ static void __rb_erase_color(struct rb_node *node, struct 
rb_node *parent,
*  / \   / \
* Sl  SrSl  Sr
*
-   * This leaves us violating 5), so
-   * recurse at p. If p is red, the
-   * recursion will just flip it to black
-   * and exit. If coming from Case 1,
-   * p is known to be red.
+   * This leaves us violating 5) which
+   * can be fixed by flipping p to black
+   * if it was red, or by recursing at p.
+   * p is red when coming from Case 1.
*/
rb_set_parent_color(sibling, parent,
RB_RED);
-   node = parent;
-   parent = rb_parent(node);
-   continue;
+   if (rb_is_red(parent))
+   rb_set_black(parent);
+   else {
+   node = parent;
+   parent = rb_parent(node);
+   if (parent)
+ 

[Xen-devel] [PATCH v5 11/17] rbtree: coding style adjustments

[Praveen Kumar]

From: Michel Lespinasse 

Set comment and indentation style to be consistent with linux coding style
and the rest of the file, as suggested by Peter Zijlstra

Signed-off-by: Michel Lespinasse 
Cc: Andrea Arcangeli 
Acked-by: David Woodhouse 
Cc: Rik van Riel 
Cc: Peter Zijlstra 
Cc: Daniel Santos 
Cc: Jens Axboe 
Cc: "Eric W. Biederman" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[Linux commit 7ce6ff9e5de99e7b72019c7de82fb438fe1dc5a0]

Ported to Xen.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c | 42 +++---
 1 file changed, 23 insertions(+), 19 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index e58336bd26..215d4f3613 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -363,8 +363,7 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
child = node->rb_right;
else if (!node->rb_right)
child = node->rb_left;
-   else
-   {
+   else {
struct rb_node *old = node, *left;
 
node = node->rb_right;
@@ -407,17 +406,15 @@ void rb_erase(struct rb_node *node, struct rb_root *root)
 
if (child)
rb_set_parent(child, parent);
-   if (parent)
-   {
+   if (parent) {
if (parent->rb_left == node)
parent->rb_left = child;
else
parent->rb_right = child;
-   }
-   else
+   } else
root->rb_node = child;
 
- color:
+color:
if (color == RB_BLACK)
__rb_erase_color(child, parent, root);
 }
@@ -459,8 +456,10 @@ struct rb_node *rb_next(const struct rb_node *node)
if (RB_EMPTY_NODE(node))
return NULL;
 
-   /* If we have a right-hand child, go down and then left as far
-  as we can. */
+   /*
+* If we have a right-hand child, go down and then left as far
+* as we can.
+*/
if (node->rb_right) {
node = node->rb_right;
while (node->rb_left)
@@ -468,12 +467,13 @@ struct rb_node *rb_next(const struct rb_node *node)
return (struct rb_node *)node;
}
 
-   /* No right-hand children.  Everything down and left is
-  smaller than us, so any 'next' node must be in the general
-  direction of our parent. Go up the tree; any time the
-  ancestor is a right-hand child of its parent, keep going
-  up. First time it's a left-hand child of its parent, said
-  parent is our 'next' node. */
+   /*
+* No right-hand children. Everything down and left is smaller than us,
+* so any 'next' node must be in the general direction of our parent.
+* Go up the tree; any time the ancestor is a right-hand child of its
+* parent, keep going up. First time it's a left-hand child of its
+* parent, said parent is our 'next' node.
+*/
while ((parent = rb_parent(node)) && node == parent->rb_right)
node = parent;
 
@@ -488,8 +488,10 @@ struct rb_node *rb_prev(const struct rb_node *node)
if (RB_EMPTY_NODE(node))
return NULL;
 
-   /* If we have a left-hand child, go down and then right as far
-  as we can. */
+   /*
+* If we have a left-hand child, go down and then right as far
+* as we can.
+*/
if (node->rb_left) {
node = node->rb_left;
while (node->rb_right)
@@ -497,8 +499,10 @@ struct rb_node *rb_prev(const struct rb_node *node)
return (struct rb_node *)node;
}
 
-   /* No left-hand children. Go up till we find an ancestor which
-  is a right-hand child of its parent */
+   /*
+* No left-hand children. Go up till we find an ancestor which
+* is a right-hand child of its parent
+*/
while ((parent = rb_parent(node)) && node == parent->rb_left)
node = parent;
 
-- 
2.12.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 111771: regressions - FAIL

[osstest service owner]

flight 111771 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111771/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfai

[Xen-devel] [distros-debian-jessie test] 71691: tolerable trouble: blocked/broken/pass

[Platform Team regression test user]

flight 71691 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71691/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-jessie-netboot-pygrub  1 build-check(1) blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 71662
 build-arm64   2 hosts-allocate   broken like 71662
 build-arm64-pvops 3 capture-logs broken like 71662
 build-arm64   3 capture-logs broken like 71662
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail 
like 71662
 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail 
like 71662

baseline version:
 flight   71662

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-arm64-arm64-armhf-jessie-netboot-pygrub blocked 
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 01/17] rbtree: changes to inline coding conventions with Linux tree

[Jan Beulich]

>>> On 14.07.17 at 07:07,  wrote:
> On Tue, 2017-07-04 at 02:24 -0600, Jan Beulich wrote:
>> > > > On 03.07.17 at 21:58,  wrote:
>> > The patch inlines the rbtree related files to Linux coding
>> > conventions to have
>> > limited conflicts in future while porting from Linux tree.
>> 
>> "inlines" has a different meaning most of the time - how about
>> "brings in line" (but I'll be happy to be corrected by a native
>> speaker)? This would then also call for a change to the subject.
>> 
>> What I'm missing though is a reference to the Linux version to
>> compare with - this is especially relevant because the format
>> the patch brings the code into is not normal Linux style (but I
>> do see that e.g. in 3.0 such oddities indeed existed).
> 
> Is it ok to add the last reference from Linux tree, which has already
> been ported to Xen code base till date, so that we can diff from start
> and verify that its only coding style changed and not anything else ?

Without you saying what you mean by "add last reference" I'm
afraid I can't really answer your question. For example, if you
mean to add a note that things up to, say, 4.12 have been
ported (by you), then this wouldn't be the full truth, as you're
leaving out certain pieces.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/9] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

[Jan Beulich]

>>> On 30.06.17 at 17:01,  wrote:
> So that hotplug (or MMCFG regions not present in the MCFG ACPI table)
> can be added at run time by the hardware domain.

I think the emphasis should be the other way around. I'm rather certain
hotplug of bridges doesn't really work right now anyway; at least
IO-APIC hotplug code is completely missing.

> When a new MMCFG area is added to a PVH Dom0, Xen will scan it and add
> the devices to the hardware domain.

Adding the MMIO regions is certainly necessary, but what's the point of
also scanning the bus and adding the devices? We expect Dom0 to tell us
anyway, and not doing the scan in Xen avoids complications we presently
have in the segment 0 case when Dom0 decides to re-number busses (e.g.
in order to fit in SR-IOV VFs).

> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -89,6 +89,10 @@ static long hvm_physdev_op(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  if ( !has_pirq(curr->domain) )
>  return -ENOSYS;
>  break;
> +case PHYSDEVOP_pci_mmcfg_reserved:
> +if ( !is_hardware_domain(curr->domain) )
> +return -ENOSYS;
> +break;

This physdevop (like most ones) is restricted to Dom0 use anyway
(properly expressed via XSM check), so I'd rather see you check
has_vpci() here, in line with e.g. the check visible in context.

> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -559,6 +559,25 @@ ret_t do_physdev_op(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  
>  ret = pci_mmcfg_reserved(info.address, info.segment,
>   info.start_bus, info.end_bus, info.flags);
> +if ( ret || !is_hvm_domain(currd) )
> +break;
> +
> +/*
> + * For HVM (PVH) domains try to add the newly found MMCFG to the
> + * domain.
> + */
> +ret = register_vpci_mmcfg_handler(currd, info.address, 
> info.start_bus,
> +  info.end_bus, info.segment);
> +if ( ret == -EEXIST )
> +{
> +ret = 0;
> +break;

I don't really understand this part: Why would handlers be registered
already? If you consider double registration, wouldn't that better
either be detected by pci_mmcfg_reserved() (and the call here avoided
altogether) or the fact indeed be reported back to the caller?

> @@ -1110,6 +1110,37 @@ void __hwdom_init setup_hwdom_pci_devices(
>  pcidevs_unlock();
>  }
>  
> +static int add_device(uint8_t devfn, struct pci_dev *pdev)
> +{
> +return iommu_add_device(pdev);
> +}

You're discarding devfn here, just for iommu_add_device() to re-do the
phantom function handling. At the very least this is wasteful. Perhaps
you minimally want to call iommu_add_device() only when
devfn == pdev->devfn (if all of this code stays in the first place)?

> +int pci_scan_and_setup_segment(uint16_t segment)
> +{
> +struct pci_seg *pseg = get_pseg(segment);
> +struct setup_hwdom ctxt = {
> +.d = current->domain,
> +.handler = add_device,
> +};
> +int ret;
> +
> +if ( !pseg )
> +return -EINVAL;
> +
> +pcidevs_lock();
> +ret = _scan_pci_devices(pseg, NULL);
> +if ( ret )
> +goto out;
> +
> +ret = _setup_hwdom_pci_devices(pseg, &ctxt);
> +if ( ret )
> +goto out;
> +
> + out:

Please let's avoid such unnecessary goto-s. Even the first one could be
easily avoided without making the code anywhere near unreadable.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/9] xen/mm: move modify_identity_mmio to global file and drop __init

[Jan Beulich]

>>> On 30.06.17 at 17:01,  wrote:
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -1465,6 +1465,46 @@ int prepare_ring_for_helper(
>  return 0;
>  }
>  
> +#if defined(CONFIG_X86) || defined(CONFIG_HAS_PCI)

Why both? X86 selects HAS_PCI, and such (reverse) dependencies exist
precisely to avoid such conditionals to become rather complex over
time.

> +int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn, unsigned long 
> nr_pages,
> +const bool map)

Already in the original function I've been puzzled by this const - if
you wanted such, you should put it consistently on all applicable
parameters. But since we don't normally do so elsewhere, the globally
consistent approach would be to simply drop it.

> +{
> +int rc;
> +
> +/*
> + * ATM this function should only be used by the hardware domain
> + * because it doesn't support preemption/continuation, and as such
> + * can take a non-trivial amount of time. Note that it periodically calls

non-negligible?

> + * process_pending_softirqs in order to avoid stalling the system.
> + */
> +ASSERT(is_hardware_domain(d));
> +
> +for ( ; ; )
> +{
> +rc = (map ? map_mmio_regions : unmap_mmio_regions)
> + (d, gfn, nr_pages, mfn);
> +if ( rc == 0 )
> +break;
> +if ( rc < 0 )
> +{
> +printk(XENLOG_G_WARNING

As long as this is Dom0 only I'd suggest to drop the _G_ infix, just
like it was in the original.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 5/9] xen/pci: split code to size BARs from pci_add_device

[Jan Beulich]

>>> On 30.06.17 at 17:01,  wrote:
> So that it can be called from outside in order to get the size of regular PCI
> BARs. This will be required in order to map the BARs from PCI devices into PVH
> Dom0 p2m.
> 
> Signed-off-by: Roger Pau Monné 
> 
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -588,6 +588,54 @@ static void pci_enable_acs(struct pci_dev *pdev)
>  pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
>  }
>  
> +int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot,
> + unsigned int func, unsigned int pos, bool last,
> + uint64_t *paddr, uint64_t *psize)
> +{
> +uint32_t hi = 0, bar = pci_conf_read32(seg, bus, slot, func, pos);
> +uint64_t addr, size;
> +
> +ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
> +pci_conf_write32(seg, bus, slot, func, pos, ~0);
> +if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> + PCI_BASE_ADDRESS_MEM_TYPE_64 )
> +{
> +if ( last )
> +{
> +printk(XENLOG_WARNING
> +"device %04x:%02x:%02x.%u with 64-bit BAR in last 
> slot\n",

This message needs to tell what kind of slot is being processed (just
like the original did).

> +seg, bus, slot, func);
> +return -EINVAL;
> +}
> +hi = pci_conf_read32(seg, bus, slot, func, pos + 4);
> +pci_conf_write32(seg, bus, slot, func, pos + 4, ~0);
> +}
> +size = pci_conf_read32(seg, bus, slot, func, pos) &
> +   PCI_BASE_ADDRESS_MEM_MASK;
> +if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> + PCI_BASE_ADDRESS_MEM_TYPE_64 )
> +{
> +size |= (u64)pci_conf_read32(seg, bus, slot, func, pos + 4) << 32;

uint64_t

> +pci_conf_write32(seg, bus, slot, func, pos + 4, hi);
> +}
> +else if ( size )
> +size |= (u64)~0 << 32;

Again (and more below).

> +pci_conf_write32(seg, bus, slot, func, pos, bar);
> +size = -(size);

Stray parentheses.

> +addr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((u64)hi << 32);
> +
> +if ( paddr )
> +*paddr = addr;
> +if ( psize )
> +*psize = size;

Is it reasonable to expect the caller to not care about the size?

> @@ -663,38 +710,12 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
> seg, bus, slot, func, i);
>  continue;
>  }
> -pci_conf_write32(seg, bus, slot, func, idx, ~0);
> -if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> - PCI_BASE_ADDRESS_MEM_TYPE_64 )
> -{
> -if ( i >= PCI_SRIOV_NUM_BARS )
> -{
> -printk(XENLOG_WARNING
> -   "SR-IOV device %04x:%02x:%02x.%u with 64-bit"
> -   " vf BAR in last slot\n",
> -   seg, bus, slot, func);
> -break;
> -}
> -hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
> -pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
> -}
> -pdev->vf_rlen[i] = pci_conf_read32(seg, bus, slot, func, 
> idx) &
> -   PCI_BASE_ADDRESS_MEM_MASK;
> -if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> - PCI_BASE_ADDRESS_MEM_TYPE_64 )
> -{
> -pdev->vf_rlen[i] |= (u64)pci_conf_read32(seg, bus,
> - slot, func,
> - idx + 4) << 32;
> -pci_conf_write32(seg, bus, slot, func, idx + 4, hi);
> -}
> -else if ( pdev->vf_rlen[i] )
> -pdev->vf_rlen[i] |= (u64)~0 << 32;
> -pci_conf_write32(seg, bus, slot, func, idx, bar);
> -pdev->vf_rlen[i] = -pdev->vf_rlen[i];
> -if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> - PCI_BASE_ADDRESS_MEM_TYPE_64 )
> -++i;
> +ret = pci_size_mem_bar(seg, bus, slot, func, idx,
> +   i == PCI_SRIOV_NUM_BARS - 1, NULL,
> +   &pdev->vf_rlen[i]);
> +if ( ret < 0 )
> +break;

ASSERT(ret) ?

> +i += ret;

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v9 0/7] Add LMCE support

[Jan Beulich]

>>> On 12.07.17 at 04:04,  wrote:
> Changes in v9:
>  * Minor updates in patch 1 per Jan's comments.
>  * Collect Jan's R-b in patch 2.
> 
> Haozhong Zhang (7):
>   [M   ] x86/domctl: generalize the restore of vMCE parameters
>   [  R ] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL
>   [  R ] x86/vmce: enable injecting LMCE to guest on Intel host
>   [  RA] x86/vmce, tools/libxl: expose LMCE capability in guest 
> MSR_IA32_MCG_CAP
>   [  R ] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

I've committed these, but ...

>   [   A] tools/libxc: add support of injecting MC# to specified CPUs
>   [   A] tools/xen-mceinj: add support of injecting LMCE

... I've left out these, due to Konrad's (late) comments which I'm
not sure are being expected to be addressed in another round.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline baseline-only test] 71690: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71690 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71690/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop fail REGR. vs. 71686

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 71686
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 71686
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 71686
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 71686
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 71686
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 71686
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 qemuu31fe1c414501047cbb91b695bdccc0068496dcf6
baseline version:
 qemuuaa916e409c04cb614ec2fee8b6b33836bf5998bb

Last test of basis71686  2017-07-13 05:18:17 Z1 days
Testing same since71690  2017-07-14 04:16:05 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Lluís Vilanova 
  Peter Maydell 
  Stefan Hajnoczi 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386 

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send

[Jan Beulich]

>>> On 13.07.17 at 09:50,  wrote:
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  break;
>  }
>  
> +case EVTCHNOP_send_imm:
> +rc = evtchn_send(current->domain, (unsigned long)arg.p);

Two more things: For one this discards the upper half of the 64-bit
handle. I'd suggest you instead check it to be zero. And then x86's
do_event_channel_op_compat() should refuse to handle "immediate"
commands.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 08/15] xen: x86: add SGX cpuid handling support.

[Jan Beulich]

>>> On 14.07.17 at 09:37,  wrote:
> On 13/07/17 07:42, Huang, Kai wrote:
>> On 7/12/2017 10:56 PM, Andrew Cooper wrote:
>>> On 09/07/17 10:10, Kai Huang wrote:
 +/* Subleaf 2. */
 +uint32_t base_valid:1, :11, base_pfn_low:20;
 +uint32_t base_pfn_high:20, :12;
 +uint32_t size_valid:1, :11, npages_low:20;
 +uint32_t npages_high:20, :12;
 +};
>>>
>>> Are the {base,size}_valid fields correct?  The manual says the are 
>>> 4-bit fields rather than single bit fields.
>>
>> They are 4 bits in SDM but actually currently only bit 1 is valid 
>> (other values are reserved). I think for now bool base_valid should be 
>> enough. We can extend when new values come out. What's your suggestion?
> 
> Ok.  That can work for now.
> 
>>
>>>
>>> I would also drop the _pfn from the base names.  The fields still 
>>> need shifting to get a sensible value.
>>
>> OK. Will do.
> 
> As a further thought, what about uint64_t base:40 and size:40?  That 
> would reduce the complexity of calculating the values.

But that may not really be portable. I've just checked the Intel
compiler (on Windows, admittedly), and it then starts the base
and size fields each on an 8-byte boundary. Hence all other fields
would then better also be uint64_t.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 15/15] xen: tools: expose EPC in ACPI table

[Jan Beulich]

>>> On 09.07.17 at 10:16,  wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -330,6 +330,15 @@ cpuid(uint32_t idx, uint32_t *eax, uint32_t *ebx, 
> uint32_t *ecx, uint32_t *edx)
>  : "0" (idx) );
>  }
>  
> +void cpuid_count(uint32_t idx, uint32_t count, uint32_t *eax,

Please name the first two leaf and subleaf.

> @@ -888,6 +897,18 @@ static uint8_t acpi_lapic_id(unsigned cpu)
>  return LAPIC_ID(cpu);
>  }
>  
> +static void get_epc_info(struct acpi_config *config)
> +{
> +uint32_t eax, ebx, ecx, edx;
> +
> +cpuid_count(0x12, 0x2, &eax, &ebx, &ecx, &edx);
> +
> +config->epc_base = (((uint64_t)(ebx & 0xf)) << 32) |
> +   (uint64_t)(eax & 0xf000);

Pointless cast.

> +config->epc_size = (((uint64_t)(edx & 0xf)) << 32) |
> +   (uint64_t)(ecx & 0xf000);

Again.

> --- a/tools/libacpi/dsdt.asl
> +++ b/tools/libacpi/dsdt.asl
> @@ -441,6 +441,55 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
>  }
>  }
>  }
> +
> +Device (EPC)
> +{
> +Name (_HID, EisaId ("INT0E0C"))
> +Name (_STR, Unicode ("Enclave Page Cache 1.5"))
> +Name (_MLS, Package (0x01)
> +{
> +Package (0x02)
> +{
> +"en",
> +Unicode ("Enclave Page Cache 1.5")
> +}
> +})
> +Name (RBUF, ResourceTemplate ()
> +{
> +QWordMemory (ResourceConsumer, PosDecode, MinFixed, MaxFixed,
> +Cacheable, ReadWrite,
> +0x, // Granularity
> +0x, // Range Minimum
> +0x, // Range Maximum
> +0x, // Translation Offset
> +0x0001, // Length
> +,, _Y03,
> +AddressRangeMemory, TypeStatic)
> +})
> +
> +Method(_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
> +{
> +CreateQwordField (RBUF, \_SB.EPC._Y03._MIN, EMIN) // _MIN: 
> Minimuum Base Address
> +CreateQwordField (RBUF, \_SB.EPC._Y03._MAX, EMAX) // _MIN: 
> Maximum Base Address
> +CreateQwordField (RBUF, \_SB.EPC._Y03._LEN, ELEN) // _LEN: 
> Length

Please see the comment in _SB.PCI0._CRS regarding operations
on qword fields. Even if we may not formally support the named
Windows versions anymore, we should continue to be careful
here. You could have noticed this by seeing that ...

> @@ -21,6 +21,8 @@
> LMIN, 32,
> HMIN, 32,
> LLEN, 32,
> -   HLEN, 32
> +   HLEN, 32,
> +   EMIN, 64,
> +   ELEN, 64,
> }

... there have been no 64-bit fields here so far.

> @@ -156,6 +156,9 @@ static int init_acpi_config(libxl__gc *gc,
>  config->lapic_id = acpi_lapic_id;
>  config->acpi_revision = 5;
>  
> +config->epc_base = b_info->u.hvm.sgx.epcbase;
> +config->epc_size = (b_info->u.hvm.sgx.epckb << 10);

Pointless parentheses. Plus I guess the field names could do with
an underscore separator in the middle - it took me a moment to
realize this is a kB value (explaining the shift by 10).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Regression PCI passthrough from 4.5.5 to 4.6.0-rc1

[Jan Beulich]

>>> On 10.07.17 at 18:56,  wrote:
> Hello Jan, Pasi, all
> 
>>> I noticed that PCI passthrough for an LSI SAS HBA 9211 did not longer work 
> (at least under Windows) when using Xen 4.8.1.
>>> I then bisected through various released versions and finally I narrowed it 
> down to
>>> 4.5.5 (with qemu from Xen 4.6.5) -> working
>>> 4.6.0-rc1 (with qemu from Xen 4.6.5) -> no longer working
>> So can you please bisect which exact commit between Xen 4.5 and 4.6 causes 
> the problem?
> 
> Initially I did not bisect through unstable code as I expected to hit broken 
> intermediate snapshots. But finally it worked.
> 
> I found that commit 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=ad28e42bd1d28d746988ed716 
> 54e8aa670629753 is causing the problem (x86/MSI: track host and guest masking 
> separately) which appeared on the mailing list already:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03923.html 
> https://lists.xenproject.org/archives/html/xen-devel/2016-04/msg00028.html 
> 
> Commit 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=84d6add5593d865736831d150 
> da7c38588f669f6 does not fix it.

So it's possibly a different issue from at least what Sander had seen,
as that change has been tested by him successfully.

> Attached is some first debug info.

What I first of all notice is that there's no interrupt at all which is
bound to either Dom1 or Dom2 in the debug key output. qemu
logs may therefore also be necessary, likely even with verbosity
first increased in the sources (by #define-ing
XEN_PT_LOGGING_ENABLED in xen_pt.h prior to its first use).

It further looks like it's Windows you're having the problem with.
Unless Windows provides you with some kind of diagnostics,
could you check with Linux (allowing us to also see the kernel
log)?

Finally, it would help if you could do all debugging on at least 4.9,
preferably even master. Among other benefits that'll exclude
there potentially being some other change missing from the older
tree.

> Jan, I still have access to the hardware so perhaps we can finally solve 
> this problem.

Feel free to go ahead; I'll be on vacation for the next three weeks.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] x86/monitor: Notify monitor if an emulation fails.

[Jan Beulich]

>>> On 12.07.17 at 19:21,  wrote:
> ---
>  tools/libxc/include/xenctrl.h |  2 ++
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/hvm/emulate.c|  5 -
>  xen/arch/x86/hvm/monitor.c| 18 ++
>  xen/arch/x86/monitor.c| 12 
>  xen/include/asm-x86/domain.h  |  1 +
>  xen/include/asm-x86/hvm/monitor.h |  1 +
>  xen/include/asm-x86/monitor.h |  3 ++-
>  xen/include/public/domctl.h   |  1 +
>  xen/include/public/vm_event.h |  2 ++
>  10 files changed, 57 insertions(+), 2 deletions(-)

Please be sure to Cc maintainers of all files you modify.

> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -57,6 +57,24 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old
>  return 0;
>  }
>  
> +bool hvm_monitor_emul_unhandleable(void)
> +{
> +struct vcpu *curr = current;
> +struct domain *d = curr->domain;

currd, but the variable is used just once, so perhaps best to omit
it altogether.

> +/*
> + * Send a vm_event to the monitor to signal that the current
> + * instruction couldn't be emulated.
> + */
> +vm_event_request_t req = {
> +.reason = VM_EVENT_REASON_EMUL_UNHANDLEABLE,
> +.vcpu_id  = curr->vcpu_id,
> +};
> +
> +return ( d->arch.monitor.emul_unhandleable_enabled &&
> + monitor_traps(curr, true, &req) );

Just in case Tamas'es request isn't going to be picked up: Stray
parentheses and blanks.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Jan Beulich]

>>> On 14.07.17 at 10:26,  wrote:
> The patch aligns the coding style of rbtree related files to Linux coding
> conventions to have limited conflicts in future while porting from Linux 
> tree.
> 
> This patch includes only the style changes.

Certainly not: In the header you introduce at least 3 new inline
functions. Please be _really_ careful with such statements.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Ping: [PATCH 11/11] gnttab: drop useless locking

[Jan Beulich]

>>> On 21.06.17 at 11:38,  wrote:
> Holding any lock while accessing the maptrack entry fields is
> pointless, as these entries are protected by their associated active
> entry lock (which is being acquired later, before re-validating the
> fields read without holding the lock).
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -1122,19 +1122,14 @@ __gnttab_unmap_common(
>  smp_rmb();
>  map = &maptrack_entry(lgt, op->handle);
>  
> -grant_read_lock(lgt);
> -
>  if ( unlikely(!read_atomic(&map->flags)) )
>  {
> -grant_read_unlock(lgt);
>  gdprintk(XENLOG_INFO, "Zero flags for handle %#x\n", op->handle);
>  op->status = GNTST_bad_handle;
>  return;
>  }
>  
>  dom = map->domid;
> -grant_read_unlock(lgt);
> -
>  if ( unlikely((rd = rcu_lock_domain_by_id(dom)) == NULL) )
>  {
>  /* This can happen when a grant is implicitly unmapped. */




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Praveen Kumar]

On Fri, 2017-07-14 at 06:28 -0600, Jan Beulich wrote:
> > 
> > > 
> > > > 
> > > > On 14.07.17 at 10:26,  wrote:
> > The patch aligns the coding style of rbtree related files to Linux
> > coding
> > conventions to have limited conflicts in future while porting from
> > Linux 
> > tree.
> > 
> > This patch includes only the style changes.
> 
> Certainly not: In the header you introduce at least 3 new inline
> functions. Please be _really_ careful with such statements.
> 
> Jan
> 
Agreed, I shouldn't have added.
rbtree.h file does include incline functions which are actually
commented, and in order to have complete similarity I did include the
same here.

Also, rbtree.c does have comment in header note being modified, for the
same reason.

Further, do you suggest to keep the old ones, but that may cause
porting issue and it won't be exact replica from Linux base. Please
suggest.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 111804: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

flight 111804 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111804/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2b8a8a03f56e21381c7dd560b081002d357639e2
baseline version:
 xen  614a14736e33fb84872eb00f08799ebbc73a96c6

Last test of basis   111733  2017-07-12 11:03:10 Z2 days
Testing same since   111804  2017-07-14 11:02:51 Z0 days1 attempts


People who touched revisions under test:
  Haozhong Zhang 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2b8a8a03f56e21381c7dd560b081002d357639e2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2b8a8a03f56e21381c7dd560b081002d357639e2
+ branch=xen-unstable-smoke
+ revision=2b8a8a03f56e21381c7dd560b081002d357639e2
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x2b8a8a03f56e21381c7dd560b081002d357639e2 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.x

Re: [Xen-devel] [PATCH v5 01/17] rbtree: changes to align the coding conventions with Linux tree

[Jan Beulich]

>>> On 14.07.17 at 14:51,  wrote:
> On Fri, 2017-07-14 at 06:28 -0600, Jan Beulich wrote:
>> > 
>> > > 
>> > > > 
>> > > > On 14.07.17 at 10:26,  wrote:
>> > The patch aligns the coding style of rbtree related files to Linux
>> > coding
>> > conventions to have limited conflicts in future while porting from
>> > Linux 
>> > tree.
>> > 
>> > This patch includes only the style changes.
>> 
>> Certainly not: In the header you introduce at least 3 new inline
>> functions. Please be _really_ careful with such statements.
>> 
> Agreed, I shouldn't have added.
> rbtree.h file does include incline functions which are actually
> commented, and in order to have complete similarity I did include the
> same here.
> 
> Also, rbtree.c does have comment in header note being modified, for the
> same reason.
> 
> Further, do you suggest to keep the old ones, but that may cause
> porting issue and it won't be exact replica from Linux base. Please
> suggest.

I'm fine with comment updates, _as long as you say so_ in the
commit message. If you say "only style changes", then there
ought to be no additions whatsoever.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable test] 111777: tolerable FAIL

[osstest service owner]

flight 111777 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111777/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111751 pass in 
111777
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 111751 pass in 
111777
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 111751
 test-armhf-armhf-xl-cubietruck 19 leak-check/check fail pass in 111751
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111751

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
111751
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 111751
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111751 blocked in 
111777
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111751
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111751
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111751
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111751
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111751
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111751
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  614a14736e33fb84872eb00f08799ebbc73a96c6
baseline version:
 xen 

[Xen-devel] [PATCH v6 01/17] rbtree: changes to align the coding conventions with Linux tree

[Praveen Kumar]

The patch aligns the coding style of rbtree related files to Linux coding
conventions to have limited conflicts in future while porting from Linux tree.

Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h
rbtree.h file includes commented inline functions in order to have complete
replica from Linux tree.

Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c
rbtree.c has comment changes in header note for the same reason.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c  | 633 ---
 xen/include/xen/rbtree.h | 116 +++--
 2 files changed, 413 insertions(+), 336 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index d91d651d77..167ebfdc4d 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -14,7 +14,8 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; If not, see .
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
   linux/lib/rbtree.c
 */
@@ -24,261 +25,261 @@
 
 static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *right = node->rb_right;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_right = right->rb_left))
-rb_set_parent(right->rb_left, node);
-right->rb_left = node;
-
-rb_set_parent(right, parent);
-
-if (parent)
-{
-if (node == parent->rb_left)
-parent->rb_left = right;
-else
-parent->rb_right = right;
-}
-else
-root->rb_node = right;
-rb_set_parent(node, right);
+   struct rb_node *right = node->rb_right;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_right = right->rb_left))
+   rb_set_parent(right->rb_left, node);
+   right->rb_left = node;
+
+   rb_set_parent(right, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_left)
+   parent->rb_left = right;
+   else
+   parent->rb_right = right;
+   }
+   else
+   root->rb_node = right;
+   rb_set_parent(node, right);
 }
 
 static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *left = node->rb_left;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_left = left->rb_right))
-rb_set_parent(left->rb_right, node);
-left->rb_right = node;
-
-rb_set_parent(left, parent);
-
-if (parent)
-{
-if (node == parent->rb_right)
-parent->rb_right = left;
-else
-parent->rb_left = left;
-}
-else
-root->rb_node = left;
-rb_set_parent(node, left);
+   struct rb_node *left = node->rb_left;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_left = left->rb_right))
+   rb_set_parent(left->rb_right, node);
+   left->rb_right = node;
+
+   rb_set_parent(left, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_right)
+   parent->rb_right = left;
+   else
+   parent->rb_left = left;
+   }
+   else
+   root->rb_node = left;
+   rb_set_parent(node, left);
 }
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *parent, *gparent;
-
-while ((parent = rb_parent(node)) && rb_is_red(parent))
-{
-gparent = rb_parent(parent);
-
-if (parent == gparent->rb_left)
-{
-{
-register struct rb_node *uncle = gparent->rb_right;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_right == node)
-{
-register struct rb_node *tmp;
-__rb_rotate_left(parent, root);
-tmp = parent;
-parent = node;
-node = tmp;
-}
-
-rb_set_black(parent);
-rb_set_red(gparent);
-__rb_rotate_right(gparent, root);
-} else {
-{
-register struct rb_node *uncle = gparent->rb_left;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_left == node)
-{
-register struct rb_

[Xen-devel] [PATCH] AMD IOMMU: drop amd_iommu_setup_hwdom_device()

[Jan Beulich]

By moving its bridge special casing to amd_iommu_add_device(), we can
pass the latter to setup_hwdom_pci_devices() and at once consistently
handle bridges discovered at boot time as well as such reported by Dom0
later on.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -168,33 +168,6 @@ static void amd_iommu_setup_domain_devic
 }
 }
 
-static int __hwdom_init amd_iommu_setup_hwdom_device(
-u8 devfn, struct pci_dev *pdev)
-{
-int bdf = PCI_BDF2(pdev->bus, pdev->devfn);
-struct amd_iommu *iommu = find_iommu_for_device(pdev->seg, bdf);
-
-if ( unlikely(!iommu) )
-{
-/* Filter the bridge devices */
-if ( pdev->type == DEV_TYPE_PCI_HOST_BRIDGE )
-{
-AMD_IOMMU_DEBUG("Skipping host bridge %04x:%02x:%02x.%u\n",
-pdev->seg, PCI_BUS(bdf), PCI_SLOT(bdf),
-PCI_FUNC(bdf));
-return 0;
-}
-
-AMD_IOMMU_DEBUG("No iommu for device %04x:%02x:%02x.%u\n",
-pdev->seg, pdev->bus,
-PCI_SLOT(devfn), PCI_FUNC(devfn));
-return -ENODEV;
-}
-
-amd_iommu_setup_domain_device(pdev->domain, iommu, devfn, pdev);
-return 0;
-}
-
 int __init amd_iov_detect(void)
 {
 INIT_LIST_HEAD(&amd_iommu_head);
@@ -273,6 +246,8 @@ static int amd_iommu_domain_init(struct
 return 0;
 }
 
+static int amd_iommu_add_device(u8 devfn, struct pci_dev *pdev);
+
 static void __hwdom_init amd_iommu_hwdom_init(struct domain *d)
 {
 unsigned long i; 
@@ -318,7 +293,7 @@ static void __hwdom_init amd_iommu_hwdom
 IOMMU_MMIO_REGION_LENGTH - 1)) )
 BUG();
 
-setup_hwdom_pci_devices(d, amd_iommu_setup_hwdom_device);
+setup_hwdom_pci_devices(d, amd_iommu_add_device);
 }
 
 void amd_iommu_disable_domain_device(struct domain *domain,
@@ -490,15 +465,25 @@ static int amd_iommu_add_device(u8 devfn
 {
 struct amd_iommu *iommu;
 u16 bdf;
+
 if ( !pdev->domain )
 return -EINVAL;
 
 bdf = PCI_BDF2(pdev->bus, pdev->devfn);
 iommu = find_iommu_for_device(pdev->seg, bdf);
-if ( !iommu )
+if ( unlikely(!iommu) )
 {
-AMD_IOMMU_DEBUG("Fail to find iommu."
-" %04x:%02x:%02x.%u cannot be assigned to dom%d\n",
+/* Filter bridge devices. */
+if ( pdev->type == DEV_TYPE_PCI_HOST_BRIDGE &&
+ is_hardware_domain(pdev->domain) )
+{
+AMD_IOMMU_DEBUG("Skipping host bridge %04x:%02x:%02x.%u\n",
+pdev->seg, PCI_BUS(bdf), PCI_SLOT(bdf),
+PCI_FUNC(bdf));
+return 0;
+}
+
+AMD_IOMMU_DEBUG("No iommu for %04x:%02x:%02x.%u; cannot be handed to 
d%d\n",
 pdev->seg, pdev->bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
 pdev->domain->domain_id);
 return -ENODEV;




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] IOMMU/PCI: make a few functions static

[Jan Beulich]

Add forward declarations in order to not move things around.

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -587,6 +587,10 @@ static void pci_enable_acs(struct pci_de
 pci_conf_write16(seg, bus, dev, func, pos + PCI_ACS_CTRL, ctrl);
 }
 
+static int iommu_add_device(struct pci_dev *pdev);
+static int iommu_enable_device(struct pci_dev *pdev);
+static int iommu_remove_device(struct pci_dev *pdev);
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
const struct pci_dev_info *info, nodeid_t node)
 {
@@ -1254,7 +1258,7 @@ void iommu_read_msi_from_ire(
 iommu_get_ops()->read_msi_from_ire(msi_desc, msg);
 }
 
-int iommu_add_device(struct pci_dev *pdev)
+static int iommu_add_device(struct pci_dev *pdev)
 {
 const struct domain_iommu *hd;
 int rc;
@@ -1285,7 +1289,7 @@ int iommu_add_device(struct pci_dev *pde
 }
 }
 
-int iommu_enable_device(struct pci_dev *pdev)
+static int iommu_enable_device(struct pci_dev *pdev)
 {
 const struct domain_iommu *hd;
 
@@ -1302,7 +1306,7 @@ int iommu_enable_device(struct pci_dev *
 return hd->platform_ops->enable_device(pci_to_dev(pdev));
 }
 
-int iommu_remove_device(struct pci_dev *pdev)
+static int iommu_remove_device(struct pci_dev *pdev)
 {
 const struct domain_iommu *hd;
 u8 devfn;
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -53,9 +53,6 @@ extern unsigned int iommu_dev_iotlb_time
 
 int iommu_setup(void);
 
-int iommu_add_device(struct pci_dev *pdev);
-int iommu_enable_device(struct pci_dev *pdev);
-int iommu_remove_device(struct pci_dev *pdev);
 int iommu_domain_init(struct domain *d);
 void iommu_hwdom_init(struct domain *d);
 void iommu_domain_destroy(struct domain *d);




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 01/17] rbtree: changes to align the coding conventions with Linux tree

[Jan Beulich]

>>> On 14.07.17 at 15:47,  wrote:
> The patch aligns the coding style of rbtree related files to Linux coding
> conventions to have limited conflicts in future while porting from Linux 
> tree.
> 
> Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h
> rbtree.h file includes commented inline functions in order to have complete
> replica from Linux tree.
> 
> Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c
> rbtree.c has comment changes in header note for the same reason.

And other than that _only_ style changes now?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v1] xen/grant-table: log the lack of grants

[Julien Grall]

On 07/13/2017 06:42 PM, Wengang wrote:

Hi,


Hello,



Anyone can you please review this patch?


Most of the developer community were at Xen Summit this week, so you may 
expect some delay in review.


However, in general it is better to CC relevant maintainers of your code 
to raise attention on your patch. I did it for you this time.


Cheers,



thanks,

wengang


On 07/07/2017 11:23 AM, Wengang Wang wrote:

log a message when we enter this situation:
1) we already allocated the max number of available grants from 
hypervisor

and
2) we still need more (but the request fails because of 1)).

Sometimes the lack of grants causes IO hangs in xen_blkfront devices.
Adding this log would help debuging.

Signed-off-by: Wengang Wang 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Junxiao Bi 
---
  drivers/xen/grant-table.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index d6786b8..2c6a911 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -42,6 +42,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
@@ -1072,8 +1073,14 @@ static int gnttab_expand(unsigned int req_entries)
  cur = nr_grant_frames;
  extra = ((req_entries + (grefs_per_grant_frame-1)) /
   grefs_per_grant_frame);
-if (cur + extra > gnttab_max_grant_frames())
+if (cur + extra > gnttab_max_grant_frames()) {
+pr_warn_ratelimited("xen/grant-table: max_grant_frames reached"
+" cur=%u extra=%u limit=%u"
+" gnttab_free_count=%u req_entries=%u\n",
+cur, extra, gnttab_max_grant_frames(),
+gnttab_free_count, req_entries);
  return -ENOSPC;
+}
  rc = gnttab_map(cur, cur + extra - 1);
  if (rc == 0)



___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Dump FDT for Linux Guest from Xen

[Julien Grall]

On 07/13/2017 12:40 PM, Waseem, Amna wrote:

Hello All,


Hello,



Is there a way to dump FDT prepared by Xen given to Linux Guest while 
booting Domain 0.



I want to see flattened device tree created by Xen by remapping I/O and 
IRQs for Guest.



Is there a simple API to dump the flattened device?


I am not sure there is a facility in the Linux kernel to dump the 
device-tree. However, you can do it from the user space with:


dtc -I fs /proc/device-tree -O dts

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Dump FDT for Linux Guest from Xen

[Waseem, Amna]

Thanks Julien


From: Julien Grall 
Sent: Friday, July 14, 2017 4:20 PM
To: Waseem, Amna; sstabell...@kernel.org; xen-devel@lists.xen.org
Subject: Re: [Xen-devel] Dump FDT for Linux Guest from Xen

On 07/13/2017 12:40 PM, Waseem, Amna wrote:
> Hello All,

Hello,

>
> Is there a way to dump FDT prepared by Xen given to Linux Guest while
> booting Domain 0.
>
>
> I want to see flattened device tree created by Xen by remapping I/O and
> IRQs for Guest.
>
>
> Is there a simple API to dump the flattened device?

I am not sure there is a facility in the Linux kernel to dump the
device-tree. However, you can do it from the user space with:

dtc -I fs /proc/device-tree -O dts

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7 01/17] rbtree: changes to align the code with Linux tree

[Praveen Kumar]

The patch aligns the code of rbtree related files with Linux tree.
This will minimize the conflicts during any future porting from Linux tree.

Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h
This includes addition of commented inline functions in rbtree.h, to have
complete replica from Linux tree.

Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c
This includes updates in comments in header note in rbtree.c.

Signed-off-by: Praveen Kumar 
---
 xen/common/rbtree.c  | 633 ---
 xen/include/xen/rbtree.h | 116 +++--
 2 files changed, 413 insertions(+), 336 deletions(-)

diff --git a/xen/common/rbtree.c b/xen/common/rbtree.c
index d91d651d77..167ebfdc4d 100644
--- a/xen/common/rbtree.c
+++ b/xen/common/rbtree.c
@@ -14,7 +14,8 @@
   GNU General Public License for more details.
 
   You should have received a copy of the GNU General Public License
-  along with this program; If not, see .
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 
   linux/lib/rbtree.c
 */
@@ -24,261 +25,261 @@
 
 static void __rb_rotate_left(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *right = node->rb_right;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_right = right->rb_left))
-rb_set_parent(right->rb_left, node);
-right->rb_left = node;
-
-rb_set_parent(right, parent);
-
-if (parent)
-{
-if (node == parent->rb_left)
-parent->rb_left = right;
-else
-parent->rb_right = right;
-}
-else
-root->rb_node = right;
-rb_set_parent(node, right);
+   struct rb_node *right = node->rb_right;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_right = right->rb_left))
+   rb_set_parent(right->rb_left, node);
+   right->rb_left = node;
+
+   rb_set_parent(right, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_left)
+   parent->rb_left = right;
+   else
+   parent->rb_right = right;
+   }
+   else
+   root->rb_node = right;
+   rb_set_parent(node, right);
 }
 
 static void __rb_rotate_right(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *left = node->rb_left;
-struct rb_node *parent = rb_parent(node);
-
-if ((node->rb_left = left->rb_right))
-rb_set_parent(left->rb_right, node);
-left->rb_right = node;
-
-rb_set_parent(left, parent);
-
-if (parent)
-{
-if (node == parent->rb_right)
-parent->rb_right = left;
-else
-parent->rb_left = left;
-}
-else
-root->rb_node = left;
-rb_set_parent(node, left);
+   struct rb_node *left = node->rb_left;
+   struct rb_node *parent = rb_parent(node);
+
+   if ((node->rb_left = left->rb_right))
+   rb_set_parent(left->rb_right, node);
+   left->rb_right = node;
+
+   rb_set_parent(left, parent);
+
+   if (parent)
+   {
+   if (node == parent->rb_right)
+   parent->rb_right = left;
+   else
+   parent->rb_left = left;
+   }
+   else
+   root->rb_node = left;
+   rb_set_parent(node, left);
 }
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
 {
-struct rb_node *parent, *gparent;
-
-while ((parent = rb_parent(node)) && rb_is_red(parent))
-{
-gparent = rb_parent(parent);
-
-if (parent == gparent->rb_left)
-{
-{
-register struct rb_node *uncle = gparent->rb_right;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_right == node)
-{
-register struct rb_node *tmp;
-__rb_rotate_left(parent, root);
-tmp = parent;
-parent = node;
-node = tmp;
-}
-
-rb_set_black(parent);
-rb_set_red(gparent);
-__rb_rotate_right(gparent, root);
-} else {
-{
-register struct rb_node *uncle = gparent->rb_left;
-if (uncle && rb_is_red(uncle))
-{
-rb_set_black(uncle);
-rb_set_black(parent);
-rb_set_red(gparent);
-node = gparent;
-continue;
-}
-}
-
-if (parent->rb_left == node)
-{
-register struct rb_node *

Re: [Xen-devel] [PATCH v4 6/9] xen/vpci: add handlers to map the BARs

[Jan Beulich]

>>> On 30.06.17 at 17:01,  wrote:
> Introduce a set of handlers that trap accesses to the PCI BARs and the command
> register, in order to emulate BAR sizing and BAR relocation.

I don't think "emulate" is the right term here - you really don't mean to
change anything, you only want to snoop Dom0 writes.

> --- /dev/null
> +++ b/xen/drivers/vpci/header.c
> @@ -0,0 +1,473 @@
> +/*
> + * Generic functionality for handling accesses to the PCI header from the
> + * configuration space.
> + *
> + * Copyright (C) 2017 Citrix Systems R&D
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define MAPPABLE_BAR(x) \
> +(((x)->type == VPCI_BAR_MEM32 || (x)->type == VPCI_BAR_MEM64_LO ||  \
> + ((x)->type == VPCI_BAR_ROM && (x)->enabled)) &&\
> + (x)->addr != INVALID_PADDR)
> +
> +static struct rangeset *vpci_get_bar_memory(const struct domain *d,
> +const struct vpci_bar *map)
> +{
> +const struct pci_dev *pdev;
> +struct rangeset *mem = rangeset_new(NULL, NULL, 0);
> +int rc;
> +
> +if ( !mem )
> +return ERR_PTR(-ENOMEM);
> +
> +/*
> + * Create a rangeset that represents the current BAR memory region
> + * and compare it against all the currently active BAR memory regions.
> + * If an overlap is found, subtract it from the region to be
> + * mapped/unmapped.
> + *
> + * NB: the rangeset uses frames, and if start and end addresses are
> + * equal it means only one frame is used, that's why PFN_DOWN is used
> + * to calculate the end of the rangeset.
> + */

That explanation doesn't seem to fit: Did you perhaps mean to
point out that rangeset ranges are inclusive ones?

> +rc = rangeset_add_range(mem, PFN_DOWN(map->addr),
> +PFN_DOWN(map->addr + map->size));

Don't you need to subtract 1 here (and elsewhere below)?

> +if ( rc )
> +{
> +rangeset_destroy(mem);
> +return ERR_PTR(rc);
> +}
> +
> +list_for_each_entry(pdev, &d->arch.pdev_list, domain_list)
> +{
> +uint16_t cmd = pci_conf_read16(pdev->seg, pdev->bus,
> +   PCI_SLOT(pdev->devfn),
> +   PCI_FUNC(pdev->devfn),
> +   PCI_COMMAND);

This is quite a lot of overhead - a loop over all devices plus a config
space read on each one. What state the memory decode bit is in
could be recorded in the ->enabled flag, couldn't it? And devices on
different sub-branches of the topology can't possibly have
overlapping entries that we need to worry about, as the bridge
windows would suppress actual accesses.

> +unsigned int i;
> +
> +/* Check if memory decoding is enabled. */
> +if ( !(cmd & PCI_COMMAND_MEMORY) )
> +continue;
> +
> +for ( i = 0; i < ARRAY_SIZE(pdev->vpci->header.bars); i++ )
> +{
> +const struct vpci_bar *bar = &pdev->vpci->header.bars[i];
> +
> +if ( bar == map || !MAPPABLE_BAR(bar) ||
> + !rangeset_overlaps_range(mem, PFN_DOWN(bar->addr),
> +  PFN_DOWN(bar->addr + bar->size)) )
> +continue;
> +
> +rc = rangeset_remove_range(mem, PFN_DOWN(bar->addr),
> +   PFN_DOWN(bar->addr + bar->size));

I'm struggling to convince myself of the correctness of this approach
(including other code further down which is also involved). I think you
should have taken the time to add a few words on the approach
chosen to the description. For example, it doesn't look like things will
go right if the device being dealt with has two BARs both using part
of the same page.

> +static int vpci_modify_bar(struct domain *d, const struct vpci_bar *bar,
> +   const bool map)
> +{
> +struct rangeset *mem;
> +struct map_data data = { .d = d, .map = map };
> +int rc;
> +
> +ASSERT(MAPPABLE_BAR(bar));
> +
> +mem = vpci_get_bar_memory(d, bar);
> +if ( IS_ERR(mem) )
> +return -PTR_ERR(mem);

The negation looks wrong to me.

> +static void vpci_cmd_write(struct pci_dev *pdev, unsigned int reg,
> +   union vpci_val val, void *data)

Re: [Xen-devel] [PATCH v7 01/17] rbtree: changes to align the code with Linux tree

[Jan Beulich]

>>> On 14.07.17 at 16:57,  wrote:
> The patch aligns the code of rbtree related files with Linux tree.
> This will minimize the conflicts during any future porting from Linux tree.
> 
> Linux commit till f4b477c47332367d35686bd2b808c2156b96d7c7 for rbtree.h
> This includes addition of commented inline functions in rbtree.h, to have
> complete replica from Linux tree.
> 
> Linux commit till 4c60117811171d867d4f27f17ea07d7419d45dae for rbtree.c
> This includes updates in comments in header note in rbtree.c.
> 
> Signed-off-by: Praveen Kumar 
> ---

This time it is completely unclear what the difference to v6 is. I
think it was pointed out before that below this marker there should
be a brief description of what changed over the previous version.
Also please slow down your submission rate. Give people time to
look at what you've sent. If you get feedback from one person,
someone else may disagree a few hours later. You don't want to
ping-pong between variants.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monné]

On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
> > --- /dev/null
> > +++ b/tools/tests/vpci/Makefile
> > @@ -0,0 +1,40 @@
> > +
> > +XEN_ROOT=$(CURDIR)/../../..
> > +include $(XEN_ROOT)/tools/Rules.mk
> > +
> > +TARGET := test_vpci
> > +
> > +.PHONY: all
> > +all: $(TARGET)
> > +
> > +.PHONY: run
> > +run: $(TARGET)
> > +./$(TARGET) > $(TARGET).out
> 
> Is this a good way to run a test? Aiui it'll result in there not being
> anything visible immediately; one has to go look at the produced file.
> I'd suggest to leave it to the person invoking "make run" whether to
> redirect output.

OK, this is based in the hpet testing code, that does this. I'm fine
with not redirecting the output.

> > +$(TARGET): vpci.c vpci.h list.h
> > +$(HOSTCC) -g -o $@ vpci.c main.c
> 
> If you compile main.c, why is there no dependency on it? And how about
> emul.h?

I didn't add such dependencies because those files are not the result
of any other targets, but I agree it's better to explicitly list them.

> > +.PHONY: clean
> > +clean:
> > +rm -rf $(TARGET) $(TARGET).out *.o *~ vpci.h vpci.c list.h
> > +
> > +.PHONY: distclean
> > +distclean: clean
> > +
> > +.PHONY: install
> > +install:
> > +
> > +vpci.h: $(XEN_ROOT)/xen/include/xen/vpci.h
> > +sed -e '/#include/d' <$< >$@
> 
> Couldn't you combine this and list.h's rule into a pattern one?

Yes, I think so, let me try.

> > --- /dev/null
> > +++ b/tools/tests/vpci/emul.h
> > @@ -0,0 +1,117 @@
> > +/*
> > + * Unit tests for the generic vPCI handler code.
> > + *
> > + * Copyright (C) 2017 Citrix Systems R&D
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms and conditions of the GNU General Public
> > + * License, version 2, as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public
> > + * License along with this program; If not, see 
> > .
> > + */
> > +
> > +#ifndef _TEST_VPCI_
> > +#define _TEST_VPCI_
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define container_of(ptr, type, member) ({  \
> > +typeof(((type *)0)->member) *__mptr = (ptr);\
> > +(type *)((char *)__mptr - offsetof(type, member));  \
> 
> I don't know what tools maintainers think about such name space
> violations; in hypervisor code I'd ask you to avoid leading underscores
> in macro local variables (same in min()/max() and elsewhere then).

OK. container_of, max and min and verbatim copies of the macros in
xen/include/xen/kernel.h, with the style adjusted in the container_of
case IIRC (as requested in the previous review).

> > +/* Read a 32b register using all possible sizes. */
> > +void multiread4(unsigned int reg, uint32_t val)
> > +{
> > +unsigned int i;
> > +
> > +/* Read using bytes. */
> > +for ( i = 0; i < 4; i++ )
> > +VPCI_READ_CHECK(reg + i, 1, (val >> (i * 8)) & UINT8_MAX);
> > +
> > +/* Read using 2bytes. */
> > +for ( i = 0; i < 2; i++ )
> > +VPCI_READ_CHECK(reg + i * 2, 2, (val >> (i * 2 * 8)) & UINT16_MAX);
> > +
> > +VPCI_READ_CHECK(reg, 4, val);
> > +}
> > +
> > +void multiwrite4_check(unsigned int reg, uint32_t val)
> 
> Naming question again: Why the _check suffix here, but not on the read
> function above?

Right, I guess it's clearer to add the _check prefix to both. I didn't
add it to the read one because I felt it was already implicit, while
on the write one not so much.

> > +{
> > +unsigned int i;
> > +
> > +/* Write using bytes. */
> > +for ( i = 0; i < 4; i++ )
> > +VPCI_WRITE_CHECK(reg + i, 1, (val >> (i * 8)) & UINT8_MAX);
> > +multiread4(reg, val);
> > +
> > +/* Write using 2bytes. */
> > +for ( i = 0; i < 2; i++ )
> > +VPCI_WRITE_CHECK(reg + i * 2, 2, (val >> (i * 2 * 8)) & 
> > UINT16_MAX);
> > +multiread4(reg, val);
> > +
> > +VPCI_WRITE_CHECK(reg, 4, val);
> > +multiread4(reg, val);
> > +}
> 
> Wouldn't it be better to vary the value written between the individual
> sizes? Perhaps move the 32-bit write between the two loops, using ~val?
> Otherwise you won't know whether what you read back is a result of the
> writes you actually mean to test or earlier ones?

So storing a new value in val between each size test? I could even use
something randomly generated.

> > +int
> > +main(int argc, char **argv)
> > +{
> > +/* Index storage by offset. */
> > +uint32_t r0 = 0xdeadbeef;
> > +uint8> +uint16_t r20[2] = { 0 };
> 
> Just { } will suffice.
> 
> > + 

Re: [Xen-devel] [RFC 5/6] ACPI: arm: Support for IORT

[Jan Beulich]

>>> On 08.06.17 at 21:30,  wrote:
> Verbatim files from Linux kernel.

This is pretty odd - they won't even come close to compile in that
shape. But if the ARM folks are happy with it to be done this way,
so be it.

> iort.c: commit ca78d3173cff:Merge tag 'arm64-upstream'

Please don't name merge commits - there must be a real one (or
perhaps it's more than one, but anyway).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

[Jan Beulich]

>>> On 08.06.17 at 21:30,  wrote:
> Add limited support for parsing IORT table to initialize SMMU devices.
> 
> Signed-off-by: Sameer Goel 
> ---
>  xen/arch/arm/setup.c|   3 +
>  xen/drivers/acpi/Makefile   |   1 +
>  xen/drivers/acpi/arm/Makefile   |   1 +
>  xen/drivers/acpi/arm/iort.c | 232 
> +++-

With the amount of changes done to this file I question even more
the value of first pulling in the plain Linux commits.

> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -9,7 +9,12 @@
>  #include 
>  
>  #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
> -#define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
> +#define WARN_ON(p) ({  \
> +int __ret_warn_on = !!(p); \
> +if (unlikely(__ret_warn_on))   \
> +WARN();\
> +unlikely(__ret_warn_on);   \
> +})

This has nothing to do with the intention of the patch. If you want
WARN_ON()s behavior to change, please submit a separate patch
doing just that.

> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -88,6 +88,7 @@ struct pci_dev {
>  #define PT_FAULT_THRESHOLD 10
>  } fault;
>  u64 vf_rlen[6];
> +struct device dev;

Why? Please rationalize your changes in the patch description (and
perhaps split them).

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-4.9 test] 111786: regressions - FAIL

[osstest service owner]

flight 111786 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111786/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111411
 build-armhf-libvirt   6 libvirt-build  fail in 111763 REGR. vs. 111411

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail in 111737 
pass in 111786
 test-arm64-arm64-xl-credit2   7 xen-boot fail in 111763 pass in 111786
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111737
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111763
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 111763

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 111763 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 111763 n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 111763 n/a
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 111411
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111737 
like 111411
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 111763 like 111411
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 111411
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111411
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

[Jan Beulich]

>>> On 14.07.17 at 17:33,  wrote:
> On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
>> > +#define container_of(ptr, type, member) ({  \
>> > +typeof(((type *)0)->member) *__mptr = (ptr);\
>> > +(type *)((char *)__mptr - offsetof(type, member));  \
>> 
>> I don't know what tools maintainers think about such name space
>> violations; in hypervisor code I'd ask you to avoid leading underscores
>> in macro local variables (same in min()/max() and elsewhere then).
> 
> OK. container_of, max and min and verbatim copies of the macros in
> xen/include/xen/kernel.h, with the style adjusted in the container_of
> case IIRC (as requested in the previous review).

Well, that's one of the frequent problems we have: People copy and
paste things without questioning them. We only make things worse if
we clone code we wouldn't permit in anymore nowadays.

>> > +{
>> > +unsigned int i;
>> > +
>> > +/* Write using bytes. */
>> > +for ( i = 0; i < 4; i++ )
>> > +VPCI_WRITE_CHECK(reg + i, 1, (val >> (i * 8)) & UINT8_MAX);
>> > +multiread4(reg, val);
>> > +
>> > +/* Write using 2bytes. */
>> > +for ( i = 0; i < 2; i++ )
>> > +VPCI_WRITE_CHECK(reg + i * 2, 2, (val >> (i * 2 * 8)) & 
>> > UINT16_MAX);
>> > +multiread4(reg, val);
>> > +
>> > +VPCI_WRITE_CHECK(reg, 4, val);
>> > +multiread4(reg, val);
>> > +}
>> 
>> Wouldn't it be better to vary the value written between the individual
>> sizes? Perhaps move the 32-bit write between the two loops, using ~val?
>> Otherwise you won't know whether what you read back is a result of the
>> writes you actually mean to test or earlier ones?
> 
> So storing a new value in val between each size test? I could even use
> something randomly generated.

Random data is bad for reproducibility (if e.g. you want to debug a
case where the test suddenly fails).

>> > +/*
>> > + * Test all possible read/write size combinations.
>> > + *
>> > + * Populate 128bits (16B) with 1B registers, 160bits (20B) with 2B
>> > + * registers, and finally 192bits (24B) with 4B registers.
>> 
>> I can't see how the numbers here are in line with the code this is
>> meant to describe. Perhaps this is a leftover from an earlier variant
>> of the code?
> 
> I'm not sure I understand this, the registers (or layout) described in
> this comment are just added below the comment. Would you like me to
> first add the registers and place the comment afterwards?

No, my point is that code that follows this doesn't populate as
many bits as the comment says. From what I understand, you
use 4 byte registers, 2 word ones, and one dword one.

>> > --- a/xen/arch/arm/xen.lds.S
>> > +++ b/xen/arch/arm/xen.lds.S
>> > @@ -41,6 +41,9 @@ SECTIONS
>> >  
>> >. = ALIGN(PAGE_SIZE);
>> >.rodata : {
>> > +   __start_vpci_array = .;
>> > +   *(.rodata.vpci)
>> > +   __end_vpci_array = .;
>> 
>> Do you really need this (unconditionally)?
> 
> Right, this should have a ifdef CONFIG_PCI.

CONFIG_HAS_PCI for one, and then ARM doesn't select this at
all. Hence the question.

>> > +static int vpci_access_check(unsigned int reg, unsigned int len)
>> 
>> The way you use it, this function want to return bool.
>> 
>> > +void hvm_pci_decode_addr(unsigned int cf8, unsigned int addr,
>> > + unsigned int *bus, unsigned int *slot,
>> > + unsigned int *func, unsigned int *reg)
>> 
>> Since you return nothing right now, how about avoid one of the
>> indirections? Best candidate would probably be the register value.
> 
> I don't really like functions that return some data in the return
> value (if it's not an error code) and some other data in parameters.

Well, okay, I view it the other way around - return by indirection
is to be used if return by value is not reasonable (too much data).
Hence it's kind of an overflow to me, not a replacement.

>> > +int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
>> 
>> As pointed out in reply to an earlier version, this lacks a prereq
>> change: setup_one_hwdom_device() needs to be marked __hwdom_init. And
>> then, now that you have the annotation here, the placement of the
>> array in the linker script should depend on whether __hwdom_init is an
>> alias of __init.
> 
> The __hwdom_init prefix is dropped shortly from this function (patch
> #3), but I agree on sending a pre-patch to address
> setup_one_hwdom_device.

I have one ready, btw.

> The linker script I'm not sure it's worth modifying, by the end of the
> series the list of handlers must reside in .rodata.

As per the reply to that later patch, I'm not yet convinced that
these annotations will go away. Hence I'd prefer if things were
handled fully correctly here.

>> > +static uint32_t vpci_read_hw(unsigned int seg, unsigned int bus,
>> > + unsigned int slot, unsigned int func,
>> > +   

Re: [Xen-devel] [PATCH v4 2/9] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

[Roger Pau Monné]

On Thu, Jul 13, 2017 at 02:15:26PM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne  06/30/17 5:02 PM >>>
> > @@ -1041,6 +1043,24 @@ static int __init pvh_setup_acpi(struct domain *d, 
> > paddr_t start_info)
> >  return 0;
> >  }
> >  
> > +int __init pvh_setup_mmcfg(struct domain *d)
> 
> Didn't I point out that __init van't be correct here, and instead this
> needs to be __hwdom_init? I can see that the only current caller is
> __init, but that merely suggests there is a second call missing.

Mostly likely, and I failed to update it.

AFAIK it's not possible to build a late PVH hwdom (or I don't see
how), so I guess that missing call should be added if we ever support
that.

> > +{
> > +unsigned int i;
> > +int rc;
> > +
> > +for ( i = 0; i < pci_mmcfg_config_num; i++ )
> > +{
> > +rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
> > + 
> > pci_mmcfg_config[i].start_bus_number,
> > + 
> > pci_mmcfg_config[i].end_bus_number,
> > + pci_mmcfg_config[i].pci_segment);
> > +if ( rc )
> > +return rc;
> 
> I would make this a best effort thing, i.e. issue a log message upon
> failure but continue the loop. There's a good chance Dom0 will still
> be able to come up.

It's worth a try certainly.

> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -261,11 +261,11 @@ void register_g2m_portio_handler(struct domain *d)
> >  static int vpci_access_check(unsigned int reg, unsigned int len)
> >  {
> >  /* Check access size. */
> > -if ( len != 1 && len != 2 && len != 4 )
> > +if ( len != 1 && len != 2 && len != 4 && len != 8 )
> >  return -EINVAL;
> >  
> > -/* Check if access crosses a double-word boundary. */
> > -if ( (reg & 3) + len > 4 )
> > +/* Check if access crosses a double-word boundary or it's not aligned. 
> > */
> > +if ( (len <= 4 && (reg & 3) + len > 4) || (len == 8 && (reg & 3) != 0) 
> > )
> >  return -EINVAL;
> 
> For one I suppose you mean "& 7" in the 8-byte case.

I cannot find anything in the PCIe 3.1A specification that says that
8B accesses should be aligned. AFAICT it only mentions that accesses
should not cross double-word (4B) boundaries, because it's not
mandatory for the root complex to support such accesses.

> And then I don't
> understand why you permit mis-aligned 2-byte writes, but not mis-aligned
> 4-byte ones as long as they fall withing a quad-word. Any such asymmetry
> needs at least a comment.

IIRC reading soemthing like that on the Mindshare PCI book, but I
don't have it at hand. Will check on Monday. Anyway, I cannot seem to
find any specific set of restrictions in the PCI/PCIe specifications,
apart from the one that accesses should not cross a double-word
boundary.

I'm fine with only allowing accesses aligned to their respective
sizes, but I think I should add a comment somewhere regarding where
this has been picked from. Do you have any references from the
AMD/Intel SDMs maybe?

> > @@ -398,6 +398,188 @@ void register_vpci_portio_handler(struct domain *d)
> >  handler->ops = &vpci_portio_ops;
> >  }
> >  
> > +struct hvm_mmcfg {
> > +paddr_t addr;
> > +size_t size;
> 
> paddr_t and size_t don't really fit together, most notably on 32-bit.
> As I don't think any individual range can possibly be 4Gb or larger, I
> think unsigned int would suffice here.
> 
> > +unsigned int bus;
> > +unsigned int segment;
> 
> Depending on how many instances of this structure we expect, it may be
> worthwhile to limit these two to 8 and 16 bits respectively.

Hm, so far the boxes I've tested on only had 1 MCFG area, but it's
probably best to change the types and the order, so that there's no
padding.

> > +/* Handlers to trap PCI ECAM config accesses. */
> 
> An "ECAM" did survive here.

Shame, I should have grepped the patch.

> > +static const struct hvm_mmcfg *vpci_mmcfg_find(struct domain *d,
> > +   unsigned long addr)
> 
> paddr_t (to match the structure field)
> 
> > +static void vpci_mmcfg_decode_addr(const struct hvm_mmcfg *mmcfg,
> > +   unsigned long addr, unsigned int *bus,
> 
> Same here (and it seems more below). Also, just like in patch 1,
> perhaps return the register by value rather than via indirection.
> 
> > +   unsigned int *slot, unsigned int *func,
> > +   unsigned int *reg)
> > +{
> > +addr -= mmcfg->addr;
> > +*bus = ((addr >> 20) & 0xff) + mmcfg->bus;
> > +*slot = (addr >> 15) & 0x1f;
> > +*func = (addr >> 12) & 0x7;
> > +*reg = addr & 0xfff;
> 
> Iirc there already was a comment to use manifest constants or macros
> here.

Yes, going to fix that.

> > +static int vpci_mmcfg_accept(struct vcpu *v, unsigned long addr)
> > +{
> > +struct domain *d =

Re: [Xen-devel] [PATCH v4 1/9] xen/vpci: introduce basic handlers to trap accesses to the PCI config space

[Roger Pau Monné]

On Fri, Jul 14, 2017 at 10:01:54AM -0600, Jan Beulich wrote:
> >>> On 14.07.17 at 17:33,  wrote:
> > On Thu, Jul 13, 2017 at 08:36:18AM -0600, Jan Beulich wrote:
> >> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
> >> > +#define container_of(ptr, type, member) ({  \
> >> > +typeof(((type *)0)->member) *__mptr = (ptr);\
> >> > +(type *)((char *)__mptr - offsetof(type, member));  \
> >> 
> >> I don't know what tools maintainers think about such name space
> >> violations; in hypervisor code I'd ask you to avoid leading underscores
> >> in macro local variables (same in min()/max() and elsewhere then).
> > 
> > OK. container_of, max and min and verbatim copies of the macros in
> > xen/include/xen/kernel.h, with the style adjusted in the container_of
> > case IIRC (as requested in the previous review).
> 
> Well, that's one of the frequent problems we have: People copy and
> paste things without questioning them. We only make things worse if
> we clone code we wouldn't permit in anymore nowadays.

Sorry, that comment sounded like a justification, which is not
intended. I was just explaining how that ended up there the way it
is.

> >> > +/*
> >> > + * Test all possible read/write size combinations.
> >> > + *
> >> > + * Populate 128bits (16B) with 1B registers, 160bits (20B) with 2B
> >> > + * registers, and finally 192bits (24B) with 4B registers.
> >> 
> >> I can't see how the numbers here are in line with the code this is
> >> meant to describe. Perhaps this is a leftover from an earlier variant
> >> of the code?
> > 
> > I'm not sure I understand this, the registers (or layout) described in
> > this comment are just added below the comment. Would you like me to
> > first add the registers and place the comment afterwards?
> 
> No, my point is that code that follows this doesn't populate as
> many bits as the comment says. From what I understand, you
> use 4 byte registers, 2 word ones, and one dword one.

OK, I think I see what you mean. The comment makes it looks I'm
populating 128bits, which what I indented to say is:

[...]
 * Place 4 1B registers at 128bits (16B), 2 2B registers at 160bits (20B)
 * and finally 1 4B register at 192bits (24B).

> >> > --- a/xen/arch/arm/xen.lds.S
> >> > +++ b/xen/arch/arm/xen.lds.S
> >> > @@ -41,6 +41,9 @@ SECTIONS
> >> >  
> >> >. = ALIGN(PAGE_SIZE);
> >> >.rodata : {
> >> > +   __start_vpci_array = .;
> >> > +   *(.rodata.vpci)
> >> > +   __end_vpci_array = .;
> >> 
> >> Do you really need this (unconditionally)?
> > 
> > Right, this should have a ifdef CONFIG_PCI.
> 
> CONFIG_HAS_PCI for one, and then ARM doesn't select this at
> all. Hence the question.

I think it would be better to just add it now? The code is not really
x86 specific (although it's only used by x86 ATM). IMHO adding a
CONFIG_HAS_PCI to both linker scripts is the best solution.

> >> > +static int vpci_access_check(unsigned int reg, unsigned int len)
> >> 
> >> The way you use it, this function want to return bool.
> >> 
> >> > +void hvm_pci_decode_addr(unsigned int cf8, unsigned int addr,
> >> > + unsigned int *bus, unsigned int *slot,
> >> > + unsigned int *func, unsigned int *reg)
> >> 
> >> Since you return nothing right now, how about avoid one of the
> >> indirections? Best candidate would probably be the register value.
> > 
> > I don't really like functions that return some data in the return
> > value (if it's not an error code) and some other data in parameters.
> 
> Well, okay, I view it the other way around - return by indirection
> is to be used if return by value is not reasonable (too much data).
> Hence it's kind of an overflow to me, not a replacement.
> 
> >> > +int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
> >> 
> >> As pointed out in reply to an earlier version, this lacks a prereq
> >> change: setup_one_hwdom_device() needs to be marked __hwdom_init. And
> >> then, now that you have the annotation here, the placement of the
> >> array in the linker script should depend on whether __hwdom_init is an
> >> alias of __init.
> > 
> > The __hwdom_init prefix is dropped shortly from this function (patch
> > #3), but I agree on sending a pre-patch to address
> > setup_one_hwdom_device.
> 
> I have one ready, btw.
> 
> > The linker script I'm not sure it's worth modifying, by the end of the
> > series the list of handlers must reside in .rodata.
> 
> As per the reply to that later patch, I'm not yet convinced that
> these annotations will go away. Hence I'd prefer if things were
> handled fully correctly here.
> 
> >> > +static uint32_t vpci_read_hw(unsigned int seg, unsigned int bus,
> >> > + unsigned int slot, unsigned int func,
> >> > + unsigned int reg, uint32_t size)
> >> > +{
> >> > +uint32_t data;
> >> > +
> >> > +switch ( size )
> >> > +{
> >> > +case 4:
> >> > +  

Re: [Xen-devel] Renesas R-Car Gen3 SoCs earlyprintk support.

[Andrii Anisov]

Hello Julien,

On 05.07.17 19:50, Julien Grall wrote:
Yocto aside, I think updating the wiki pages don't take too long. It 
is just adding:


   * Adding a point of contact in 
https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results
   * Make sure Salvator-X webpage is accurate and doesn't contain 
non-upstream pointer (i.e dropping this yocto link contain security 
flaw).

I've updated the wiki [1]. Point of contact in [2] was updated earlier.

[1] 
https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X

[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test/Results

--

*Andrii Anisov*


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] Question about Xen on ARM

[Christopher Lambert]

Hello,
I would like to test xen on an ARM target with one linux (as dom0) and one 
android (as domU).My goal is to prototype a system with one critical 
application (on linux side) and one non critical gui application (on android 
side).
If possible, I don't want to do porting job (driver writting). I only want to 
build the "applicative part".
My questions are:  - Is it possible?- Which board should I buy to make this 
work?
Thanks,
Regards.
Christopher Lambert___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-3.18 test] 111793: regressions - FAIL

[osstest service owner]

flight 111793 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111793/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 
REGR. vs. 110441

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111523 
pass in 111793
 test-amd64-amd64-xl-rtds  7 xen-boot fail in 111770 pass in 111793
 test-armhf-armhf-xl-arndale   6 xen-install  fail in 111770 pass in 111793
 test-amd64-amd64-xl-rtds 10 debian-install fail pass in 111523
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111523
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111770

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111523 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111770 blocked in 
110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111770 
like 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111770 
like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386

Re: [Xen-devel] [PATCH] IOMMU/PCI: make a few functions static

[Wei Liu]

On Fri, Jul 14, 2017 at 08:05:05AM -0600, Jan Beulich wrote:
> Add forward declarations in order to not move things around.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [qemu-mainline test] 111790: regressions - FAIL

[osstest service owner]

flight 111790 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111790/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111765

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
111765
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111765
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 111765
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111765
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111765
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111765
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu49bcce4b9c11759678fd223aefb48691c4959d4f
baseline version:
 qemuu31fe1c414501047cbb91b695bdccc0068496dcf6

Last test of basis   111765  2017-07-13 10:20:16 Z1 days
Testing same since   111790  2017-07-14 04:20:46 Z0 days1 attempts


People who touched revisions under test:
  Alexander Graf 
  Aurelien Jarno 
  Cédric Le Goater 
  Daniel P. Berrange 
  Denis V. Lunev 
  Eric Blake 
  Joel Stanley 
  Krzysztof Kozlowski 
  Li Ping 
  Mao Zhongyi 
  Marc-André Lureau 
  Markus Armbruster 
  Max Filippov 
  Max Reitz 
  Michael Tokarev 
  Miodrag Dinic 
  Paolo Bonzini 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  sochin.jiang 
  Stefan Hajnoczi 
  Thomas Huth 
  Vladimir Sementsov-Ogievskiy 
  Yongbok Kim 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm   

[Xen-devel] [ovmf test] 111810: all pass - PUSHED

[osstest service owner]

flight 111810 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111810/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0df6c8c157af9510e21bff7bb8aa1f461d04707b
baseline version:
 ovmf b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e

Last test of basis   111785  2017-07-14 00:47:37 Z0 days
Testing same since   111810  2017-07-14 16:48:12 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=ovmf
+ revision=0df6c8c157af9510e21bff7bb8aa1f461d04707b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
0df6c8c157af9510e21bff7bb8aa1f461d04707b
+ branch=ovmf
+ revision=0df6c8c157af9510e21bff7bb8aa1f461d04707b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x0df6c8c157af9510e21bff7bb8aa1f461d04707b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvo

[Xen-devel] [PATCH 1/6] xen-blkfront: quiesce/unquiesce queue instead of start/stop queues

[Ming Lei]

stopping queue may cause race and may not stop the queue really
after the API returns, and we have improved quiescing
interface and it really can block dispatching once it returns.

So switch to quiesce/unquiece like what we did on other drivers
(NVMe, NBD, mtip32xx, ...)

The blk_mq_stop_hw_queues() and blk_mq_start_stopped_hw_queues()
used in blkif_queue_rq() and blkif_interrupt() are for congestion
control, we leave it as it is since it is safe for this usage.

Cc: Konrad Rzeszutek Wilk 
Cc: "Roger Pau Monné" 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Ming Lei 
---
 drivers/block/xen-blkfront.c | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index c852ed3c01d5..1578befda635 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1187,7 +1187,7 @@ static void xlvbd_release_gendisk(struct blkfront_info 
*info)
return;
 
/* No more blkif_request(). */
-   blk_mq_stop_hw_queues(info->rq);
+   blk_mq_quiesce_queue(info->rq);
 
for (i = 0; i < info->nr_rings; i++) {
struct blkfront_ring_info *rinfo = &info->rinfo[i];
@@ -1216,8 +1216,10 @@ static void xlvbd_release_gendisk(struct blkfront_info 
*info)
 /* Already hold rinfo->ring_lock. */
 static inline void kick_pending_request_queues_locked(struct 
blkfront_ring_info *rinfo)
 {
-   if (!RING_FULL(&rinfo->ring))
+   if (!RING_FULL(&rinfo->ring)) {
blk_mq_start_stopped_hw_queues(rinfo->dev_info->rq, true);
+   blk_mq_kick_requeue_list(rinfo->dev_info->rq);
+   }
 }
 
 static void kick_pending_request_queues(struct blkfront_ring_info *rinfo)
@@ -1225,7 +1227,8 @@ static void kick_pending_request_queues(struct 
blkfront_ring_info *rinfo)
unsigned long flags;
 
spin_lock_irqsave(&rinfo->ring_lock, flags);
-   kick_pending_request_queues_locked(rinfo);
+   if (!RING_FULL(&rinfo->ring))
+   blk_mq_run_hw_queues(rinfo->dev_info->rq, true);
spin_unlock_irqrestore(&rinfo->ring_lock, flags);
 }
 
@@ -1346,7 +1349,7 @@ static void blkif_free(struct blkfront_info *info, int 
suspend)
BLKIF_STATE_SUSPENDED : BLKIF_STATE_DISCONNECTED;
/* No more blkif_request(). */
if (info->rq)
-   blk_mq_stop_hw_queues(info->rq);
+   blk_mq_quiesce_queue(info->rq);
 
for (i = 0; i < info->nr_rings; i++)
blkif_free_ring(&info->rinfo[i]);
@@ -2018,22 +2021,13 @@ static int blkif_recover(struct blkfront_info *info)
/* Now safe for us to use the shared ring */
info->connected = BLKIF_STATE_CONNECTED;
 
-   for (r_index = 0; r_index < info->nr_rings; r_index++) {
-   struct blkfront_ring_info *rinfo;
-
-   rinfo = &info->rinfo[r_index];
-   /* Kick any other new requests queued since we resumed */
-   kick_pending_request_queues(rinfo);
-   }
-
list_for_each_entry_safe(req, n, &info->requests, queuelist) {
/* Requeue pending requests (flush or discard) */
list_del_init(&req->queuelist);
BUG_ON(req->nr_phys_segments > segs);
blk_mq_requeue_request(req, false);
}
-   blk_mq_start_stopped_hw_queues(info->rq, true);
-   blk_mq_kick_requeue_list(info->rq);
+   blk_mq_unquiesce_queue(info->rq);
 
while ((bio = bio_list_pop(&info->bio_list)) != NULL) {
/* Traverse the list of pending bios and re-queue them */
-- 
2.9.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [libvirt test] 111792: tolerable all pass - PUSHED

[osstest service owner]

flight 111792 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111792/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111755
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111755
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111755
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  407a281a8e2b6c5078ba1148535663ea64fd9314
baseline version:
 libvirt  3d52a8444bc01d8d3d1b7a38976633fcbc645d21

Last test of basis   111755  2017-07-13 04:20:19 Z1 days
Testing same since   111792  2017-07-14 04:29:46 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Jiri Denemark 
  Juan Hernandez 
  Martin Kletzander 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary

[Xen-devel] [PATCH v14 18/23] x86: L2 CAT: implement get value flow.

[Yi Sun]

This patch implements L2 CAT get value interface in domctl.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v14:
- rebase domctl.c on latest codes: bool_t is replace by bool.
v11:
- remove "get_val' assignment because it has been replaced by generic
  codes.
  (suggested by Jan Beulich)
v10:
- remove cast in domctl.
  (suggested by Jan Beulich)
v9:
- reuse 'cat_get_val' for L2 CAT to reduce redundant codes
  (suggested by Roger Pau)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v5:
- remove type check in callback function.
  (suggested by Jan Beulich)
v4:
- create this patch because of codes architecture change.
  (suggested by Jan Beulich)
---
 xen/arch/x86/domctl.c   | 7 +++
 xen/include/public/domctl.h | 1 +
 2 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 6aa3d06..7b58053 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1460,6 +1460,13 @@ long arch_do_domctl(
 copyback = true;
 break;
 
+case XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM:
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  &val32, PSR_CBM_TYPE_L2);
+domctl->u.psr_cat_op.data = val32;
+copyback = true;
+break;
+
 default:
 ret = -EOPNOTSUPP;
 break;
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index ff39762..61d44cd 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1142,6 +1142,7 @@ struct xen_domctl_psr_cat_op {
 #define XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA3
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE4
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA5
+#define XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM 7
 uint32_t cmd;   /* IN: XEN_DOMCTL_PSR_CAT_OP_* */
 uint32_t target;/* IN */
 uint64_t data;  /* IN/OUT */
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v14 14/23] x86: refactor psr: CDP: implement get hw info flow.

[Yi Sun]

This patch implements get HW info flow for CDP including L3 CDP callback
function. The flow is almost same as L3 CAT.

With this patch, 'psr-hwinfo' can work for L3 CDP.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v12:
- remove input parameter 'info' in 'psr_cbm_type_to_feat_type'. Use
  'feat_props' array to check.
  (suggested by Jan Beulich)
v11:
- modify 'psr_get_info' flow to make it simple to cover CDP case.
v10:
- update renamed macros used by psr_get_info.
  (suggested by Jan Beulich)
- change 'psr_get_info' flow to cover CDP case to make codes in sysctl
  more simple.
  (suggested by Jan Beulich)
- remove sysctl redundant codes after applying above changes.
  (suggested by Jan Beulich)
v9:
- modify commit message to explain flow more clearly.
- reuse 'cat_get_feat_info' for CDP to reduce redundant codes.
  (suggested by Roger Pau)
- fix coding style issues.
  (suggested by Wei Liu and Roger Pau)
- rename macros used by psr_get_info to make them meaningful.
  (suggested by Jan Beulich)
v5:
- rename 'dat[]' to 'data[]'.
  (suggested by Jan Beulich)
- remove type check in callback function.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 35b78f6..a9e1b56 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -222,7 +222,21 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum 
cbm_type type)
 {
 case PSR_CBM_TYPE_L3:
 feat_type = FEAT_TYPE_L3_CAT;
+
+/*
+ * If type is L3 CAT but we cannot find it in feat_props array,
+ * try CDP.
+ */
+if ( !feat_props[feat_type] )
+feat_type = FEAT_TYPE_L3_CDP;
+
+break;
+
+case PSR_CBM_TYPE_L3_DATA:
+case PSR_CBM_TYPE_L3_CODE:
+feat_type = FEAT_TYPE_L3_CDP;
 break;
+
 default:
 ASSERT_UNREACHABLE();
 }
@@ -350,7 +364,12 @@ static const struct feat_props l3_cat_props = {
 static bool l3_cdp_get_feat_info(const struct feat_node *feat,
  uint32_t data[], uint32_t array_len)
 {
-return false;
+if ( !cat_get_feat_info(feat, data, array_len) )
+return false;
+
+data[PSR_INFO_IDX_CAT_FLAG] |= XEN_SYSCTL_PSR_CAT_L3_CDP;
+
+return true;
 }
 
 static void l3_cdp_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
type)
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v14 00/23] Enable L2 Cache Allocation Technology & Refactor psr.c

[Yi Sun]

Hi all,

We plan to bring a new PSR (Platform Shared Resource) feature called
Intel L2 Cache Allocation Technology (L2 CAT) to Xen. It has been enabled
in Linux Kernel.

Besides the L2 CAT implementaion, we refactor the psr.c to make it more
flexible and easily to extend to add new features. We abstract the general
operations of all features and encapsulate them into a structure. Then,
the development of new feature is simple to mainly implement these callback
functions.

The patch set can be found at:
https://github.com/yisun-git/xen.git l2_cat_v14

---
Acked and Reviewed list before V14:
  The changes in some reviewed patches are small. So I retain the a/r.

a - Acked-by
r - Reviewed-by

  r  patch 1  - docs: create Cache Allocation Technology (CAT) and Code and
Data Prioritization (CDP) feature document
  a  patch 2  - x86: move cpuid_count_leaf from cpuid.c to processor.h.
  ar patch 3  - x86: refactor psr: remove L3 CAT/CDP codes.
  r  patch 4  - x86: refactor psr: L3 CAT: implement main data structures, CPU 
init and free flows.
  r  patch 5  - x86: refactor psr: L3 CAT: implement Domain init/free and 
schedule flows.
  r  patch 6  - x86: refactor psr: L3 CAT: implement get hw info flow.
  r  patch 7  - x86: refactor psr: L3 CAT: implement get value flow.
  r  patch 8  - x86: refactor psr: L3 CAT: set value: implement framework.
  r  patch 9  - x86: refactor psr: L3 CAT: set value: assemble features value 
array.
  r  patch 10 - x86: refactor psr: L3 CAT: set value: implement cos finding 
flow.
  r  patch 11 - x86: refactor psr: L3 CAT: set value: implement cos id picking 
flow.
  r  patch 14 - x86: refactor psr: CDP: implement get hw info flow.
  r  patch 15 - x86: refactor psr: CDP: implement set value callback function.
  r  patch 17 - x86: L2 CAT: implement get hw info flow.
  r  patch 18 - x86: L2 CAT: implement get value flow.
  r  patch 19 - x86: L2 CAT: implement set value flow.
  a  patch 20 - tools: L2 CAT: support get HW info for L2 CAT.
  a  patch 21 - tools: L2 CAT: support show cbm for L2 CAT.
  a  patch 22 - tools: L2 CAT: support set cbm for L2 CAT.
  a  patch 23 - docs: add L2 CAT description in docs.

---
V14 change list:

Patch 1:
- fix a typo.
  (suggested by Meng Xu)
- modify revision.
Patch 4:
- rename 'feat_l3_cat' to 'feat_l3' to represent for either L3 CAT or CDP.
  Because only one of them can exist at same time.
  (suggested by Jan Beulich)
- put address of 'feat_l3' back into it if 'cat_init_feature()' fails to
  avoid leakage.
  (suggested by Jan Beulich)
Patch 7:
- rebase domctl.c on latest code: bool_t is replaced by bool.
Patch 8:
- add 'const' for parameter 'val[]' in 'write_psr_msrs'.
  (suggested by Jan Beulich)
Patch 9:
- remove parameter '**val' in skip_prior_features and return the length to
  skip value array in the caller.
  (suggested by Jan Beulich)
- remove a stray blank.
  (suggested by Jan Beulich)
Patch 12:
- changes related to 'skip_prior_features' change in previous patch.
  (suggested by Jan Beulich)
Patch 13:
- remove the 'Notes' in commit message because a stub function is
  implemented to avoid potential issue.
  (suggested by Jan Beulich)
- remove 'feat_l3_cdp' because it can be replaced by 'feat_l3'.
  (suggested by Jan Beulich)
- implement stub callback functions for CDP to avoid system crash if
  not full CDP patches applied.
  (suggested by Jan Beulich)
- directly assign correct value to 'alt_type' of CDP.
  (suggested by Jan Beulich)
- goto L3 CAT init process if CDP init fails.
  (suggested by Jan Beulich)
Patch 16:
- remove the 'Notes' in commit message because a stub function is
  implemented to avoid the potential issue.
  (suggested by Jan Beulich)
- put address of 'feat_l2_cat' back to it if 'cat_init_feature()' fails
  to avoid leakage.
  (suggested by Jan Beulich)
- change 'feat_name' to 'cat_feat_name' and move it into
  'cat_init_feature()' which is the only caller.
  (suggested by Jan Beulich)
- register the callback functions into 'l2_cat_props' to avoid crash if
  user does not apply later patches.
  (suggested by Jan Beulich)
Patch 18:
- rebase domctl.c on latest codes: bool_t is replace by bool.

Yi Sun (23):
  docs: create Cache Allocation Technology (CAT) and Code and Data
Prioritization (CDP) feature document
  x86: move cpuid_count_leaf from cpuid.c to processor.h.
  x86: refactor psr: remove L3 CAT/CDP codes.
  x86: refactor psr: L3 CAT: implement main data structures, CPU init
and free flows.
  x86: refactor psr: L3 CAT: implement Domain init/free and schedule
flows.
  x86: refactor psr: L3 CAT: implement get hw info flow.
  x86: refactor psr: L3 CAT: implement get value flow.
  x86: refactor psr: L3 CAT: set value: implement framework.
  x86: refactor psr: L3 CAT: set value: assemble features value array.
  x86: refactor 

[Xen-devel] [PATCH v14 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Yi Sun]

This patch implements the CPU init flow for CDP. The flow is almost
same as L3 CAT.

Signed-off-by: Yi Sun 
---
v14:
- remove the 'Notes' in commit message because a stub function is
  implemented to avoid potential issue.
  (suggested by Jan Beulich)
- remove 'feat_l3_cdp' because it can be replaced by 'feat_l3'.
  (suggested by Jan Beulich)
- implement stub callback functions for CDP to avoid system crash if
  not full CDP patches applied.
  (suggested by Jan Beulich)
- directly assign correct value to 'alt_type' of CDP.
  (suggested by Jan Beulich)
- goto L3 CAT init process if CDP init fails.
  (suggested by Jan Beulich)
v13:
- add commit message.
  (suggested by Jan Beulich)
- fix comment issue.
  (suggested by Jan Beulich)
- set CDP default value before enabling it.
  (suggested by Jan Beulich)
- remove unnecessary check.
  (suggested by Jan Beulich)
- set 'alt_type' for CDP.
  (suggested by Jan Beulich)
- check 'cos_max' and substract 1 before right shift it to get correct
  value.
  (suggested by Jan Beulich)
v12:
- move 'type[]' assignment into l3_cdp_props declaration to make it be
  'const'.
  (suggested by Jan Beulich)
- remove "L2 CAT" indication in printk.
  (suggested by Jan Beulich)
- fix coding style issue.
  (suggested by Jan Beulich)
- change 'val' type to uint64_t.
  (suggested by Jan Beulich)
- use 1ull.
  (suggested by Jan Beulich)
- restore mask(0) MSR to default value.
  (suggested by Jan Beulich)
v11:
- changes about 'feat_props'.
  (suggested by Jan Beulich)
- remove MSR restore action which is unnecessary.
  (suggested by Jan Beulich)
- modify commit message.
v10:
- fix comment.
  (suggested by Jan Beulich)
- use swith in 'cat_init_feature' to handle different feature types.
  (suggested by Jan Beulich)
- changes about 'props'.
  (suggested by Jan Beulich)
- restore MSRs to default value when cpu online.
  (suggested by Jan Beulich)
- remove feat_mask.
  (suggested by Jan Beulich)
v9:
- modify commit message to describe flow clearer.
- handle cpu offline and online again case to read MSRs registers values
  back and save them into cos array to make user can get real data.
- modify error handling process in 'psr_cpu_prepare' to reduce redundant
  codes.
- modify 'get_cdp_data' and 'get_cdp_code' to make them standard.
  (suggested by Roger Pau and Jan Beulich)
- encapsulate CDP operations into 'cat_init_feature' to reduce redundant
  codes.
  (suggested by Roger Pau)
- reuse 'cat_get_cos_max' for CDP.
  (suggested by Roger Pau)
- handle 'PSR_CDP' in psr_presmp_init to make init work can be done when
  there is only 'psr=cdp' in cmdline.
- remove unnecessary comment.
  (suggested by Jan Beulich)
- move CDP related codes in 'cpu_init_work' into 'psr_cpu_init'.
  (suggested by Jan Beulich)
- add codes to handle CDP's 'cos_num'.
  (suggested by Jan Beulich)
- fix coding style issue.
  (suggested by Jan Beulich)
- do not free resources when allocation fails in 'psr_cpu_prepare'.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v7:
- initialize 'l3_cdp'.
  (suggested by Konrad Rzeszutek Wilk)
v6:
- use 'cpuid_leaf'.
  (suggested by Konrad Rzeszutek Wilk and Jan Beulich)
v5:
- remove codes to free 'feat_l3_cdp' in 'free_feature'.
  (suggested by Jan Beulich)
- encapsulate cpuid registers into 'struct cpuid_leaf_regs'.
  (suggested by Jan Beulich)
- print socket info when 'opt_cpu_info' is true.
  (suggested by Jan Beulich)
- rename 'l3_cdp_get_max_cos_max' to 'l3_cdp_get_cos_max'.
  (suggested by Jan Beulich)
- rename 'dat[]' to 'data[]'.
  (suggested by Jan Beulich)
- move 'cpu_prepare_work' contents into 'psr_cpu_prepare'.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 83 ++
 1 file changed, 78 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index a3aa1db..35b78f6 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -62,6 +62,7 @@
 
 enum psr_feat_type {
 FEAT_TYPE_L3_CAT,
+FEAT_TYPE_L3_CDP,
 FEAT_TYPE_NUM,
 FEAT_TYPE_UNKNOWN,
 };
@@ -163,6 +164,22 @@ static struct feat_node *feat_l3;
 #define cat_default_val(len) (0x >> (32 - (len)))
 
 /*
+ * get_cdp_data - get DATA COS register value from input COS ID.
+ * @feat:the feature node.
+ * @cos: the COS ID.
+ */
+#define get_cdp_data(feat, cos)  \
+((feat)->cos_reg_val[(cos) * 2])
+
+/*
+ * get_cdp_code - get CODE COS register value from input COS ID.
+ * @

[Xen-devel] [PATCH v14 10/23] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

[Yi Sun]

Continue from patch:
'x86: refactor psr: L3 CAT: set value: assemble features value array'

We can try to find if there is a COS ID on which all features' COS registers
values are same as the array assembled before.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v13:
- remove unnecessary blank line.
  (suggested by Jan Beulich)
v12:
- use 'ARRAY_SIZE' to calculate array boundary.
  (suggested by Jan Beulich)
- move same type variables declaration to one line.
  (suggested by Jan Beulich)
- use 'ASSERT_UNREACHABLE()' to record bug and return error code if feat
  exists but props does not exist.
  (suggested by Jan Beulich)
- move 'i' definition into the loop to limit its scope.
  (suggested by Jan Beulich)
v11:
- move 'compare_val' implementation from CDP patch to this.
  (suggested by Jan Beulich)
- remove 'rc' in 'compare_val' to make codes clearer.
  (suggested by Jan Beulich)
- changes about 'feat_props'.
  (suggested by Jan Beulich)
- fix bug.
  (suggested by Jan Beulich)
- remove unnecessary variable initialization.
  (suggested by Jan Beulich)
- remove unnecessary comment.
  (suggested by Jan Beulich)
- adjust array check place prior to using the array.
  (suggested by Jan Beulich)
- add comment.
v10:
- remove 'compare_val' hook and its CAT implementation. Make its
  functionality be generic in 'find_cos' flow.
  (suggested by Jan Beulich)
- changes related to 'props'.
  (suggested by Jan Beulich)
- rename 'val_array' to 'val_ptr'.
  (suggested by Jan Beulich)
- rename 'find' to 'found'.
  (suggested by Jan Beulich)
- move some variables declaration and initialization into loop.
  (suggested by Jan Beulich)
- adjust codes positions.
  (suggested by Jan Beulich)
v9:
- modify comments of 'compare_val' to be same as current implementation.
  (suggested by Wei Liu)
- fix indentation issue.
  (suggested by Wei Liu)
- rename 'l3_cat_compare_val' to 'cat_compare_val' to cover all L3/L2 CAT
  features.
  (suggested by Roger Pau)
- remove parameter 'found' from 'cat_compare_val' and modify the return
  values to let caller know if the id is found or not.
  (suggested by Roger Pau)
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- replace 'get_cos_num' to 'feat->cos_num'.
  (suggested by Jan Beulich)
- directly use 'cos_reg_val[0]' as default value.
  (suggested by Jan Beulich)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v5:
- modify commit message to provide exact patch name to continue from.
  (suggested by Jan Beulich)
- remove 'get_cos_max_from_type' because it can be replaced by
  'get_cos_max'.
- move type check out from callback functions to caller.
  (suggested by Jan Beulich)
- modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
- modify comments according to changes of codes.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 100 +
 1 file changed, 100 insertions(+)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 2c04131..ab070c2 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -753,10 +753,110 @@ static int insert_val_into_array(uint32_t val[],
 return -EINVAL;
 }
 
+static int compare_val(const uint32_t val[],
+   const struct feat_node *feat,
+   const struct feat_props *props,
+   unsigned int cos)
+{
+unsigned int i;
+
+for ( i = 0; i < props->cos_num; i++ )
+{
+uint32_t feat_val;
+
+/* If cos is bigger than cos_max, we need compare default value. */
+if ( cos > feat->cos_max )
+{
+/*
+ * COS ID 0 always stores the default value.
+ * For CDP:
+ * - DATA default value stored in cos_reg_val[0];
+ * - CODE default value stored in cos_reg_val[1].
+ */
+feat_val = feat->cos_reg_val[i];
+
+/*
+ * If cos is bigger than feature's cos_max, the val should be
+ * default value. Otherwise, it fails to find a COS ID. So we
+ * have to exit find flow.
+ */
+if ( val[i] != feat_val )
+return -EINVAL;
+}
+else
+{
+feat_val = feat->cos_reg_val[cos * props->cos_num + i];
+if ( val[i] != feat_val )
+return 0;
+}
+}
+
+return 1;
+}
+
 static int find_cos(const uint32_t val[], unsigned int array_len,
 enum psr_f

[Xen-devel] [PATCH v14 12/23] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Yi Sun]

Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos id picking flow.'

We have got the feature value and COS ID to set. Then, we write MSRs of the
designated feature.

Till now, set value process is completed.

Signed-off-by: Yi Sun 
---
v14:
- changes related to 'skip_prior_features' change in previous patch.
  (suggested by Jan Beulich)
v13:
- use 'skip_prior_features'.
  (suggested by Jan Beulich)
- add 'const' for some variables.
  (suggested by Jan Beulich)
v12:
- declare same type varaibles in one line.
  (suggested by Jan Beulich)
- replace 'feat_type' to 'props' in 'struct cos_write_info'.
  (suggested by Jan Beulich)
- assign the 'cos_num' to a local variable.
  (suggested by Jan Beulich)
- use 'ASSERT_UNREACHABLE()' to record bug and return error code if feat
  exists but props does not exist.
  (suggested by Jan Beulich)
v11:
- rename 'write_psr_msr' to 'write_psr_msrs'.
- rename 'do_write_psr_msr' to 'do_write_psr_msrs'.
- change parameters and codes of 'write_psr_msrs' to handle value array.
- add 'feat_type' in 'struct cos_write_info' to handle props array.
- in 'do_write_psr_msrs', write value array into msrs according to
  'props->type[i]'.
- move 'feat->cos_reg_val' assignment and value comparison in 'write_msr'
  callback function out as generic codes.
  (suggested by Jan Beulich)
- move check from 'do_write_psr_msrs' to 'write_psr_msrs'.
  (suggested by Jan Beulich)
- change about 'cos_max'.
  (suggested by Jan Beulich)
- change about 'feat_props'.
  (suggested by Jan Beulich)
v10:
- remove 'type' from 'write_msr' parameter list. Will add it back when
  implementing CDP.
  (suggested by Jan Beulich)
- remove unnecessary casts.
  (suggested by Jan Beulich)
- changes about 'props'.
  (suggested by Jan Beulich)
v9:
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- add 'array_len' in 'struct cos_write_info' and check if val array
  exceeds it.
- modify 'write_psr_msr' flow only to set one value a time. No need to
  set whole feature array values.
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v8:
- modify 'write_msr' callback function to 'void' because we have to set
  all features' cbm. When input cos exceeds some features' cos_max, just
  skip them but not break the iteration.
v5:
- modify commit message to provide exact patch name to continue from.
  (suggested by Jan Beulich)
- modify return value of callback functions because we do not need them
  to return number of entries the feature uses. In caller, we call
  'get_cos_num' to get the number of entries the feature uses.
  (suggested by Jan Beulich)
- move type check out from callback functions to caller.
  (suggested by Jan Beulich)
- modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
- correct code format.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 79 +-
 1 file changed, 78 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index e698872..a3aa1db 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -113,6 +113,9 @@ static const struct feat_props {
 /* get_feat_info is used to return feature HW info through sysctl. */
 bool (*get_feat_info)(const struct feat_node *feat,
   uint32_t data[], unsigned int array_len);
+
+/* write_msr is used to write out feature MSR register. */
+void (*write_msr)(unsigned int cos, uint32_t val, enum cbm_type type);
 } *feat_props[FEAT_TYPE_NUM];
 
 /*
@@ -289,11 +292,17 @@ static bool cat_get_feat_info(const struct feat_node 
*feat,
 }
 
 /* L3 CAT props */
+static void l3_cat_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
type)
+{
+wrmsrl(MSR_IA32_PSR_L3_MASK(cos), val);
+}
+
 static const struct feat_props l3_cat_props = {
 .cos_num = 1,
 .type[0] = PSR_CBM_TYPE_L3,
 .alt_type = PSR_CBM_TYPE_UNKNOWN,
 .get_feat_info = cat_get_feat_info,
+.write_msr = l3_cat_write_msr,
 };
 
 static void __init parse_psr_bool(char *s, char *value, char *feature,
@@ -947,11 +956,79 @@ static int pick_avail_cos(const struct psr_socket_info 
*info,
 return -EOVERFLOW;
 }
 
+static unsigned int get_socket_cpu(unsigned int socket)
+{
+if ( likely(socket < nr_sockets) )
+return cpumask_any(socket_cpumask[socket]);
+
+return nr_cpu_ids;
+}
+
+struct cos_write_info
+{
+unsigned int cos;
+struct feat_node *feature;
+const uint32_t *val;
+const struct feat_props *props;
+};

[Xen-devel] [PATCH v14 15/23] x86: refactor psr: CDP: implement set value callback function.

[Yi Sun]

This patch implements L3 CDP set value related callback function.

With this patch, 'psr-cat-cbm-set' command can work for L3 CDP.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v13:
- remove 'strict' from 'psr_cbm_type_to_feat_type' because we use 'alt_type'
  to check if we need set both DATA and CODE now.
  (suggested by Jan Beulich)
- adjust the implementation in circle in 'insert_val_into_array' to make
  codes clearer to show how to decide the return value.
  (suggested by Jan Beulich)
v12:
- add comment to explain how to deal with the case that user set new val
  for both DATA and CODE at same time.
- add parameter for 'psr_cbm_type_to_feat_type' to return the feature type
  according to it.
- use the feature type returned by 'psr_cbm_type_to_feat_type' to check
  if we need insert the new value into all items of the feature value array.
- use conditional expression for wrmsrl.
  (suggested by Jan Beulich)
v11:
- move 'feat->cos_reg_val' assignment and value comparison in 'write_msr'
  callback function out as generic codes.
  (suggested by Jan Beulich)
- changes about setting both CDP DATA and CODE at same time.
- move 'type[]' declaration into previous patch which introduced 'cos_num'.
  (suggested by Jan Beulich)
- changes about 'type[]'.
  (suggested by Jan Beulich)
- move 'compare_val' to previous patch.
  (suggested by Jan Beulich)
- changes about 'get_val' which has been replace by generic codes.
  (suggested by Jan Beulich)
- remove 'restore_default_val' which is unnecessary now.
  (suggested by Jan Beulich)
v10:
- remove 'l3_cdp_get_old_val' and use 'l3_cdp_get_val' to replace it.
  (suggested by Jan Beulich)
- remove 'l3_cdp_set_new_val'.
- modify 'insert_val_to_array' flow to handle multiple COSs case.
  (suggested by Jan Beulich)
- remove 'l3_cdp_compare_val' and implement a generic function
  'comapre_val'.
  (suggested by Jan Beulich)
- remove 'l3_cdp_fits_cos_max'.
  (suggested by Jan Beulich)
- introduce macro 'PSR_MAX_COS_NUM'.
- introduce a new member in 'feat_props', 'type[PSR_MAX_COS_NUM]' to record
  all 'cbm_type' the feature has.
  (suggested by Jan Beulich)
- modify 'gather_val_array' flow to handle multiple COSs case.
  (suggested by Jan Beulich)
- modify 'find_cos' flow and implement 'compare_val' to handle multiple
  COSs case.
  (suggested by Jan Beulich)
- modify 'fits_cos_max' flow to handle multiple COSs case.
  (suggested by Jan Beulich)
- changes about 'props'.
  (suggested by Jan Beulich)
- remove cast in 'l3_cdp_write_msr'.
  (suggested by Jan Beulich)
- implement 'compare_val' function to compare if feature values are what
  we expect in finding flow.
- implement 'restore_default_val' function to restore feature's COS values
  to default if the feature has multiple COSs. It is called when the COS
  ID is reduced to 0.
v9:
- add comment to explain why CDP uses 2 COSs.
  (suggested by Wei Liu)
- use 'cat_default_val'.
  (suggested by Wei Liu)
- remove 'l3_cdp_get_cos_num' because we can directly get cos_num from
  feat_node now.
  (suggested by Jan Beulich)
- remove cos checking because it has been moved to common function.
  (suggested by Jan Beulich)
- l3_cdp_set_new_val parameter 'm' is changed to 'new_val'.
  (suggested by Jan Beulich)
- directly use get_cdp_data(feat, 0) and get_cdp_code(feat, 0) to get
  default value.
  (suggested by Jan Beulich)
- modify 'l3_cdp_write_msr' flow to write value into register according
  to input type.
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v8:
- modify 'l3_cdp_write_msr' type to 'void'.
v5:
- remove type check in callback function.
  (suggested by Jan Beulich)
- modify return value of callback functions because we do not need them
  to return number of entries the feature uses. In caller, we call
  'get_cos_num' to get the number of entries the feature uses.
  (suggested by Jan Beulich)
- remove 'l3_cdp_get_cos_max_from_type'.
- rename 'l3_cdp_exceeds_cos_max' to 'l3_cdp_fits_cos_max'.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index a9e1b56..c211c77 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -374,6 +374,10 @@ static bool l3_cdp_get_feat_info(const struct feat_node 
*feat,
 
 static void l3_cdp_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
type)
 {
+wrmsrl(((type == PSR_CBM_TYPE_L3_DATA) ?
+MSR_IA32_PSR_L3_MASK_DATA(cos) :
+MSR_IA32_PSR_L3_MASK_CODE(cos)),
+  

[Xen-devel] [PATCH v14 21/23] tools: L2 CAT: support show cbm for L2 CAT.

[Yi Sun]

This patch implements changes in xl/xc changes to support
showing CBM of L2 CAT.

The new level option is introduced to original CAT showing
command in order to show CBM for specified level CAT.
- 'xl psr-cat-show' is updated to show CBM of a domain
  according to input cache level.

Examples:
root@:~$ xl psr-cat-show -l2 1
Socket ID   : 0
Default CBM : 0xff
   ID NAME CBM
1 ubuntu140x7f

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
---
v9:
- move xl_cmdimpl.c changes into xl/xl_psr.c.
- move xl_cmdtable.c changes into xl/xl_cmdtable.c.
v6:
- check if input level is correct.
- adjust '{' postion for 'if'.
  (suggested by Wei Liu)
v5:
- remove 'L2_CBM' in idl because it has been moved to patch 21:
  "tools: L2 CAT: support get HW info for L2 CAT".
  (suggested by Wei Liu)
v4:
- create this patch because of codes architecture change.
---
 tools/libxc/include/xenctrl.h |  1 +
 tools/libxc/xc_psr.c  |  3 ++
 tools/xl/xl_cmdtable.c|  3 +-
 tools/xl/xl_psr.c | 85 +--
 4 files changed, 63 insertions(+), 29 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c615d17..2248900 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2456,6 +2456,7 @@ enum xc_psr_cat_type {
 XC_PSR_CAT_L3_CBM  = 1,
 XC_PSR_CAT_L3_CBM_CODE = 2,
 XC_PSR_CAT_L3_CBM_DATA = 3,
+XC_PSR_CAT_L2_CBM  = 4,
 };
 typedef enum xc_psr_cat_type xc_psr_cat_type;
 
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 84a08c4..04f5927 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -299,6 +299,9 @@ int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t 
domid,
 case XC_PSR_CAT_L3_CBM_DATA:
 cmd = XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA;
 break;
+case XC_PSR_CAT_L2_CBM:
+cmd = XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM;
+break;
 default:
 errno = EINVAL;
 return -1;
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 30eb93c..539cb64 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -557,7 +557,8 @@ struct cmd_spec cmd_table[] = {
 { "psr-cat-show",
   &main_psr_cat_show, 0, 1,
   "Show Cache Allocation Technology information",
-  "",
+  "[options] ",
+  "-l Specify the cache level to process, otherwise L3 
cache is processed\n"
 },
 
 #endif
diff --git a/tools/xl/xl_psr.c b/tools/xl/xl_psr.c
index 271b88f..575f4a0 100644
--- a/tools/xl/xl_psr.c
+++ b/tools/xl/xl_psr.c
@@ -342,7 +342,7 @@ static void psr_cat_print_one_domain_cbm_type(uint32_t 
domid, uint32_t socketid,
 }
 
 static void psr_cat_print_one_domain_cbm(uint32_t domid, uint32_t socketid,
- bool cdp_enabled)
+ bool cdp_enabled, unsigned int lvl)
 {
 char *domain_name;
 
@@ -350,27 +350,38 @@ static void psr_cat_print_one_domain_cbm(uint32_t domid, 
uint32_t socketid,
 printf("%5d%25s", domid, domain_name);
 free(domain_name);
 
-if (!cdp_enabled) {
-psr_cat_print_one_domain_cbm_type(domid, socketid,
-  LIBXL_PSR_CBM_TYPE_L3_CBM);
-} else {
-psr_cat_print_one_domain_cbm_type(domid, socketid,
-  LIBXL_PSR_CBM_TYPE_L3_CBM_CODE);
+switch (lvl) {
+case 3:
+if (!cdp_enabled) {
+psr_cat_print_one_domain_cbm_type(domid, socketid,
+  LIBXL_PSR_CBM_TYPE_L3_CBM);
+} else {
+psr_cat_print_one_domain_cbm_type(domid, socketid,
+  LIBXL_PSR_CBM_TYPE_L3_CBM_CODE);
+psr_cat_print_one_domain_cbm_type(domid, socketid,
+  LIBXL_PSR_CBM_TYPE_L3_CBM_DATA);
+}
+break;
+case 2:
 psr_cat_print_one_domain_cbm_type(domid, socketid,
-  LIBXL_PSR_CBM_TYPE_L3_CBM_DATA);
+  LIBXL_PSR_CBM_TYPE_L2_CBM);
+break;
+default:
+printf("Input lvl %d is wrong!", lvl);
+break;
 }
 
 printf("\n");
 }
 
 static int psr_cat_print_domain_cbm(uint32_t domid, uint32_t socketid,
-bool cdp_enabled)
+bool cdp_enabled, unsigned int lvl)
 {
 int i, nr_domains;
 libxl_dominfo *list;
 
 if (domid != INVALID_DOMID) {
-psr_cat_print_one_domain_cbm(domid, socketid, cdp_enabled);
+psr_cat_print_one_domain_cbm(domid, socketid, cdp_enabled, lvl);
 return 0;
 }
 
@@ -380,49 +391,59 @@ static int psr_cat_print_domain_cbm(uint32_t domid, 
uint32_t socketid,
 }
 
 for (i = 0; i < nr_domains;

[Xen-devel] [PATCH v14 19/23] x86: L2 CAT: implement set value flow.

[Yi Sun]

This patch implements L2 CAT set value related callback function
and domctl interface.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v11:
- remove 'domctl->u.psr_cat_op.data' check because it has been moved into
  'psr_set_val'.
  (suggested by Jan Beulich)
- move 'feat->cos_reg_val' assignment and value comparison in 'write_msr'
  callback function out as generic codes.
  (suggested by Jan Beulich)
v10:
- check input data and remove cast in domctl.
  (suggested by Jan Beulich)
- remove some hooks assignment due to previous patches changes.
  (suggested by Jan Beulich)
- remove cast in 'l2_cat_write_msr'.
  (suggested by Jan Beulich)
- remove 'return in 'l2_cat_write_msr'.
  (suggested by Jan Beulich)
v9:
- reuse some CAT common functions for L2 CAT to reduce redundant codes.
  (suggested by Roger Pau)
- remove parameter 'found' from 'cat_compare_val' and modify the return
  values to let caller know if the id is found or not. These things are
  done in patch "x86: refactor psr: set value: implement cos finding flow."
  (suggested by Roger Pau and Dario Faggioli)
- remove 'get_cos_num' related codes.
  (suggested by Jan Beulich)
- modify 'l2_cat_write_msr' according to previous patch change.
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v8:
- modify 'l2_cat_write_msr' to 'void'.
v5:
- remove type check in callback function.
  (suggested by Jan Beulich)
- modify return value of callback functions because we do not need them
  to return number of entries the feature uses. In caller, we call
  'get_cos_num' to get the number of entries the feature uses.
  (suggested by Jan Beulich)
- remove 'l2_cat_get_cos_max_from_type'.
  (suggested by Jan Beulich)
- rename 'l2_cat_exceeds_cos_max' to 'l2_cat_fits_cos_max'.
  (suggested by Jan Beulich)
v4:
- create this patch because of codes architecture change.
  (suggested by Jan Beulich)
---
 xen/arch/x86/domctl.c   | 6 ++
 xen/arch/x86/psr.c  | 1 +
 xen/include/public/domctl.h | 1 +
 3 files changed, 8 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7b58053..e5e0df4 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1439,6 +1439,12 @@ long arch_do_domctl(
   PSR_CBM_TYPE_L3_DATA);
 break;
 
+case XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM:
+ret = psr_set_val(d, domctl->u.psr_cat_op.target,
+  domctl->u.psr_cat_op.data,
+  PSR_CBM_TYPE_L2);
+break;
+
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
 ret = psr_get_val(d, domctl->u.psr_cat_op.target,
   &val32, PSR_CBM_TYPE_L3);
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 1b1a36b..ab87004 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -408,6 +408,7 @@ static const struct feat_props l3_cdp_props = {
 /* L2 CAT props */
 static void l2_cat_write_msr(unsigned int cos, uint32_t val, enum cbm_type 
type)
 {
+wrmsrl(MSR_IA32_PSR_L2_MASK(cos), val);
 }
 
 static const struct feat_props l2_cat_props = {
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 61d44cd..0669c31 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1142,6 +1142,7 @@ struct xen_domctl_psr_cat_op {
 #define XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA3
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE4
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA5
+#define XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM 6
 #define XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM 7
 uint32_t cmd;   /* IN: XEN_DOMCTL_PSR_CAT_OP_* */
 uint32_t target;/* IN */
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v14 01/23] docs: create Cache Allocation Technology (CAT) and Code and Data Prioritization (CDP) feature document

[Yi Sun]

This patch creates CAT and CDP feature document in doc/features/. It describes
key points to implement L3 CAT/CDP and L2 CAT which is described in details in
Intel SDM "INTEL® RESOURCE DIRECTOR TECHNOLOGY (INTEL® RDT) ALLOCATION 
FEATURES".

Signed-off-by: Yi Sun 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Wei Liu 
---
v14:
- fix a typo.
  (suggested by Meng Xu)
- modify revision.
v11:
- modify data structure descriptions according to code changes.
- modify revision.
v9:
- add 'CMT' to the list of acronyms.
  (suggested by Wei Liu)
- change feature list to feature array.
- modify data structure descriptions according to latest codes.
- modify revision.
v8:
- change revision info.
  (suggested by Konrad Rzeszutek Wilk)
- add content int 'Areas for improvement'.
  (suggested by Konrad Rzeszutek Wilk)
v7:
- correct typo.
  (suggested by Konrad Rzeszutek Wilk)
- replace application/VM to domain.
  (suggested by Konrad Rzeszutek Wilk)
- amend description of `feat_mask` to make it clearer.
  (suggested by Konrad Rzeszutek Wilk)
- update revision.
  (suggested by Konrad Rzeszutek Wilk)
- other minor fixes.
  (suggested by Konrad Rzeszutek Wilk)
v6:
- write a new feature document to cover L3 CAT/CDP and L2 CAT.
  (suggested by Kevin Tian)
- adjust 'Terminology' position in document.
  (suggested by Dario Faggioli)
- fix wordings.
  (suggested by Dario Faggioli, Kevin Tian and Konrad Rzeszutek Wilk)
- add SDM chapter title in commit message.
  (suggested by Konrad Rzeszutek Wilk)
- add more explanations.
  (suggested by Kevin Tian)
v4:
- change file name to be more descriptive, 'intel_psr_l2_cat.pandoc'.
  (suggested by Dario Faggioli)
- remove 'Ext' and 'New' prefixes.
  (suggested by Dario Faggioli)
- remove change log in Revison part.
  (suggested by Dario Faggioli)
- adjust Xen release number to 4.9 to show this feature targets 4.9.
  (suggested by Dario Faggioli)
- provide 'Terminology' and more sections.
  (suggested by Dario Faggioli)
- fix wordings.
  (suggested by Konrad Rzeszutek Wilk)
- remove chapter number.
  (suggested by Konrad Rzeszutek Wilk)
v3:
- make design document be a patch.
  (suggested by Konrad Rzeszutek Wilk)
v2:
- provide chapter for the L2 CAT.
  (suggested by Meng Xu)
---
 docs/features/intel_psr_cat_cdp.pandoc | 463 +
 1 file changed, 463 insertions(+)
 create mode 100644 docs/features/intel_psr_cat_cdp.pandoc

diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
b/docs/features/intel_psr_cat_cdp.pandoc
new file mode 100644
index 000..4fc6c31
--- /dev/null
+++ b/docs/features/intel_psr_cat_cdp.pandoc
@@ -0,0 +1,463 @@
+% Intel Cache Allocation Technology and Code and Data Prioritization Features
+% Revision 1.14
+
+\clearpage
+
+# Basics
+
+ 
+ Status: **Tech Preview**
+
+Architecture(s): Intel x86
+
+   Component(s): Hypervisor, toolstack
+
+   Hardware: L3 CAT: Haswell and beyond CPUs
+ CDP   : Broadwell and beyond CPUs
+ L2 CAT: Atom codename Goldmont and beyond CPUs
+ 
+
+# Terminology
+
+* CAT Cache Allocation Technology
+* CBM Capacity BitMasks
+* CDP Code and Data Prioritization
+* CMT Cache Monitoring Technology
+* COS/CLOSClass of Service
+* MSRsMachine Specific Registers
+* PSR Intel Platform Shared Resource
+
+# Overview
+
+Intel provides a set of allocation capabilities including Cache Allocatation
+Technology (CAT) and Code and Data Prioritization (CDP).
+
+CAT allows an OS or hypervisor to control allocation of a CPU's shared cache
+based on application/domain priority or Class of Service (COS). Each COS is
+configured using capacity bitmasks (CBMs) which represent cache capacity and
+indicate the degree of overlap and isolation between classes. Once CAT is co-
+nfigured, the processor allows access to portions of cache according to the
+established COS. Intel Xeon processor E5 v4 family (and some others) introduce
+capabilities to configure and make use of the CAT mechanism on the L3 cache.
+Intel Goldmont processor provides support for control over the L2 cache.
+
+Code and Data Prioritization (CDP) Technology is an extension of CAT. CDP
+enables isolation and separate prioritization of code and data fetches to
+the L3 cache in a SW configurable manner, which can enable workload priorit-
+ization and tuning of cache capacity to the characteristics of the workload.
+CDP extends CAT by providing separate code and data masks per Class of Service
+(COS). When SW configures to enable CDP, L3 CAT is disabled.
+
+# User details
+
+* Feature Enabling:
+
+  Add "psr=cat" to boot line parameter to enable al

[Xen-devel] [PATCH v14 03/23] x86: refactor psr: remove L3 CAT/CDP codes.

[Yi Sun]

The current cache allocation codes in psr.c do not consider
future features addition and are not friendly to extend.

To make psr.c be more flexible to add new features and fulfill
the program principle, open for extension but closed for
modification, we have to refactor the psr.c:
1. Analyze cache allocation features and abstract general data
   structures.
2. Analyze the init and all other functions flow, abstract all
   steps that different features may have different implementations.
   Make these steps be callback functions and register feature
   specific fuctions. Then, the main processes will not be changed
   when introducing a new feature.

Because the quantity of refactor codes is big and the logics are
changed a lot, it will cause reviewers confused if just change
old codes. Reviewers have to understand both old codes and new
implementations. After review iterations from V1 to V3, Jan has
proposed to remove all old cache allocation codes firstly, then
implement new codes step by step. This will help to make codes
be more easily reviewable.

There is no construction without destruction. So, this patch
removes all current L3 CAT/CDP codes in psr.c. The following
patches will introduce the new mechanism.

Signed-off-by: Yi Sun 
Acked-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Wei Liu 
---
v4:
- create this patch to make codes easily understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 470 +
 1 file changed, 5 insertions(+), 465 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 381f9a0..96a8589 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -23,24 +23,6 @@
 #define PSR_CAT(1<<1)
 #define PSR_CDP(1<<2)
 
-struct psr_cat_cbm {
-union {
-uint64_t cbm;
-struct {
-uint64_t code;
-uint64_t data;
-};
-};
-unsigned int ref;
-};
-
-struct psr_cat_socket_info {
-unsigned int cbm_len;
-unsigned int cos_max;
-struct psr_cat_cbm *cos_to_cbm;
-spinlock_t cbm_lock;
-};
-
 struct psr_assoc {
 uint64_t val;
 uint64_t cos_mask;
@@ -48,26 +30,11 @@ struct psr_assoc {
 
 struct psr_cmt *__read_mostly psr_cmt;
 
-static unsigned long *__read_mostly cat_socket_enable;
-static struct psr_cat_socket_info *__read_mostly cat_socket_info;
-static unsigned long *__read_mostly cdp_socket_enable;
-
 static unsigned int opt_psr;
 static unsigned int __initdata opt_rmid_max = 255;
-static unsigned int __read_mostly opt_cos_max = 255;
 static uint64_t rmid_mask;
 static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
 
-static struct psr_cat_cbm *temp_cos_to_cbm;
-
-static unsigned int get_socket_cpu(unsigned int socket)
-{
-if ( likely(socket < nr_sockets) )
-return cpumask_any(socket_cpumask[socket]);
-
-return nr_cpu_ids;
-}
-
 static void __init parse_psr_bool(char *s, char *value, char *feature,
   unsigned int mask)
 {
@@ -107,9 +74,6 @@ static void __init parse_psr_param(char *s)
 if ( val_str && !strcmp(s, "rmid_max") )
 opt_rmid_max = simple_strtoul(val_str, NULL, 0);
 
-if ( val_str && !strcmp(s, "cos_max") )
-opt_cos_max = simple_strtoul(val_str, NULL, 0);
-
 s = ss + 1;
 } while ( ss );
 }
@@ -213,16 +177,7 @@ static inline void psr_assoc_init(void)
 {
 struct psr_assoc *psra = &this_cpu(psr_assoc);
 
-if ( cat_socket_info )
-{
-unsigned int socket = cpu_to_socket(smp_processor_id());
-
-if ( test_bit(socket, cat_socket_enable) )
-psra->cos_mask = ((1ull << get_count_order(
- cat_socket_info[socket].cos_max)) - 1) << 32;
-}
-
-if ( psr_cmt_enabled() || psra->cos_mask )
+if ( psr_cmt_enabled() )
 rdmsrl(MSR_IA32_PSR_ASSOC, psra->val);
 }
 
@@ -231,12 +186,6 @@ static inline void psr_assoc_rmid(uint64_t *reg, unsigned 
int rmid)
 *reg = (*reg & ~rmid_mask) | (rmid & rmid_mask);
 }
 
-static inline void psr_assoc_cos(uint64_t *reg, unsigned int cos,
- uint64_t cos_mask)
-{
-*reg = (*reg & ~cos_mask) | (((uint64_t)cos << 32) & cos_mask);
-}
-
 void psr_ctxt_switch_to(struct domain *d)
 {
 struct psr_assoc *psra = &this_cpu(psr_assoc);
@@ -245,459 +194,54 @@ void psr_ctxt_switch_to(struct domain *d)
 if ( psr_cmt_enabled() )
 psr_assoc_rmid(®, d->arch.psr_rmid);
 
-if ( psra->cos_mask )
-psr_assoc_cos(®, d->arch.psr_cos_ids ?
-  d->arch.psr_cos_ids[cpu_to_socket(smp_processor_id())] :
-  0, psra->cos_mask);
-
 if ( reg != psra->val )
 {
 wrmsrl(MSR_IA32_PSR_ASSOC, reg);
 psra->val = reg;
 }
 }
-static struct psr_cat_socket_info *get_cat_socket_info(unsigned int socket)
-{
-if ( !cat_socket_info )
-return ERR_PTR(-ENODEV);
-
-if ( socket >= nr_sockets )
-ret

[Xen-devel] [PATCH v14 04/23] x86: refactor psr: L3 CAT: implement main data structures, CPU init and free flows.

[Yi Sun]

To construct an extendible framework, we need analyze PSR features
and abstract the common things and feature specific things. Then,
encapsulate them into different data structures.

By analyzing PSR features, we can get below map.
+--+--+--+
  ->| Dom0 | Dom1 | ...  |
  | +--+--+--+
  ||
  |Dom ID  | cos_id of domain
  |V
  |
+-+
User ->| PSR
 |
 Socket ID |  +--+---+---+  
 |
   |  | Socket0 Info | Socket 1 Info |...|  
 |
   |  +--+---+---+  
 |
   ||   cos_id=0   cos_id=1 
 ... |
   ||  
+---+---+---+ |
   ||->Ref   : | ref 0 | ref 1 
| ...   | |
   ||  
+---+---+---+ |
   ||  
+---+---+---+ |
   ||->L3 CAT: | cos 0 | cos 1 
| ...   | |
   ||  
+---+---+---+ |
   ||  
+---+---+---+ |
   ||->L2 CAT: | cos 0 | cos 1 
| ...   | |
   ||  
+---+---+---+ |
   ||  
+---+---+---+---+---+ |
   ||->CDP   : | cos0 code | cos0 data | cos1 code | cos1 data 
| ...   | |
   |   
+---+---+---+---+---+ |
   
+-+

So, we need define a socket info data structure, 'struct
psr_socket_info' to manage information per socket. It contains a
reference count array according to COS ID and a feature array to
manage all features enabled. Every entry of the reference count
array is used to record how many domains are using the COS registers
according to the COS ID. For example, L3 CAT and L2 CAT are enabled,
Dom1 uses COS_ID=1 registers of both features to save CBM values, like
below.
+---+---+---+-+
| COS 0 | COS 1 | COS 2 | ... |
+---+---+---+-+
L3 CAT  | 0x7ff | 0x1ff | ...   | ... |
+---+---+---+-+
L2 CAT  | 0xff  | 0xff  | ...   | ... |
+---+---+---+-+

If Dom2 has same CBM values, it can reuse these registers which COS_ID=1.
That means, both Dom1 and Dom2 use same COS registers(ID=1) to keep same
L3/L2 values. So, the value of ref[1] is 2 which means 2 domains are using
COS_ID 1.

To manage a feature, we need define a feature node data structure,
'struct feat_node', to manage feature's specific HW info, and an array of all
COS registers values of this feature.

To manage feature properties, we need define a feature property data structure,
'struct feat_props', to manage common properties (callback functions - all
feature's specific behaviors are encapsulated into these callback functions,
and generic values - e.g. the cos_max), the feature independent values.

CDP is a special feature which uses two entries of the array
for one COS ID. So, the number of CDP COS registers is the half of L3
CAT. E.g. L3 CAT has 16 COS registers, then CDP has 8 COS registers if
it is enabled. CDP uses the COS registers array as below.

 
+---+---+---+---+---+
CDP cos_reg_val[] index: | 0 | 1 | 2 | 3 |
...|
 
+---+---+---+---+---+
  value: | cos0 code | cos0 data | cos1 code | cos1 data |
...|
 
+---+---+---+---+---+

For more details, please refer SDM and patches to implement 'get value' and
'set value'.

This patch also implements the CPU init and free flow including L3 CAT
initialization and some resources free. It includes below flows:
1. presmp init:
- parse command line parameter.
- allocate socket info for every socket.
- allocate feature resource.
- initialize socket info, get feature info and add feature into feature
  array per cpuid result.
- free resources allocated if error happens.
- register cpu notifier to handle cpu events.
2. cpu notif

[Xen-devel] [PATCH v14 05/23] x86: refactor psr: L3 CAT: implement Domain init/free and schedule flows.

[Yi Sun]

This patch implements the Domain init/free and schedule flows.
- When domain init, its psr resource should be allocated.
- When domain free, its psr resource should be freed too.
- When domain is scheduled, its COS ID on the socket should be
  set into ASSOC register to make corresponding COS MSR value
  work.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v13:
- modify macro name to be consistent.
  (suggested by Jan Beulich)
- fix indenting issue.
  (suggested by Jan Beulich)
v12:
- fix coding style issue.
  (suggested by Jan Beulich)
- in 'get_max_cos_max', invert the condition and dropping 'continue'.
  (suggested by Jan Beulich)
- modify 'psr_assoc_cos' to directly return 'reg' value.
  (suggested by Jan Beulich)
- modify code style.
  (suggested by Jan Beulich)
- do not break domain creation if 'psr_cos_ids' allocation fails.
  (suggested by Jan Beulich)
v11:
- replace 'feat_init_done()' to 'feat_init' flag.
  (suggested by Jan Beulich)
- adjust parameters positions when calling 'psr_assoc_cos'.
  (suggested by Jan Beulich)
- add comment to explain why to check 'psr_cos_ids'.
v10:
- remove 'cat_get_cos_max' as 'cos_max' is a feature property now which
  can be directly used.
  (suggested by Jan Beulich)
- replace 'info->feat_mask' check to 'feat_init_done'.
  (suggested by Jan Beulich)
v9:
- rename 'l3_cat_get_cos_max' to 'cat_get_cos_max' to cover all CAT/CDP
  features.
  (suggested by Roger Pau)
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- implement 'psr_alloc_cos' to match 'psr_free_cos'.
  (suggested by Wei Liu)
- use 'psr_alloc_feat_enabled'.
  (suggested by Wei Liu)
- fix coding style issue.
  (suggested by Wei Liu)
- remove 'inline'.
  (suggested by Jan Beulich)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- remove 'psr_cos_ids' check in 'psr_free_cos'.
  (suggested by Jan Beulich)
v6:
- change 'PSR_ASSOC_REG_POS' to 'PSR_ASSOC_REG_SHIFT'.
  (suggested by Konrad Rzeszutek Wilk)
v5:
- rename 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
- define 'PSR_ASSOC_REG_POS'.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/domain.c |  3 +--
 xen/arch/x86/psr.c| 67 ---
 xen/include/asm-x86/psr.h |  2 +-
 3 files changed, 65 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index dd8bf13..b88ee75 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -495,8 +495,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 spin_lock_init(&d->arch.e820_lock);
 
-if ( (rc = psr_domain_init(d)) != 0 )
-goto fail;
+psr_domain_init(d);
 
 if ( is_hvm_domain(d) )
 {
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 39d8581..91bb1f0 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -50,6 +50,8 @@
  */
 #define MAX_COS_REG_CNT  128
 
+#define ASSOC_REG_SHIFT 32
+
 /*
  * Every PSR feature uses some COS registers for each COS ID, e.g. CDP uses 2
  * COS registers (DATA and CODE) for one COS ID, but CAT uses 1 COS register.
@@ -372,11 +374,37 @@ void psr_free_rmid(struct domain *d)
 d->arch.psr_rmid = 0;
 }
 
-static inline void psr_assoc_init(void)
+static unsigned int get_max_cos_max(const struct psr_socket_info *info)
+{
+unsigned int cos_max = 0, i;
+
+for ( i = 0; i < ARRAY_SIZE(info->features); i++ )
+{
+const struct feat_node *feat = info->features[i];
+
+if ( feat )
+cos_max = max(feat->cos_max, cos_max);
+}
+
+return cos_max;
+}
+
+static void psr_assoc_init(void)
 {
 struct psr_assoc *psra = &this_cpu(psr_assoc);
 
-if ( psr_cmt_enabled() )
+if ( psr_alloc_feat_enabled() )
+{
+unsigned int socket = cpu_to_socket(smp_processor_id());
+const struct psr_socket_info *info = socket_info + socket;
+unsigned int cos_max = get_max_cos_max(info);
+
+if ( info->feat_init )
+psra->cos_mask = ((1ull << get_count_order(cos_max)) - 1) <<
+ ASSOC_REG_SHIFT;
+}
+
+if ( psr_cmt_enabled() || psra->cos_mask )
 rdmsrl(MSR_IA32_PSR_ASSOC, psra->val);
 }
 
@@ -385,6 +413,13 @@ static inline void psr_assoc_rmid(uint64_t *reg, unsigned 
int rmid)
 *reg = (*reg & ~rmid_mask) | (rmid & rmid_mask);
 }
 
+static uint64_t psr_assoc_cos(uint64_t reg, unsigned int cos,
+  uint64_t cos_mask)
+{
+return (reg & ~cos_mask) |
+(((uint64_t)cos << ASSOC_REG_SHIFT) & cos_mask);
+}
+
 void psr_ctxt_switch_to(struct domain *d)
 {
 struct psr_assoc *psra = &this_cpu(psr_assoc);
@@ -393,6 +428,14 @@ void psr_ctxt_s

[Xen-devel] [PATCH v14 06/23] x86: refactor psr: L3 CAT: implement get hw info flow.

[Yi Sun]

This patch implements get HW info flow including L3 CAT callback
function.

It also changes sysctl interface to make it more general.

With this patch, 'psr-hwinfo' can work for L3 CAT.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v12:
- use 'ASSERT_UNREACHABLE()' to record bug.
  (suggested by Jan Beulich)
v11:
- changes about 'cos_max' and 'cbm_len'.
  (suggested by Jan Beulich)
- change about 'feat_props'.
  (suggested by Jan Beulich)
- declare 'PSR_SOCKET_FEAT_UNKNOWN' to handle error case.
  (suggested by Jan Beulich)
- use 'ASSERT' to check data.
  (suggested by Jan Beulich)
- fix comment of 'get_feat_info'.
  (suggested by Jan Beulich)
- fix a bug when checking 'feat_type'.
  (suggested by Jan Beulich)
v10:
- remove 'PSR_SOCKET_UNKNOWN' and use 'ASSERT_UNREACHABLE()' to handle
  this case.
  (suggested by Jan Beulich)
- check 'feat_type'.
  (suggested by Jan Beulich)
- adjust macros names and values to make them more appropriate.
  (suggested by Jan Beulich)
- use 'feat_init_done'.
  (suggested by Jan Beulich)
- changes about 'cbm_len'.
  (suggested by Jan Beulich)
v9:
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- define 'PSR_INFO_SIZE'.
  (suggested by Roger Pau)
- fix coding style issue.
  (suggested by Roger Pau and Jan Beulich)
- use 'ARRAY_SIZE'.
  (suggested by Roger Pau)
- rename 'l3_cat_get_feat_info' to 'cat_get_feat_info' to make it a common
  function for both L3/L2 CAT.
  (suggested by Roger Pau)
- move constant to the right of comparison.
  (suggested by Wei Liu)
- remove wrong comment.
  (suggested by Jan Beulich)
- rename macros used by psr_get_info to make them meaningful.
  (suggested by Jan Beulich)
- remove assignment for 'PSR_SOCKET_UNKNOWN'.
  (suggested by Jan Beulich)
- retain blank line after 'case XEN_SYSCTL_PSR_CAT_get_l3_info'.
  (suggested by Jan Beulich)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- move common data check into common function.
  (suggested by Jan Beulich)
v6:
- fix coding style issue.
  (suggested by Konrad Rzeszutek Wilk)
- define 'PSR_SOCKET_UNKNOWN' in 'psr_feat_type'.
  (suggested by Konrad Rzeszutek Wilk)
- change '-ENOTSOCK' to 'ERANGE'.
  (suggested by Konrad Rzeszutek Wilk)
- modify position of macros to remove odd spacing in psr.h.
  (suggested by Konrad Rzeszutek Wilk)
v5:
- change 'dat[]' to 'data[]'.
  (suggested by Jan Beulich)
- modify parameter type to avoid fixed width type when there is no such
  intention.
  (suggested by Jan Beulich)
- use 'const' when it is possible.
  (suggested by Jan Beulich)
- check feature type outside callback function.
  (suggested by Jan Beulich)
- modify macros names to add prefix 'PSR_' and change 'CDP_FLAG' to
  'PSR_FLAG'.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c| 81 +--
 xen/arch/x86/sysctl.c | 19 ---
 xen/include/asm-x86/psr.h | 16 +++---
 3 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 91bb1f0..20d083e 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -63,6 +63,7 @@
 enum psr_feat_type {
 FEAT_TYPE_L3_CAT,
 FEAT_TYPE_NUM,
+FEAT_TYPE_UNKNOWN,
 };
 
 /*
@@ -108,6 +109,10 @@ static const struct feat_props {
  * feature does some special operations.
  */
 enum cbm_type alt_type;
+
+/* get_feat_info is used to return feature HW info through sysctl. */
+bool (*get_feat_info)(const struct feat_node *feat,
+  uint32_t data[], unsigned int array_len);
 } *feat_props[FEAT_TYPE_NUM];
 
 /*
@@ -184,6 +189,22 @@ static void free_socket_resources(unsigned int socket)
 memset(info->cos_ref, 0, MAX_COS_REG_CNT * sizeof(unsigned int));
 }
 
+static enum psr_feat_type psr_cbm_type_to_feat_type(enum cbm_type type)
+{
+enum psr_feat_type feat_type = FEAT_TYPE_UNKNOWN;
+
+switch ( type )
+{
+case PSR_CBM_TYPE_L3:
+feat_type = FEAT_TYPE_L3_CAT;
+break;
+default:
+ASSERT_UNREACHABLE();
+}
+
+return feat_type;
+}
+
 /* CAT common functions implementation. */
 static int cat_init_feature(const struct cpuid_leaf *regs,
 struct feat_node *feat,
@@ -226,11 +247,25 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 return 0;
 }
 
+static bool cat_get_feat_info(const struct feat_node *feat,
+  uint32_t data[], unsigned int array_len)
+{
+if ( array_len != PSR_INFO_ARRAY_SIZE )
+return false;
+
+data[PSR_INFO_IDX_COS_MAX] = feat->cos_max;

[Xen-devel] [PATCH v14 11/23] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

[Yi Sun]

Continue from previous patch:
'x86: refactor psr: L3 CAT: set value: implement cos finding flow.'

If fail to find a COS ID, we need pick a new COS ID for domain. Only COS ID
that ref[COS_ID] is 1 or 0 can be picked to input a new set feature values.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v13:
- remove unnecessary blank line.
  (suggested by Jan Beulich)
- remove unnecessary comment and fix comment wording.
  (suggested by Jan Beulich)
v12:
- use 'ASSERT_UNREACHABLE()' to record bug and return error code if feat
  exists but props does not exist.
  (suggested by Jan Beulich)
- declare same type vairables in one line.
  (suggested by Jan Beulich)
- use 'ARRAY_SIZE' to calculate array boundary.
  (suggested by Jan Beulich)
v11:
- remove unnecessary variable initialization.
  (suggested by Jan Beulich)
- changes about 'feat_props'.
  (suggested by Jan Beulich)
- replace 'get_val' calling to generic codes.
  (suggested by Jan Beulich)
v10:
- remove 'fits_cos_max' hook and CAT implementation. Move the process into
  generic flow.
  (suggested by Jan Beulich)
- changes about 'props'.
  (suggested by Jan Beulich)
- adjust codes positions.
  (suggested by Jan Beulich)
v9:
- modify return value of 'pick_avail_cos' to make it more accurate.
- rename 'l3_cat_fits_cos_max' to 'cat_fits_cos_max' to cover L3/L2 CAT
  features.
  (suggested by Roger Pau)
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- fix comment.
  (suggested by Wei Liu)
- directly use 'cos_reg_val[0]' as default value.
  (suggested by Jan Beulich)
- replace 'get_cos_num' to 'feat->cos_num'.
  (suggested by Jan Beulich)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v5:
- modify commit message to provide exact patch name to continue from.
  (suggested by Jan Beulich)
- change 'exceeds_cos_max' to 'fits_cos_max' to be accurate.
  (suggested by Jan Beulich)
- modify comments according to changes of codes.
  (suggested by Jan Beulich)
- modify return value of callback functions because we do not need them
  to return number of entries the feature uses. In caller, we call
  'get_cos_num' to get the number of entries the feature uses.
  (suggested by Jan Beulich)
- move type check out from callback functions to caller.
  (suggested by Jan Beulich)
- modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
- modify code format.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 81 +-
 1 file changed, 80 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index ab070c2..e698872 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -860,12 +860,91 @@ static int find_cos(const uint32_t val[], unsigned int 
array_len,
 return -ENOENT;
 }
 
+static bool fits_cos_max(const uint32_t val[],
+ uint32_t array_len,
+ const struct psr_socket_info *info,
+ unsigned int cos)
+{
+unsigned int i;
+
+for ( i = 0; i < ARRAY_SIZE(info->features); i++ )
+{
+const struct feat_node *feat = info->features[i];
+const struct feat_props *props = feat_props[i];
+
+if ( !feat )
+continue;
+
+if ( !props )
+{
+ASSERT_UNREACHABLE();
+return false;
+}
+
+if ( array_len < props->cos_num )
+return false;
+
+if ( cos > feat->cos_max )
+{
+unsigned int j;
+
+for ( j = 0; j < props->cos_num; j++ )
+{
+/* Get default value, the COS ID of which is zero. */
+uint32_t default_val = feat->cos_reg_val[j];
+
+if ( val[j] != default_val )
+return false;
+}
+}
+
+array_len -= props->cos_num;
+val += props->cos_num;
+}
+
+return true;
+}
+
 static int pick_avail_cos(const struct psr_socket_info *info,
   const uint32_t val[], unsigned int array_len,
   unsigned int old_cos,
   enum psr_feat_type feat_type)
 {
-return -ENOENT;
+unsigned int cos, cos_max = 0;
+const struct feat_node *feat;
+const unsigned int *ref = info->cos_ref;
+
+/* cos_max is the one of the feature which is being set. */
+feat = info->features[feat_type];
+if ( !feat )
+return -ENOENT;
+
+cos_max = feat->cos_max;
+if ( !cos_max )
+return -ENOENT;
+
+/* We cannot u

[Xen-devel] [PATCH v14 20/23] tools: L2 CAT: support get HW info for L2 CAT.

[Yi Sun]

This patch implements xl/xc changes to support get HW info
for L2 CAT.

'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
info.

Example(on machine which only supports L2 CAT):
Cache Monitoring Technology (CMT):
Enabled : 0
Cache Allocation Technology (CAT): L2
Socket ID   : 0
Maximum COS : 3
CBM length  : 8
Default CBM : 0xff

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 
Acked-by: Jan Beulich 
Acked-by: Wei Liu 
---
v12:
- acked by Wei for tools side changes.
v11:
- acked by Jan for Hypervisor side changes.
v10:
- change macros names according to previous changes.
  (suggested by Jan Beulich)
v9:
- add some cases to handle return error no.
- move xl_cmdimpl.c codes into xl/xl_psr.c.
- change 'l3_info' to 'cat_info' to cover both L3 and L2 CAT.
v6:
- adjust '{' position for 'switch'.
  (suggested by Wei Liu)
- modify commit message to remove error log.
  (suggested by Dario Faggioli)
v5:
- modify commit message to remove error log.
  (suggested by Wei Liu and Jan Beulich)
- replace unnecessary 'return' to 'break'.
  (suggested by Wei Liu)
- restore 'libxl_psr_cat_get_l3_info' to keep interface backward compatible
  but change codes in it to call new function to get hw info.
  (suggested by Wei Liu)
- add 'L2_CBM' into 'psr_cbm_type' because it is interface change which
  should be in same patch with new 'LIBXL_HAVE_' macro.
  (suggested by Wei Liu)
- addjust logs sentence to make unnecessary error logs not show.
  (suggested by Wei Liu and Jan Beulich)
v4:
- create this patch to help reviewers better understand the codes.
---
 tools/libxc/include/xenctrl.h |  6 ++---
 tools/libxc/xc_psr.c  | 39 +++-
 tools/libxl/libxl.h   |  9 
 tools/libxl/libxl_psr.c   | 28 ++-
 tools/libxl/libxl_types.idl   |  1 +
 tools/xl/xl_psr.c | 52 +--
 xen/arch/x86/sysctl.c | 12 +-
 xen/include/public/sysctl.h   |  2 +-
 8 files changed, 111 insertions(+), 38 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c51bb3b..c615d17 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2480,9 +2480,9 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, 
uint32_t domid,
 int xc_psr_cat_get_domain_data(xc_interface *xch, uint32_t domid,
xc_psr_cat_type type, uint32_t target,
uint64_t *data);
-int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
-   uint32_t *cos_max, uint32_t *cbm_len,
-   bool *cdp_enabled);
+int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, unsigned int lvl,
+uint32_t *cos_max, uint32_t *cbm_len,
+bool *cdp_enabled);
 
 int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps);
 int xc_get_cpu_featureset(xc_interface *xch, uint32_t index,
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 43b3286..84a08c4 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -317,24 +317,41 @@ int xc_psr_cat_get_domain_data(xc_interface *xch, 
uint32_t domid,
 return rc;
 }
 
-int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
-   uint32_t *cos_max, uint32_t *cbm_len,
-   bool *cdp_enabled)
+int xc_psr_cat_get_info(xc_interface *xch, uint32_t socket, unsigned int lvl,
+uint32_t *cos_max, uint32_t *cbm_len, bool 
*cdp_enabled)
 {
-int rc;
+int rc = -1;
 DECLARE_SYSCTL;
 
 sysctl.cmd = XEN_SYSCTL_psr_cat_op;
-sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
 sysctl.u.psr_cat_op.target = socket;
 
-rc = xc_sysctl(xch, &sysctl);
-if ( !rc )
+switch ( lvl )
 {
-*cos_max = sysctl.u.psr_cat_op.u.l3_info.cos_max;
-*cbm_len = sysctl.u.psr_cat_op.u.l3_info.cbm_len;
-*cdp_enabled = sysctl.u.psr_cat_op.u.l3_info.flags &
-   XEN_SYSCTL_PSR_CAT_L3_CDP;
+case 2:
+sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l2_info;
+rc = xc_sysctl(xch, &sysctl);
+if ( !rc )
+{
+*cos_max = sysctl.u.psr_cat_op.u.cat_info.cos_max;
+*cbm_len = sysctl.u.psr_cat_op.u.cat_info.cbm_len;
+*cdp_enabled = false;
+}
+break;
+case 3:
+sysctl.u.psr_cat_op.cmd = XEN_SYSCTL_PSR_CAT_get_l3_info;
+rc = xc_sysctl(xch, &sysctl);
+if ( !rc )
+{
+*cos_max = sysctl.u.psr_cat_op.u.cat_info.cos_max;
+*cbm_len = sysctl.u.psr_cat_op.u.cat_info.cbm_len;
+*cdp_enabled = sysctl.u.psr_cat_op.u.cat_info.flags &
+   XEN_SYSCTL_PSR_CAT_L3_CDP;
+}
+break;
+default:
+

[Xen-devel] [PATCH v14 22/23] tools: L2 CAT: support set cbm for L2 CAT.

[Yi Sun]

This patch implements the xl/xc changes to support set CBM
for L2 CAT.

The new level option is introduced to original CAT setting
command in order to set CBM for specified level CAT.
- 'xl psr-cat-set' is updated to set cache capacity bitmasks(CBM)
  for a domain according to input cache level.

root@:~$ xl psr-cat-set -l2 1 0x7f

root@:~$ xl psr-cat-show -l2 1
Socket ID   : 0
Default CBM : 0xff
   ID NAME CBM
1 ubuntu140x7f

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
---
v11:
- revert change in v9 to handle the case to set both CODE and DATA for CDP
  at same time. This must be handled in hypervisor.
v10:
- fix comments.
  (suggested by Wei Liu)
v9:
- handle the case to set both CODE and DATA for CDP at same time.
  For such case, user does not input '-c' or '-d' to set CDP cbm.
- move xl_cmdimpl.c changes into xl/xl_psr.c.
- move xl_cmdtable.c changes into xl/xl_cmdtable.c.
v6:
- rename 'psr-cat-cbm-set' to 'psr-cat-set'.
  (suggested by Kevin Tian)
- return 'EXIT_FAILURE' for error case.
  (suggested by Dario Faggioli)
- print error info when input level is wrong.
v4:
- create this patch because of codes architecture change.
---
 tools/libxc/xc_psr.c   |  3 +++
 tools/xl/xl_cmdtable.c |  3 ++-
 tools/xl/xl_psr.c  | 33 +++--
 3 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 04f5927..039b920 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -266,6 +266,9 @@ int xc_psr_cat_set_domain_data(xc_interface *xch, uint32_t 
domid,
 case XC_PSR_CAT_L3_CBM_DATA:
 cmd = XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA;
 break;
+case XC_PSR_CAT_L2_CBM:
+cmd = XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM;
+break;
 default:
 errno = EINVAL;
 return -1;
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 539cb64..2c71a9f 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -546,11 +546,12 @@ struct cmd_spec cmd_table[] = {
 },
 #endif
 #ifdef LIBXL_HAVE_PSR_CAT
-{ "psr-cat-cbm-set",
+{ "psr-cat-set",
   &main_psr_cat_cbm_set, 0, 1,
   "Set cache capacity bitmasks(CBM) for a domain",
   "[options]  ",
   "-sSpecify the socket to process, otherwise all sockets 
are processed\n"
+  "-l Specify the cache level to process, otherwise L3 
cache is processed\n"
   "-cSet code CBM if CDP is supported\n"
   "-dSet data CBM if CDP is supported\n"
 },
diff --git a/tools/xl/xl_psr.c b/tools/xl/xl_psr.c
index 575f4a0..7309d4f 100644
--- a/tools/xl/xl_psr.c
+++ b/tools/xl/xl_psr.c
@@ -490,19 +490,21 @@ int main_psr_cat_cbm_set(int argc, char **argv)
 char *value;
 libxl_string_list socket_list;
 unsigned long start, end;
-int i, j, len;
+unsigned int i, j, len;
+unsigned int lvl = 3;
 
 static struct option opts[] = {
 {"socket", 1, 0, 's'},
 {"data", 0, 0, 'd'},
 {"code", 0, 0, 'c'},
+{"level", 1, 0, 'l'},
 COMMON_LONG_OPTS
 };
 
 libxl_socket_bitmap_alloc(ctx, &target_map, 0);
 libxl_bitmap_set_none(&target_map);
 
-SWITCH_FOREACH_OPT(opt, "s:cd", opts, "psr-cat-cbm-set", 2) {
+SWITCH_FOREACH_OPT(opt, "s:l:cd", opts, "psr-cat-set", 2) {
 case 's':
 trim(isspace, optarg, &value);
 split_string_into_string_list(value, ",", &socket_list);
@@ -522,24 +524,35 @@ int main_psr_cat_cbm_set(int argc, char **argv)
 case 'c':
 opt_code = 1;
 break;
+case 'l':
+lvl = atoi(optarg);
+break;
 }
 
-if (opt_data && opt_code) {
-fprintf(stderr, "Cannot handle -c and -d at the same time\n");
-return -1;
-} else if (opt_data) {
-type = LIBXL_PSR_CBM_TYPE_L3_CBM_DATA;
-} else if (opt_code) {
-type = LIBXL_PSR_CBM_TYPE_L3_CBM_CODE;
+if (lvl == 2)
+type = LIBXL_PSR_CBM_TYPE_L2_CBM;
+else if (lvl == 3) {
+if (opt_data && opt_code) {
+fprintf(stderr, "Cannot handle -c and -d at the same time\n");
+return EXIT_FAILURE;
+} else if (opt_data) {
+type = LIBXL_PSR_CBM_TYPE_L3_CBM_DATA;
+} else if (opt_code) {
+type = LIBXL_PSR_CBM_TYPE_L3_CBM_CODE;
+} else {
+type = LIBXL_PSR_CBM_TYPE_L3_CBM;
+}
 } else {
 type = LIBXL_PSR_CBM_TYPE_L3_CBM;
+fprintf(stderr, "Input lvl %d is wrong\n", lvl);
+return EXIT_FAILURE;
 }
 
 if (libxl_bitmap_is_empty(&target_map))
 libxl_bitmap_set_any(&target_map);
 
 if (argc != optind + 2) {
-help("psr-cat-cbm-set");
+help("psr-cat-set");
 return 2;
 }
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-dev

[Xen-devel] [PATCH v14 16/23] x86: L2 CAT: implement CPU init flow.

[Yi Sun]

This patch implements the CPU init flow for L2 CAT.

Signed-off-by: Yi Sun 
---
v14:
- remove the 'Notes' in commit message because a stub function is
  implemented to avoid the potential issue.
  (suggested by Jan Beulich)
- put address of 'feat_l2_cat' back to it if 'cat_init_feature()' fails
  to avoid leakage.
  (suggested by Jan Beulich)
- change 'feat_name' to 'cat_feat_name' and move it into
  'cat_init_feature()' which is the only caller.
  (suggested by Jan Beulich)
- register the callback functions into 'l2_cat_props' to avoid crash if
  user does not apply later patches.
  (suggested by Jan Beulich)
v13:
- add commit message.
  (suggested by Jan Beulich)
- set 'alt_type' for L2 CAT.
  (suggested by Jan Beulich)
- define a static string array to show which feature's info is printing.
  (suggested by Jan Beulich)
v12:
- move 'type[]' assignment into l2_cat_props declaration to make it be
  'const'.
  (suggested by Jan Beulich)
- add "L2 CAT" indicator in printk.
  (suggested by Jan Beulich)
- restore mask(0) MSR to default value.
  (suggested by Jan Beulich)
v11:
- move l2 cat 'type[]' assignement into 'psr_cpu_init'.
- remove COS MSR restore action in 'cpu_init_feature'.
- set 'feat_init' to true after CPU init.
- modify commit message.
v10:
- implement L2 CAT case in 'cat_init_feature'.
  (suggested by Jan Beulich)
- changes about 'props'.
  (suggested by Jan Beulich)
- introduce 'PSR_CBM_TYPE_L2'.
v9:
- modify error handling process in 'psr_cpu_prepare' to reduce redundant
  codes.
- reuse 'cat_init_feature' and 'cat_get_cos_max' for L2 CAT to reduce
  redundant codes.
  (suggested by Roger Pau)
- remove unnecessary comment.
  (suggested by Jan Beulich)
- move L2 CAT related codes from 'cpu_init_work' into 'psr_cpu_init'.
  (suggested by Jan Beulich)
- do not free resource when allocation fails in 'psr_cpu_prepare'.
  (suggested by Jan Beulich)
v7:
- initialize 'l2_cat'.
  (suggested by Konrad Rzeszutek Wilk)
v6:
- use 'struct cpuid_leaf'.
  (suggested by Konrad Rzeszutek Wilk and Jan Beulich)
v5:
- remove 'feat_l2_cat' free in 'free_feature'.
  (suggested by Jan Beulich)
- encapsulate cpuid registers into 'struct cpuid_leaf_regs'.
  (suggested by Jan Beulich)
- print socket info when 'opt_cpu_info' is true.
  (suggested by Jan Beulich)
- rename 'l2_cat_get_max_cos_max' to 'l2_cat_get_cos_max'.
  (suggested by Jan Beulich)
- rename 'dat[]' to 'data[]'
  (suggested by Jan Beulich)
- move 'cpu_prepare_work' contents into 'psr_cpu_prepare'.
  (suggested by Jan Beulich)
v4:
- create this patch because of codes architecture change.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c  | 48 ++---
 xen/include/asm-x86/msr-index.h |  1 +
 xen/include/asm-x86/psr.h   |  2 ++
 3 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index c211c77..320c2c7 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -63,6 +63,7 @@
 enum psr_feat_type {
 FEAT_TYPE_L3_CAT,
 FEAT_TYPE_L3_CDP,
+FEAT_TYPE_L2_CAT,
 FEAT_TYPE_NUM,
 FEAT_TYPE_UNKNOWN,
 };
@@ -159,6 +160,7 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
  * array creation. It is used to transiently store a spare node.
  */
 static struct feat_node *feat_l3;
+static struct feat_node *feat_l2_cat;
 
 /* Common functions */
 #define cat_default_val(len) (0x >> (32 - (len)))
@@ -273,6 +275,12 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 struct psr_socket_info *info,
 enum psr_feat_type type)
 {
+const char * const cat_feat_name[FEAT_TYPE_NUM] = {
+"L3 CAT",
+"CDP",
+"L2 CAT",
+};
+
 /* No valid value so do not enable feature. */
 if ( !regs->a || !regs->d )
 return -ENOENT;
@@ -283,13 +291,17 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 switch ( type )
 {
 case FEAT_TYPE_L3_CAT:
+case FEAT_TYPE_L2_CAT:
 if ( feat->cos_max < 1 )
 return -ENOENT;
 
 /* We reserve cos=0 as default cbm (all bits within cbm_len are 1). */
 feat->cos_reg_val[0] = cat_default_val(feat->cbm_len);
 
-wrmsrl(MSR_IA32_PSR_L3_MASK(0), cat_default_val(feat->cbm_len));
+wrmsrl((type == FEAT_TYPE_L3_CAT ?
+MSR_IA32_PSR_L3_MASK(0) :
+MSR_IA32_PSR_L2_MASK(0)),
+   cat_default_val(feat->cbm_len));
 
 break;
 
@@ -327,8 +339,8 @@ static int cat_init_feature(const struct cpuid_leaf *regs,
 return 0;
 
 printk(XENLOG_INFO "%s: enabled on socket %u, cos_max:%u, cbm_len:%u\n",
-   ((type == FEAT_TYPE_L3_CDP) ? "CDP" : "L3 CAT"),
-

[Xen-devel] [PATCH v14 08/23] x86: refactor psr: L3 CAT: set value: implement framework.

[Yi Sun]

As set value flow is the most complicated one in psr, it will be
divided to some patches to make things clearer. This patch
implements the set value framework to show a whole picture firstly.

It also changes domctl interface to make it more general.

To make the set value flow be general and can support multiple features
at same time, it includes below steps:
1. Test and set dom_ids bit corresponding to the domain. If the old bit is 0
   which means the domain's COS ID is invalid, restore COS ID to 0. If the
   COS ID is valid, get the COS ID that current domain is using.
2. Gather a value array to store all features current value
   into it and replace the current value of the feature which is
   being set to the new input value.
3. Find if there is already a COS ID on which all features'
   values are same as the array. Then, we can reuse this COS
   ID.
4. If fail to find, we need pick an available COS ID. Only COS ID which ref
   is 0 or 1 can be picked.
5. Write the feature's MSRs according to the COS ID.
6. Update ref according to COS ID.
7. Save the COS ID into current domain's psr_cos_ids[socket] so that we
   can know which COS the domain is using on the socket.

So, some functions are abstracted and the callback functions will be
implemented in next patches.

Here is an example to understand the process. The CPU supports
two featuers, e.g. L3 CAT and L2 CAT. User wants to set L3 CAT
of Dom1 to 0x1ff.
1. At the initial time, the old_cos of Dom1 is 0. The COS registers values
are below at this time.
---
| COS 0 | COS 1 | COS 2 | ... |
---
L3 CAT  | 0x7ff | 0x7ff | 0x7ff | ... |
---
L2 CAT  | 0xff  | 0xff  | 0xff  | ... |
---

2. Gather the value array and insert new value into it:
val[0]: 0x1ff
val[1]: 0xff

3. It cannot find a matching COS.

4. Pick COS 1 to store the value set.

5. Write the L3 CAT COS 1 registers. The COS registers values are
changed to below now.
---
| COS 0 | COS 1 | COS 2 | ... |
---
L3 CAT  | 0x7ff | 0x1ff | ...   | ... |
---
L2 CAT  | 0xff  | 0xff  | ...   | ... |
---

6. The ref[1] is increased to 1 because Dom1 is using it now.

7. Save 1 to Dom1's psr_cos_ids[socket].

Then, user wants to set L3 CAT of Dom2 to 0x1ff too. The old_cos
of Dom2 is 0 too. Repeat above flow.

The val array assembled is:
val[0]: 0x1ff
val[1]: 0xff

So, it can find a matching COS, COS 1. Then, it can reuse COS 1
for Dom2.

The ref[1] is increased to 2 now because both Dom1 and Dom2 are
using this COS ID. Set 1 to Dom2's psr_cos_ids[socket].

There is one thing need to emphasize that we need restore domain's COS ID to
0 when socket is offline. Otherwise, a wrong COS ID will be used when the
socket is online again. That may cause user see the wrong CBM shown. But it
takes much time to iterate all domains to restore COS ID to 0. So, we define
a 'dom_ids[]' to represents all domains, one bit corresponds to one domain.
If the bit is 0 when entering 'psr_ctxt_switch_to', that means this is the
first time the domain is switched to this socket or domain's COS ID has not
been set since the socket is online. So, the COS ID set to ASSOC register on
this socket should be default value, 0. If not, that means the domain's COS
ID has been set when the socket was online. So, this COS ID is valid and we
can directly use it. We restore the domain's COS ID to 0 if the bit
corresponding to the domain is 0 but the domain's COS ID is not 0 when
'psr_get_val' and 'psr_set_val' is called. This can avoid CPU serialization
if restoring action is exectued in 'psr_ctxt_switch_to'.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v14:
- add 'const' for parameter 'val[]' in 'write_psr_msrs'.
  (suggested by Jan Beulich)
v13:
- replace 'test_bit' to 'test_and_set_bit' in 'psr_get_val/psr_set_val'.
  (suggested by Jan Beulich)
- remove 'set_bit' used in 'psr_set_val' .
  (suggested by Jan Beulich)
- remove unused parameter in 'get_cos_num()'.
  (suggested by Jan Beulich)
v12:
- remove the memebers position changes in 'psr_socket_info'.
  (suggested by Jan Beulich)
- rename 'dom_ids' to 'dom_set'.
  (suggested by Jan Beulich)
- call 'bitmap_zero' to clear bitmap.
  (suggested by Jan Beulich)
- combine two if()-s in 'psr_ctxt_switch_to' and add comment.
  (suggested by Jan Beulich)
- remove redundant check in 'psr_get_val'.
  (suggested by Jan Beulich)
- use 'domain_lock()' to protect 'psr_cos_ids' so that the codes do not
  depend on 'domctl_lock'.
  (suggested by Jan Beulich)
- adjust codes to avoid cast in 'psr_set_val'.
  (suggested by Jan Beulich)
- adjust codes to avoid duplication of error paths in 'psr_set_val'.
  (sug

[Xen-devel] [PATCH v14 17/23] x86: L2 CAT: implement get hw info flow.

[Yi Sun]

This patch implements L2 CAT get HW info flow and interface in sysctl.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v10:
- modify macro name according to previous patch change.
  (suggested by Jan Beulich)
- modify commit message.
v9:
- reuse 'cat_get_feat_info' for L2 CAT to reduce redundant codes.
  (suggested by Roger Pau)
- modify sysctl implementation of L2 CAT to input data[3] to use
  'cat_get_feat_info'.
  (suggested by Roger Pau)
- modify macros names to newly defined ones.
  (suggested by Jan Beulich)
- remove 'l2_info' to reuse 'l3_info'.
  (suggested by Jan Beulich)
- modify macro name according to previous patch change.
  (suggested by Jan Beulich)
v5:
- rename 'dat[]' to 'data[]'
  (suggested by Jan Beulich)
- remove type check in callback function.
  (suggested by Jan Beulich)
v4:
- create this patch because of codes architecture change.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c  |  4 
 xen/arch/x86/sysctl.c   | 23 +--
 xen/include/public/sysctl.h |  1 +
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 320c2c7..1b1a36b 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -239,6 +239,10 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum 
cbm_type type)
 feat_type = FEAT_TYPE_L3_CDP;
 break;
 
+case PSR_CBM_TYPE_L2:
+feat_type = FEAT_TYPE_L2_CAT;
+break;
+
 default:
 ASSERT_UNREACHABLE();
 }
diff --git a/xen/arch/x86/sysctl.c b/xen/arch/x86/sysctl.c
index c23270d..5e91755 100644
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -174,10 +174,10 @@ long arch_do_sysctl(
 case XEN_SYSCTL_psr_cat_op:
 switch ( sysctl->u.psr_cat_op.cmd )
 {
-case XEN_SYSCTL_PSR_CAT_get_l3_info:
-{
 uint32_t data[PSR_INFO_ARRAY_SIZE];
 
+case XEN_SYSCTL_PSR_CAT_get_l3_info:
+{
 ret = psr_get_info(sysctl->u.psr_cat_op.target,
PSR_CBM_TYPE_L3, data, ARRAY_SIZE(data));
 if ( ret )
@@ -195,6 +195,25 @@ long arch_do_sysctl(
 break;
 }
 
+case XEN_SYSCTL_PSR_CAT_get_l2_info:
+{
+ret = psr_get_info(sysctl->u.psr_cat_op.target,
+   PSR_CBM_TYPE_L2, data, ARRAY_SIZE(data));
+if ( ret )
+break;
+
+sysctl->u.psr_cat_op.u.l3_info.cos_max =
+  data[PSR_INFO_IDX_COS_MAX];
+sysctl->u.psr_cat_op.u.l3_info.cbm_len =
+  data[PSR_INFO_IDX_CAT_CBM_LEN];
+sysctl->u.psr_cat_op.u.l3_info.flags =
+  data[PSR_INFO_IDX_CAT_FLAG];
+
+if ( !ret && __copy_field_to_guest(u_sysctl, sysctl, u.psr_cat_op) 
)
+ret = -EFAULT;
+break;
+}
+
 default:
 ret = -EOPNOTSUPP;
 break;
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index ee76a66..4c76d3a 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -744,6 +744,7 @@ typedef struct xen_sysctl_pcitopoinfo 
xen_sysctl_pcitopoinfo_t;
 DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
 
 #define XEN_SYSCTL_PSR_CAT_get_l3_info   0
+#define XEN_SYSCTL_PSR_CAT_get_l2_info   1
 struct xen_sysctl_psr_cat_op {
 uint32_t cmd;   /* IN: XEN_SYSCTL_PSR_CAT_* */
 uint32_t target;/* IN */
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v14 23/23] docs: add L2 CAT description in docs.

[Yi Sun]

This patch adds L2 CAT description in related documents.

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 
Acked-by: Wei Liu 
---
v13:
- rebase the patch on latest code.
---
 docs/man/xl.pod.1.in  | 27 +++
 docs/misc/xl-psr.markdown | 18 --
 2 files changed, 35 insertions(+), 10 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index d87fe16..16c8306 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1712,6 +1712,9 @@ occupancy monitoring share the same set of underlying 
monitoring service. Once
 a domain is attached to the monitoring service, monitoring data can be shown
 for any of these monitoring types.
 
+There is no cache monitoring and memory bandwidth monitoring on L2 cache so
+far.
+
 =over 4
 
 =item B I
@@ -1736,7 +1739,7 @@ monitor types are:
 
 Intel Broadwell and later server platforms offer capabilities to configure and
 make use of the Cache Allocation Technology (CAT) mechanisms, which enable more
-cache resources (i.e. L3 cache) to be made available for high priority
+cache resources (i.e. L3/L2 cache) to be made available for high priority
 applications. In the Xen implementation, CAT is used to control cache 
allocation
 on VM basis. To enforce cache on a specific domain, just set capacity bitmasks
 (CBM) for the domain.
@@ -1746,11 +1749,11 @@ Intel Broadwell and later server platforms also offer 
Code/Data Prioritization
 applications. CDP is used on a per VM basis in the Xen implementation. To
 specify code or data CBM for the domain, CDP feature must be enabled and CBM
 type options need to be specified when setting CBM, and the type options (code
-and data) are mutually exclusive.
+and data) are mutually exclusive. There is no CDP support on L2 so far.
 
 =over 4
 
-=item B [I] I I
+=item B [I] I I
 
 Set cache capacity bitmasks(CBM) for a domain. For how to specify I
 please refer to L.
@@ -1763,6 +1766,11 @@ B
 
 Specify the socket to process, otherwise all sockets are processed.
 
+=item B<-l LEVEL>, B<--level=LEVEL>
+
+Specify the cache level to process, otherwise the last level cache (L3) is
+processed.
+
 =item B<-c>, B<--code>
 
 Set code CBM when CDP is enabled.
@@ -1773,10 +1781,21 @@ Set data CBM when CDP is enabled.
 
 =back
 
-=item B [I]
+=item B [I] [I]
 
 Show CAT settings for a certain domain or all domains.
 
+B
+
+=over 4
+
+=item B<-l LEVEL>, B<--level=LEVEL>
+
+Specify the cache level to process, otherwise the last level cache (L3) is
+processed.
+
+=back
+
 =back
 
 =head1 IGNORED FOR COMPATIBILITY WITH XM
diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index c3c1e8e..04dd957 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -70,7 +70,7 @@ total-mem-bandwidth instead of cache-occupancy). E.g. after a 
`xl psr-cmt-attach
 
 Cache Allocation Technology (CAT) is a new feature available on Intel
 Broadwell and later server platforms that allows an OS or Hypervisor/VMM to
-partition cache allocation (i.e. L3 cache) based on application priority or
+partition cache allocation (i.e. L3/L2 cache) based on application priority or
 Class of Service (COS). Each COS is configured using capacity bitmasks (CBM)
 which represent cache capacity and indicate the degree of overlap and
 isolation between classes. System cache resource is divided into numbers of
@@ -107,7 +107,7 @@ System CAT information such as maximum COS and CBM length 
can be obtained by:
 
 The simplest way to change a domain's CBM from its default is running:
 
-`xl psr-cat-cbm-set  [OPTIONS]  `
+`xl psr-cat-set  [OPTIONS]  `
 
 where cbm is a number to represent the corresponding cache subset can be used.
 A cbm is valid only when:
@@ -119,13 +119,19 @@ A cbm is valid only when:
 In a multi-socket system, the same cbm will be set on each socket by default.
 Per socket cbm can be specified with the `--socket SOCKET` option.
 
+In different systems, the different cache level is supported, e.g. L3 cache or
+L2 cache. Per cache level cbm can be specified with the `--level LEVEL` option.
+
 Setting the CBM may not be successful if insufficient COS is available. In
 such case unused COS(es) may be freed by setting CBM of all related domains to
 its default value(all-ones).
 
 Per domain CBM settings can be shown by:
 
-`xl psr-cat-show`
+`xl psr-cat-show [OPTIONS] `
+
+In different systems, the different cache level is supported, e.g. L3 cache or
+L2 cache. Per cache level cbm can be specified with the `--level LEVEL` option.
 
 ## Code and Data Prioritization (CDP)
 
@@ -172,13 +178,13 @@ options is invalid.
 Example:
 
 Setting code CBM for a domain:
-`xl psr-cat-cbm-set -c  `
+`xl psr-cat-set -c  `
 
 Setting data CBM for a domain:
-`xl psr-cat-cbm-set -d  `
+`xl psr-cat-set -d  `
 
 Setting the same code and data CBM for a domain:
-`xl psr-cat-cbm-set  `
+`xl psr-cat-set  `
 
 ## Reference
 
-- 
1.9.1


_

[Xen-devel] [PATCH v14 02/23] x86: move cpuid_count_leaf from cpuid.c to processor.h.

[Yi Sun]

This patch moves 'cpuid_count_leaf' from cpuid.c to processor.h to
make it available to external codes.

Signed-off-by: Yi Sun 
Acked-by: Jan Beulich 
---
v9:
- create this patch alone to move 'cpuid_count_leaf'.
  (suggested by Wei Liu)
v6:
- use 'struct cpuid_leaf' in psr.c. So we have to access 'cpuid_count_leaf'
  which has to be moved to processor.h.
  (suggested by Andrew Cooper)
---
 xen/arch/x86/cpuid.c| 6 --
 xen/include/asm-x86/processor.h | 7 +++
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index d359e09..f1a6e9f 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -35,12 +35,6 @@ static void cpuid_leaf(uint32_t leaf, struct cpuid_leaf 
*data)
 cpuid(leaf, &data->a, &data->b, &data->c, &data->d);
 }
 
-static void cpuid_count_leaf(uint32_t leaf, uint32_t subleaf,
- struct cpuid_leaf *data)
-{
-cpuid_count(leaf, subleaf, &data->a, &data->b, &data->c, &data->d);
-}
-
 static void sanitise_featureset(uint32_t *fs)
 {
 /* for_each_set_bit() uses unsigned longs.  Extend with zeroes. */
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 5bf56b4..4bef698 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #endif
 
 #include 
@@ -264,6 +265,12 @@ static always_inline unsigned int cpuid_count_ebx(
 return ebx;
 }
 
+static always_inline void cpuid_count_leaf(uint32_t leaf, uint32_t subleaf,
+   struct cpuid_leaf *data)
+{
+cpuid_count(leaf, subleaf, &data->a, &data->b, &data->c, &data->d);
+}
+
 static inline unsigned long read_cr0(void)
 {
 unsigned long cr0;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [ovmf baseline-only test] 71692: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71692 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71692/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0df6c8c157af9510e21bff7bb8aa1f461d04707b
baseline version:
 ovmf b926f2f2a4cd404df1d2c1dddbcd1178acc63b5e

Last test of basis71689  2017-07-14 03:51:09 Z0 days
Testing same since71692  2017-07-14 22:51:24 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


commit 0df6c8c157af9510e21bff7bb8aa1f461d04707b
Author: Ard Biesheuvel 
Date:   Thu Jul 13 13:44:27 2017 +0100

BaseTools/tools_def AARCH64: avoid SIMD registers in XIP code

XIP code may execute with the MMU off, in which case all memory accesses
should be strictly aligned to their size. Some versions of GCC violate
this restriction even when -mstrict-align is passed, when performing
loads and stores that involve SIMD registers. This is clearly a bug in
the compiler, but we can easily work around it by avoiding SIMD registers
altogether when building code that may execute in such a context. So add
-mgeneral-regs-only to the AARCH64 XIP CC flags.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 6d73863b5464f382af2a17b2c2ec1abc550d0af5
Author: Ard Biesheuvel 
Date:   Thu Jul 13 13:41:12 2017 +0100

BaseTools/tools_def AARCH64: mark register x18 as reserved

The AArch64 ABI classifies register x18 as a platform register, which
means it should not be used unless the code is guaranteed to run on a
platform that doesn't use it in such a capacity.

GCC does not honour this requirement by default, and so we need to tell
it not to touch it explicitly, by passing the -ffixed-x18 command line
option.

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=625
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v14 07/23] x86: refactor psr: L3 CAT: implement get value flow.

[Yi Sun]

There is an interface in user space to show feature value of
domains.

This patch implements get value flow in hypervisor.

It also changes domctl interface to make it more general.

With this patch, 'psr-cat-show' can work for L3 CAT but not for
L3 code/data which is implemented in CDP related patches.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v14:
- rebase domctl.c on latest code: bool_t is replaced by bool.
v12:
- remove 'psr_get_feat_and_type' and implement its functionality in
  'psr_get_val'.
- use 'ASSERT_UNREACHABLE' to record error.
  (suggested by Jan Beulich)
- return success only if the 'val' is set in 'psr_get_val'.
  (suggested by Jan Beulich)
v11:
- declare a 'switch()' wide variable 'val32' in domctl.
  (suggested by Jan Beulich)
- remove 'get_val' callback function which is replaced by generic codes.
  (suggested by Jan Beulich)
- fix coding style issue.
  (suggested by Jan Beulich)
- do not 'ASSERT' domain pointer.
  (suggested by Jan Beulich)
- modify commit message.
v10:
- use an intermediate variable to get value and avoid cast in domctl.
  (suggested by Jan Beulich)
- remove 'type' in 'get_val' parameters and will add it back when
  implementing CDP.
  (suggested by Jan Beulich)
- remove unnecessary variable and return error about 'info' in
  'psr_get_feat'.
  (suggested by Jan Beulich)
- use 'ASSERT' to check input parameter in 'psr_get_val'.
  (suggested by Jan Beulich)
- changes about 'feat_props'.
  (suggested by Jan Beulich)
v9:
- add commit message to explain there is an user space interface.
- rename 'l3_cat_get_val' to 'cat_get_val' to cover all L3/L2 CAT features.
  (suggested by Roger Pau)
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- change parameter of 'psr_get'. Use 'psr_cos_ids' directly to replace
  domain. Also declare it to 'const'.
  (suggested by Jan Beulich)
- change code flow to remove 'psr_get' but add 'psr_get_feat' to make codes
  more reasonable.
  (suggested by Jan Beulich)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- move cos check into common function because this check is required by all
  features.
  (suggested by Jan Beulich)
- fix coding style issue.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v7:
- rename '__psr_get' to 'psr_get'.
  (suggested by Wei Liu)
v6:
- modify commit message to make it clearer.
  (suggested by Konrad Rzeszutek Wilk)
- remove one extra space in code.
  (suggested by Konrad Rzeszutek Wilk)
- remove unnecessary comment.
  (suggested by Konrad Rzeszutek Wilk)
- write a helper function to move get info and get val functions into
  it. Because most codes of 'get_info' and 'get_val' are same.
  (suggested by Konrad Rzeszutek Wilk)
v5:
- rename 'dat[]' to 'data[]'
  (suggested by Jan Beulich)
- modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
- check if feature type match in caller of feature callback function.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/domctl.c | 20 ++-
 xen/arch/x86/psr.c| 51 ---
 xen/include/asm-x86/psr.h |  4 ++--
 3 files changed, 61 insertions(+), 14 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 7fa58b4..abfa68a 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1419,6 +1419,8 @@ long arch_do_domctl(
 case XEN_DOMCTL_psr_cat_op:
 switch ( domctl->u.psr_cat_op.cmd )
 {
+uint32_t val32;
+
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM:
 ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
  domctl->u.psr_cat_op.data,
@@ -1438,23 +1440,23 @@ long arch_do_domctl(
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
-ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- &domctl->u.psr_cat_op.data,
- PSR_CBM_TYPE_L3);
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  &val32, PSR_CBM_TYPE_L3);
+domctl->u.psr_cat_op.data = val32;
 copyback = true;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE:
-ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- &domctl->u.psr_cat_op.data,
- PSR_CBM_TYPE_L3_CODE);
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  &val32, PSR_CBM_TYPE_L3_CODE);
+  

[Xen-devel] [PATCH v14 09/23] x86: refactor psr: L3 CAT: set value: assemble features value array.

[Yi Sun]

Only can one COS ID be used by one domain at one time. That means all enabled
features' COS registers at this COS ID are valid for this domain at that time.

When user updates a feature's value, we need make sure all other features'
values are not affected. So, we firstly need gather an array which contains
all features current values and replace the setting feature's value in array
to new value.

Then, we can try to find if there is a COS ID on which all features' COS
registers values are same as the array. If we can find, we just use this COS
ID. If fail to find, we need pick a new COS ID.

This patch implements value array assembling flow.

Signed-off-by: Yi Sun 
Reviewed-by: Jan Beulich 
---
v14:
- remove parameter '**val' in skip_prior_features and return the length to
  skip value array in the caller.
  (suggested by Jan Beulich)
- remove a stray blank.
  (suggested by Jan Beulich)
v13:
- remove an unnecessary blank line.
  (suggested by Jan Beulich)
- add a new function 'skip_prior_features()' to skip value array according
  to feature type. This function will be used in later patches too.
  (suggested by Jan Beulich)
v12:
- use 'ARRAY_SIZE' to calculate array boundary.
  (suggested by Jan Beulich)
- use 'ASSERT_UNREACHABLE()' to record bug and return error code if feat
  exist but props does not exist.
  (suggested by Jan Beulich)
- return 0 only when value is set in 'insert_val_into_array'.
  (suggested by Jan Beulich)
v11:
- changes about 'feat_props'.
  (suggested by Jan Beulich)
- changes about 'get_val'. It is replaced by generic codes.
  (suggested by Jan Beulich)
v10:
- remove 'get_old_val' to directly call 'get_val' to get needed val.
  (suggested by Jan Beulich)
- move 'psr_check_cbm' into 'insert_val_to_array'.
  (suggested by Jan Beulich)
- change type of 'cbm' in 'psr_check_cbm' to 'unsigned long'.
  (suggested by Jan Beulich)
- remove 'set_new_val' as it can be handled in generic process.
- changes related to 'feat_props'.
  (suggested by Jan Beulich)
- adjust flow in 'gather_val_array' to avoid array cross.
  (suggested by Jan Beulich)
- adjust flow in 'insert_val_to_array' to avoid array cross.
  (suggested by Jan Beulich)
v9:
- add comments about boundary checking.
  (suggested by Wei Liu)
- rename 'assemble_val_array' to 'combine_val_array' in pervious patch.
  (suggested by Wei Liu)
- rename 'l3_cat_get_cos_num' to 'cat_get_cos_num' to cover all L3/L2 CAT
  features.
  (suggested by Roger Pau)
- rename 'l3_cat_get_old_val' to 'cat_get_old_val' to cover all L3/L2 CAT
  features and reuse cat_get_val in it.
  (suggested by Roger Pau)
- replace feature list handling to feature array handling.
  (suggested by Roger Pau)
- modify patch title to indicate 'L3 CAT'.
  (suggested by Jan Beulich)
- replace 'm' to 'new_val'.
  (suggested by Jan Beulich)
- move cos check outside callback function.
  (suggested by Jan Beulich)
- remove 'get_cos_num' callback function.
  (suggested by Jan Beulich)
- changes about 'uint64_t' to 'uint32_t'.
  (suggested by Jan Beulich)
v6:
- change 'assemble_val_array' to 'combine_val_array'.
  (suggested by Konrad Rzeszutek Wilk)
- check return value of 'get_old_val'.
  (suggested by Konrad Rzeszutek Wilk)
- replace some 'EINVAL' to 'ENOSPC'.
  (suggested by Konrad Rzeszutek Wilk)
v5:
- modify comments according to changes of codes.
  (suggested by Jan Beulich)
- change 'bool_t' to 'bool'.
  (suggested by Jan Beulich)
- modify return value of callback functions because we do not need them
  to return number of entries the feature uses. In caller, we call
  'get_cos_num' to get the number of entries the feature uses.
  (suggested by Jan Beulich)
- modify variables names to make them better, e.g. 'feat_tmp' to 'feat'.
  (suggested by Jan Beulich)
v4:
- create this patch to make codes easier to understand.
  (suggested by Jan Beulich)
---
 xen/arch/x86/psr.c | 135 -
 1 file changed, 133 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index f1b5837..2c04131 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -210,6 +210,29 @@ static enum psr_feat_type psr_cbm_type_to_feat_type(enum 
cbm_type type)
 return feat_type;
 }
 
+static bool psr_check_cbm(unsigned int cbm_len, unsigned long cbm)
+{
+unsigned int first_bit, zero_bit;
+
+/* Set bits should only in the range of [0, cbm_len]. */
+if ( cbm & (~0ul << cbm_len) )
+return false;
+
+/* At least one bit need to be set. */
+if ( cbm == 0 )
+return false;
+
+first_bit = find_first_bit(&cbm, cbm_len);
+zero_bit = find_next_zero_bit(&cbm, cbm_len, first_bit);
+
+/* Set bits should be c

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt
testid guest-saverestore.2

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  4ca6df134847a6349620b485a3e63f00fb3bfad8
  Bug not present: 63f700aab4c11d46626de3cd051dae56cf7e9056
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/111820/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-libvirt.guest-saverestore.2.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-libvirt.guest-saverestore.2
 --summary-out=tmp/111820.bisection-summary --basis-template=110515 
--blessings=real,real-bisect linux-linus test-amd64-i386-libvirt 
guest-saverestore.2
Searching for failure / basis pass:
 111771 fail [host=chardonnay1] / 111363 [host=huxelrebe0] 111332 
[host=merlot0] 111280 [host=nobling1] 111222 [host=rimava0] 83 
[host=elbling1] 48 [host=huxelrebe1] 24 [host=baroque1] 111081 
[host=italia0] 110984 [host=italia1] 110950 [host=baroque0] 110515 
[host=huxelrebe0] 110486 [host=fiano0] 110464 [host=rimava0] 110427 ok.
Failure / basis pass flights: 111771 / 110427
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fde654be5307a570b7b0f31537e18e70a274cd50 
ce4ee4cbb596a9d7de2786cf8c48cf62a4edede7 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
4ca6df134847a6349620b485a3e63f00fb3bfad8 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
89df98b77d28136c4d7aade13a1c8bc154d2919f
Basis pass 2feb2fe2512771763000930b68b689750c124454 
da830b5146cb553ac2a4bcfe76caeb57bda24cc3 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
63f700aab4c11d46626de3cd051dae56cf7e9056 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
aeef64107afca9c6c0428b2cb26a3ba599b3ed75
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#2feb2fe2512771763000930b68b689750c124454-fde654be5307a570b7b0f31537e18e70a274cd50
 
git://git.sv.gnu.org/gnulib.git#da830b5146cb553ac2a4bcfe76caeb57bda24cc3-ce4ee4cbb596a9d7de2786cf8c48cf62a4edede7
 
https://gitlab.com/keycodemap/keycodemapdb.git#7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0-7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0
 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#63f700aab4c11d46626de3cd051dae56cf7e9056-4ca6df134847a6349620b485a3e63f00fb3bfad8
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7-414d069b38ab114b89085e44989bf57604ea86d7
 
git://xenbits.xen.org/xen.git#aeef64107afca9c6c0428b2cb26a3ba599b3ed75-89df98b77d28136c4d7aade13a1c8bc154d2919f
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 4007 nodes in revision graph
Searching for test results:
 110399 [host=huxelrebe1]
 110427 pass 2feb2fe2512771763000930b68b689750c124454 
da830b5146cb553ac2a4bcfe76caeb57bda24cc3 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
63f700aab4c11d46626de3cd051dae56cf7e9056 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
aeef64107afca9c6c0428b2cb26a3ba599b3ed75
 110464 [host=rimava0]
 110486 [host=fiano0]
 110515 [host=huxelrebe0]
 110547 []
 110536 []
 110560 []
 110908 []
 110950 [host=baroque0]
 110984 [host=italia1]
 111081 [host=italia0]
 24 [host=baroque1]
 48 [host=huxelrebe1]
 111280 [host=nobling1]
 83

[Xen-devel] [linux-next test] 111799: regressions - FAIL

[osstest service owner]

flight 111799 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111799/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 111771
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 111771
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 111771
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
111771
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 111771

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 111771

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 16 guest-localmigrate fail blocked in 111771
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail  like 111771
 test-amd64-amd64-libvirt-pair 21 guest-start/debian   fail like 111771
 test-amd64-i386-pair 21 guest-start/debian   fail  like 111771
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail  like 111771
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail  like 111771
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail  like 111771
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail  like 111771
 test-amd64-amd64-xl-multivcpu 15 guest-saverestorefail like 111771
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail  like 111771
 test-amd64-i386-xl   16 guest-localmigrate   fail  like 111771
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail  like 111771
 test-amd64-amd64-xl  16 guest-localmigrate   fail  like 111771
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail  like 111771
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail  like 111771
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 111771
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 111771
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 111771
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 111771
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 111771
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111771
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-ar