[Xen-devel] [linux-mingo-tip-master test] 66316: regressions - FAIL

[osstest service owner]

flight 66316 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66316/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  5 kernel-build  fail REGR. vs. 60684
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a

version targeted for testing:
 linux2cb804c7cdee1298637e91efea9a8bd8d07b9b53
baseline version:
 linux

Re: [Xen-devel] [PATCH v4 --for 4.6 COLOPre 11/25] tools/libxc: support to resume uncooperative HVM guests

[Wen Congyang]

On 07/17/2015 12:27 AM, Ian Jackson wrote:
> Yang Hongyang writes ("Re: [Xen-devel] [PATCH v4 --for 4.6 COLOPre 11/25] 
> tools/libxc: support to resume uncooperative HVM guests"):
>> On 07/16/2015 11:40 PM, Ian Jackson wrote:
>>>what this patch is doing
>>>
>>>  That is, what the change in behaviour is.  This includes clearly
>>>  distinguishing old behaviour, before the patch, from new
>>>  behaviour, after the patch.  I appreciate that there may be
>>>  language problems which are making this more difficult - I think
>>>  your native language may not use tenses the way English does.  So
>>>  we can help you with the language, but we need the old and new
>>>  behaviours to be clearly marked in your message.
>>
>> I thought this is being addressed in the commit message, sorry again
>> for my poor English and not make it clear, I would appreciate your
>> help.
> 
> Right.  Thanks.  I hope we can work on this together.  I appreciate
> that working in a non-native language is difficult.
> 
> OK, at the moment I find the existing proposed commit message unclear
> about before-and-after.  I'm not sure I can write it correctly.  Can I
> make a suggestion ?  How about you send me a copy of it with
> the different parts explicitly marked BEFORE: and AFTER: ?
> 
>>>what the constraints on the new functionality will be.
>>>
>>>  It appears that you are supporting slow path resume for all HVM
>>>  guests.  Is that true ?  Are there any cases left unhandled ?
>>
>> For the first question, yes. For second, Sorry that I don't catch
>> your question, did you mean in some cases resuming HVM through slow
>> path will be unhandled?
> 
> What I mean is: I think that this patch has this overall effect:
> 
>BEFORE: HVM resume for slow path does not work
> 
>AFTER: HVM resume for slow path does work
> 
> But I have questions.  I don't know in what way it "does not work".
> What happens instead ?

Sorry for the late reply.
BEFORE: HVM resume for slow path does not work. You will get the following
error message:
"Cannot resume uncooperative HVM guests"

Fast resume: the guest status is not changed, so there is no need to disconnect 
and
reconnect the backend and frontend pv driver.

Slow path resume: the guest status is changed, so we must disconnect and 
reconnect
the backend and frontend pv driver. When we reconnect the backend and frontend, 
it
will take too many time, because xenstore is very slow. That is why it is a 
slow path.

In which case the slow path doesn't work? If the guest status is changed, but 
it is
also corrupted. I don't know what will happen in this case. I think resuming PV 
guest
in such state doesn't work(the behavior is undefined.)

> 
> And, another question: is it true that
> 
>AFTER: HVM resume for slow path does work in all cases
> 
> or
> 
>AFTER: HVM resume for slow path works in some cases (specify!)
>   but in other cases it (does something else - what?)
> 
> Does that make sense of my question ?

In my test, it works. I know I cannot say it does work in all cases.
How to know if it does work in all cases?
List all cases, and do a test for all cases.
But I think it is hard to list all cases...

How to resume domU if its state(memory, device state, cpu's register...) is 
changed?
Note that, the domU can be resumed.(All states are copied from another guest 
with the same
config).
Before this patch, we only support pv guest, and do the following thing:
1. rewrite store_mfn and console_mfn
2. reset all secondary CPU states
3. resume domain(do_domctl(xch, ...), cmd is XEN_DOMCTL_resumedomain)

Thanks
Wen Congyang

> 
> 
> Thanks,
> Ian.
> .
> 




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

[Xen-devel] [V9 1/3] Remove identical relationship between ioreq type and rangeset type.

[Shuai Ruan]

From: Yu Zhang 

This patch uses HVMOP_IO_RANGE_XXX values rather than the raw ioreq
type to select the ioreq server, therefore the identical relationship
between ioreq type and rangeset type is no longer necessary.

Signed-off-by: Yu Zhang 
Reviewed-by: Paul Durrant 
Signed-off-by: Shuai Ruan 
Acked-by: Jan Beulich 
---
 xen/arch/x86/hvm/hvm.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 92d57ff..2197e9b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2572,7 +2572,7 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
   PCI_SLOT(CF8_BDF(cf8)),
   PCI_FUNC(CF8_BDF(cf8)));
 
-type = IOREQ_TYPE_PCI_CONFIG;
+type = HVMOP_IO_RANGE_PCI;
 addr = ((uint64_t)sbdf << 32) |
CF8_ADDR_LO(cf8) |
(p->addr & 3);
@@ -2590,7 +2590,8 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
 }
 else
 {
-type = p->type;
+type = (p->type == IOREQ_TYPE_PIO) ?
+HVMOP_IO_RANGE_PORT : HVMOP_IO_RANGE_MEMORY;
 addr = p->addr;
 }
 
@@ -2606,31 +2607,28 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
 if ( !s->enabled )
 continue;
 
-BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
-BUILD_BUG_ON(IOREQ_TYPE_COPY != HVMOP_IO_RANGE_MEMORY);
-BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG != HVMOP_IO_RANGE_PCI);
 r = s->range[type];
 
 switch ( type )
 {
 unsigned long end;
 
-case IOREQ_TYPE_PIO:
+case HVMOP_IO_RANGE_PORT:
 end = addr + p->size - 1;
 if ( rangeset_contains_range(r, addr, end) )
 return s;
 
 break;
-case IOREQ_TYPE_COPY:
+case HVMOP_IO_RANGE_MEMORY:
 end = addr + (p->size * p->count) - 1;
 if ( rangeset_contains_range(r, addr, end) )
 return s;
 
 break;
-case IOREQ_TYPE_PCI_CONFIG:
+case HVMOP_IO_RANGE_PCI:
 if ( rangeset_contains_singleton(r, addr >> 32) )
 {
-p->type = type;
+p->type = IOREQ_TYPE_PCI_CONFIG;
 p->addr = addr;
 return s;
 }
-- 
1.9.1


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

[Xen-devel] [V9 2/3] Refactor rangeset structure for better performance.

[Shuai Ruan]

From: Yu Zhang 

This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.

Signed-off-by: Yu Zhang 
Reviewed-by: Paul Durrant 
Signed-off-by: Shuai Ruan 
---
 xen/common/rangeset.c | 82 +--
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..d15d8d5 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -10,11 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* An inclusive range [s,e] and pointer to next range in ascending order. */
 struct range {
-struct list_head list;
+struct rb_node node;
 unsigned long s, e;
 };
 
@@ -24,7 +25,7 @@ struct rangeset {
 struct domain   *domain;
 
 /* Ordered list of ranges contained in this set, and protecting lock. */
-struct list_head range_list;
+struct rb_root   range_tree;
 
 /* Number of ranges that can be allocated */
 long nr_ranges;
@@ -45,41 +46,78 @@ struct rangeset {
 static struct range *find_range(
 struct rangeset *r, unsigned long s)
 {
-struct range *x = NULL, *y;
+struct rb_node *node;
+struct range   *x;
+struct range   *prev = NULL;
 
-list_for_each_entry ( y, >range_list, list )
+node = r->range_tree.rb_node;
+while ( node != NULL )
 {
-if ( y->s > s )
-break;
-x = y;
+x = container_of(node, struct range, node);
+if ( (s >= x->s) && (s <= x->e) )
+return x;
+if ( s < x->s )
+node = node->rb_left;
+else
+{
+prev = x;
+node = node->rb_right;
+}
 }
 
-return x;
+return prev;
 }
 
 /* Return the lowest range in the set r, or NULL if r is empty. */
 static struct range *first_range(
 struct rangeset *r)
 {
-if ( list_empty(>range_list) )
-return NULL;
-return list_entry(r->range_list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_first(>range_tree);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
 }
 
 /* Return range following x in ascending order, or NULL if x is the highest. */
 static struct range *next_range(
 struct rangeset *r, struct range *x)
 {
-if ( x->list.next == >range_list )
-return NULL;
-return list_entry(x->list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_next(>node);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
 }
 
 /* Insert range y after range x in r. Insert as first range if x is NULL. */
 static void insert_range(
 struct rangeset *r, struct range *x, struct range *y)
 {
-list_add(>list, (x != NULL) ? >list : >range_list);
+struct rb_node **node;
+struct rb_node *parent = NULL;
+
+if ( x == NULL )
+node = >range_tree.rb_node;
+else
+{
+node = >node.rb_right;
+parent = >node;
+}
+
+while ( *node != NULL )
+{
+parent = *node;
+node = >rb_left;
+}
+
+/* Add new node and rebalance the red-black tree. */
+rb_link_node(>node, parent, node);
+rb_insert_color(>node, >range_tree);
 }
 
 /* Remove a range from its list and free it. */
@@ -88,7 +126,7 @@ static void destroy_range(
 {
 r->nr_ranges++;
 
-list_del(>list);
+rb_erase(>node, >range_tree);
 xfree(x);
 }
 
@@ -319,7 +357,7 @@ bool_t rangeset_contains_singleton(
 bool_t rangeset_is_empty(
 const struct rangeset *r)
 {
-return ((r == NULL) || list_empty(>range_list));
+return ((r == NULL) || RB_EMPTY_ROOT(>range_tree));
 }
 
 struct rangeset *rangeset_new(
@@ -332,7 +370,7 @@ struct rangeset *rangeset_new(
 return NULL;
 
 rwlock_init(>lock);
-INIT_LIST_HEAD(>range_list);
+r->range_tree = RB_ROOT;
 r->nr_ranges = -1;
 
 BUG_ON(flags & ~RANGESETF_prettyprint_hex);
@@ -410,7 +448,7 @@ void rangeset_domain_destroy(
 
 void rangeset_swap(struct rangeset *a, struct rangeset *b)
 {
-LIST_HEAD(tmp);
+struct rb_node *tmp;
 
 if ( a < b )
 {
@@ -423,9 +461,9 @@ void rangeset_swap(struct rangeset *a, struct rangeset *b)
 write_lock(>lock);
 }
 
-list_splice_init(>range_list, );
-list_splice_init(>range_list, >range_list);
-list_splice(, >range_list);
+tmp = a->range_tree.rb_node;
+   

[Xen-devel] [V9 3/3] Differentiate IO/mem resources tracked by ioreq server

[Shuai Ruan]

From: Yu Zhang 

Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each. This
patch uses a seperate rangeset for the guest ram pages.

Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.

Signed-off-by: Yu Zhang 
Acked-by: Wei Liu 
Acked-by: Ian Campbell 
Signed-off-by: Shuai Ruan 
---
 tools/libxc/include/xenctrl.h| 31 
 tools/libxc/xc_domain.c  | 61 
 xen/arch/x86/hvm/hvm.c   | 27 +++---
 xen/include/asm-x86/hvm/domain.h |  4 +--
 xen/include/public/hvm/hvm_op.h  |  1 +
 5 files changed, 118 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..1a08f69 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2023,6 +2023,37 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface 
*xch,
 int is_mmio,
 uint64_t start,
 uint64_t end);
+/**
+ * This function registers a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
+
+/**
+ * This function deregisters a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_unmap_wp_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
 
 /**
  * This function registers a PCI device for config space emulation.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 96506d5..41c5ae2 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1543,6 +1543,67 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface 
*xch, domid_t domid,
 return rc;
 }
 
+int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg->domid = domid;
+arg->id = id;
+arg->type = HVMOP_IO_RANGE_WP_MEM;
+arg->start = start;
+arg->end = end;
+
+rc = do_xen_hypercall(xch, );
+
+xc_hypercall_buffer_free(xch, arg);
+return rc;
+}
+
+int xc_hvm_unmap_wp_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_unmap_io_range_from_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg->domid = domid;
+

[Xen-devel] [V9 0/3] Refactor ioreq server for better performance.

[Shuai Ruan]

From: Yu Zhang 

XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the 
rangeset is searched to see if the I/O range is recorded. However,
traversing the link list inside rangeset could be time consuming
when number of ranges is too high. On HSW platform, number of PPGTTs
for each vGPU could be several hundred. On BDW, this value could
be several thousand.  This patch series refactored rangeset to base
it on red-back tree, so that the searching would be more efficient. 

Besides, this patchset also splits the tracking of MMIO and guest
ram ranges into different rangesets. And to accommodate more ranges,
limitation of the number of ranges in an ioreq server, MAX_NR_IO_RANGES
is changed - future patches might be provided to tune this with other
approaches.

Changes in v9: 
1> Change order of patch 2 and patch3.
2> Intruduce a const static array before hvm_ioreq_server_alloc_rangesets().
3> Coding style changes.

Changes in v8: 
Use a clearer API name to map/unmap the write-protected memory in
ioreq server.

Changes in v7: 
1> Coding style changes;
2> Fix a typo in hvm_select_ioreq_server().

Changes in v6: 
Break the identical relationship between ioreq type and rangeset
index inside ioreq server.

Changes in v5:
1> Use gpfn, instead of gpa to track guest write-protected pages;
2> Remove redundant conditional statement in routine find_range().

Changes in v4:
Keep the name HVMOP_IO_RANGE_MEMORY for MMIO resources, and add
a new one, HVMOP_IO_RANGE_WP_MEM, for write-protected memory.

Changes in v3:
1> Use a seperate rangeset for guest ram pages in ioreq server;
2> Refactor rangeset, instead of introduce a new data structure.

Changes in v2:
1> Split the original patch into 2;
2> Take Paul Durrant's comments:
  a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
  b> Keep original routine names for hvm ioreq server;
  c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.


Yu Zhang (3):
  Remove identical relationship between ioreq type and rangeset type.
  Refactor rangeset structure for better performance.
  Differentiate IO/mem resources tracked by ioreq server

 tools/libxc/include/xenctrl.h| 31 +++
 tools/libxc/xc_domain.c  | 61 ++
 xen/arch/x86/hvm/hvm.c   | 43 ++---
 xen/common/rangeset.c| 82 +---
 xen/include/asm-x86/hvm/domain.h |  4 +-
 xen/include/public/hvm/hvm_op.h  |  1 +
 6 files changed, 185 insertions(+), 37 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[Chun Yan Liu]

>>> On 12/14/2015 at 07:37 PM, in message
, George
Dunlap  wrote: 
> On Mon, Dec 14, 2015 at 7:25 AM, Chun Yan Liu  wrote: 
> > 
> > 
>  On 12/10/2015 at 08:08 PM, in message <56696b4b.7060...@citrix.com>, 
>  George 
> > Dunlap  wrote: 
> >> On 10/12/15 12:05, George Dunlap wrote: 
> >> > From: Chunyan Liu  
> >> > 
> >> > Add pvusb APIs, including: 
> >> >  - attach/detach (create/destroy) virtual usb controller. 
> >> >  - attach/detach usb device 
> >> >  - list usb controller and usb devices 
> >> >  - some other helper functions 
> >> > 
> >> > Signed-off-by: Chunyan Liu  
> >> > Signed-off-by: Simon Cao  
> >> > Signed-off-by: George Dunlap  
> >> 
> >> Attached is a diff of v9 -> v10 for convenience. 
> > 
> > Thanks very much, George! 
> > I've applied your new patch and tested, there are a couple of changes  
> needed to 
> > get tests PASSED. A small extra patch is written on top of your new patch,  
> as in 
> > attachment, please have a look. 
>  
> Thanks -- the changes in the patch look good. 
>  
> >> > +static int usbdev_get_all_interfaces(libxl__gc *gc, const char *busid, 
> >> > + char ***intfs, int *num) 
> >> > +{ 
> >> > +DIR *dir; 
> >> > +char *buf; 
> >> > +int rc; 
> >> > + 
> >> > +*intfs = NULL; 
> >> > +*num = 0; 
> >> > + 
> >> > +buf = GCSPRINTF("%s:", busid); 
> >> > + 
> >> > +dir = opendir(SYSFS_USB_DEV); 
> >> > +if (!dir) { 
> >> > +LOGE(ERROR, "opendir failed: '%s'", SYSFS_USB_DEV); 
> >> > +return ERROR_FAIL; 
> >> > +} 
> >> > + 
> >> > +size_t need = offsetof(struct dirent, d_name) + 
> >> > +pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1; 
> >> > +struct dirent *de_buf = libxl__zalloc(gc, need); 
> >> 
> >> Is this thing with manually calculating the size of the structure really 
> >> necessary?  Could we not just declare "struct dirent de_buf" on the stack? 
> > 
> > Calculating in above way is to allocate enough space for d_name, whereas 
> > "struct dirent de_buf" won't allocate space for d_name (which is char *). 
> > 
> > Codes for calling read_dir_r are often done like above. 
>  
> OK -- in that case, can you put the allocation of the structure into a 
> macro or helper function, fold in the patch you sent, and re-send this 
> series as v11? 

OK. Will update soon!

- Chunyan

>  
> Thanks! 
>  
>  -George 
>  
>  



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

Re: [Xen-devel] [linux-3.10 test] 65697: regressions - FAIL

[Ian Campbell]

On Sat, 2015-12-12 at 11:50 +, osstest service owner wrote:
> flight 65697 linux-3.10 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65697/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs.
> 64456

Expected regression, force pushed.
> 
> version targeted for testing:
>  linux03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
> baseline version:
>  linuxbdf8cfb859e9cd265ec1696d9e007fac66e7aea7

(test-lab)osstest@osstest:~/branches/for-linux-3.10.git$ 
OSSTEST_CONFIG=production-config ./ap-push linux-3.10 
03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
+ branch=linux-3.10
+ revision=03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
+ . ./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 linux-3.10 
03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
+ branch=linux-3.10
+ revision=03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
+ . ./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=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.10
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x03ed106ff4c200d01f3c72f71fa9c5b18da07d9b = 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://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 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-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.10
++ : daily-cron.linux-3.10
++ : daily-cron.linux-3.10
++ : daily-cron.linux-3.10
++ : daily-cron.linux-3.10
++ : 

Re: [Xen-devel] [linux-3.14 test] 65709: regressions - FAIL

[Ian Campbell]

On Sat, 2015-12-12 at 17:37 +, osstest service owner wrote:
> flight 65709 linux-3.14 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65709/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs.
> 64562

Expected regression, force pushed.

> version targeted for testing:
>  linux5d7b0fcc26d66db767a477574effc764022c19ac
> baseline version:
>  linux769b79eb206ad5b0249a08665fefb913c3d1998e

(test-lab)osstest@osstest:~/branches/for-linux-3.14.git$ 
OSSTEST_CONFIG=production-config ./ap-push linux-3.14 
5d7b0fcc26d66db767a477574effc764022c19ac
+ branch=linux-3.14
+ revision=5d7b0fcc26d66db767a477574effc764022c19ac
+ . ./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 linux-3.14 
5d7b0fcc26d66db767a477574effc764022c19ac
+ branch=linux-3.14
+ revision=5d7b0fcc26d66db767a477574effc764022c19ac
+ . ./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=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-3.14
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x5d7b0fcc26d66db767a477574effc764022c19ac = 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://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 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-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : daily-cron.linux-3.14
++ : 

Re: [Xen-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability

[Stefano Stabellini]

On Fri, 11 Dec 2015, Ian Campbell wrote:
> On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> >  
> > It is not possible to do this at runtime. I think we should do this at
> > compile time because in any case it is not supported to run a QEMU built
> > for a given Xen version on a different Xen version.
>
> I am currently working pretty hard to make this possible in the future, it
> would be a shame to add another reason it wasn't possible at this stage.
>
> I proposed (in <1445442435.9563.184.ca...@citrix.com>) that as well as the
> various stable libraries extracted from libxenctrl we will probably also
> want to have a libxendevicemodel.so at some point, to provide a stable way
> to interface with all the stuff which being a DM involves.

I understand the direction we are heading toward, but unfortunately we
are still pretty far from it. I don't think we want to block this patch
until we have a stable libxendevicemodel ABI? Also this particular
change regards PCI passthrough, which is not convered by the proposed
ABI yet.


> Maybe that library could contain a way to get this information? (In which
> case it could be hardcoded at compile time now and I'll see what I can do
> when I get to producing the library).

Given the choice, I would rather have only compile time or only run time
Xen version checks in QEMU and not both to avoid complexity. Especially
as long as the underlying libraries don't make any stability guarantees.


> For the original issue here, could the flag be exposed as a
> XEN_SYSCTL_PHYSCAP_

Feature flags are welcome and the best course of action in my opinion.___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.

[Ian Campbell]

On Fri, 2015-12-11 at 17:35 +, Ian Campbell wrote:
> On Fri, 2015-12-11 at 17:19 +, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32]
> > tools/libs/gnttab: Extensive updates to API documentation."):
> > > I'm currently intending to write something very similar for each of
> > > the
> > > xen*_open (gntshr, gnttab, foreignmemory, evtchn and probably call
> > > too)
> > > functions. I don't really like repeating the same thing like this,
> > > but
> > > I
> > > also don't really like API documentation which makes you play follow
> > > the
> > > piece of string to the docs of other libraries to find out what is
> > > going
> > > on.
> > 
> > That would be fine by me.  But do these other functions suffer from
> > the same problem ?
> > 
> > Ie, can we for gntshr et al, tell the user that they should call
> > blah_unmap ?  This is not practical in a multithreaded program for
> > hypercall memory but it might well be practical for other kinds of
> > borrowed memory.
> 
> Good point, I think most of the rest of them probably can support unmap
> after fork, but I've not checked (I will before I write anything).

Good thing I did.

On Linux both the gnttab and privcmd foreign mappings set VMA_DONTCOPY on
the mappings from the driver, which is the same effect as the
madvise(DONTFORK) in the hypercall buffer allocation has.

For gnttab this is obvious now I think about it, since you cannot unmap or
otherwise operate on a gntmap with normal PTE updates, you have to use
gntmap hypercalls, which core OS code like CoW handling obviously won't.

The same could be true for privcmd foreign mappings for PV guests, I think,
since the PTE update hypercall needs the foreign domid in it, which common
code wouldn't have.

So those memory regions simply won't exist in the child, and munmap would
therefore either fail or unmap whatever new thing has shown up at an
address.

So I think at least call, foreignmemory and gnttab need a
restriction/caveat like the above, which is that on fork but not exec you
can call close() and hope it does something, but unmap is off the table.

gntshr might be ok, although TBH I'm not really sure what the effect of
cow-wing memory which has been granted, nor how one ensures the desired
child/parent ends up with the actually granted memory and not a copy (IOW
it's not clear why VMA_DONTCOPY isn't applied here too). On that basis I'd
be inclined to give gntshr the same semantics as the others.

evtchn doesn't actually involve any memory mappings, and in that case
closing the fd is always fine and sufficient AFAICT, no need to disable
individual irqs first. I'm not entirely sure what the semantics of a poll
or read from both parent and child would be. I'm slightly inclined to
outlaw use in the child at the library API level. A slightly less draconian
rule would be one or the other may continue to use it, but never both.

That's all based on the Linux implementation, but the libraries need to be
LCD and so far that's pretty low... I looked at the FreeBSD privcmd, and it
didn't seem to have any obvious equivalent to VMA_DONTCOPY, but I might be
missing something (and it doesn't really matter for the library API given
Linux).

Ian.

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

[Xen-devel] [PATCH v2 10/10] igd: handle igd-passthrough-isa-bridge setup in realize()

[Gerd Hoffmann]

That way a simple '-device igd-passthrough-isa-bridge,addr=1f' will
do the setup.

Also instead of looking up reasonable PCI IDs based on the graphic
device id simply copy over the ids from the host, thereby reusing the
infrastructure we have in place for the igd host bridges.  Less code,
and should be more robust as we don't have to maintain the id table
to keep things going.

Note that igd-passthrough-isa-bridge will be needed for '-machine pc'
only.  For q35 the plan is https://lkml.org/lkml/2015/11/26/183 (should
land in the next merge window, i.e. linux 4.5).

TODO: Figure if and how we are going to add this to the virtual machine
automatically.  The options I see are:

  (1) Nothing automatic, users must add the device manually.  This is
  what you get with this patch, except when running on xen.
  (2) Do it the xen way, let the pci pass-thru code add it when it
  finds a igd device (i.e. vfio-pci for kvm).  It's a bit ugly
  though, and it also has the problem that pc and q35 machine
  types have different needs here.
  (3) Let machine init do it in case igd-passthru=on is set.

Signed-off-by: Gerd Hoffmann 
---
 hw/pci-host/igd.c | 115 +-
 1 file changed, 28 insertions(+), 87 deletions(-)

diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
index 96b679d..2887b31 100644
--- a/hw/pci-host/igd.c
+++ b/hw/pci-host/igd.c
@@ -123,111 +123,52 @@ static const TypeInfo igd_passthrough_q35_info = {
 .class_init= igd_passthrough_q35_class_init,
 };
 
-typedef struct {
-uint16_t gpu_device_id;
-uint16_t pch_device_id;
-uint8_t pch_revision_id;
-} IGDDeviceIDInfo;
-
-/* In real world different GPU should have different PCH. But actually
- * the different PCH DIDs likely map to different PCH SKUs. We do the
- * same thing for the GPU. For PCH, the different SKUs are going to be
- * all the same silicon design and implementation, just different
- * features turn on and off with fuses. The SW interfaces should be
- * consistent across all SKUs in a given family (eg LPT). But just same
- * features may not be supported.
- *
- * Most of these different PCH features probably don't matter to the
- * Gfx driver, but obviously any difference in display port connections
- * will so it should be fine with any PCH in case of passthrough.
- *
- * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
- * scenarios, 0x9cc3 for BDW(Broadwell).
- */
-static const IGDDeviceIDInfo igd_combo_id_infos[] = {
-/* HSW Classic */
-{0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
-{0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
-{0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
-{0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
-{0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
-/* HSW ULT */
-{0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
-{0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
-{0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
-{0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
-{0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
-{0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
-/* HSW CRW */
-{0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
-{0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
-/* HSW Server */
-{0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
-/* HSW SRVR */
-{0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
-/* BSW */
-{0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
-{0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
-{0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
-{0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
-{0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
-{0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
-{0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
-{0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
-{0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
-{0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
-{0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
+static const IGDHostInfo igd_isa_bridge_infos[] = {
+{PCI_VENDOR_ID,   2},
+{PCI_DEVICE_ID,   2},
+{PCI_REVISION_ID, 2},
+{PCI_SUBSYSTEM_VENDOR_ID, 2},
+{PCI_SUBSYSTEM_ID,2},
 };
 
+static void igd_pt_isa_bridge_realize(PCIDevice *pci_dev, Error **errp)
+{
+Error *err = NULL;
+
+if (pci_dev->devfn != PCI_DEVFN(0x1f, 0)) {
+error_setg(errp, "igd isa bridge must have address 1f.0");
+return;
+}
+
+host_pci_config_copy(pci_dev, ":00:1f.0",
+ igd_isa_bridge_infos,
+ ARRAY_SIZE(igd_isa_bridge_infos),
+ );
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+}
+
 static void isa_bridge_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
-dc->desc  

[Xen-devel] [PATCH v2 07/10] igd: revamp host config read

[Gerd Hoffmann]

Move all work to the host_pci_config_copy helper function,
which we can easily reuse when adding q35 support.
Open sysfs file only once for all values.  Use pread.
Proper error handling.  Fix bugs:

 * Don't throw away results (like old host_pci_config_read
   did because val was passed by value not reference).
 * Update config space directly (writing via
   pci_default_write_config only works for registers
   whitelisted in wmask).

Hmm, this code can hardly ever worked before,
/me wonders what test coverage it had.

With this patch in place igd-passthru=on actually
works, although it still requires root priviledges
because linux refuses to allow non-root users access
pci config space above offset 0x50.

Signed-off-by: Gerd Hoffmann 
---
 hw/pci-host/igd.c | 65 +++
 1 file changed, 27 insertions(+), 38 deletions(-)

diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
index 0784128..ec48875 100644
--- a/hw/pci-host/igd.c
+++ b/hw/pci-host/igd.c
@@ -19,47 +19,39 @@ static const IGDHostInfo igd_host_bridge_infos[] = {
 {0xa8, 4},  /* SNB: base of GTT stolen memory */
 };
 
-static int host_pci_config_read(int pos, int len, uint32_t val)
+static void host_pci_config_copy(PCIDevice *guest, const char *host,
+ const IGDHostInfo *list, int len, Error 
**errp)
 {
-char path[PATH_MAX];
-int config_fd;
-ssize_t size = sizeof(path);
-/* Access real host bridge. */
-int rc = snprintf(path, size, "/sys/bus/pci/devices/%04x:%02x:%02x.%d/%s",
-  0, 0, 0, 0, "config");
-int ret = 0;
+char *path;
+int config_fd, rc, i;
 
-if (rc >= size || rc < 0) {
-return -ENODEV;
-}
-
-config_fd = open(path, O_RDWR);
+path = g_strdup_printf("/sys/bus/pci/devices/%s/config", host);
+config_fd = open(path, O_RDONLY);
 if (config_fd < 0) {
-return -ENODEV;
+error_setg_file_open(errp, errno, path);
+goto out_free;
 }
 
-if (lseek(config_fd, pos, SEEK_SET) != pos) {
-ret = -errno;
-goto out;
+for (i = 0; i < len; i++) {
+rc = pread(config_fd, guest->config + list[i].offset,
+   list[i].len, list[i].offset);
+if (rc != list[i].len) {
+error_setg_errno(errp, errno, "read %s, offset 0x%x",
+ path, list[i].offset);
+goto out_close;
+}
 }
-do {
-rc = read(config_fd, (uint8_t *), len);
-} while (rc < 0 && (errno == EINTR || errno == EAGAIN));
-if (rc != len) {
-ret = -errno;
-}
-out:
+
+out_close:
 close(config_fd);
-return ret;
+out_free:
+g_free(path);
 }
 
 static void (*i440fx_realize)(PCIDevice *pci_dev, Error **errp);
 static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error **errp)
 {
 Error *err = NULL;
-uint32_t val = 0;
-int rc, i, num;
-int pos, len;
 
 i440fx_realize(pci_dev, );
 if (err != NULL) {
@@ -67,16 +59,13 @@ static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error 
**errp)
 return;
 }
 
-num = ARRAY_SIZE(igd_host_bridge_infos);
-for (i = 0; i < num; i++) {
-pos = igd_host_bridge_infos[i].offset;
-len = igd_host_bridge_infos[i].len;
-rc = host_pci_config_read(pos, len, val);
-if (rc) {
-error_setg(errp, "failed to read host config");
-return;
-}
-pci_default_write_config(pci_dev, pos, val, len);
+host_pci_config_copy(pci_dev, ":00:00.0",
+ igd_host_bridge_infos,
+ ARRAY_SIZE(igd_host_bridge_infos),
+ );
+if (err != NULL) {
+error_propagate(errp, err);
+return;
 }
 }
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 09/10] igd: move igd-passthrough-isa-bridge to igd.c too

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/i386/pc_piix.c | 113 --
 hw/pci-host/igd.c | 108 +++
 2 files changed, 108 insertions(+), 113 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ce6c3c5..656bc39 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -921,119 +921,6 @@ static void pc_i440fx_0_10_machine_options(MachineClass 
*m)
 DEFINE_I440FX_MACHINE(v0_10, "pc-0.10", pc_compat_0_13,
   pc_i440fx_0_10_machine_options);
 
-typedef struct {
-uint16_t gpu_device_id;
-uint16_t pch_device_id;
-uint8_t pch_revision_id;
-} IGDDeviceIDInfo;
-
-/* In real world different GPU should have different PCH. But actually
- * the different PCH DIDs likely map to different PCH SKUs. We do the
- * same thing for the GPU. For PCH, the different SKUs are going to be
- * all the same silicon design and implementation, just different
- * features turn on and off with fuses. The SW interfaces should be
- * consistent across all SKUs in a given family (eg LPT). But just same
- * features may not be supported.
- *
- * Most of these different PCH features probably don't matter to the
- * Gfx driver, but obviously any difference in display port connections
- * will so it should be fine with any PCH in case of passthrough.
- *
- * So currently use one PCH version, 0x8c4e, to cover all HSW(Haswell)
- * scenarios, 0x9cc3 for BDW(Broadwell).
- */
-static const IGDDeviceIDInfo igd_combo_id_infos[] = {
-/* HSW Classic */
-{0x0402, 0x8c4e, 0x04}, /* HSWGT1D, HSWD_w7 */
-{0x0406, 0x8c4e, 0x04}, /* HSWGT1M, HSWM_w7 */
-{0x0412, 0x8c4e, 0x04}, /* HSWGT2D, HSWD_w7 */
-{0x0416, 0x8c4e, 0x04}, /* HSWGT2M, HSWM_w7 */
-{0x041E, 0x8c4e, 0x04}, /* HSWGT15D, HSWD_w7 */
-/* HSW ULT */
-{0x0A06, 0x8c4e, 0x04}, /* HSWGT1UT, HSWM_w7 */
-{0x0A16, 0x8c4e, 0x04}, /* HSWGT2UT, HSWM_w7 */
-{0x0A26, 0x8c4e, 0x06}, /* HSWGT3UT, HSWM_w7 */
-{0x0A2E, 0x8c4e, 0x04}, /* HSWGT3UT28W, HSWM_w7 */
-{0x0A1E, 0x8c4e, 0x04}, /* HSWGT2UX, HSWM_w7 */
-{0x0A0E, 0x8c4e, 0x04}, /* HSWGT1ULX, HSWM_w7 */
-/* HSW CRW */
-{0x0D26, 0x8c4e, 0x04}, /* HSWGT3CW, HSWM_w7 */
-{0x0D22, 0x8c4e, 0x04}, /* HSWGT3CWDT, HSWD_w7 */
-/* HSW Server */
-{0x041A, 0x8c4e, 0x04}, /* HSWSVGT2, HSWD_w7 */
-/* HSW SRVR */
-{0x040A, 0x8c4e, 0x04}, /* HSWSVGT1, HSWD_w7 */
-/* BSW */
-{0x1606, 0x9cc3, 0x03}, /* BDWULTGT1, BDWM_w7 */
-{0x1616, 0x9cc3, 0x03}, /* BDWULTGT2, BDWM_w7 */
-{0x1626, 0x9cc3, 0x03}, /* BDWULTGT3, BDWM_w7 */
-{0x160E, 0x9cc3, 0x03}, /* BDWULXGT1, BDWM_w7 */
-{0x161E, 0x9cc3, 0x03}, /* BDWULXGT2, BDWM_w7 */
-{0x1602, 0x9cc3, 0x03}, /* BDWHALOGT1, BDWM_w7 */
-{0x1612, 0x9cc3, 0x03}, /* BDWHALOGT2, BDWM_w7 */
-{0x1622, 0x9cc3, 0x03}, /* BDWHALOGT3, BDWM_w7 */
-{0x162B, 0x9cc3, 0x03}, /* BDWHALO28W, BDWM_w7 */
-{0x162A, 0x9cc3, 0x03}, /* BDWGT3WRKS, BDWM_w7 */
-{0x162D, 0x9cc3, 0x03}, /* BDWGT3SRVR, BDWM_w7 */
-};
-
-static void isa_bridge_class_init(ObjectClass *klass, void *data)
-{
-DeviceClass *dc = DEVICE_CLASS(klass);
-PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
-
-dc->desc= "ISA bridge faked to support IGD PT";
-k->vendor_id= PCI_VENDOR_ID_INTEL;
-k->class_id = PCI_CLASS_BRIDGE_ISA;
-};
-
-static TypeInfo isa_bridge_info = {
-.name  = "igd-passthrough-isa-bridge",
-.parent= TYPE_PCI_DEVICE,
-.instance_size = sizeof(PCIDevice),
-.class_init = isa_bridge_class_init,
-};
-
-static void pt_graphics_register_types(void)
-{
-type_register_static(_bridge_info);
-}
-type_init(pt_graphics_register_types)
-
-void igd_passthrough_isa_bridge_create(PCIBus *bus, uint16_t gpu_dev_id)
-{
-struct PCIDevice *bridge_dev;
-int i, num;
-uint16_t pch_dev_id = 0x;
-uint8_t pch_rev_id;
-
-num = ARRAY_SIZE(igd_combo_id_infos);
-for (i = 0; i < num; i++) {
-if (gpu_dev_id == igd_combo_id_infos[i].gpu_device_id) {
-pch_dev_id = igd_combo_id_infos[i].pch_device_id;
-pch_rev_id = igd_combo_id_infos[i].pch_revision_id;
-}
-}
-
-if (pch_dev_id == 0x) {
-return;
-}
-
-/* Currently IGD drivers always need to access PCH by 1f.0. */
-bridge_dev = pci_create_simple(bus, PCI_DEVFN(0x1f, 0),
-   "igd-passthrough-isa-bridge");
-
-/*
- * Note that vendor id is always PCI_VENDOR_ID_INTEL.
- */
-if (!bridge_dev) {
-fprintf(stderr, "set igd-passthrough-isa-bridge failed!\n");
-return;
-}
-pci_config_set_device_id(bridge_dev->config, pch_dev_id);
-pci_config_set_revision(bridge_dev->config, pch_rev_id);
-}
-
 static void isapc_machine_options(MachineClass *m)
 {
 m->desc = "ISA-only PC";
diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
index f6e3f7a..96b679d 100644
--- 

[Xen-devel] [PATCH v2 02/10] pc: remove has_igd_gfx_passthru global

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/xen/xen_pt.h |  3 +--
 vl.c| 10 --
 2 files changed, 1 insertion(+), 12 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index c545280..6d8702b 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -320,10 +320,9 @@ extern void *pci_assign_dev_load_option_rom(PCIDevice *dev,
 unsigned int domain,
 unsigned int bus, unsigned int 
slot,
 unsigned int function);
-extern bool has_igd_gfx_passthru;
 static inline bool is_igd_vga_passthrough(XenHostPCIDevice *dev)
 {
-return (has_igd_gfx_passthru
+return (qdev_get_machine->igd_gfx_passthru
 && ((dev->class_code >> 0x8) == PCI_CLASS_DISPLAY_VGA));
 }
 int xen_pt_register_vga_regions(XenHostPCIDevice *dev);
diff --git a/vl.c b/vl.c
index 4211ff1..e45a1da 100644
--- a/vl.c
+++ b/vl.c
@@ -1365,13 +1365,6 @@ static inline void semihosting_arg_fallback(const char 
*file, const char *cmd)
 }
 }
 
-/* Now we still need this for compatibility with XEN. */
-bool has_igd_gfx_passthru;
-static void igd_gfx_passthru(void)
-{
-has_igd_gfx_passthru = current_machine->igd_gfx_passthru;
-}
-
 /***/
 /* USB devices */
 
@@ -4550,9 +4543,6 @@ int main(int argc, char **argv, char **envp)
 exit(1);
 }
 
-/* Check if IGD GFX passthrough. */
-igd_gfx_passthru();
-
 /* init generic devices */
 if (qemu_opts_foreach(qemu_find_opts("device"),
   device_init_func, NULL, NULL)) {
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 05/10] igd: TYPE_IGD_PASSTHROUGH_I440FX_PCI_DEVICE: call parent realize

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 hw/pci-host/igd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/pci-host/igd.c b/hw/pci-host/igd.c
index d1eeafb..6f52ab1 100644
--- a/hw/pci-host/igd.c
+++ b/hw/pci-host/igd.c
@@ -53,12 +53,20 @@ out:
 return ret;
 }
 
+static void (*i440fx_realize)(PCIDevice *pci_dev, Error **errp);
 static void igd_pt_i440fx_realize(PCIDevice *pci_dev, Error **errp)
 {
+Error *err = NULL;
 uint32_t val = 0;
 int rc, i, num;
 int pos, len;
 
+i440fx_realize(pci_dev, );
+if (err != NULL) {
+error_propagate(errp, err);
+return;
+}
+
 num = ARRAY_SIZE(igd_host_bridge_infos);
 for (i = 0; i < num; i++) {
 pos = igd_host_bridge_infos[i].offset;
@@ -77,6 +85,7 @@ static void igd_passthrough_i440fx_class_init(ObjectClass 
*klass, void *data)
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
 
+i440fx_realize = k->realize;
 k->realize = igd_pt_i440fx_realize;
 dc->desc = "IGD Passthrough Host bridge";
 }
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: Extensive updates to API documentation.

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH XEN v6 25/32] tools/libs/gnttab: 
Extensive updates to API documentation."):
> So I think at least call, foreignmemory and gnttab need a
> restriction/caveat like the above, which is that on fork but not exec you
> can call close() and hope it does something, but unmap is off the table.

Hrm, right.

(This all seems rather unsatisfactory but I guess it's where we are.
ISTM that part of what's needed is a version of MADV_DONTFORK which
causes children to get a mapping of nothing, with PROT_NONE, for the
relevant ranges.  Then you could safely munmap.)

Ian.

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

Re: [Xen-devel] [linux-4.1 test] 65781: regressions - FAIL

[Ian Campbell]

On Sun, 2015-12-13 at 22:34 +, osstest service owner wrote:
> flight 65781 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65781/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 
> 63996

An expected regression. Force pushed.

> 
version targeted for testing:
>  linuxcb371265c2f1a0dd0cee03bd7fff413d671c53f0
> baseline version:
>  linux1f2ce4a2e7aea3a2123b17aff62a80553df31e21
> 

(test-lab)osstest@osstest:~/branches/for-linux-4.1.git$ 
OSSTEST_CONFIG=production-config ./ap-push linux-4.1 
cb371265c2f1a0dd0cee03bd7fff413d671c53f0
+ branch=linux-4.1
+ revision=cb371265c2f1a0dd0cee03bd7fff413d671c53f0
+ . ./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 linux-4.1 
cb371265c2f1a0dd0cee03bd7fff413d671c53f0
+ branch=linux-4.1
+ revision=cb371265c2f1a0dd0cee03bd7fff413d671c53f0
+ . ./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=linux
+ xenbranch=xen-unstable
+ '[' xlinux = xlinux ']'
+ linuxbranch=linux-4.1
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' xcb371265c2f1a0dd0cee03bd7fff413d671c53f0 = 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://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 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-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.linux-4.1
++ : daily-cron.linux-4.1
++ : daily-cron.linux-4.1
++ : daily-cron.linux-4.1
++ : daily-cron.linux-4.1
++ : 

Re: [Xen-devel] [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Daniel P. Berrange]

On Thu, Dec 10, 2015 at 11:38:36AM +, Ian Campbell wrote:
> Upstream Xen is in the process of splitting the (stable API) xtl_*
> interfaces out from the (unstable API) libxenctrl library and into a
> new (stable API) libxentoollog.
> 
> In order to be compatible with Xen both before and after this
> transition check for xtl_createlogger_stdiostream in a libxentoollog
> library and use it if present. If it is not present assume it is in
> libxenctrl.

Ok, so there's no API changes, just move stuf from one to the other.

> It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
> of the box? Not sure what the libvirt stable backport policy is but it
> might also be good to eventually consider it for that?

We've missed 1.3.0 release, but I'd be ok with adding it to the
stable branch if that's going to be useful.

> diff --git a/configure.ac b/configure.ac
> index 98cf210..b641cc7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -883,7 +883,6 @@ if test "$with_libxl" != "no" ; then
>  PKG_CHECK_MODULES([LIBXL], [xenlight], [
>   LIBXL_FIRMWARE_DIR=`$PKG_CONFIG --variable xenfirmwaredir xenlight`
>   LIBXL_EXECBIN_DIR=`$PKG_CONFIG --variable libexec_bin xenlight`
> - LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
>   with_libxl=yes
>  ], [LIBXL_FOUND=no])
>  if test "$LIBXL_FOUND" = "no"; then
> @@ -896,7 +895,7 @@ if test "$with_libxl" != "no" ; then
>  LIBS="$LIBS $LIBXL_LIBS"
>  AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [
>  with_libxl=yes
> -LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl"
> +LIBXL_LIBS="$LIBXL_LIBS -lxenlight"
>  ],[
>  if test "$with_libxl" = "yes"; then
>  fail=1
> @@ -924,6 +923,14 @@ if test "$with_libxl" = "yes"; then
>  if test "x$LIBXL_EXECBIN_DIR" != "x"; then
>  AC_DEFINE_UNQUOTED([LIBXL_EXECBIN_DIR], ["$LIBXL_EXECBIN_DIR"], 
> [directory containing Xen libexec binaries])
>  fi
> +dnl Check if the xtl_* infrastructure is in libxentoollog
> +dnl (since Xen 4.7) if not then assume it is in libxenctrl
> +dnl (as it was for 4.6 and earler)
> +AC_CHECK_LIB([xentoollog], [xtl_createlogger_stdiostream], [
> +LIBXL_LIBS="$LIBXL_LIBS -lxentoollog"
> +],[
> +LIBXL_LIBS="$LIBXL_LIBS -lxenctrl"
> +])
>  fi
>  AM_CONDITIONAL([WITH_LIBXL], [test "$with_libxl" = "yes"])

Looks, fine from me but will let Jim push it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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

Re: [Xen-devel] [linux-3.14 test] 65633: regressions - FAIL

[Ian Jackson]

Robert Hu writes ("Re: [Xen-devel] [linux-3.14 test] 65633: regressions - 
FAIL"):
> On Mon, 2015-12-14 at 09:38 +, Ian Campbell wrote:
> > We test all kernel.org long term kernels in independent branches (from the
> > "linux stable tree" as you call it). This report is for the branch which is
> > testing linux-3.14.y.
> 
> OK. I thought this linux-3.14.y was from osstest/linux-pvops tree.
> I previously used linux-stable tree's master branch for test
> development.

The osstest/linux-pvops tree contains branches which track the
corresponding upstream branches; they are updated from upstream when
the tests pass (strictly, when there are no regressions).

So our 3.14.y is just a perhaps-slightly-out-of-date version of
upstream 3.14.y.

Ian.

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

Re: [Xen-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability

[Stefano Stabellini]

On Mon, 14 Dec 2015, Jan Beulich wrote:
> >>> On 11.12.15 at 17:56,  wrote:
> > On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> >>  
> >> It is not possible to do this at runtime. I think we should do this at
> >> compile time because in any case it is not supported to run a QEMU built
> >> for a given Xen version on a different Xen version.
> > 
> > I am currently working pretty hard to make this possible in the future, it
> > would be a shame to add another reason it wasn't possible at this stage.
> 
> And I don't think it's not possible - if anything, the infrastructure to
> do so is just missing. I'm definitely not going to make this a build time
> check, since I deem it very wrong namely when considering
> --with-system-qemu (as in that case there shouldn't be any
> dependency on the precise Xen tools versions in use - using plural
> intentionally here to point out the possibility of multiple ones being
> present).

Compile time checks are indeed suboptimal, but so are runtime checks:
what if we backport the fix to more Xen releases? What if we revert the
fix on the Xen tree for any reason?

I think that a feature flag is the best course of action.

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

Re: [Xen-devel] [libvirt] [PATCH v2 5/7] virNetDevMacVLanTapSetup: Allow enabling of IFF_MULTI_QUEUE

[Michal Privoznik]

On 14.12.2015 11:23, Ian Campbell wrote:
> Hello,
> 
> On Thu, 2015-12-10 at 08:38 +0100, Michal Privoznik wrote:
>> Like we are doing for TUN/TAP devices, we should do the same for
>> macvtaps. Although, it's not as critical as in that case, we
>> should do it for the consistency.
>>
>> Signed-off-by: Michal Privoznik 
> 
> This has triggered a build failure on amd64+i386+armhf within the Xen
> automated test framework (which uses Debian Wheezy as the build
> environment), I doubt it is in any way Xen specific though:
> 
> util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
> util/virnetdevmacvlan.c:338:26: error: 'IFF_MULTI_QUEUE' undeclared (first 
> use in this function)
> util/virnetdevmacvlan.c:338:26: note: each undeclared identifier is reported 
> only once for each function it appears in
> 

this is supposed to be fixed by:


commit ec93cc25ecdad100a535cb52c08f7eaa3004b960
Author: Michal Privoznik 
AuthorDate: Sat Dec 12 08:05:17 2015 +0100
Commit: Michal Privoznik 
CommitDate: Sun Dec 13 08:35:46 2015 +0100

virNetDevMacVLanTapSetup: Work around older systems

Some older systems, e.g. RHEL-6 do not have IFF_MULTI_QUEUE flag
which we use to enable multiqueue feature. Therefore one gets the
following compile error there:

  CC util/libvirt_util_la-virnetdevmacvlan.lo
util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
util/virnetdevmacvlan.c:338: error: 'IFF_MULTI_QUEUE' undeclared (first use 
in this function)
util/virnetdevmacvlan.c:338: error: (Each undeclared identifier is reported 
only once
util/virnetdevmacvlan.c:338: error: for each function it appears in.)
make[3]: *** [util/libvirt_util_la-virnetdevmacvlan.lo] Error 1

So, whenever user wants us to enable the feature on such systems,
we will just throw a runtime error instead.

Signed-off-by: Michal Privoznik 



Michal

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

Re: [Xen-devel] [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel capability)

[Ian Jackson]

Ian Campbell writes ("[PATCH] flask: Allow device model to raise PCI interrupts 
(pcilevel capability)"):
...
> - allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
> irqlevel pciroute cacheattr send_irq };
> + allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
> irqlevel pciroute pcilevel cacheattr send_irq };

Thanks for tracking this down.

Based on xen/xsm/flask/policy/access_vectors this seems like a
no-brainer.  Hopefully Daniel will agree :-).

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] [PATCH v10 3/5] libxl: add pvusb API

[George Dunlap]

On Mon, Dec 14, 2015 at 7:25 AM, Chun Yan Liu  wrote:
>
>
 On 12/10/2015 at 08:08 PM, in message <56696b4b.7060...@citrix.com>, George
> Dunlap  wrote:
>> On 10/12/15 12:05, George Dunlap wrote:
>> > From: Chunyan Liu 
>> >
>> > Add pvusb APIs, including:
>> >  - attach/detach (create/destroy) virtual usb controller.
>> >  - attach/detach usb device
>> >  - list usb controller and usb devices
>> >  - some other helper functions
>> >
>> > Signed-off-by: Chunyan Liu 
>> > Signed-off-by: Simon Cao 
>> > Signed-off-by: George Dunlap 
>>
>> Attached is a diff of v9 -> v10 for convenience.
>
> Thanks very much, George!
> I've applied your new patch and tested, there are a couple of changes needed 
> to
> get tests PASSED. A small extra patch is written on top of your new patch, as 
> in
> attachment, please have a look.

Thanks -- the changes in the patch look good.

>> > +static int usbdev_get_all_interfaces(libxl__gc *gc, const char *busid,
>> > + char ***intfs, int *num)
>> > +{
>> > +DIR *dir;
>> > +char *buf;
>> > +int rc;
>> > +
>> > +*intfs = NULL;
>> > +*num = 0;
>> > +
>> > +buf = GCSPRINTF("%s:", busid);
>> > +
>> > +dir = opendir(SYSFS_USB_DEV);
>> > +if (!dir) {
>> > +LOGE(ERROR, "opendir failed: '%s'", SYSFS_USB_DEV);
>> > +return ERROR_FAIL;
>> > +}
>> > +
>> > +size_t need = offsetof(struct dirent, d_name) +
>> > +pathconf(SYSFS_USB_DEV, _PC_NAME_MAX) + 1;
>> > +struct dirent *de_buf = libxl__zalloc(gc, need);
>>
>> Is this thing with manually calculating the size of the structure really
>> necessary?  Could we not just declare "struct dirent de_buf" on the stack?
>
> Calculating in above way is to allocate enough space for d_name, whereas
> "struct dirent de_buf" won't allocate space for d_name (which is char *).
>
> Codes for calling read_dir_r are often done like above.

OK -- in that case, can you put the allocation of the structure into a
macro or helper function, fold in the patch you sent, and re-send this
series as v11?

Thanks!

 -George

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

Re: [Xen-devel] [libvirt] [PATCH LIBVIRT] libxl: Use libxentoollog in preference to libxenctrl if available.

[Ian Campbell]

On Mon, 2015-12-14 at 11:15 +, Daniel P. Berrange wrote:
> On Thu, Dec 10, 2015 at 11:38:36AM +, Ian Campbell wrote:
> > Upstream Xen is in the process of splitting the (stable API) xtl_*
> > interfaces out from the (unstable API) libxenctrl library and into a
> > new (stable API) libxentoollog.
> > 
> > In order to be compatible with Xen both before and after this
> > transition check for xtl_createlogger_stdiostream in a libxentoollog
> > library and use it if present. If it is not present assume it is in
> > libxenctrl.
> 
> Ok, so there's no API changes, just move stuf from one to the other.

Indeed, it should really have been a separate library all along and the API
already setup that way.

I'm working on some other library splits, which will involve API changes,
but AFAIK they are all isolated from libvirt via the use of libxl, so there
should be no churn for you guys other than this one patch.

> > It might be nice to get this into 1.3.0 so that supports Xen 4.7 out
> > of the box? Not sure what the libvirt stable backport policy is but it
> > might also be good to eventually consider it for that?
> 
> We've missed 1.3.0 release, but I'd be ok with adding it to the
> stable branch if that's going to be useful.

I think it would, to allow things to build with Xen 4.7 (when it is
released).

[...]

> Looks, fine from me but will let Jim push it.

Thanks.


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

Re: [Xen-devel] [PATCH v3 2/2] VT-d: Fix vt-d flush timeout issue.

[Jan Beulich]

>>> On 12.12.15 at 14:21,  wrote:
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1890,6 +1890,9 @@ static int intel_iommu_add_device(u8 devfn, struct 
> pci_dev *pdev)
>  if ( !pdev->domain )
>  return -EINVAL;
>  
> +if ( is_pdev_unassignable(pdev) )
> +return -EACCES;

Is this case possible at all (i.e. a newly added device being
unassignable)?

> --- a/xen/drivers/passthrough/vtd/qinval.c
> +++ b/xen/drivers/passthrough/vtd/qinval.c
> @@ -27,12 +27,58 @@
>  #include "dmar.h"
>  #include "vtd.h"
>  #include "extern.h"
> +#include "../ats.h"
>  
>  static int __read_mostly iommu_qi_timeout_ms = 1;
>  integer_param("iommu_qi_timeout_ms", iommu_qi_timeout_ms);
>  
>  #define IOMMU_QI_TIMEOUT (iommu_qi_timeout_ms * MILLISECS(1))
>  
> +void invalidate_timeout(struct iommu *iommu)
> +{
> +struct domain *d;
> +unsigned long nr_dom, i;
> +struct pci_dev *pdev;
> +
> +nr_dom = cap_ndoms(iommu->cap);
> +i = find_first_bit(iommu->domid_bitmap, nr_dom);
> +while ( i < nr_dom ) {
> +d = rcu_lock_domain_by_id(iommu->domid_map[i]);
> +ASSERT(d);
> +
> +/* Mark the devices as unassignable. */
> +for_each_pdev(d, pdev)
> +mark_pdev_unassignable(pdev);
> +if ( !is_hardware_domain(d) )
> +domain_kill(d);

DYM domain_crash() here?

> +void device_tlb_invalidate_timeout(struct iommu *iommu, u16 did,
> +   u16 seg, u8 bus, u8 devfn)
> +{
> +struct domain *d;
> +struct pci_dev *pdev;
> +
> +d = rcu_lock_domain_by_id(iommu->domid_map[did]);
> +ASSERT(d);
> +for_each_pdev(d, pdev)
> +if ( (pdev->seg == seg) &&
> + (pdev->bus == bus) &&
> + (pdev->devfn == devfn) )
> +{
> +mark_pdev_unassignable(pdev);
> +break;
> +}
> +
> +if ( !is_hardware_domain(d) )
> +domain_kill(d);
> +rcu_unlock_domain(d);
> +}

Except for the variable declarations, indentation is broken for the
entire function.

> @@ -262,6 +308,14 @@ static int __iommu_flush_iec(struct iommu *iommu, u8 
> granu, u8 im, u16 iidx)
>  
>  queue_invalidate_iec(iommu, granu, im, iidx);
>  ret = invalidate_sync(iommu);
> +
> +if ( ret == -ETIMEDOUT )
> +{
> +invalidate_timeout(iommu);
> +dprintk(XENLOG_WARNING VTDPREFIX,
> +"IEC flush timeout.\n");
> +return ret;
> +}
>  /*

Considering the recurring pattern, wouldn't it be better for
invalidate_sync() to invoke invalidate_timeout() (at once making
sure no current or future caller misses the need to do so)?

Also please insert the blank line at the end of your additions, and
no trailing full stops in log messages please.

> @@ -88,6 +89,16 @@ struct pci_dev {
>  #define for_each_pdev(domain, pdev) \
>  list_for_each_entry(pdev, &(domain->arch.pdev_list), domain_list)
>  
> +static inline void mark_pdev_unassignable(struct pci_dev *pdev)
> +{
> +pdev->info.is_unassignable = 1;
> +}
> +
> +static inline bool_t is_pdev_unassignable(const struct pci_dev *pdev)
> +{
> +return pdev->info.is_unassignable;
> +}

Are you aware that we already have a mechanism to prevent
assignment (via pci_{ro,hide}_device())? I think at the very least
this check should consider both variants. Whether fully using the
existing mechanism for your purpose is feasible I can't immediately
tell (since the ownership change may be problematic at the points
where you want the flagging to happen).

Jan


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

Re: [Xen-devel] [xen-unstable test] 65791: regressions - FAIL

[Jan Beulich]

>>> On 14.12.15 at 08:50,  wrote:
> flight 65791 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/65791/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-armhf   5 xen-build fail REGR. vs. 
> 65635

An issue with the box this got run on?

Jan


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

Re: [Xen-devel] [libvirt test] 65654: regressions - FAIL

[Stefano Stabellini]

On Fri, 11 Dec 2015, Ian Jackson wrote:
> Ian Campbell writes ("Re: [libvirt test] 65654: regressions - FAIL"):
> > On Fri, 2015-12-11 at 15:18 +, osstest service owner wrote:
> > > flight 65654 libvirt real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/65654/
> > >
> > > Regressions :-(
> > >
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
> > > 63340
> >
> > Stefano has posted a fix for this to qemu-upstream but it isn't going to
> > make the QEMU 2.5.0 release:
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01435.html
> > and given the freeze for that it is going to be a while before it is
> > accepted.
> >
> > I don't really see that point in blocking the libvirt push gate over this
> > issue, so I would suggest a force push.
>
> I have no objection, if Jim and Stefano are happy with that.

That's OK for me___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] stubdom migration failure on merlot* XSM related (Was: [adhoc test] 65682: tolerable FAIL])

[Ian Campbell]

On Mon, 2015-12-14 at 11:11 +, George Dunlap wrote:
> On Mon, Dec 14, 2015 at 10:14 AM, Ian Campbell 
> wrote:
> > On Fri, 2015-12-11 at 15:16 +, Ian Campbell wrote:
> > > 
> > > I have a new flight going on (65755) with flask=permissive instead of
> > > flask=enforcing (assuming I didn't botch the osstest modifications to
> > > support that setting via a runvar).
> > 
> > I did botch the mods, but luckily permissive is the default, so I got
> > what
> > I wanted ;-)
> > 
> > > If that test passes, prints the AVC message but not the missing IRQ
> > > message
> > > then I think that would be our smoking gun.
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/65758/
> > 
> > From serial-merlot1.log:
> > 
> > Dec 11 18:01:57.001037 (XEN) Flask: 64 avtab hash slots, 236 rules.
> > Dec 11 18:01:57.009023 (XEN) Flask: 64 avtab hash slots, 236 rules.
> > Dec 11 18:01:57.017004 (XEN) Flask:  3 users, 3 roles, 36 types, 2
> > bools
> > Dec 11 18:01:57.017038 (XEN) Flask:  12 classes, 236 rules
> > Dec 11 18:01:57.025015 (XEN) Flask:  Starting in permissive mode.
> > [...]
> > Dec 11 18:06:01.229194 (XEN) avc:  denied  { pcilevel } for domid=2
> > target=1 scontext=system_u:system_r:dm_dom_t
> > tcontext=system_u:system_r:domU_t_target tclass=hvm
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/65758/test-amd64-amd64
> > -xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---var-log-xen-qemu-dm-
> > debianhvm.guest.osstest--incoming.log.10
> 
> So wait -- does flask not report denials when in enforcing mode?

It does, I'm not sure what made you think otherwise, earlier in the thread
I quoted such a denial and it was that which lead me down this path.

Ian.

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

Re: [Xen-devel] [libvirt] [PATCH v2 5/7] virNetDevMacVLanTapSetup: Allow enabling of IFF_MULTI_QUEUE

[Ian Campbell]

On Mon, 2015-12-14 at 12:35 +0100, Michal Privoznik wrote:
> On 14.12.2015 11:23, Ian Campbell wrote:
> > Hello,
> > 
> > On Thu, 2015-12-10 at 08:38 +0100, Michal Privoznik wrote:
> > > Like we are doing for TUN/TAP devices, we should do the same for
> > > macvtaps. Although, it's not as critical as in that case, we
> > > should do it for the consistency.
> > > 
> > > Signed-off-by: Michal Privoznik 
> > 
> > This has triggered a build failure on amd64+i386+armhf within the Xen
> > automated test framework (which uses Debian Wheezy as the build
> > environment), I doubt it is in any way Xen specific though:
> > 
> > util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
> > util/virnetdevmacvlan.c:338:26: error: 'IFF_MULTI_QUEUE' undeclared
> > (first use in this function)
> > util/virnetdevmacvlan.c:338:26: note: each undeclared identifier is
> > reported only once for each function it appears in
> > 
> 
> this is supposed to be fixed by:

Ah, I somehow missed that commit in the logs, sorry.

The test run in question had picked up afe73ed46856 which was before the
fixup, the next one will pickup the newer version and be fine.

Thanks and sorry for the noise.

Ian.

> 
> 
> commit ec93cc25ecdad100a535cb52c08f7eaa3004b960
> Author: Michal Privoznik 
> AuthorDate: Sat Dec 12 08:05:17 2015 +0100
> Commit: Michal Privoznik 
> CommitDate: Sun Dec 13 08:35:46 2015 +0100
> 
> virNetDevMacVLanTapSetup: Work around older systems
> 
> Some older systems, e.g. RHEL-6 do not have IFF_MULTI_QUEUE flag
> which we use to enable multiqueue feature. Therefore one gets the
> following compile error there:
> 
>   CC util/libvirt_util_la-virnetdevmacvlan.lo
> util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
> util/virnetdevmacvlan.c:338: error: 'IFF_MULTI_QUEUE' undeclared
> (first use in this function)
> util/virnetdevmacvlan.c:338: error: (Each undeclared identifier is
> reported only once
> util/virnetdevmacvlan.c:338: error: for each function it appears in.)
> make[3]: *** [util/libvirt_util_la-virnetdevmacvlan.lo] Error 1
> 
> So, whenever user wants us to enable the feature on such systems,
> we will just throw a runtime error instead.
> 
> Signed-off-by: Michal Privoznik 
> 
> 
> 
> Michal

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

[Xen-devel] [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel capability)

[Ian Campbell]

Allows:

(XEN) avc:  denied  { pcilevel } for domid=2 target=1 
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
tclass=hvm

Which otherwise leads to the following on resume after migrate (comparing
non-XSM to XSM):

 ata2.00: configured for MWDMA2
 usb 1-2: reset full-speed USB device number 2 using uhci_hcd
+PM: restore of devices complete after 3779.268 msecs
 usb 1-2: USB disconnect, device number 2
-PM: restore of devices complete after 2342.528 msecs
 usb 1-2: new full-speed USB device number 3 using uhci_hcd
 usb 1-2: New USB device found, idVendor=0627, idProduct=0001
 usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 usb 1-2: Product: QEMU USB Tablet
 usb 1-2: Manufacturer: QEMU 0.10.2
 usb 1-2: SerialNumber: 1
 input: QEMU 0.10.2 QEMU USB Tablet as 
/devices/pci:00/:00:01.2/usb1/1-2/1-2:1.0/input/input8
 generic-usb 0003:0627:0001.0002: input,hidraw0: USB HID v0.01 Pointer [QEMU 
0.10.2 QEMU USB Tablet] on usb-:00:01.2-2/input0
 Restarting tasks ... done.
 Setting capacity to 2048
 Setting capacity to 2048
+uhci_hcd :00:01.2: Unlink after no-IRQ?  Controller is probably using the 
wrong IRQ.

And a glitch in the domU which is sufficient to disrupt the post migration
checks done by osstest.

This has been through a test run on merlot1 and resolved the migration
issues with the test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm
osstest test case.

Signed-off-by: Ian Campbell 
Cc: Daniel De Graaf 
---
 tools/flask/policy/policy/modules/xen/xen.if | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if 
b/tools/flask/policy/policy/modules/xen/xen.if
index 32dd7b3..00d1bbb 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -150,7 +150,7 @@ define(`device_model', `
 
allow $1 $2_target:domain shutdown;
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute cacheattr send_irq };
+   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
-- 
2.6.1


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

Re: [Xen-devel] stubdom migration failure on merlot* XSM related (Was: [adhoc test] 65682: tolerable FAIL])

[Ian Campbell]

On Mon, 2015-12-14 at 10:14 +, Ian Campbell wrote:
> 
> I've running a test with the following patch. I'm reasonably hopeful.

and it did indeed pass:
http://logs.test-lab.xenproject.org/osstest/logs/66273/

I'll resubmit as a proper patch.

Ian.

> 
> Ian.
> 
> From 3f14c5afedc0df360952364b93c2f04de00f00c4 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Mon, 14 Dec 2015 08:22:41 +
> Subject: [PATCH] flask: Allow device model to raise PCI interrupts
> (pcilevel
>  capability)
> 
> Allows:
> 
> (XEN) avc:  denied  { pcilevel } for domid=2 target=1
> scontext=system_u:system_r:dm_dom_t
> tcontext=system_u:system_r:domU_t_target tclass=hvm
> 
> Which otherwise leads to the following on resume after migrate (comparing
> non-XSM to XSM):
> 
>  ata2.00: configured for MWDMA2
>  usb 1-2: reset full-speed USB device number 2 using uhci_hcd
> +PM: restore of devices complete after 3779.268 msecs
>  usb 1-2: USB disconnect, device number 2
> -PM: restore of devices complete after 2342.528 msecs
>  usb 1-2: new full-speed USB device number 3 using uhci_hcd
>  usb 1-2: New USB device found, idVendor=0627, idProduct=0001
>  usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
>  usb 1-2: Product: QEMU USB Tablet
>  usb 1-2: Manufacturer: QEMU 0.10.2
>  usb 1-2: SerialNumber: 1
>  input: QEMU 0.10.2 QEMU USB Tablet as
> /devices/pci:00/:00:01.2/usb1/1-2/1-2:1.0/input/input8
>  generic-usb 0003:0627:0001.0002: input,hidraw0: USB HID v0.01 Pointer
> [QEMU 0.10.2 QEMU USB Tablet] on usb-:00:01.2-2/input0
>  Restarting tasks ... done.
>  Setting capacity to 2048
>  Setting capacity to 2048
> +uhci_hcd :00:01.2: Unlink after no-IRQ?  Controller is probably
> using the wrong IRQ.
> 
> And a glitch in the domU which is sufficient to disrupt the post
> migration
> checks done by osstest.
> 
> Signed-off-by: Ian Campbell 
> Cc: Daniel De Graaf 
> ---
>  tools/flask/policy/policy/modules/xen/xen.if | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/flask/policy/policy/modules/xen/xen.if
> b/tools/flask/policy/policy/modules/xen/xen.if
> index 32dd7b3..00d1bbb 100644
> --- a/tools/flask/policy/policy/modules/xen/xen.if
> +++ b/tools/flask/policy/policy/modules/xen/xen.if
> @@ -150,7 +150,7 @@ define(`device_model', `
>  
>   allow $1 $2_target:domain shutdown;
>   allow $1 $2_target:mmu { map_read map_write adjust physmap
> target_hack };
> - allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
> irqlevel pciroute cacheattr send_irq };
> + allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl
> irqlevel pciroute pcilevel cacheattr send_irq };
>  ')
>  
>  # make_device_model(priv, dm_dom, hvm_dom)

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

Re: [Xen-devel] [PATCH v3 1/2] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed.

[Jan Beulich]

>>> On 12.12.15 at 14:21,  wrote:
> @@ -167,10 +172,12 @@ static int queue_invalidate_wait(struct iommu *iommu,
>  start_time = NOW();
>  while ( poll_slot != QINVAL_STAT_DONE )
>  {
> -if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
> +if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
>  {
>  print_qi_regs(iommu);
> -panic("queue invalidate wait descriptor was not executed");
> +dprintk(XENLOG_WARNING VTDPREFIX,
> +"Queue invalidate wait descriptor was timeout.\n");
> +return -ETIMEDOUT;
>  }

Without the v2 discussion even having finished, and without you
having taken care of v2 comments here, I don't see much value in
this v3.

Jan


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

Re: [Xen-devel] [xen-unstable test] 65791: regressions - FAIL

[Ian Campbell]

On Mon, 2015-12-14 at 02:39 -0700, Jan Beulich wrote:
> > > > On 14.12.15 at 08:50,  wrote:
> > flight 65791 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/65791/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-armhf   5 xen-build fail REGR.
> > vs. 65635
> 
> An issue with the box this got run on?

There seems to have been a few glitches with the git proxy over the
weekend, leading to some timeouts. I've gotten a bit of cronspam from the
system with similar causes.

It looks fine now, not heavily loaded or anything.

Ian.


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

[Xen-devel] Question about arm passthrough and power related

[Peng Fan]

Hi,

I am trying to passthrough a platform device to domU, but as we know
clk dts property and related code are handled in dom0. If passthrough the
platform device to domU, then how the clock for the device.

I came across this documentation "How to passthrough your integrated device to a
VM on ARM" at  
https://events.linuxfoundation.org/sites/events/files/slides/talk_5.pdf.
And follow the steps, and I can assign machine io memory space to domU on my
platform without smmu support. But domU driver probe function will fail,
because there is no clk property in the domU partial dts.

For example, without the clocks property, domU driver probe will fail.
uart2: serial@3089 {
compatible = "fsl,imx7d-uart", "fsl,imx6q-uart", "fsl,imx21-uart";
reg = <0x3087 0x1>;
interrupts = ;
clocks = < IMX7D_UART2_ROOT_CLK>,
< IMX7D_UART2_ROOT_CLK>;
clock-names = "ipg", "per";
xx
};


I have another question which is about power related. Without xen, linux can
runs into suspend state, ddr into self-refresh state, arm core powered off, and
clocks for some devices are off and power off;
If with xen, should the power related stuff implemented in xen hypervisorr
or still in dom0 linux?

Thanks,
Peng.

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

Re: [Xen-devel] [linux-3.14 test] 65633: regressions - FAIL

[Robert Hu]

On Mon, 2015-12-14 at 09:38 +, Ian Campbell wrote:
> On Mon, 2015-12-14 at 10:30 +0800, Robert Hu wrote:
> > On Fri, 2015-12-11 at 12:01 +, Ian Campbell wrote:
> > > On Fri, 2015-12-11 at 11:48 +0800, Robert Hu wrote:
> > > > On Fri, 2015-12-11 at 01:16 +, osstest service owner wrote:
> > > > > flight 65633 linux-3.14 real [real]
> > > > > http://logs.test-lab.xenproject.org/osstest/logs/65633/
> > > > > 
> > > > > Regressions :-(
> > > > > 
> > > > > Tests which did not succeed and are blocking,
> > > > > including tests which could not be run:
> > > > >  test-amd64-i386-rumpuserxen-i386 10 guest-start   fail
> > > > > REGR.
> > > > > vs. 64562
> > > > [trim...]
> > > > Hi Ian,
> > > > 
> > > > Why does it still fails there and even marked 'never pass' now?
> > > 
> > > This is the test of the linux-3.14 branch, not the xen-unstable branch
> > > which was failing before.
> > > 
> > > Once the revert passes through the xen-unstable push gate then the
> > > linux-
> > > 3.14 branch (and most other branches) will pick up that change.
> > > 
> > > I don't know why the nested test case has never passed on the 3.14
> > > branch,
> > > someone would have to investigate if they think that is a problem.
> > 
> > I think better to use linux-stable tree, which I have always for the
> > test development.
> > I remember at very beginning, I tried to use the linux-pvops tree but
> > failed. Result seems aligned with your side.
> 
> We test all kernel.org long term kernels in independent branches (from the
> "linux stable tree" as you call it). This report is for the branch which is
> testing linux-3.14.y.

OK. I thought this linux-3.14.y was from osstest/linux-pvops tree.
I previously used linux-stable tree's master branch for test
development.

> 
> Ian.
> 



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

Re: [Xen-devel] [PATCH v13 7/8] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz]

On 12/07/15 08:36, Paul Durrant wrote:
>> -Original Message-
> [snip]
>>
>>  if ( rc )
>> -hvm_unmap_ioreq_page(s, 0);
>> +{
>> +hvm_unmap_ioreq_page(s, IOREQ_PAGE_TYPE_IOREQ);
>> +return rc;
>> +}
>> +
>> +rc = hvm_map_ioreq_page(s, IOREQ_PAGE_TYPE_VMPORT,
>> vmport_ioreq_pfn);
>
> Is every ioreq server going to have one of these? It doesn't look
> like it, so should you not have validity check on the pfn?
>


 Currently the default is that all ioreq servers get the mapping:

>>>
>>> That's probably a bit wasteful. It should probably be
>>> selectable in the create HVM op.
>>
>> Since the most common case is QEMU and it can use it since upstream
>> version 2.2.0, the waste is real small.  If a non-QEMU ioreq server does
>> not want it, it add 0 overhead. 
> 
> It's not 0 overhead if an extra magic page is used for each ioreq server is 
> it?
>

My understanding is that the Xen overhead is 1 entry in p2m for each
ioreq server.


>> The only case I know of (which is PVH
>> related to PVH) is if QEMU is not running and you add a non-QEMU ioreq
>> server that does not use it, you get 1 page + page table entries.
>>
>> While the following exists:
>>
>> #define HVM_IOREQSRV_BUFIOREQ_OFF0
>> #define HVM_IOREQSRV_BUFIOREQ_LEGACY 1
>> /*
>>  * Use this when read_pointer gets updated atomically and
>>  * the pointer pair gets read atomically:
>>  */
>> #define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
>> uint8_t handle_bufioreq; /* IN - should server handle buffered ioreqs */
>>
>> I see no tests that use these.  Also adding vmport enable/disable to
>> handle_bufioreq is much more of a hack then I expect to pass a code
>> review.
>>
>> Does not look simple to add a new additional argument, but that could
>> just be my lack of understanding in the area.
> 
> It doesn't look that bad. The bufioreq flag has now expanded
> from 1 bit to 2 bits, but you could rename 'handle_bufioreq' to
> 'flags' or some such and then use bit 3 to indicate whether or
> not the vmport ioreq page should be allocated.
> 

Ok, I will code this up and plan to go with it.  Since old QEMU need to
be supported, bit 3 will be a negative flag, when set no page will be
mapped.

>>
>>> I don't know whether you'd
>>> even need it there in the default server since I guess the QEMU
>>> end of things post-dates the use of the HVM op (rather than the
>>> old param).
>>>
>>
>> Not sure how to parse "post-dates".  Here is some tables about this that
>> I know about:
>>
>>
>> xen Supportshandle_bufioreq
>>  create_ioreq_server
>> 4.5 yes 0 or !0
>> 4.6 yes 0 or !0
>> 4.7 yes 0 or !0
>>
>> Upstream vmport is_default atomic
>>  QEMU support
>>
>> 2.2.xyesyesn/a
>> 2.3.xyesno no
>> 2.4.xyesno no
>> 2.5.xyesno yes
>>
>> Xen  vmport is_default atomic
>>  QEMU support
>>
>> 4.5.xno yesn/a
>> 4.6.xyesno yes
>> 4.7.xyesno yes
>>
>> With just a "xen only" build, you will not get a QEMU that is a default
>> ioreq server.  However it looks possible to mix Xen and QEMU and get
>> this case.
>>
> 
> What I meant was that I believe that the vmport ioreq page will
> only be used by a qemu that also make use of the
> create_ioreq_server hmvop, so you don't have to care about
> making it work with older QEMU. It looks like 2.2.x may prove
> me wrong though in which case it should be present in the
> default ioreq server but still optional for all others.
> 

Yes, default ioreq server will get the mapping when enabled,
optional for all others.

   -Don Slutz

>   Paul
> 
>> So unless I hear otherwise, I will not be making a change here.
>>
 +/* VMware port */
 +if ( i == HVMOP_IO_RANGE_VMWARE_PORT &&
 +s->domain->arch.hvm_domain.is_vmware_port_enabled )
 +rc = rangeset_add_range(s->range[i], 1, 1);



 but you are right that a check on is_vmware_port_enabled should be
 added.  Will do.
>>>
>>> Cool. Thanks,
>>>
>>>   Paul
>>>

-Don Slutz

>   Paul
>

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

Re: [Xen-devel] stubdom migration failure on merlot* XSM related (Was: [adhoc test] 65682: tolerable FAIL])

[Ian Campbell]

On Fri, 2015-12-11 at 15:16 +, Ian Campbell wrote:
> 
> I have a new flight going on (65755) with flask=permissive instead of
> flask=enforcing (assuming I didn't botch the osstest modifications to
> support that setting via a runvar).

I did botch the mods, but luckily permissive is the default, so I got what
I wanted ;-)

> If that test passes, prints the AVC message but not the missing IRQ message
> then I think that would be our smoking gun.

http://logs.test-lab.xenproject.org/osstest/logs/65758/

From serial-merlot1.log:

Dec 11 18:01:57.001037 (XEN) Flask: 64 avtab hash slots, 236 rules.
Dec 11 18:01:57.009023 (XEN) Flask: 64 avtab hash slots, 236 rules.
Dec 11 18:01:57.017004 (XEN) Flask:  3 users, 3 roles, 36 types, 2 bools
Dec 11 18:01:57.017038 (XEN) Flask:  12 classes, 236 rules
Dec 11 18:01:57.025015 (XEN) Flask:  Starting in permissive mode.
[...]
Dec 11 18:06:01.229194 (XEN) avc:  denied  { pcilevel } for domid=2 target=1 
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
tclass=hvm

http://logs.test-lab.xenproject.org/osstest/logs/65758/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---var-log-xen-qemu-dm-debianhvm.guest.osstest--incoming.log.10

i.e. no "uhci_hcd :00:01.2: Unlink after no-IRQ?  Controller is
probably using the wrong IRQ." and the test case has passed.

I've running a test with the following patch. I'm reasonably hopeful.

Ian.

From 3f14c5afedc0df360952364b93c2f04de00f00c4 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Mon, 14 Dec 2015 08:22:41 +
Subject: [PATCH] flask: Allow device model to raise PCI interrupts (pcilevel
 capability)

Allows:

(XEN) avc:  denied  { pcilevel } for domid=2 target=1 
scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
tclass=hvm

Which otherwise leads to the following on resume after migrate (comparing
non-XSM to XSM):

 ata2.00: configured for MWDMA2
 usb 1-2: reset full-speed USB device number 2 using uhci_hcd
+PM: restore of devices complete after 3779.268 msecs
 usb 1-2: USB disconnect, device number 2
-PM: restore of devices complete after 2342.528 msecs
 usb 1-2: new full-speed USB device number 3 using uhci_hcd
 usb 1-2: New USB device found, idVendor=0627, idProduct=0001
 usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
 usb 1-2: Product: QEMU USB Tablet
 usb 1-2: Manufacturer: QEMU 0.10.2
 usb 1-2: SerialNumber: 1
 input: QEMU 0.10.2 QEMU USB Tablet as 
/devices/pci:00/:00:01.2/usb1/1-2/1-2:1.0/input/input8
 generic-usb 0003:0627:0001.0002: input,hidraw0: USB HID v0.01 Pointer [QEMU 
0.10.2 QEMU USB Tablet] on usb-:00:01.2-2/input0
 Restarting tasks ... done.
 Setting capacity to 2048
 Setting capacity to 2048
+uhci_hcd :00:01.2: Unlink after no-IRQ?  Controller is probably using the 
wrong IRQ.

And a glitch in the domU which is sufficient to disrupt the post migration
checks done by osstest.

Signed-off-by: Ian Campbell 
Cc: Daniel De Graaf 
---
 tools/flask/policy/policy/modules/xen/xen.if | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/flask/policy/policy/modules/xen/xen.if 
b/tools/flask/policy/policy/modules/xen/xen.if
index 32dd7b3..00d1bbb 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -150,7 +150,7 @@ define(`device_model', `
 
    allow $1 $2_target:domain shutdown;
    allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute cacheattr send_irq };
+   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
-- 
2.6.1


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

Re: [Xen-devel] stubdom migration failure on merlot* XSM related (Was: [adhoc test] 65682: tolerable FAIL])

[George Dunlap]

On Mon, Dec 14, 2015 at 10:14 AM, Ian Campbell  wrote:
> On Fri, 2015-12-11 at 15:16 +, Ian Campbell wrote:
>>
>> I have a new flight going on (65755) with flask=permissive instead of
>> flask=enforcing (assuming I didn't botch the osstest modifications to
>> support that setting via a runvar).
>
> I did botch the mods, but luckily permissive is the default, so I got what
> I wanted ;-)
>
>> If that test passes, prints the AVC message but not the missing IRQ message
>> then I think that would be our smoking gun.
>
> http://logs.test-lab.xenproject.org/osstest/logs/65758/
>
> From serial-merlot1.log:
>
> Dec 11 18:01:57.001037 (XEN) Flask: 64 avtab hash slots, 236 rules.
> Dec 11 18:01:57.009023 (XEN) Flask: 64 avtab hash slots, 236 rules.
> Dec 11 18:01:57.017004 (XEN) Flask:  3 users, 3 roles, 36 types, 2 bools
> Dec 11 18:01:57.017038 (XEN) Flask:  12 classes, 236 rules
> Dec 11 18:01:57.025015 (XEN) Flask:  Starting in permissive mode.
> [...]
> Dec 11 18:06:01.229194 (XEN) avc:  denied  { pcilevel } for domid=2 target=1 
> scontext=system_u:system_r:dm_dom_t tcontext=system_u:system_r:domU_t_target 
> tclass=hvm
>
> http://logs.test-lab.xenproject.org/osstest/logs/65758/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/merlot1---var-log-xen-qemu-dm-debianhvm.guest.osstest--incoming.log.10

So wait -- does flask not report denials when in enforcing mode?

I can see the point of not letting a rogue / misconfigured guest DoS
your logs, but it seems like some sort of rate-limiting would be a
better solution than just not printing anything.

 -George

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

Re: [Xen-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability

[Ian Campbell]

On Mon, 2015-12-14 at 11:19 +, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Campbell wrote:
> > On Fri, 2015-12-11 at 16:44 +, Stefano Stabellini wrote:
> > >  
> > > It is not possible to do this at runtime. I think we should do this
> > > at
> > > compile time because in any case it is not supported to run a QEMU
> > > built
> > > for a given Xen version on a different Xen version.
> > 
> > I am currently working pretty hard to make this possible in the future,
> > it
> > would be a shame to add another reason it wasn't possible at this
> > stage.
> > 
> > I proposed (in <1445442435.9563.184.ca...@citrix.com>) that as well as
> > the
> > various stable libraries extracted from libxenctrl we will probably
> > also
> > want to have a libxendevicemodel.so at some point, to provide a stable
> > way
> > to interface with all the stuff which being a DM involves.
> 
> I understand the direction we are heading toward, but unfortunately we
> are still pretty far from it. I don't think we want to block this patch
> until we have a stable libxendevicemodel ABI?

No, but I would appreciate if such things were explicitly considered on a
case by case by case basis rather than just bundled under a generic "it's
not possible yet", since there may be cases where we want to hold off, or
more likely where doing something a particular way now will ease things for
the transition in the future.

>  Also this particular
> change regards PCI passthrough, which is not convered by the proposed
> ABI yet.
> 
> 
> > Maybe that library could contain a way to get this information? (In
> > which
> > case it could be hardcoded at compile time now and I'll see what I can
> > do
> > when I get to producing the library).
> 
> Given the choice, I would rather have only compile time or only run time
> Xen version checks in QEMU and not both to avoid complexity. Especially
> as long as the underlying libraries don't make any stability guarantees.

"that library" obviously will make such guarantees as a matter of design.

Ian.

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

Re: [Xen-devel] [PATCH] tools: always enable HAS_MEM_ACCESS

[Razvan Cojocaru]

On 12/11/2015 06:00 PM, Doug Goldstein wrote:
> For all supported targets HAS_MEM_ACCESS is enabled so this drops the
> conditional and always makes it enabled. The goal here is to remove the
> setting in the top level config directory when kconfig changes land.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [libvirt bisection] complete build-i386-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.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:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  1e90c744d5b98d00af5957819afb9d9568f9daff
  Bug not present: 136fe2f7cc7035294d270f63c4dba13fa839390c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/66362/


  commit 1e90c744d5b98d00af5957819afb9d9568f9daff
  Author: Michal Privoznik 
  Date:   Tue Dec 8 13:17:26 2015 +0100
  
  virNetDevMacVLanTapSetup: Allow enabling of IFF_MULTI_QUEUE
  
  Like we are doing for TUN/TAP devices, we should do the same for
  macvtaps. Although, it's not as critical as in that case, we
  should do it for the consistency.
  
  Signed-off-by: Michal Privoznik 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-i386-libvirt.libvirt-build 
--summary-out=tmp/66362.bisection-summary --basis-template=63340 
--blessings=real,real-bisect libvirt build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 65789 fail [host=italia0] / 65654 [host=huxelrebe0] 65460 [host=huxelrebe0] 
65419 [host=huxelrebe1] 65394 ok.
Failure / basis pass flights: 65789 / 65394
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.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 034e47c338b13a95cf02106a3af912c1c5f818d7 
f39477dba778e99392948dd3dd19ec0d46aee932 
91c15bfaec1764ce2896a393eabee1183afe1130 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
a841b1b1286d122fd472b43db3c423b9876262e5
Basis pass 2b8d0d44b92cfcc14476f366173783ea0dc854ae 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#2b8d0d44b92cfcc14476f366173783ea0dc854ae-034e47c338b13a95cf02106a3af912c1c5f818d7
 
git://git.sv.gnu.org/gnulib.git#f39477dba778e99392948dd3dd19ec0d46aee932-f39477dba778e99392948dd3dd19ec0d46aee932
 
git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-91c15bfaec1764ce2896a393eabee1183afe1130
 
git://xenbits.xen.org/qemu-xen.git#f6787aedc9043bffc5ee5b64c6d46b8fc7298a96-f6787aedc9043bffc5ee5b64c6d46b8fc7298a96
 
git://xenbits.xen.org/xen.git#713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1-a841b1b1286d122fd472b43db3c423b9876262e5
Loaded 3003 nodes in revision graph
Searching for test results:
 65453 [host=baroque1]
 65447 [host=huxelrebe1]
 65394 pass 2b8d0d44b92cfcc14476f366173783ea0dc854ae 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65457 [host=baroque1]
 65456 [host=baroque1]
 65449 [host=baroque1]
 65419 [host=huxelrebe1]
 65466 [host=chardonnay1]
 65442 pass irrelevant
 65445 pass 2b8d0d44b92cfcc14476f366173783ea0dc854ae 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 65451 pass irrelevant
 65464 [host=baroque0]
 65469 [host=chardonnay0]
 65472 [host=baroque1]
 65460 [host=huxelrebe0]
 65654 [host=huxelrebe0]
 65756 fail afe73ed4685649e3cef3e23f344d75bf96a6c0d6 
f39477dba778e99392948dd3dd19ec0d46aee932 
91c15bfaec1764ce2896a393eabee1183afe1130 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
a841b1b1286d122fd472b43db3c423b9876262e5
 65789 fail 034e47c338b13a95cf02106a3af912c1c5f818d7 
f39477dba778e99392948dd3dd19ec0d46aee932 
91c15bfaec1764ce2896a393eabee1183afe1130 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
a841b1b1286d122fd472b43db3c423b9876262e5
 65790 pass 2b8d0d44b92cfcc14476f366173783ea0dc854ae 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
713b7e4ef2aa4ec3ae697cde9c81d5a57548f9b1
 66299 fail 034e47c338b13a95cf02106a3af912c1c5f818d7 
f39477dba778e99392948dd3dd19ec0d46aee932 
91c15bfaec1764ce2896a393eabee1183afe1130 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
a841b1b1286d122fd472b43db3c423b9876262e5
 66337 pass 24a7beea5a512daae56b21c83b9ad5796d4822ba 
f39477dba778e99392948dd3dd19ec0d46aee932 

[Xen-devel] [PATCH v2 3/4] libxc: stop migration in case of p2m list structural changes

[Juergen Gross]

With support of the virtual mapped linear p2m list for migration it is
now possible to detect structural changes of the p2m list which before
would either lead to a crashing or otherwise wrong behaving domU.

A guest supporting the linear p2m list will increment the
p2m_generation counter located in the shared info page before and after
each modification of a mapping related to the p2m list. A change of
that counter can be detected by the tools and reacted upon.

As such a change should occur only very rarely once the domU is up the
most simple reaction is to cancel migration in such an event.

Signed-off-by: Juergen Gross 
---
 tools/libxc/xc_sr_common.h   | 12 +++
 tools/libxc/xc_sr_save.c |  7 ++-
 tools/libxc/xc_sr_save_x86_hvm.c |  7 +++
 tools/libxc/xc_sr_save_x86_pv.c  | 45 
 4 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 9aecde2..60b43e8 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -83,6 +83,15 @@ struct xc_sr_save_ops
 int (*end_of_checkpoint)(struct xc_sr_context *ctx);
 
 /**
+ * Check state of guest to decide whether it makes sense to continue
+ * migration.  This is called in each iteration or checkpoint to check
+ * whether all criteria for the migration are still met.  If that's not
+ * the case either migration is cancelled via a bad rc or the situation
+ * is handled, e.g. by sending appropriate records.
+ */
+int (*check_vm_state)(struct xc_sr_context *ctx);
+
+/**
  * Clean up the local environment.  Will be called exactly once, either
  * after a successful save, or upon encountering an error.
  */
@@ -280,6 +289,9 @@ struct xc_sr_context
 /* Read-only mapping of guests shared info page */
 shared_info_any_t *shinfo;
 
+/* p2m generation count for verifying validity of local p2m. */
+uint64_t p2m_generation;
+
 union
 {
 struct
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index cefcef5..88d85ef 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -394,7 +394,8 @@ static int send_dirty_pages(struct xc_sr_context *ctx,
 DPRINTF("Bitmap contained more entries than expected...");
 
 xc_report_progress_step(xch, entries, entries);
-return 0;
+
+return ctx->save.ops.check_vm_state(ctx);
 }
 
 /*
@@ -751,6 +752,10 @@ static int save(struct xc_sr_context *ctx, uint16_t 
guest_type)
 if ( rc )
 goto err;
 
+rc = ctx->save.ops.check_vm_state(ctx);
+if ( rc )
+goto err;
+
 if ( ctx->save.live )
 rc = send_domain_memory_live(ctx);
 else if ( ctx->save.checkpointed )
diff --git a/tools/libxc/xc_sr_save_x86_hvm.c b/tools/libxc/xc_sr_save_x86_hvm.c
index f3d6cee..e347b3b 100644
--- a/tools/libxc/xc_sr_save_x86_hvm.c
+++ b/tools/libxc/xc_sr_save_x86_hvm.c
@@ -175,6 +175,12 @@ static int x86_hvm_start_of_checkpoint(struct 
xc_sr_context *ctx)
 return 0;
 }
 
+static int x86_hvm_check_vm_state(struct xc_sr_context *ctx)
+{
+/* no-op */
+return 0;
+}
+
 static int x86_hvm_end_of_checkpoint(struct xc_sr_context *ctx)
 {
 int rc;
@@ -221,6 +227,7 @@ struct xc_sr_save_ops save_ops_x86_hvm =
 .start_of_stream = x86_hvm_start_of_stream,
 .start_of_checkpoint = x86_hvm_start_of_checkpoint,
 .end_of_checkpoint   = x86_hvm_end_of_checkpoint,
+.check_vm_state  = x86_hvm_check_vm_state,
 .cleanup = x86_hvm_cleanup,
 };
 
diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index 98e9011..63caf2e 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -280,6 +280,39 @@ err:
 }
 
 /*
+ * Get p2m_generation count.
+ * Returns an error if the generation count has changed since the last call.
+ */
+static int get_p2m_generation(struct xc_sr_context *ctx)
+{
+uint64_t p2m_generation;
+int rc;
+
+p2m_generation = GET_FIELD(ctx->x86_pv.shinfo, arch.p2m_generation,
+   ctx->x86_pv.width);
+
+rc = (p2m_generation == ctx->x86_pv.p2m_generation) ? 0 : -1;
+ctx->x86_pv.p2m_generation = p2m_generation;
+
+return rc;
+}
+
+static int x86_pv_check_vm_state_p2m_list(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+int rc;
+
+if ( !ctx->save.live )
+return 0;
+
+rc = get_p2m_generation(ctx);
+if ( rc )
+ERROR("p2m generation count changed. Migration aborted.");
+
+return rc;
+}
+
+/*
  * Map the guest p2m frames specified via a cr3 value, a virtual address, and
  * the maximum pfn. PTE entries are 64 bits vor both, 32 and 64 bit guests as
  * in 32 bit case we support PAE guests only.
@@ -303,6 +336,8 @@ static int map_p2m_list(struct xc_sr_context *ctx, 

[Xen-devel] [PATCH v2 1/4] libxc: split mapping p2m leaves into a separate function

[Juergen Gross]

In order to prepare using the virtual mapped linear p2m list for
migration split mapping of the p2m leaf pages into a separate function.

Signed-off-by: Juergen Gross 
Reviewed-by: Andrew Cooper 
---
 tools/libxc/xc_sr_save_x86_pv.c | 77 -
 1 file changed, 45 insertions(+), 32 deletions(-)

diff --git a/tools/libxc/xc_sr_save_x86_pv.c b/tools/libxc/xc_sr_save_x86_pv.c
index c8d6f0b..d7acd37 100644
--- a/tools/libxc/xc_sr_save_x86_pv.c
+++ b/tools/libxc/xc_sr_save_x86_pv.c
@@ -68,6 +68,50 @@ static int copy_mfns_from_guest(const struct xc_sr_context 
*ctx,
 }
 
 /*
+ * Map the p2m leave pages and build an array of their pfns.
+ */
+static int map_p2m_leaves(struct xc_sr_context *ctx, xen_pfn_t *mfns,
+  size_t n_mfns)
+{
+xc_interface *xch = ctx->xch;
+unsigned x;
+
+ctx->x86_pv.p2m = xc_map_foreign_pages(xch, ctx->domid, PROT_READ,
+   mfns, n_mfns);
+if ( !ctx->x86_pv.p2m )
+{
+PERROR("Failed to map p2m frames");
+return -1;
+}
+
+ctx->save.p2m_size = ctx->x86_pv.max_pfn + 1;
+ctx->x86_pv.p2m_frames = n_mfns;
+ctx->x86_pv.p2m_pfns = malloc(n_mfns * sizeof(*mfns));
+if ( !ctx->x86_pv.p2m_pfns )
+{
+ERROR("Cannot allocate %zu bytes for p2m pfns list",
+  n_mfns * sizeof(*mfns));
+return -1;
+}
+
+/* Convert leaf frames from mfns to pfns. */
+for ( x = 0; x < n_mfns; ++x )
+{
+if ( !mfn_in_pseudophysmap(ctx, mfns[x]) )
+{
+ERROR("Bad mfn in p2m_frame_list[%u]", x);
+dump_bad_pseudophysmap_entry(ctx, mfns[x]);
+errno = ERANGE;
+return -1;
+}
+
+ctx->x86_pv.p2m_pfns[x] = mfn_to_pfn(ctx, mfns[x]);
+}
+
+return 0;
+}
+
+/*
  * Walk the guests frame list list and frame list to identify and map the
  * frames making up the guests p2m table.  Construct a list of pfns making up
  * the table.
@@ -173,7 +217,6 @@ static int map_p2m(struct xc_sr_context *ctx)
 ctx->x86_pv.p2m_frames = (ctx->x86_pv.max_pfn + fpp) / fpp;
 DPRINTF("max_pfn %#lx, p2m_frames %d", ctx->x86_pv.max_pfn,
 ctx->x86_pv.p2m_frames);
-ctx->save.p2m_size = ctx->x86_pv.max_pfn + 1;
 fl_entries  = (ctx->x86_pv.max_pfn / fpp) + 1;
 
 /* Map the guest mid p2m frames. */
@@ -211,38 +254,8 @@ static int map_p2m(struct xc_sr_context *ctx)
 }
 
 /* Map the p2m leaves themselves. */
-ctx->x86_pv.p2m = xc_map_foreign_pages(xch, ctx->domid, PROT_READ,
-   local_fl, fl_entries);
-if ( !ctx->x86_pv.p2m )
-{
-PERROR("Failed to map p2m frames");
-goto err;
-}
+rc = map_p2m_leaves(ctx, local_fl, fl_entries);
 
-ctx->x86_pv.p2m_frames = fl_entries;
-ctx->x86_pv.p2m_pfns = malloc(local_fl_size);
-if ( !ctx->x86_pv.p2m_pfns )
-{
-ERROR("Cannot allocate %zu bytes for p2m pfns list",
-  local_fl_size);
-goto err;
-}
-
-/* Convert leaf frames from mfns to pfns. */
-for ( x = 0; x < fl_entries; ++x )
-{
-if ( !mfn_in_pseudophysmap(ctx, local_fl[x]) )
-{
-ERROR("Bad mfn in p2m_frame_list[%u]", x);
-dump_bad_pseudophysmap_entry(ctx, local_fl[x]);
-errno = ERANGE;
-goto err;
-}
-
-ctx->x86_pv.p2m_pfns[x] = mfn_to_pfn(ctx, local_fl[x]);
-}
-
-rc = 0;
 err:
 
 free(local_fl);
-- 
2.6.2


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

[Xen-devel] [PATCH v2 4/4] libxc: set flag for support of linear p2m list in domain builder

[Juergen Gross]

Set the SIF_VIRT_P2M_4TOOLS flag for pv-domUs in the domain builder
to indicate the Xen tools have full support for the virtual mapped
linear p2m list.

This will enable pv-domUs to drop support of the 3 level p2m tree
and use the linear list only. Without setting this flag some kernels
might limit themselves to 512 GB memory size in order not to break
migration.

Signed-off-by: Juergen Gross 
---
 docs/features/migration.pandoc| 7 ---
 tools/libxc/xc_dom_compat_linux.c | 2 +-
 tools/libxc/xc_dom_core.c | 2 ++
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/docs/features/migration.pandoc b/docs/features/migration.pandoc
index 9852a19..151c50d 100644
--- a/docs/features/migration.pandoc
+++ b/docs/features/migration.pandoc
@@ -1,5 +1,5 @@
 % Migration
-% Revision 1
+% Revision 2
 
 \clearpage
 
@@ -95,7 +95,6 @@ scenarios, which will involve starting with VMs from Xen 4.5
 # Areas for improvement
 
 * Arm support
-* Linear P2M support for x86 PV
 * Live looping parameters
 
 # Known issues
@@ -105,7 +104,8 @@ scenarios, which will involve starting with VMs from Xen 4.5
 * x86 HVM with nested-virt (no relevant information included in the
   stream)
 * x86 PV ballooning (P2M marked dirty, target frame not marked)
-* x86 PV P2M structure changes (not noticed, stale mappings used)
+* x86 PV P2M structure changes (not noticed, stale mappings used) for
+  guests not using the linear p2m layout
 
 # References
 
@@ -120,4 +120,5 @@ for Migration v2
 Date   Revision Version  Notes
 --   ---
 2015-10-24 1Xen 4.6  Document written
+2015-12-11 2Xen 4.7  Support of linear p2m list
 --   ---
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index abbc09f..c922c61 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -59,7 +59,7 @@ int xc_linux_build(xc_interface *xch, uint32_t domid,
  ((rc = xc_dom_ramdisk_file(dom, initrd_name)) != 0) )
 goto out;
 
-dom->flags = flags;
+dom->flags |= flags;
 dom->console_evtchn = console_evtchn;
 dom->xenstore_evtchn = store_evtchn;
 
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 2061ba6..55c779d 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -777,6 +777,8 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 dom->parms.elf_paddr_offset = UNSET_ADDR;
 dom->parms.p2m_base = UNSET_ADDR;
 
+dom->flags = SIF_VIRT_P2M_4TOOLS;
+
 dom->alloc_malloc += sizeof(*dom);
 return dom;
 
-- 
2.6.2


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

[Xen-devel] [PATCH v2 0/4] support linear p2m list in migrate stream v2

[Juergen Gross]

Add support for the virtual mapped linear p2m list of pv-domains in the
v2 migrate stream. This will allow to migrate domains larger than 512
GB.

Tested with 32- and 64-bit pv-domains both with and without linear p2m
list and with a hvm domain.

Changes in V2:
- Added some sanity tests in patch 2 as suggested by Andrew Cooper
- Modified patch 3 according to Andrew Cooper's requests: rename of
  check_iteration to check_vm_state, call check_vm_state after each
  checkpoint, don't change check_vm_state hook but do the check decision
  internally
- Modified docs/features/migration.pandoc according to changes done in the
  series in patch 4 (requested by Andrew Cooper)

Juergen Gross (4):
  libxc: split mapping p2m leaves into a separate function
  libxc: support of linear p2m list for migration of pv-domains
  libxc: stop migration in case of p2m list structural changes
  libxc: set flag for support of linear p2m list in domain builder

 docs/features/migration.pandoc|   7 +-
 tools/libxc/xc_dom_compat_linux.c |   2 +-
 tools/libxc/xc_dom_core.c |   2 +
 tools/libxc/xc_sr_common.h|  12 ++
 tools/libxc/xc_sr_save.c  |   7 +-
 tools/libxc/xc_sr_save_x86_hvm.c  |   7 +
 tools/libxc/xc_sr_save_x86_pv.c   | 303 +-
 7 files changed, 300 insertions(+), 40 deletions(-)

-- 
2.6.2


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

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

[Konrad Rzeszutek Wilk]

On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote:
> Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
> will likely perform same IPIs as would have the guest.
> 

But if the VCPU is asleep, doing it via the hypervisor will save us waking
up the guest VCPU, sending an IPI - just to do an TLB flush
of that CPU. Which is pointless as the CPU hadn't been running the
guest in the first place.

>
>More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
>guest's address on remote CPU (when, for example, VCPU from another
>guest
>is running there).

Right, so the hypervisor won't even send an IPI there.

But if you do it via the normal guest IPI mechanism (which are opaque
to the hypervisor) you and up scheduling the guest VCPU to do
send an hypervisor callback. And the callback will go the IPI routine
which will do an TLB flush. Not necessary.

This is all in case of oversubscription of course. In the case where
we are fine on vCPU resources it does not matter.

Perhaps if we have PV aware TLB flush it could do this differently?

> Signed-off-by: Boris Ostrovsky 
> Suggested-by: Jan Beulich 
> Cc: sta...@vger.kernel.org # 3.14+
> ---
>  arch/x86/xen/mmu.c |9 ++---
>  1 files changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 9c479fe..9ed7eed 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -2495,14 +2495,9 @@ void __init xen_init_mmu_ops(void)
>  {
>   x86_init.paging.pagetable_init = xen_pagetable_init;
>  
> - /* Optimization - we can use the HVM one but it has no idea which
> -  * VCPUs are descheduled - which means that it will needlessly IPI
> -  * them. Xen knows so let it do the job.
> -  */
> - if (xen_feature(XENFEAT_auto_translated_physmap)) {
> - pv_mmu_ops.flush_tlb_others = xen_flush_tlb_others;
> + if (xen_feature(XENFEAT_auto_translated_physmap))
>   return;
> - }
> +
>   pv_mmu_ops = xen_mmu_ops;
>  
>   memset(dummy_mapping, 0xff, PAGE_SIZE);
> -- 
> 1.7.1
> 

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

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

[Roger Pau Monné]

El 14/12/15 a les 16.27, Konrad Rzeszutek Wilk ha escrit:
> On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote:
>> Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
>> will likely perform same IPIs as would have the guest.
>>
> 
> But if the VCPU is asleep, doing it via the hypervisor will save us waking
> up the guest VCPU, sending an IPI - just to do an TLB flush
> of that CPU. Which is pointless as the CPU hadn't been running the
> guest in the first place.
> 
>>
>> More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
>> guest's address on remote CPU (when, for example, VCPU from another
>> guest
>> is running there).
> 
> Right, so the hypervisor won't even send an IPI there.
> 
> But if you do it via the normal guest IPI mechanism (which are opaque
> to the hypervisor) you and up scheduling the guest VCPU to do
> send an hypervisor callback. And the callback will go the IPI routine
> which will do an TLB flush. Not necessary.
> 
> This is all in case of oversubscription of course. In the case where
> we are fine on vCPU resources it does not matter.
> 
> Perhaps if we have PV aware TLB flush it could do this differently?

Why don't HVM/PVH just uses the HVMOP_flush_tlbs hypercall?

Roger.


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

Re: [Xen-devel] [PATCH] xen/tools/get-fields.sh: Use printf for POSIX compat

[Jan Beulich]

>>> On 12.12.15 at 19:18,  wrote:
> xen/tools/get-fields.sh used echo -n which is not POSIX compatible and
> breaks with dash. Change it to use printf "%s" which is usable
> everywhere.

Looks okay, but a couple of remarks:
- For the unaware as well as to know why to take care going forward,
  it would be nice if the commit message mentioned where actually you
  saw this to be an issue.
- There appears to be quite a bit of unnecessary quoting (namely on
  all the "%s" instances), making lines longer than they need to be
  (and hence possible harder to read). In fact, since field names can't
  contain %, \, or other characters with special meaning to printf it
  looks as if the use of %s is superfluous altogether.
- Please Cc all relevant maintainers, not just Keir.

Jan


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

Re: [Xen-devel] [libvirt] [PATCH v2 5/7] virNetDevMacVLanTapSetup: Allow enabling of IFF_MULTI_QUEUE

[Ian Campbell]

Hello,

On Thu, 2015-12-10 at 08:38 +0100, Michal Privoznik wrote:
> Like we are doing for TUN/TAP devices, we should do the same for
> macvtaps. Although, it's not as critical as in that case, we
> should do it for the consistency.
> 
> Signed-off-by: Michal Privoznik 

This has triggered a build failure on amd64+i386+armhf within the Xen
automated test framework (which uses Debian Wheezy as the build
environment), I doubt it is in any way Xen specific though:

util/virnetdevmacvlan.c: In function 'virNetDevMacVLanTapSetup':
util/virnetdevmacvlan.c:338:26: error: 'IFF_MULTI_QUEUE' undeclared (first use 
in this function)
util/virnetdevmacvlan.c:338:26: note: each undeclared identifier is reported 
only once for each function it appears in

I'm not sure where that definition is supposed to come from, so I can't
tell if it is a missing #include in this code or an out of date header on
the Debian system.

Full logs are at
http://logs.test-lab.xenproject.org/osstest/logs/65756/
http://logs.test-lab.xenproject.org/osstest/logs/65756/build-amd64-libvirt/5.ts-libvirt-build.log
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01470.html

But TBH there isn't much more of use than the above.

Cheers,
Ian.

> ---
>  src/util/virnetdevmacvlan.c | 40 ++-
> -
>  1 file changed, 22 insertions(+), 18 deletions(-)
> 
> diff --git a/src/util/virnetdevmacvlan.c b/src/util/virnetdevmacvlan.c
> index c4d0d53..76fd542 100644
> --- a/src/util/virnetdevmacvlan.c
> +++ b/src/util/virnetdevmacvlan.c
> @@ -289,24 +289,26 @@ virNetDevMacVLanTapOpen(const char *ifname,
>   * @tapfd: array of file descriptors of the macvtap tap
>   * @tapfdSize: number of file descriptors in @tapfd
>   * @vnet_hdr: whether to enable or disable IFF_VNET_HDR
> + * @multiqueue: whether to enable or disable IFF_MULTI_QUEUE
> + *
> + * Turn the IFF_VNET_HDR flag, if requested and available, make sure
> it's
> + * off in the other cases. Similarly, IFF_MULTI_QUEUE is enabled if
> + * requested. However, if requested and failed to set, it is considered
> a
> + * fatal error (as opposed to @vnet_hdr).
>   *
> - * Turn the IFF_VNET_HDR flag, if requested and available, make sure
> - * it's off in the other cases.
>   * A fatal error is defined as the VNET_HDR flag being set but it cannot
>   * be turned off for some reason. This is reported with -1. Other fatal
>   * error is not being able to read the interface flags. In that case the
>   * macvtap device should not be used.
>   *
> - * Returns 0 on success, -1 in case of fatal error, error code
> otherwise.
> + * Returns 0 on success, -1 in case of fatal error.
>   */
>  static int
> -virNetDevMacVLanTapSetup(int *tapfd, size_t tapfdSize, bool vnet_hdr)
> +virNetDevMacVLanTapSetup(int *tapfd, size_t tapfdSize, bool vnet_hdr,
> bool multiqueue)
>  {
>  unsigned int features;
>  struct ifreq ifreq;
>  short new_flags = 0;
> -int rc_on_fail = 0;
> -const char *errmsg = NULL;
>  size_t i;
>  
>  for (i = 0; i < tapfdSize; i++) {
> @@ -320,27 +322,29 @@ virNetDevMacVLanTapSetup(int *tapfd, size_t
> tapfdSize, bool vnet_hdr)
>  
>  new_flags = ifreq.ifr_flags;
>  
> -if ((ifreq.ifr_flags & IFF_VNET_HDR) && !vnet_hdr) {
> -new_flags = ifreq.ifr_flags & ~IFF_VNET_HDR;
> -rc_on_fail = -1;
> -errmsg = _("cannot clean IFF_VNET_HDR flag on macvtap tap");
> -} else if ((ifreq.ifr_flags & IFF_VNET_HDR) == 0 && vnet_hdr) {
> +if (vnet_hdr) {
>  if (ioctl(tapfd[i], TUNGETFEATURES, ) < 0) {
>  virReportSystemError(errno, "%s",
>   _("cannot get feature flags on
> macvtap tap"));
>  return -1;
>  }
> -if ((features & IFF_VNET_HDR)) {
> -new_flags = ifreq.ifr_flags | IFF_VNET_HDR;
> -errmsg = _("cannot set IFF_VNET_HDR flag on macvtap
> tap");
> -}
> +if (features & IFF_VNET_HDR)
> +new_flags |= IFF_VNET_HDR;
> +} else {
> +new_flags &= ~IFF_VNET_HDR;
>  }
>  
> +if (multiqueue)
> +new_flags |= IFF_MULTI_QUEUE;
> +else
> +new_flags &= ~IFF_MULTI_QUEUE;
> +
>  if (new_flags != ifreq.ifr_flags) {
>  ifreq.ifr_flags = new_flags;
>  if (ioctl(tapfd[i], TUNSETIFF, ) < 0) {
> -virReportSystemError(errno, "%s", errmsg);
> -return rc_on_fail;
> +virReportSystemError(errno, "%s",
> + _("unable to set vnet or multiqueue
> flags on macvtap"));
> +return -1;
>  }
>  }
>  }
> @@ -852,7 +856,7 @@ int virNetDevMacVLanCreateWithVPortProfile(const char
> *tgifname,
>  if (virNetDevMacVLanTapOpen(cr_ifname, , 1, 10) < 0)
>  goto disassociate_exit;
>  
> -if 

Re: [Xen-devel] [PATCHv4 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[David Vrabel]

On 14/12/15 14:52, Andrew Cooper wrote:
> On 14/12/15 14:39, David Vrabel wrote:
>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
>> index eef0372..6e0cf89 100644
>> --- a/xen/arch/x86/mm/p2m-ept.c
>> +++ b/xen/arch/x86/mm/p2m-ept.c
[...]
>> +on_selected_cpus(d->domain_dirty_cpumask,
>>   __ept_sync_domain, p2m, 1);
> 
> You can drop __ept_sync_domain() entirely by using
> smp_send_event_check_mask() instead, which is a no-op IPI (and slightly
> less overhead while holding the IPI lock).

We need to wait until the IPI has been handled on the remote PCPUs since
we may immediately free a page table page.  If a VCPU was still running
it may use paging-structure-cache entries referring to that freed page.

>> -cpumask_var_t synced_mask;
>> +cpumask_var_t invalidate;
> 
> Could you include a small comment here to describe the behaviour?  Perhaps:
> 
> /* Whether an INVEPT should be issued on VMENTER? */

Good point.

David

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

[Xen-devel] [PATCH] squash into 'build: convert HAS_VGA use to Kconfig'

[Doug Goldstein]

Signed-off-by: Doug Goldstein 
---
 xen/arch/x86/Kconfig  | 1 -
 xen/drivers/video/Kconfig | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index b03d228..a42c149 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -9,7 +9,6 @@ config X86
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_VGA
-   select HAS_VIDEO
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 6a7cafc..2b553d9 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -5,4 +5,5 @@ config HAS_VIDEO
 
 # Select HAS_VGA if VGA is supported
 config HAS_VGA
-   bool
+   bool
+   select HAS_VIDEO
-- 
2.4.10


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

Re: [Xen-devel] [PATCHv4 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[Andrew Cooper]

On 14/12/15 15:00, David Vrabel wrote:
> On 14/12/15 14:52, Andrew Cooper wrote:
>> On 14/12/15 14:39, David Vrabel wrote:
>>> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
>>> index eef0372..6e0cf89 100644
>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>> +++ b/xen/arch/x86/mm/p2m-ept.c
> [...]
>>> +on_selected_cpus(d->domain_dirty_cpumask,
>>>   __ept_sync_domain, p2m, 1);
>> You can drop __ept_sync_domain() entirely by using
>> smp_send_event_check_mask() instead, which is a no-op IPI (and slightly
>> less overhead while holding the IPI lock).
> We need to wait until the IPI has been handled on the remote PCPUs since
> we may immediately free a page table page.  If a VCPU was still running
> it may use paging-structure-cache entries referring to that freed page.

Ah yes.  Better not do that.

As some future cleanup it would be nice to be able to do this without
specifying a function, but that is a minor detail and not relevant to
this patch.

~Andrew

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

Re: [Xen-devel] [PATCHv4 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[George Dunlap]

On 14/12/15 15:09, Andrew Cooper wrote:
> On 14/12/15 15:00, David Vrabel wrote:
>> On 14/12/15 14:52, Andrew Cooper wrote:
>>> On 14/12/15 14:39, David Vrabel wrote:
 diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
 index eef0372..6e0cf89 100644
 --- a/xen/arch/x86/mm/p2m-ept.c
 +++ b/xen/arch/x86/mm/p2m-ept.c
>> [...]
 +on_selected_cpus(d->domain_dirty_cpumask,
   __ept_sync_domain, p2m, 1);
>>> You can drop __ept_sync_domain() entirely by using
>>> smp_send_event_check_mask() instead, which is a no-op IPI (and slightly
>>> less overhead while holding the IPI lock).
>> We need to wait until the IPI has been handled on the remote PCPUs since
>> we may immediately free a page table page.  If a VCPU was still running
>> it may use paging-structure-cache entries referring to that freed page.
> 
> Ah yes.  Better not do that.
> 
> As some future cleanup it would be nice to be able to do this without
> specifying a function, but that is a minor detail and not relevant to
> this patch.

This is exactly the conclusion I came to when reviewing v3 of this
series.  Actually calling __ept_sync_domain() is unnecessary, but at
that point you might as well.

 -George

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

Re: [Xen-devel] [PATCH RFC v2 4/4] xen/MSI: re-expose masking capability

[Jan Beulich]

>>> On 11.12.15 at 17:56,  wrote:
> For the original issue here, could the flag be exposed as a
> XEN_SYSCTL_PHYSCAP_

Yes, I think it could, albeit calling this a "capability" or "feature"
seems odd (since really the original behavior was bogus/buggy).
But - with sysctl not being a stable interface, is making qemu use
this actually a good idea? I.e. won't we paint ourselves into the
corner of needing to write compatibility wrappers in qemu
whenever XEN_SYSCTL_physinfo (or its libxc wrapper) changes?

Jan


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

Re: [Xen-devel] [PATCH] xen-pciback: fix up cleanup path when alloc fails

[David Vrabel]

On 02/12/15 14:56, Doug Goldstein wrote:
> On 12/2/15 4:35 AM, David Vrabel wrote:
>> On 26/11/15 20:32, Doug Goldstein wrote:
>>> When allocating a pciback device fails, avoid the possibility of a
>>> use after free.
>>
>> We should not require clearing drvdata for correctness.  We should
>> ensure we retain drvdata for as long as it is needed.
>>
>> I note that pcistub_device_release() has:
>>
>>  kfree(dev_data);
>>  pci_set_drvdata(dev, NULL);
>>
>>  /* Clean-up the device */
>>  xen_pcibk_config_free_dyn_fields(dev);
>>  xen_pcibk_config_free_dev(dev);
>>
>> Which should (at a minimum) be reordered to move the kfree(dev_data) to
>> after the calls that require it
>>
>> David
>>
> 
> I apologize but at this point I'm confused at what action I should be
> taking. Are you saying NACK to the original patch and suggesting this as
> the replacement? Or saying that this should be done in addition to the
> original patch?

I'm suggesting that the goal should be to remove all
pci_set_drvdata(dev, NULL) calls and have pciback work correctly without
them.

Konrad's the pciback maintainer though so I'll defer to him on this.

David

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

Re: [Xen-devel] [PATCH] hvmloader: Load proper ACPI tables with OVMF

[Andrew Cooper]

On 14/12/15 16:17, Ian Campbell wrote:
> On Mon, 2015-12-14 at 16:08 +, Anthony PERARD wrote:
>> This patch loads the ACPI tables associated with QEMU instead of the one
>> for qemu-traditional.
> I'd add "... we only support OVMF with qemu-xen" or something, just to make
> it clear why this is correct.

Seconded.

>
>> Signed-off-by: Anthony PERARD 
> Acked-by: Ian Campbell 

With that fixed, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

[Boris Ostrovsky]

On 12/14/2015 10:35 AM, Roger Pau Monné wrote:

El 14/12/15 a les 16.27, Konrad Rzeszutek Wilk ha escrit:

On Sat, Dec 12, 2015 at 07:25:55PM -0500, Boris Ostrovsky wrote:

Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
will likely perform same IPIs as would have the guest.


But if the VCPU is asleep, doing it via the hypervisor will save us waking
up the guest VCPU, sending an IPI - just to do an TLB flush
of that CPU. Which is pointless as the CPU hadn't been running the
guest in the first place.


OK, I then mis-read the hypervisor code, I didn't realize that 
vcpumask_to_pcpumask() takes into account vcpu_dirty_cpumask.






More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
guest's address on remote CPU (when, for example, VCPU from another
guest
is running there).

Right, so the hypervisor won't even send an IPI there.

But if you do it via the normal guest IPI mechanism (which are opaque
to the hypervisor) you and up scheduling the guest VCPU to do
send an hypervisor callback. And the callback will go the IPI routine
which will do an TLB flush. Not necessary.

This is all in case of oversubscription of course. In the case where
we are fine on vCPU resources it does not matter.

Perhaps if we have PV aware TLB flush it could do this differently?

Why don't HVM/PVH just uses the HVMOP_flush_tlbs hypercall?


It doesn't take any parameters so it will invalidate TLBs for all VCPUs, 
which is more than is being asked for. Especially in the case of 
MMUEXT_INVLPG_MULTI.


(That's in addition to the fact that it currently doesn't work for PVH 
as it has a test for is_hvm_domain() instead of has_hvm_container_domain()).


-boris

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

Re: [Xen-devel] [PATCH] hvmloader: Load proper ACPI tables with OVMF

[Ian Campbell]

On Mon, 2015-12-14 at 16:08 +, Anthony PERARD wrote:
> This patch loads the ACPI tables associated with QEMU instead of the one
> for qemu-traditional.

I'd add "... we only support OVMF with qemu-xen" or something, just to make
it clear why this is correct.

> Signed-off-by: Anthony PERARD 

Acked-by: Ian Campbell 

> ---
>  tools/firmware/hvmloader/ovmf.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/firmware/hvmloader/ovmf.c
> b/tools/firmware/hvmloader/ovmf.c
> index bb3da93..db9fa7a 100644
> --- a/tools/firmware/hvmloader/ovmf.c
> +++ b/tools/firmware/hvmloader/ovmf.c
> @@ -47,8 +47,8 @@
>  #define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
>  #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
>  
> -extern unsigned char dsdt_anycpu[];
> -extern int dsdt_anycpu_len;
> +extern unsigned char dsdt_anycpu_qemu_xen[];
> +extern int dsdt_anycpu_qemu_xen_len;
>  
>  #define OVMF_INFO_MAX_TABLES 4
>  struct ovmf_info {
> @@ -119,8 +119,8 @@ static void ovmf_load(const struct bios_config
> *config)
>  static void ovmf_acpi_build_tables(void)
>  {
>  struct acpi_config config = {
> -.dsdt_anycpu = dsdt_anycpu,
> -.dsdt_anycpu_len = dsdt_anycpu_len,
> +.dsdt_anycpu = dsdt_anycpu_qemu_xen,
> +.dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
>  .dsdt_15cpu = NULL, 
>  .dsdt_15cpu_len = 0
>  };

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

Re: [Xen-devel] [PATCHv4] xen/gntdev: add ioctl for grant copy

[Boris Ostrovsky]

On 12/14/2015 09:21 AM, David Vrabel wrote:

On 01/12/15 16:43, David Vrabel wrote:

Add IOCTL_GNTDEV_GRANT_COPY to allow applications to copy between user
space buffers and grant references.

This interface is similar to the GNTTABOP_copy hypercall ABI except
the local buffers are provided using a virtual address (instead of a
GFN and offset).  To avoid userspace from having to page align its
buffers the driver will use two or more ops if required.

If the ioctl returns 0, the application must check the status of each
segment with the segments status field.  If the ioctl returns a -ve
error code (EINVAL or EFAULT), the status of individual ops is
undefined.

Konrad, Boris,  any comments?


Reviewed-by: Boris Ostrovsky 

(You could use xen_offset_in_page(), which I didn't know existed)

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

[Xen-devel] [PATCH] squash into 'build: convert HAS_PCI use to Kconfig'

[Doug Goldstein]

Signed-off-by: Doug Goldstein 
---
 xen/include/xen/iommu.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 47f3180..8217cb7 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -107,7 +107,7 @@ int iommu_update_ire_from_msi(struct msi_desc *msi_desc, 
struct msi_msg *msg);
 void iommu_read_msi_from_ire(struct msi_desc *msi_desc, struct msi_msg *msg);
 
 #define PT_IRQ_TIME_OUT MILLISECS(8)
-#endif /* CONFIG_HAS_PCI */
+#endif /* HAS_PCI */
 
 #ifdef CONFIG_HAS_DEVICE_TREE
 #include 
@@ -145,7 +145,7 @@ struct iommu_ops {
 int (*get_device_group_id)(u16 seg, u8 bus, u8 devfn);
 int (*update_ire_from_msi)(struct msi_desc *msi_desc, struct msi_msg *msg);
 void (*read_msi_from_ire)(struct msi_desc *msi_desc, struct msi_msg *msg);
-#endif /* CONFIG_HAS_PCI */
+#endif /* HAS_PCI */
 
 void (*teardown)(struct domain *d);
 int (*map_page)(struct domain *d, unsigned long gfn, unsigned long mfn,
-- 
2.4.10


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

Re: [Xen-devel] [PATCH] xen/tools/get-fields.sh: Use printf for POSIX compat

[Alex Xu]

On Mon, 14 Dec 2015 02:12:16 -0700
"Jan Beulich"  wrote:

> >>> On 12.12.15 at 19:18,  wrote:  
> > xen/tools/get-fields.sh used echo -n which is not POSIX compatible
> > and breaks with dash. Change it to use printf "%s" which is usable
> > everywhere.  
> 
> Looks okay, but a couple of remarks:
> - For the unaware as well as to know why to take care going forward,
>   it would be nice if the commit message mentioned where actually you
>   saw this to be an issue.

I already said that it doesn't work with dash. I can insert the word
"building" if you want.

> - There appears to be quite a bit of unnecessary quoting (namely on
>   all the "%s" instances), making lines longer than they need to be
>   (and hence possible harder to read).

Habit from C.

> In fact, since field names
> can't contain %, \, or other characters with special meaning to
> printf it looks as if the use of %s is superfluous altogether.

Again, habit from C, but here I think it is useful to use %s for
several reasons.

1. works exactly the same way as before
1a. no need to exhaustively check every case to see if % or \ ever gets
in
2. less likely to cause issues if someone copies and pastes the code or
   the calls change later on

> - Please Cc all relevant maintainers, not just Keir.

OK, I looked at MAINTAINERS but I only found "THE REST" and Keir was
the only one who had touched get-fields.sh semi-recently.

> 
> Jan
> 

Thank you for the feedback. I will rewrite the commit message and send
again to everyone.

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

[Xen-devel] [PATCH] hvmloader: Load proper ACPI tables with OVMF

[Anthony PERARD]

This patch loads the ACPI tables associated with QEMU instead of the one
for qemu-traditional.

Signed-off-by: Anthony PERARD 
---
 tools/firmware/hvmloader/ovmf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index bb3da93..db9fa7a 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -47,8 +47,8 @@
 #define LOWCHUNK_END(OVMF_BEGIN + OVMF_SIZE)
 #define OVMF_INFO_PHYSICAL_ADDRESS 0x1000
 
-extern unsigned char dsdt_anycpu[];
-extern int dsdt_anycpu_len;
+extern unsigned char dsdt_anycpu_qemu_xen[];
+extern int dsdt_anycpu_qemu_xen_len;
 
 #define OVMF_INFO_MAX_TABLES 4
 struct ovmf_info {
@@ -119,8 +119,8 @@ static void ovmf_load(const struct bios_config *config)
 static void ovmf_acpi_build_tables(void)
 {
 struct acpi_config config = {
-.dsdt_anycpu = dsdt_anycpu,
-.dsdt_anycpu_len = dsdt_anycpu_len,
+.dsdt_anycpu = dsdt_anycpu_qemu_xen,
+.dsdt_anycpu_len = dsdt_anycpu_qemu_xen_len,
 .dsdt_15cpu = NULL, 
 .dsdt_15cpu_len = 0
 };
-- 
Anthony PERARD


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

[Xen-devel] [PATCH] squash into 'build: convert HAS_EHCI use to Kconfig'

[Doug Goldstein]

Signed-off-by: Doug Goldstein 
---
 xen/drivers/char/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 36a742b..08973cf 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -53,7 +53,6 @@ config HAS_SCIF
 # USB EHCI debug port support
 config HAS_EHCI
bool
-   depends on X86
help
  This selects the USB based EHCI debug port to be used as a UART. If
  you have an x86 based system with USB, say Y.
-- 
2.4.10


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

Re: [Xen-devel] [PATCH] xen/tools/get-fields.sh: Use printf for POSIX compat

[Jan Beulich]

>>> On 14.12.15 at 16:56,  wrote:
> On Mon, 14 Dec 2015 02:12:16 -0700
> "Jan Beulich"  wrote:
> 
>> >>> On 12.12.15 at 19:18,  wrote:  
>> > xen/tools/get-fields.sh used echo -n which is not POSIX compatible
>> > and breaks with dash. Change it to use printf "%s" which is usable
>> > everywhere.  
>> 
>> Looks okay, but a couple of remarks:
>> - For the unaware as well as to know why to take care going forward,
>>   it would be nice if the commit message mentioned where actually you
>>   saw this to be an issue.
> 
> I already said that it doesn't work with dash. I can insert the word
> "building" if you want.

Oh, I'm sorry, I didn't take "dash" as a shell name (and have been
wondering what you mean with that sentence (taking the word as
just what ir normally means).

>> - There appears to be quite a bit of unnecessary quoting (namely on
>>   all the "%s" instances), making lines longer than they need to be
>>   (and hence possible harder to read).
> 
> Habit from C.
> 
>> In fact, since field names
>> can't contain %, \, or other characters with special meaning to
>> printf it looks as if the use of %s is superfluous altogether.
> 
> Again, habit from C, but here I think it is useful to use %s for
> several reasons.
> 
> 1. works exactly the same way as before
> 1a. no need to exhaustively check every case to see if % or \ ever gets
> in
> 2. less likely to cause issues if someone copies and pastes the code or
>the calls change later on

Well, in general I would agree, but in this particular case I wonder
whether the shorter resulting lines aren't outweighing the benefits
you name.

>> - Please Cc all relevant maintainers, not just Keir.
> 
> OK, I looked at MAINTAINERS but I only found "THE REST" and Keir was
> the only one who had touched get-fields.sh semi-recently.

But THE REST is it in this case.

Jan


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

[Xen-devel] Pre-domain released event?

[Razvan Cojocaru]

Hello,

Currently, all the in-tree examples that figure out that a domain has
been shut down subscribe to xenstore's @releaseDomain combined with an
xs_is_domain_introduced() check. That works fine if you're only
interested that the domain no longer exists. However, I'd like to be
able to do some cleanup before a domain is suspended (on taking a
snapshot, for example).

There are various degrees of tolerability doing this if I subscribe to
various xenstore paths that disappear before @releaseDomain gets fired,
and before the guest disappears, but it looks like it's not always
foolproof.

I've previously asked the question in a somewhat more convoluted manner
here: http://lists.xen.org/archives/html/xen-devel/2015-08/msg00735.html

I'm still interested in what the best solution would be here. A new,
blocking vm_event, that fires from the hypervisor immediately after it's
decided that the guest will be shutdown is what comes to mind, but I'm
not sure where the best place to put it would be. Or indeed if there
another / better way to do this.


Thanks,
Razvan

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

[Xen-devel] [PATCH] xen: arm: Drop trailing ; from DEFINE_XEN_GUEST_HANDLE

[Ian Campbell]

This is always present at the point of use, which with -pedantic
provokes:

error: ISO C does not allow extra ';' outside of a function [-Werror=edantic]

Signed-off-by: Ian Campbell 
---
 xen/include/public/arch-arm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 6322548..870bc3b 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -173,7 +173,7 @@
 typedef union { type *p; unsigned long q; } \
 __guest_handle_ ## name;\
 typedef union { type *p; uint64_aligned_t q; }  \
-__guest_handle_64_ ## name;
+__guest_handle_64_ ## name
 
 /*
  * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
-- 
2.1.4


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

[Xen-devel] [linux-3.14 test] 66306: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3865 xen-build fail REGR. vs. 64562

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64562
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 64562
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 64562
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 64562

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-i386-rumpuserxen1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 linux5d7b0fcc26d66db767a477574effc764022c19ac
baseline version:
 linux769b79eb206ad5b0249a08665fefb913c3d1998e

Last test of basis64562  2015-11-17 09:53:45 Z   27 days
Testing same since65633  2015-12-09 19:33:10 Z5 days4 attempts


People who touched revisions under test:
  Aleksander Morgado 
  Amitkumar Karwar 
  Andrew Cooper 
  Ani Sinha 
  Bjørn Mork 
  Borislav Petkov 
  Carol L Soto 
  Catalin Marinas 
  Clemens Ladisch 
  Dan Carpenter 
  David Herrmann 
  David S. Miller 
  David Woodhouse 
  David Woodhouse 
  Dmitry Tunin 
  Eric Dumazet 
  Felipe Balbi 
  Florian Fainelli 
  Francesco Ruggeri 
  Francesco Ruggeri 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  Guillaume Nault 
  Jack Morgenstein 
  Jason Wang 
  Jiri Slaby 
  Johan Hovold 
  Johannes Berg 
  Kalle Valo 
  Krzysztof Mazur 
  Larry Finger 
  Marc Kleine-Budde 
  Marcel Holtmann 

Re: [Xen-devel] [PATCH] x86/time: Don't use EFI's GetTime call by default

[Jan Beulich]

>>> On 08.12.15 at 12:02,  wrote:
> On Wed, 2015-12-02 at 02:33 -0700, Jan Beulich wrote:
>> Then we should see about adding support for "efi=no-time".
> 
> And based on what I'm reading in this thread about the reliability of the
> time RS in the field it seems to me we should make it the default (on x86
> at least) and provide efi=time to opt in.

Which would get us to actively violate at least early versions of the
spec (the current one doesn't appear to be as strict anymore). I'm
fine making it easy to work around the issue, but I'm against us doing
the wrong thing by default.

Apart from that, Ross, the patch you provided breaks on systems
without CMOS clock (e.g. so called legacy free ones). This definitely
can't be a compile time thing.

Jan


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

Re: [Xen-devel] [PATCH v11 1/09] xen/x86: set the vPMU interface based on the presence of a lapic

[Tian, Kevin]

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, December 11, 2015 6:17 PM
> 
> Instead of choosing the interface to expose to guests based on the guest
> type, do it based on whether the guest has an emulated local apic or not.
> 
> Signed-off-by: Roger Pau Monné 
> Signed-off-by: Boris Ostrovsky 
> Acked-by: Jan Beulich 

Acked-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 05/11] xen: Set IORESOURCE_SYSTEM_RAM to System RAM

[Toshi Kani]

Set IORESOURCE_SYSTEM_RAM to the flags of memory hotplug resource
ranges with "System RAM".

Cc: Konrad Rzeszutek Wilk 
Cc: xen-de...@lists.xenproject.org
Signed-off-by: Toshi Kani 
---
 drivers/xen/balloon.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 12eab50..dc4305b 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -257,7 +257,7 @@ static struct resource 
*additional_memory_resource(phys_addr_t size)
return NULL;
 
res->name = "System RAM";
-   res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   res->flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
 
ret = allocate_resource(_resource, res,
size, 0, -1,

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

[Xen-devel] [PATCH V11 3/5] libxl: add pvusb API

[Chunyan Liu]

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 

---
changes:
* format fix: extra white space, line > 80, etc.
* return ERROR_FAILED instead of errno (>0) in sysfs_write_intf
* fix an error in libxl_ctrlport_to_device_usbdev
* extract a helper function for alloc_dirent

 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  |   34 +-
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |   13 +-
 tools/libxl/libxl_internal.h |   22 +-
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1548 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1766 insertions(+), 13 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6ff5bee..a36145a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e10242d..2e4e1c3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3201,7 +3201,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4154,8 +4154,10 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4175,13 +4177,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4205,6 +4213,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4218,6 +4230,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * libxl_device_nic_add
  * libxl_device_vtpm_add
+ * libxl_device_usbctrl_add
+ * libxl_device_usbdev_add
  */
 
 #define DEFINE_DEVICE_ADD(type) \
@@ -4249,6 +4263,12 @@ DEFINE_DEVICE_ADD(nic)
 /* vtpm */
 DEFINE_DEVICE_ADD(vtpm)
 
+/* usbctrl */
+DEFINE_DEVICE_ADD(usbctrl)
+
+/* usb */
+DEFINE_DEVICE_ADD(usbdev)
+
 #undef DEFINE_DEVICE_ADD
 
 

[Xen-devel] [PATCH V11 2/5] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 77 
 2 files changed, 81 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index beaef3f..6b873c7 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4026,6 +4026,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e42422a..7f612a6 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,83 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+if (!data) goto xe;
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+if (!data)
+goto xe;
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH V11 5/5] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.cfg.pod.5| 84 
 tools/libxl/libxl_create.c   | 73 --
 tools/libxl/libxl_device.c   |  4 +++
 tools/libxl/libxl_internal.h |  8 +
 tools/libxl/xl_cmdimpl.c | 55 -
 5 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 3b695bd..db5a443 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

[Xen-devel] [PATCH V11 1/5] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 712ea5a..e10242d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2033,7 +2033,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -2052,8 +2052,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 622c0f9..beaef3f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1167,6 +1167,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH V11 4/5] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.pod.1 |  41 
 tools/libxl/xl.h  |   5 +
 tools/libxl/xl_cmdimpl.c  | 243 ++
 tools/libxl/xl_cmdtable.c |  25 +
 4 files changed, 314 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..746f49f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,47 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I 

[Xen-devel] [PATCH V11 0/5] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V10:
* some changes in libxl pvusb API (patch 3/7)

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['1.6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['1.6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usb-ctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usb-attach domain 1.6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status of the domain by usb-list.
e.g.
xl usb-list domain
It will list USB controllers and USB devices under each controller.

You could detach a USB device with usb-detach command.
e.g.
xl usb-detach domain 1.6

You can also remove the whole USB controller by usb-ctrl-detach
command.
e.g.
xl usb-ctrl-detach domain 0
It will remove the USB controller with index 0 and all USB devices
under it.

4. PVUSB Libxl implementation

* 

Re: [Xen-devel] [PATCH v7 03/28] build: build Kconfig and config rules

[Jan Beulich]

>>> On 14.12.15 at 18:52,  wrote:
> On 12/14/15 10:35 AM, Jan Beulich wrote:
> On 10.12.15 at 17:48,  wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -0,0 +1,17 @@
>>> +config X86_64
>>> +   def_bool y
>>> +
>>> +config X86
>>> +   def_bool y
>>> +
>>> +config ARCH_DEFCONFIG
>>> +   string
>>> +   default "arch/x86/configs/x86_64_defconfig"
>>> +
>>> +menu "Architecture Features"
>>> +
>>> +endmenu
>>> +
>>> +source "common/Kconfig"
>>> +
>>> +source "drivers/Kconfig"
>> 
>> I'm still missing "config 64BIT" in this file.
> 
> You had wanted me to factor that out in earlier series. So now its only
> in the arm side which is the only place its used.

>From what I recall, I've always been asking to make this a general
setting, not an ARM specific one (irrespective of it only being used
in ARM right now).

>>> +# provide the host compiler
>>> +HOSTCC := gcc
>>> +HOSTCXX := g++
>> 
>> Didn't you mean to inherit these instead of forcing them here?
> 
> No. I pointed out that the only real way to inherit them is to pull in
> top-level Config.mk which is too heavy handed. If we have some agreement
> to break up the pieces that truly belong in there then sure.
> 
> Honestly I would prefer to do that break up after the fact. I've being
> working on this series for 3 months now and a lot of the issues brought
> up can happen after the fact because, like this one, it involves fixing
> up existing Xen makefiles rather than issues with this series.

That's fine as long as it doesn't get forgotten.

Jan


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

[Xen-devel] [linux-3.10 bisection] complete test-amd64-i386-rumpuserxen-i386

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-rumpuserxen-i386
testid guest-start

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  81a76e4b12961a9f54f5021809074196dfe6dbba
  Bug not present: cd353959cdfbe06c2a6abfd73f03f40b84e1e3f1
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/66373/


  commit 81a76e4b12961a9f54f5021809074196dfe6dbba
  Author: Juergen Gross 
  Date:   Thu Nov 12 14:43:35 2015 +0100
  
  libxc: rework of domain builder's page table handler
  
  In order to prepare a p2m list outside of the initial kernel mapping
  do a rework of the domain builder's page table handler. The goal is
  to be able to use common helpers for page table allocation and setup
  for initial kernel page tables and page tables mapping the p2m list.
  This is achieved by supporting multiple mapping areas. The mapped
  virtual addresses of the single areas must not overlap, while the
  page tables of a new area added might already be partially present.
  Especially the top level page table is existing only once, of course.
  
  Currently restrict the number of mappings to 1 because the only mapping
  now is the initial mapping created by toolstack. There should not be
  behaviour change and guest visible change introduced.
  
  Signed-off-by: Juergen Gross 
  Reviewed-by: Wei Liu 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.10/test-amd64-i386-rumpuserxen-i386.guest-start
 --summary-out=tmp/66373.bisection-summary --basis-template=64456 
--blessings=real,real-bisect linux-3.10 test-amd64-i386-rumpuserxen-i386 
guest-start
Searching for failure / basis pass:
 65778 fail [host=baroque0] / 64456 ok.
Failure / basis pass flights: 65778 / 64456
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git
Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git
Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd
Tree: xen git://xenbits.xen.org/xen.git
Latest 03ed106ff4c200d01f3c72f71fa9c5b18da07d9b 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
91c15bfaec1764ce2896a393eabee1183afe1130 
f6787aedc9043bffc5ee5b64c6d46b8fc7298a96 
30d72f3fc5e35cd53afd82c8179cc0e0b11146ad 
47b1a5eef43cce61bf018500bddf751ecf9de38e 
17a547ca2943a7d98780a0366966c3aef29093a6 
a841b1b1286d122fd472b43db3c423b9876262e5
Basis pass bdf8cfb859e9cd265ec1696d9e007fac66e7aea7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
816609b2841297925a223ec377c336360e044ee5 
30d72f3fc5e35cd53afd82c8179cc0e0b11146ad 
47b1a5eef43cce61bf018500bddf751ecf9de38e 
17a547ca2943a7d98780a0366966c3aef29093a6 
22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#bdf8cfb859e9cd265ec1696d9e007fac66e7aea7-03ed106ff4c200d01f3c72f71fa9c5b18da07d9b
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-91c15bfaec1764ce2896a393eabee1183afe1130
 
git://xenbits.xen.org/qemu-xen.git#816609b2841297925a223ec377c336360e044ee5-f6787aedc9043bffc5ee5b64c6d46b8fc7298a96
 
git://xenbits.xen.org/rumpuser-xen.git#30d72f3fc5e35cd53afd82c8179cc0e0b11146ad-30d72f3fc5e35cd53afd82c8179cc0e0b11146ad
 
https://github.com/rumpkernel/buildrump.sh.git#47b1a5eef43cce61bf018500bddf751ecf9de38e-47b1a5eef43cce61bf018500bddf751ecf9de38e
 
https://github.com/rumpkernel/src-netbsd#17a547ca2943a7d98780a0366966c3aef29093a6-17a547ca2943a7d98780a0366966c3aef29093a6
 git://xenbits.xen.org/xen.git#22a1fbb575df
 

[Xen-devel] [PATCH 00/11] Support System RAM resource type and EINJ to NVDIMM

[Toshi Kani]

This patch-set introduces a new I/O resource type, IORESOURCE_SYSTEM_RAM,
for System RAM while keeping the current IORESOURCE_MEM type bit set for
all memory-mapped ranges (including System RAM) for backward compatibility.
With the new System RAM type, walking through the iomem resource table
no longer requires to test with strcmp() against "System RAM".  After this
infrastructure update, this patch changes EINJ to support NVDIMM.

Patches 1-2 add a new System RAM type, and make resource interfaces work
with resource flags with modifier bits set.

Patches 3-7 set the System RAM type to System RAM ranges.

Patches 8-10 extend resource interfaces to check System RAM ranges with
the System RAM type.

Patch 11 changes the EINJ driver to allow injecting a memory error to
NVDIMM.

---
v1:
 - Searching for System RAM in the resource table should not require
   strcmp(). (Borislav Petkov)
 - Add a new System RAM type as a modifier to IORESOURCE_MEM.
   (Linus Torvalds)
 - NVDIMM check should remain with strcmp() against "Persistent Memory".
   (Dan Williams)
 - Reset patch version.

prev-v3:
 - Check the param2 value before target memory type. (Tony Luck)
 - Add a blank line before if-statement. Remove an unnecessary brakets.
   (Borislav Petkov)

prev-v2:
 - Change the EINJ driver to call region_intersects_ram() for checking
   RAM with a specified size. (Dan Williams)

---
Toshi Kani (11):
 01/11 resource: Add System RAM resource type
 02/11 resource: make resource flags handled properly
 03/11 x86/e820: Set IORESOURCE_SYSTEM_RAM to System RAM
 04/11 arch: Set IORESOURCE_SYSTEM_RAM to System RAM
 05/11 xen: Set IORESOURCE_SYSTEM_RAM to System RAM
 06/11 kexec: Set IORESOURCE_SYSTEM_RAM to System RAM
 07/11 memory-hotplug: Set IORESOURCE_SYSTEM_RAM to System RAM
 08/11 memremap: Change region_intersects() to use System RAM type
 09/11 resource: Change walk_system_ram to use System RAM type
 10/11 arm/samsung: Change s3c_pm_run_res() to use System RAM type
 11/11 ACPI/EINJ: Allow memory error injection to NVDIMM

---
 arch/arm/kernel/setup.c  |  6 ++---
 arch/arm/plat-samsung/pm-check.c |  4 +--
 arch/arm64/kernel/setup.c|  6 ++---
 arch/avr32/kernel/setup.c|  6 ++---
 arch/ia64/kernel/efi.c   |  6 +++--
 arch/ia64/kernel/setup.c |  6 ++---
 arch/m32r/kernel/setup.c |  4 +--
 arch/mips/kernel/setup.c | 10 +---
 arch/parisc/mm/init.c|  6 ++---
 arch/powerpc/mm/mem.c|  2 +-
 arch/s390/kernel/setup.c |  8 +++---
 arch/score/kernel/setup.c|  2 +-
 arch/sh/kernel/setup.c   |  8 +++---
 arch/sparc/mm/init_64.c  |  8 +++---
 arch/tile/kernel/setup.c | 11 +---
 arch/unicore32/kernel/setup.c|  6 ++---
 arch/x86/kernel/e820.c   | 18 +-
 arch/x86/kernel/setup.c  |  6 ++---
 drivers/acpi/apei/einj.c | 15 ---
 drivers/xen/balloon.c|  2 +-
 include/linux/ioport.h   | 11 
 include/linux/mm.h   |  3 ++-
 kernel/kexec_core.c  |  6 ++---
 kernel/kexec_file.c  |  2 +-
 kernel/memremap.c| 13 +-
 kernel/resource.c| 54 +---
 mm/memory_hotplug.c  |  2 +-
 27 files changed, 140 insertions(+), 91 deletions(-)

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

Re: [Xen-devel] [libvirt test] 65654: regressions - FAIL

[Jim Fehlig]

On 12/14/2015 03:41 AM, Stefano Stabellini wrote:
> On Fri, 11 Dec 2015, Ian Jackson wrote:
>> Ian Campbell writes ("Re: [libvirt test] 65654: regressions - FAIL"):
>>> On Fri, 2015-12-11 at 15:18 +, osstest service owner wrote:
 flight 65654 libvirt real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/65654/

 Regressions :-(

 Tests which did not succeed and are blocking,
 including tests which could not be run:
  test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 
 63340
>>> Stefano has posted a fix for this to qemu-upstream but it isn't going to
>>> make the QEMU 2.5.0 release:
>>> http://lists.xen.org/archives/html/xen-devel/2015-12/msg01435.html
>>> and given the freeze for that it is going to be a while before it is
>>> accepted.
>>>
>>> I don't really see that point in blocking the libvirt push gate over this
>>> issue, so I would suggest a force push.
>> I have no objection, if Jim and Stefano are happy with that.
> That's OK for me

No objections from me either.

Regards,
Jim


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

Re: [Xen-devel] [PATCH XEN v6 10/32] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.

[Ian Campbell]

On Thu, 2015-12-03 at 11:22 +, Ian Campbell wrote:
> [...]
> +void *xengnttab_map_grant_ref(xengnttab_handle *xgt,
> +  uint32_t domid,
> +  uint32_t ref,
> +  int prot);
> [...]
> +int xengnttab_munmap(xengnttab_handle *xgt,
> + void *start_address,
> + uint32_t count);

The use of munmap here is a bit inconsistent, it's not xengnttab_mmap and
xenforeignmemory is just unmap, so I think I'll change this
s/munmap/unmap/.

> [...]
> +void *xengntshr_share_pages(xengntshr_handle *xgs, uint32_t domid,
> +int count, uint32_t *refs, int writable);
> +
> [...]
> +int xengntshr_munmap(xengntshr_handle *xgs, void *start_address, uint32_t 
> count);

For this one I think unshare would be a better name as a counterpart to
xengntshr_share_*.

I don't think these changes should invalidate any existing review/ack, but
I thought I would mention it up front.

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

Re: [Xen-devel] [PATCH v7 23/28] build: convert HAS_EHCI use to Kconfig

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> +# USB EHCI debug port support
> +config HAS_EHCI
> + bool
> + depends on X86

As said before, dependencies on prompt-less options are bogus
and potentially confusing (and really wrong here - there's nothing
precluding ARM to also use that code as soon as they gain PCI
support). With you adding a forward and reverse dependency I'm
surprised you don't actually get a warning from kconfig.

If anything, a dependency on PCI might be considered here
(albeit I'd suggest against it for aforementioned reason).

Jan


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

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

[Boris Ostrovsky]

On 12/14/2015 08:58 AM, David Vrabel wrote:

On 13/12/15 00:25, Boris Ostrovsky wrote:

Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
will likely perform same IPIs as would have the guest.

More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
guest's address on remote CPU (when, for example, VCPU from another guest
is running there).

Signed-off-by: Boris Ostrovsky 
Suggested-by: Jan Beulich 
Cc: sta...@vger.kernel.org # 3.14+

Applied to for-linus-4.4, thanks.  But given that PVH is experimental
I've dropped the stable Cc.


The reason I want this to go to stable is that I will be removing access 
to MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to PVH guests in the 
hypervisor (as part of merging HVM and PVH hypercall tables) and that 
will result in essentially unbootable PVH guests due to warnings flood.


-boris

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

[Xen-devel] [PATCHv4 0/2] x86/ept: reduce translation invalidation impact

[David Vrabel]

This series improves the performance of EPT by further reducing the
impact of the translation invalidations (ept_sync_domain()). By:

a) Deferring invalidations until the p2m write lock is released.

Prior to this change a 16 VCPU guest could not be successfully
migrated on an (admittedly slow) 160 PCPU box because the p2m write
lock was held for such extended periods of time.  This starved the
read lock needed (by the toolstack) to map the domain's memory,
triggering the watchdog.

After this change a 64 VCPU guest could be successfully migrated.

ept_sync_domain() is very expensive because:

a) it uses on_selected_cpus() and the IPI cost can be particularly
   high for a multi-socket machine.

b) on_selected_cpus() is serialized by its own spin lock.

On this particular box, ept_sync_domain() could take ~3-5 ms.

Simply using a fair rw lock was not sufficient to resolve this (but it
was an improvement) as the cost of the ept_sync_domain calls() was
still delaying the read locks enough for the watchdog to trigger (the
toolstack maps a batch of 1024 GFNs at a time, which means trying to
acquire the p2m read lock 1024 times).

Changes in v4:

- __ept_sync_domain() is a no-op -- invalidates are done before VMENTER.
- initialize ept->invalidate to all ones so the initial invalidate is
  always done.

Changes in v3:

- Drop already applied "x86/ept: remove unnecessary sync after
  resolving misconfigured entries".
- Replaced "mm: don't free pages until mm locks are released" with
  "x86/ept: invalidate guest physical mappings on VMENTER".

Changes in v2:

- Use a per-p2m (not per-CPU) list for page table pages to be freed.
- Hold the write lock while updating the synced_mask.

David


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

[Xen-devel] [PATCHv4 2/2] x86/ept: defer the invalidation until the p2m lock is released

[David Vrabel]

Holding the p2m lock while calling ept_sync_domain() is very expensive
since it does a on_selected_cpus() call.  IPIs on many socket machines
can be very slows and on_selected_cpus() is serialized.

Defer the invalidate until the p2m lock is released.  Since the processor
may cache partial translations, we also need to make sure any page table
pages to be freed are not freed until the invalidate is complete.  Such
pages are temporarily stored in a list.

Signed-off-by: David Vrabel 
---
v2:
- use per-p2m list for deferred pages.
- update synced_mask while holding write lock.
---
 xen/arch/x86/mm/mm-locks.h | 23 ++
 xen/arch/x86/mm/p2m-ept.c  | 48 +-
 xen/arch/x86/mm/p2m.c  | 18 +
 xen/include/asm-x86/p2m.h  |  7 +++
 4 files changed, 79 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 76c7217..b5eb560 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -263,14 +263,21 @@ declare_mm_lock(altp2mlist)
  */
 
 declare_mm_rwlock(altp2m);
-#define p2m_lock(p) \
-{   \
-if ( p2m_is_altp2m(p) ) \
-mm_write_lock(altp2m, &(p)->lock);  \
-else\
-mm_write_lock(p2m, &(p)->lock); \
-}
-#define p2m_unlock(p) mm_write_unlock(&(p)->lock);
+#define p2m_lock(p) \
+do {\
+if ( p2m_is_altp2m(p) ) \
+mm_write_lock(altp2m, &(p)->lock);  \
+else\
+mm_write_lock(p2m, &(p)->lock); \
+(p)->defer_flush++; \
+} while (0)
+#define p2m_unlock(p)   \
+do {\
+if ( --(p)->defer_flush == 0 && (p)->need_flush )   \
+(p)->flush_and_unlock(p);   \
+else\
+mm_write_unlock(&(p)->lock);\
+} while (0)
 #define gfn_lock(p,g,o)   p2m_lock(p)
 #define gfn_unlock(p,g,o) p2m_unlock(p)
 #define p2m_read_lock(p)  mm_read_lock(p2m, &(p)->lock)
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 6e0cf89..25575a5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -263,7 +263,7 @@ static void ept_free_entry(struct p2m_domain *p2m, 
ept_entry_t *ept_entry, int l
 unmap_domain_page(epte);
 }
 
-p2m_free_ptp(p2m, mfn_to_page(ept_entry->mfn));
+p2m_free_ptp_defer(p2m, mfn_to_page(ept_entry->mfn));
 }
 
 static bool_t ept_split_super_page(struct p2m_domain *p2m,
@@ -1095,24 +1095,53 @@ static void __ept_sync_domain(void *info)
  */
 }
 
-void ept_sync_domain(struct p2m_domain *p2m)
+static void ept_sync_domain_prepare(struct p2m_domain *p2m)
 {
 struct domain *d = p2m->domain;
 struct ept_data *ept = >ept;
-/* Only if using EPT and this domain has some VCPUs to dirty. */
-if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
-return;
-
-ASSERT(local_irq_is_enabled());
 
 if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
 p2m_flush_nestedp2m(d);
 
 /* May need to invalidate on all PCPUs. */
 cpumask_setall(ept->invalidate);
+}
+
+static void ept_sync_domain_mask(struct p2m_domain *p2m, const cpumask_t *mask)
+{
+on_selected_cpus(mask, __ept_sync_domain, p2m, 1);
+}
+
+void ept_sync_domain(struct p2m_domain *p2m)
+{
+struct domain *d = p2m->domain;
+
+/* Only if using EPT and this domain has some VCPUs to dirty. */
+if ( !paging_mode_hap(d) || !d->vcpu || !d->vcpu[0] )
+return;
+
+ept_sync_domain_prepare(p2m);
+
+if ( p2m->defer_flush )
+{
+p2m->need_flush = 1;
+return;
+}
+p2m->need_flush = 0;
+
+ept_sync_domain_mask(p2m, d->domain_dirty_cpumask);
+}
+
+static void ept_flush_and_unlock(struct p2m_domain *p2m)
+{
+PAGE_LIST_HEAD(deferred_pages);
+
+page_list_move(_pages, >deferred_pages);
+
+mm_write_unlock(>lock);
 
-on_selected_cpus(d->domain_dirty_cpumask,
- __ept_sync_domain, p2m, 1);
+ept_sync_domain_mask(p2m, p2m->domain->domain_dirty_cpumask);
+p2m_free_ptp_list(p2m, _pages);
 }
 
 static void ept_enable_pml(struct p2m_domain *p2m)
@@ -1163,6 +1192,7 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->change_entry_type_range = ept_change_entry_type_range;
 p2m->memory_type_changed = ept_memory_type_changed;
 p2m->audit_p2m = NULL;
+p2m->flush_and_unlock = ept_flush_and_unlock;
 
 /* Set the memory type used when accessing EPT paging structures. */
 ept->ept_mt = 

[Xen-devel] [PATCHv4 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[David Vrabel]

If a guest allocates a page and the tlbflush_timestamp on the page
indicates that a TLB flush of the previous owner is required, only the
linear and combined mappings are invalidated.  The guest-physical
mappings are not invalidated.

This is currently safe because the EPT code ensures that the
guest-physical and combined mappings are invalidated /before/ the page
is freed.  However, this prevents us from deferring the EPT invalidate
until after the page is freed (e.g., to defer the invalidate until the
p2m locks are released).

The TLB flush that may be done after allocating page already causes
the original guest to VMEXIT, thus on VMENTER we can do an INVEPT if
one is pending.

This means __ept_sync_domain() need not do anything and the thus the
on_selected_cpu() call does not need to wait for as long.

ept_sync_domain() now marks all PCPUs as needing to be invalidated,
including PCPUs that the domain has not run on.  We still only IPI
those PCPUs that are active so this does not result in any more INVEPT
calls.

We do not attempt to track when PCPUs may have cached translations
because the only safe way to clear this per-CPU state is if
immediately after an invalidate the PCPU is not active (i.e., the PCPU
is not in d->domain_dirty_cpumask).  Since we only invalidate on
VMENTER or by IPIing active PCPUs this can never happen.

Signed-off-by: David Vrabel 
---
v4:
- __ept_sync_domain() is a no-op -- invalidates are done before VMENTER.
- initialize ept->invalidate to all ones so the initial invalidate is
  always done.
---
 xen/arch/x86/hvm/vmx/vmx.c | 22 ++
 xen/arch/x86/mm/p2m-ept.c  | 29 ++---
 xen/include/asm-x86/hvm/vmx/vmcs.h |  3 +--
 3 files changed, 25 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index f7c5e4f..cca35f2 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -744,24 +744,12 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
 
 static void vmx_ctxt_switch_to(struct vcpu *v)
 {
-struct domain *d = v->domain;
 unsigned long old_cr4 = read_cr4(), new_cr4 = mmu_cr4_features;
-struct ept_data *ept_data = _get_hostp2m(d)->ept;
 
 /* HOST_CR4 in VMCS is always mmu_cr4_features. Sync CR4 now. */
 if ( old_cr4 != new_cr4 )
 write_cr4(new_cr4);
 
-if ( paging_mode_hap(d) )
-{
-unsigned int cpu = smp_processor_id();
-/* Test-and-test-and-set this CPU in the EPT-is-synced mask. */
-if ( !cpumask_test_cpu(cpu, ept_get_synced_mask(ept_data)) &&
- !cpumask_test_and_set_cpu(cpu,
-   ept_get_synced_mask(ept_data)) )
-__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept_data), 0);
-}
-
 vmx_restore_guest_msrs(v);
 vmx_restore_dr(v);
 }
@@ -3507,6 +3495,16 @@ void vmx_vmenter_helper(const struct cpu_user_regs *regs)
 if ( unlikely(need_flush) )
 vpid_sync_all();
 
+if ( paging_mode_hap(curr->domain) )
+{
+struct ept_data *ept = _get_hostp2m(curr->domain)->ept;
+unsigned int cpu = smp_processor_id();
+
+if ( cpumask_test_cpu(cpu, ept->invalidate)
+ && cpumask_test_and_clear_cpu(cpu, ept->invalidate) )
+__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
+}
+
  out:
 HVMTRACE_ND(VMENTRY, 0, 1/*cycles*/, 0, 0, 0, 0, 0, 0, 0);
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index eef0372..6e0cf89 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1089,9 +1089,10 @@ static void ept_memory_type_changed(struct p2m_domain 
*p2m)
 
 static void __ept_sync_domain(void *info)
 {
-struct ept_data *ept = &((struct p2m_domain *)info)->ept;
-
-__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
+/*
+ * The invalidate will be done before VMENTER (see
+ * vmx_vmenter_helper()).
+ */
 }
 
 void ept_sync_domain(struct p2m_domain *p2m)
@@ -1107,16 +1108,10 @@ void ept_sync_domain(struct p2m_domain *p2m)
 if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
 p2m_flush_nestedp2m(d);
 
-/*
- * Flush active cpus synchronously. Flush others the next time this domain
- * is scheduled onto them. We accept the race of other CPUs adding to
- * the ept_synced mask before on_selected_cpus() reads it, resulting in
- * unnecessary extra flushes, to avoid allocating a cpumask_t on the stack.
- */
-cpumask_and(ept_get_synced_mask(ept),
-d->domain_dirty_cpumask, _online_map);
+/* May need to invalidate on all PCPUs. */
+cpumask_setall(ept->invalidate);
 
-on_selected_cpus(ept_get_synced_mask(ept),
+on_selected_cpus(d->domain_dirty_cpumask,
  __ept_sync_domain, p2m, 1);
 }
 
@@ -1182,10 +1177,14 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->flush_hardware_cached_dirty = ept_flush_pml_buffers;
 }

Re: [Xen-devel] [PATCH RFC 0/3] Xen on Virtio

[David Vrabel]

On 07/12/15 16:19, Stefano Stabellini wrote:
> Hi all,
> 
> this patch series introduces support for running Linux on top of Xen
> inside a virtual machine with virtio devices (nested virt scenario).
> The problem is that Linux virtio drivers use virt_to_phys to get the
> guest pseudo-physical addresses to pass to the backend, which doesn't
> work as expected on Xen.
> 
> Switching the virtio drivers to the dma APIs (dma_alloc_coherent,
> dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as
> Xen support in Linux provides an implementation of the dma API which
> takes care of the additional address conversions. However using the dma
> API would increase the complexity of the non-Xen case too. We would also
> need to keep track of the physical or virtual address in addition to the
> dma address for each vring_desc to be able to free the memory in
> detach_buf (see patch #3).
> 
> Instead this series adds few obvious checks to perform address
> translations in a couple of key places, without changing non-Xen code
> paths. You are welcome to suggest improvements or alternative
> implementations.

Andy Lutomirski also looked at this.  Andy what happened to this work?

David

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

Re: [Xen-devel] [PATCH RFC 1/3] xen: export xen_phys_to_bus, xen_bus_to_phys and xen_virt_to_bus

[David Vrabel]

On 07/12/15 16:19, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini 

Can you add a brief description about why these are being moved?  Then,
assuming this is needed in the end:

Acked-by: David Vrabel 

David

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

Re: [Xen-devel] [PATCH RFC 0/3] Xen on Virtio

[Michael S. Tsirkin]

On Mon, Dec 14, 2015 at 02:00:05PM +, David Vrabel wrote:
> On 07/12/15 16:19, Stefano Stabellini wrote:
> > Hi all,
> > 
> > this patch series introduces support for running Linux on top of Xen
> > inside a virtual machine with virtio devices (nested virt scenario).
> > The problem is that Linux virtio drivers use virt_to_phys to get the
> > guest pseudo-physical addresses to pass to the backend, which doesn't
> > work as expected on Xen.
> > 
> > Switching the virtio drivers to the dma APIs (dma_alloc_coherent,
> > dma_map/unmap_single and dma_map/unmap_sg) would solve the problem, as
> > Xen support in Linux provides an implementation of the dma API which
> > takes care of the additional address conversions. However using the dma
> > API would increase the complexity of the non-Xen case too. We would also
> > need to keep track of the physical or virtual address in addition to the
> > dma address for each vring_desc to be able to free the memory in
> > detach_buf (see patch #3).
> > 
> > Instead this series adds few obvious checks to perform address
> > translations in a couple of key places, without changing non-Xen code
> > paths. You are welcome to suggest improvements or alternative
> > implementations.
> 
> Andy Lutomirski also looked at this.  Andy what happened to this work?
> 
> David

The approach there was to try and convert all virtio to use DMA
API unconditionally.
This is reasonable if there's a way for devices to request
1:1 mappings individually.
As that is currently missing, that patchset can not be merged yet.

-- 
MST

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

Re: [Xen-devel] [PATCH] squash into 'build: convert HAS_MEM_ACCESS to use Kconfig'

[Doug Goldstein]

On 12/14/15 3:01 AM, Jan Beulich wrote:
 On 11.12.15 at 17:15,  wrote:
>> I've submitted 'tools: always enable HAS_MEM_ACCESS' and once that lands
>> this can be squashed into 'build: convert HAS_MEM_ACCESS to use Kconfig'.
> 
> Well, for some particular definition of "squash" only. I can't see how it
> would apply incrementally on top of that patch; I suppose it would apply
> only on top of the entires series, yet I think that patch you refer to
> really should do the whole thing in one go.
> 
> Jan
> 

No matter what it will require a rebase of HAS_MEM_PAGING and
HAS_MEM_SHARING since the context lines would be changed. I can resubmit
the whole series.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv4] xen/gntdev: add ioctl for grant copy

[David Vrabel]

On 01/12/15 16:43, David Vrabel wrote:
> Add IOCTL_GNTDEV_GRANT_COPY to allow applications to copy between user
> space buffers and grant references.
> 
> This interface is similar to the GNTTABOP_copy hypercall ABI except
> the local buffers are provided using a virtual address (instead of a
> GFN and offset).  To avoid userspace from having to page align its
> buffers the driver will use two or more ops if required.
> 
> If the ioctl returns 0, the application must check the status of each
> segment with the segments status field.  If the ioctl returns a -ve
> error code (EINVAL or EFAULT), the status of individual ops is
> undefined.

Konrad, Boris,  any comments?

David

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

[Xen-devel] [linux-mingo-tip-master test] 65794: regressions - FAIL

[osstest service owner]

flight 65794 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65794/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxf3240ee7a6870bc277f628d7e07bbc84d119d012
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  123 days
Failing since 60712  2015-08-15 18:33:48 Z  120 days   83 attempts
Testing same since65763  2015-12-11 22:04:03 Z2 days2 attempts

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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  

Re: [Xen-devel] [PATCH v7 00/28] Kconfig conversion

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> The following series is a follow on to the Kconfig conversion patch series.
> There are still more components to convert however this is the bare minimal
> to get everything working and get the options out of the existing makefiles.
> 
> The CONFIG_HAS_ variables are there to match the behavior of the Linux
> CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env
> supports this option while the CONFIG_ variable states that this option was
> requested on/off by user intervention.
> 
> Ultimately my goal is to allow for more parts of the hypervisor to be turned
> off at compile time and potentially make it easier to include more
> experimental features by others which can be turned off by default. Also to
> provide the one true location for all possible knobs in the source code.

Patches 5-11,13-22:
Acked-by: Jan Beulich 
(albeit patch 7 still has a couple of #endif comment changes left)

I have yet to take a closer look at patches 3 and 4.

Jan


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

Re: [Xen-devel] [PATCH] scripts: Add a script to build and submit to coverity.

[Ian Campbell]

On Thu, 2015-12-10 at 18:06 +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH] scripts: Add a script to build and
> submit to coverity."):
> > If curl can do that then fine.  Given
> > 
> > > > > > +declare -a curl_args
> > > > > > +curl_args+=("--form" "token=$COV_TOKEN")
> > > > > > +curl_args+=("--form" "email=$COV_EMAIL")
> > 
> > this could be achieved by having ts-do-coverity-thing set COV_TOKEN to
> > $HOME/.xen-osstest/coverity-secret or whatever.  ts-do-coverity-thing
> > would need to set a bunch of other COV_SOMETHING anyay.
> 
> It occurs to me that it would be better if
>  - the Coverity token did not have to be sent to the build host,
> but could remain on the controller
>  - the Coverity log file thing could be left in the build logs
> 
> But I don't think this means that your script ought not to have an
> `upload' function.  It just means that maybe osstest will need what
> amounts to a copy of it.

Having implemented the bulk of a new ts-coverity-scan this morning I'm
basically concluding that all going via xen.git/scripts/coverity-build.sh
is doing is making things more opaque and more difficult to work with from
the test system, without really adding much value (the commands are not all
that complex after all).

Therefore I'm considering (actually, I've pretty much decided) that the ts
script should probably just do things itself.

And given a regular automated scan run that I'm not sure what value the in
tree helper script is, so I'd likely propose to drop this patch too, unless
other folks think it would be useful.

Ian.

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

Re: [Xen-devel] [PATCHv4 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[Andrew Cooper]

On 14/12/15 14:39, David Vrabel wrote:
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index eef0372..6e0cf89 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1089,9 +1089,10 @@ static void ept_memory_type_changed(struct p2m_domain 
> *p2m)
>  
>  static void __ept_sync_domain(void *info)
>  {
> -struct ept_data *ept = &((struct p2m_domain *)info)->ept;
> -
> -__invept(INVEPT_SINGLE_CONTEXT, ept_get_eptp(ept), 0);
> +/*
> + * The invalidate will be done before VMENTER (see
> + * vmx_vmenter_helper()).
> + */
>  }
>  
>  void ept_sync_domain(struct p2m_domain *p2m)
> @@ -1107,16 +1108,10 @@ void ept_sync_domain(struct p2m_domain *p2m)
>  if ( nestedhvm_enabled(d) && !p2m_is_nestedp2m(p2m) )
>  p2m_flush_nestedp2m(d);
>  
> -/*
> - * Flush active cpus synchronously. Flush others the next time this 
> domain
> - * is scheduled onto them. We accept the race of other CPUs adding to
> - * the ept_synced mask before on_selected_cpus() reads it, resulting in
> - * unnecessary extra flushes, to avoid allocating a cpumask_t on the 
> stack.
> - */
> -cpumask_and(ept_get_synced_mask(ept),
> -d->domain_dirty_cpumask, _online_map);
> +/* May need to invalidate on all PCPUs. */
> +cpumask_setall(ept->invalidate);
>  
> -on_selected_cpus(ept_get_synced_mask(ept),
> +on_selected_cpus(d->domain_dirty_cpumask,
>   __ept_sync_domain, p2m, 1);

You can drop __ept_sync_domain() entirely by using
smp_send_event_check_mask() instead, which is a no-op IPI (and slightly
less overhead while holding the IPI lock).

>  }
>  
> @@ -1182,10 +1177,14 @@ int ept_p2m_init(struct p2m_domain *p2m)
>  p2m->flush_hardware_cached_dirty = ept_flush_pml_buffers;
>  }
>  
> -if ( !zalloc_cpumask_var(>synced_mask) )
> +if ( !zalloc_cpumask_var(>invalidate) )
>  return -ENOMEM;
>  
> -on_each_cpu(__ept_sync_domain, p2m, 1);
> +/*
> + * Assume an initial invalidation is required, in case an EP4TA is
> + * reused.
> + */
> +cpumask_setall(ept->invalidate);
>  
>  return 0;
>  }
> @@ -1193,7 +1192,7 @@ int ept_p2m_init(struct p2m_domain *p2m)
>  void ept_p2m_uninit(struct p2m_domain *p2m)
>  {
>  struct ept_data *ept = >ept;
> -free_cpumask_var(ept->synced_mask);
> +free_cpumask_var(ept->invalidate);
>  }
>  
>  static void ept_dump_p2m_table(unsigned char key)
> diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
> b/xen/include/asm-x86/hvm/vmx/vmcs.h
> index a8d4d5b..e778d86 100644
> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -67,7 +67,7 @@ struct ept_data {
>  };
>  u64 eptp;
>  };
> -cpumask_var_t synced_mask;
> +cpumask_var_t invalidate;

Could you include a small comment here to describe the behaviour?  Perhaps:

/* Whether an INVEPT should be issued on VMENTER? */

~Andrew

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

Re: [Xen-devel] [PATCH v7 12/28] build: convert HAS_VGA use to Kconfig

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> --- a/xen/drivers/video/Kconfig
> +++ b/xen/drivers/video/Kconfig
> @@ -2,3 +2,7 @@
>  # Select HAS_VIDEO if video is supported
>  config HAS_VIDEO
>   bool
> +
> +# Select HAS_VGA if VGA is supported
> +config HAS_VGA
> +   bool

I think HAS_VGA should select HAS_VIDEO, eliminating the need for
x86 to select both.

Also indentation is broken here (either on this new entry [using
spaces] or on the one visible in context [using a tab]).

Jan


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

Re: [Xen-devel] [PATCH] xen/x86/pvh: Use HVM's flush_tlb_others op

[David Vrabel]

On 13/12/15 00:25, Boris Ostrovsky wrote:
> Using MMUEXT_TLB_FLUSH_MULTI doesn't buy us much since the hypervisor
> will likely perform same IPIs as would have the guest.
> 
> More importantly, using MMUEXT_INVLPG_MULTI may not to invalidate the
> guest's address on remote CPU (when, for example, VCPU from another guest
> is running there).
> 
> Signed-off-by: Boris Ostrovsky 
> Suggested-by: Jan Beulich 
> Cc: sta...@vger.kernel.org # 3.14+

Applied to for-linus-4.4, thanks.  But given that PVH is experimental
I've dropped the stable Cc.

David

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

Re: [Xen-devel] [PATCHv3 1/2] x86/ept: invalidate guest physical mappings on VMENTER

[David Vrabel]

On 07/12/15 10:25, George Dunlap wrote:
> 
> I took the past tense ("synced") to mean, "These CPUs have been
> brought into sync (or are no longer out of sync)".  So they start out
> not-synced, so you initialize the bit to be clear; when an INVEPT is
> executed, they become synced, so you set the bit; and when you change
> the EPT tables, they are no longer synced so you clear the bit.

It didn't work like that though.  I have retained the changed name and
meaning.

David

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

Re: [Xen-devel] [PATCH v7 04/28] build: use generated Kconfig options for Xen

[Jan Beulich]

>>> On 10.12.15 at 17:48,  wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -34,6 +34,8 @@ default: build
>  .PHONY: dist
>  dist: install
>  
> +build:: include/config/auto.conf
> +
>  .PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags
>  build install uninstall debug clean distclean cscope TAGS tags MAP gtags::
>  ifneq ($(XEN_TARGET_ARCH),x86_32)
> @@ -236,9 +238,14 @@ kconfig := silentoldconfig oldconfig config menuconfig 
> defconfig \
>  $(kconfig):
>   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig 
> ARCH=$(XEN_TARGET_ARCH) 
> $@
>  
> -include/config/%.conf: include/config/auto.conf.cmd
> +include/config/%.conf: include/config/auto.conf.cmd .config

$(KCONFIG_CONFIG)?

With that adjusted (or a reason given why it cannot be adjusted)
Acked-by: Jan Beulich 

Jan


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