Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
On 21.05.15 at 17:16, david.vra...@citrix.com wrote: On 21/05/15 15:53, Jan Beulich wrote: On 21.05.15 at 15:36, david.vra...@citrix.com wrote: On 21/05/15 11:32, Jan Beulich wrote: On 20.05.15 at 17:54, david.vra...@citrix.com wrote: @@ -827,9 +828,11 @@ __gnttab_map_grant_ref( if ( (wrc + rdc) == 0 ) err = iommu_map_page(ld, frame, frame, IOMMUF_readable); } + +double_gt_lock(lgt, rgt); unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like? I think it will be no worse than what it was before -- this path already really sucks (mapcount() loops over 1000s of entries). I don't care about this path at all. It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be). What's your point? Are you going to refuse this series unless it also optimizes dom0-strict mode? No, I'm certainly not going to be. But this series of I don't care worry me to a certain degree (apart from making me wonder why, as so far I thought an as secure as possible environment is key for XenServer, and iommu=dom0-strict is certainly helping with that, which is also why I said that this should arguably become the default). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.5-testing test] 56898: regressions - FAIL
On 22.05.15 at 09:19, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 08:11 +0100, Jan Beulich wrote: On 21.05.15 at 21:30, osst...@xenbits.xen.org wrote: flight 56898 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56898/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 This is recurring (i.e. presumably real), but none of the few changes under test appear to be related in any way. And going through the logs I can't spot anything suspicious either. Does anyone else have a clue? For a long time this test was marked never passed. However I recently added osstest support for using the ACPI shutdown method against certain guests when configured to do so and configured win7. However it is starting to look like the ACPI shutdown method is unreliable, since this now seems to be failing intermittently. I haven't had a chance to analyse it yet, but it seems like it might also be specific to Windows 7. In this case, as with the other one I looked at earlier in the week, the guest vnc screenshot shows no sign that it is considering shutting down. test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728 I suppose this (also recurring, and also seemingly unrelated to any of the commits under test) Correct, this is a long standing heisenbug. I recently increased the number of iterations used in this test to (hopefully) reduce the incidences of false passes. I would force push any flight which failed only this case. Together with your explanation on the other failure this then perhaps is enough reason to actually do a force push here (which iiuc will at once make both of them allowable failures going forward). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 7/8] xenalyze: remove traling whitespaces
Result of sed -i 's@[[:blank:]]\+$@@' tools/xentrace/xenalyze.c
Signed-off-by: Olaf Hering o...@aepfle.de
Acked-by: George Dunlap george.dun...@eu.citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 350 +++---
1 file changed, 175 insertions(+), 175 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 2300348..bc233c0 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -2,7 +2,7 @@
* xenalyze.c: Analyzing xentrace output
*
* Written by George Dunlap.
- *
+ *
* Copyright (c) 2006-2007, XenSource Inc.
* Copyright (c) 2007-2008, Citrix Systems RD Ltd, UK
*
@@ -62,7 +62,7 @@ struct array_struct {
fprintf(warn, ##_x); \
} \
} while(0)\
-
+
/* -- Global variables -- */
struct {
int fd;
@@ -88,7 +88,7 @@ struct {
.progress = { .update_offset = 0 },
};
-/*
+/*
Kinds of errors:
Unexpected values
- RIP with information in high bits (not all 0 or 1)
@@ -116,7 +116,7 @@ struct {
- domain runstates
- runstate / tsc skew
- vcpu_{prev,next}_update p-current{==,!=}null
-- vcpu start conditions
+- vcpu start conditions
- lost_cpu count higher than # of seen cpus / 0
- lost cpu has non-null p-current
Symbol file
@@ -147,7 +147,7 @@ enum error_level {
int verbosity = 5;
struct {
-unsigned
+unsigned
scatterplot_interrupt_eip:1,
scatterplot_cpi:1,
scatterplot_unpin_promote:1,
@@ -226,7 +226,7 @@ struct {
} opt = {
.scatterplot_interrupt_eip=0,
.scatterplot_cpi=0,
-.scatterplot_unpin_promote=0,
+.scatterplot_unpin_promote=0,
.scatterplot_cr3_switch=0,
.scatterplot_wake_to_halt=0,
.scatterplot_vmexit_eip=0,
@@ -356,7 +356,7 @@ void parse_symbol_file(char *fn) {
error(ERR_ASSERT, NULL);
} else
last_addr = (*p)-symbols[(*p)-count].addr;
-
+
(*p)-count++;
/* If this struct is full, point to the next. It will be allocated
@@ -419,7 +419,7 @@ struct {
void (*dump)(struct eip_list_struct *);
} eip_list_type[EIP_LIST_TYPE_MAX] = {
[EIP_LIST_TYPE_NONE] = {
-.update=NULL,
+.update=NULL,
.new=NULL,
.dump=NULL },
};
@@ -428,7 +428,7 @@ struct {
/* --- HVM class of events --- */
/*
- * -- Algorithms --
+ * -- Algorithms --
*
* Interrupt Wake-to-halt detection
*
@@ -451,7 +451,7 @@ struct {
*
* The waking interrupts we want to sub-classify into
* wake-only (when interrupt was the only interrupt from wake to halt) and
- * wake-all (whether this was the only interrupt or not).
+ * wake-all (whether this was the only interrupt or not).
*/
/* VMX data */
@@ -969,7 +969,7 @@ char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
pf_inject,
inj_exc,
inj_virq,
-reinj_virq,
+reinj_virq,
io_read,
io_write,
cr_read, /* 8 */
@@ -1470,7 +1470,7 @@ void init_hvm_data(struct hvm_data *h, struct vcpu_data
*v) {
size);
error(ERR_SYSTEM, NULL);
}
-
+
}
for(i=0; iGUEST_INTERRUPT_MAX+1; i++)
h-summary.guest_interrupt[i].count=0;
@@ -1758,7 +1758,7 @@ struct domain_data {
struct cr3_value_struct *cr3_value_head;
struct eip_list_struct *emulate_eip_list;
struct eip_list_struct *interrupt_eip_list;
-
+
int guest_interrupt[GUEST_INTERRUPT_MAX+1];
struct hvm_short_summary_struct hvm_short;
struct {
@@ -1841,7 +1841,7 @@ void volume_summary(struct trace_volume *vol)
printf( +-%-7s: %10lld\n,
hvm_vol_name[k], vol-hvm[k]);
}
-
+
break;
}
}
@@ -2050,7 +2050,7 @@ long long percentile(long long * A, int N, int ple) {
I++; J--;
}
} while (I = J); /* Keep going until our pointers meet or pass */
-
+
/* Re-adjust L and R, based on which element we're looking for */
if(JK)
L=I;
@@ -2134,9 +2134,9 @@ float weighted_percentile(float * A, /* values */
} while (I = J); /* Keep going until our pointers meet or pass */
/* Re-adjust L and R, based on which element we're looking for */
-if(J_weightK_weight)
+if(J_weightK_weight)
L=I; L_weight = I_weight;
-if(K_weightI_weight)
+if(K_weightI_weight)
R=J; R_weight = J_weight;
}
@@ -2365,7 +2365,7 @@ static inline void clear_interval_cpi(struct
weighted_cpi_summary *s) {
static inline
[Xen-devel] [PATCH v3 8/8] xenalyze: remove argp_program_version
Since xenalyze is now upstream its Open Source and part of the given
release.
Signed-off-by: Olaf Hering o...@aepfle.de
Acked-by: George Dunlap george.dun...@eu.citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index bc233c0..bfb7e2c 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -10407,7 +10407,6 @@ const struct argp parser_def = {
.doc = ,
};
-const char *argp_program_version = xenalyze - Open-source xen-unstable (3.4);
const char *argp_program_bug_address = George Dunlap
george.dun...@eu.citrix.com;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 5/8] xenalyze: handle TRC_TRACE_WRAP_BUFFER
Signed-off-by: Olaf Hering o...@aepfle.de
Acked-by: George Dunlap george.dun...@eu.citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 58e8456..0566d00 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -8469,6 +8469,8 @@ void base_process(struct pcpu_info *p) {
struct record_info *ri = p-ri;
switch(ri-event)
{
+case TRC_TRACE_WRAP_BUFFER:
+break;
case TRC_LOST_RECORDS:
process_lost_records(p);
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 6/8] xenalyze: handle more events in sched_process
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 75 ++-
1 file changed, 68 insertions(+), 7 deletions(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 0566d00..2300348 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -30,6 +30,7 @@
#include fcntl.h
#include unistd.h
#include public/trace.h
+#include public/sched.h
#include analyze.h
#include mread.h
#include pv.h
@@ -7569,24 +7570,84 @@ void sched_summary_domain(struct domain_data *d)
}
}
+void sched_class(struct record_info *ri)
+{
+/* Just a stub for now */
+}
void sched_process(struct pcpu_info *p)
{
struct record_info *ri = p-ri;
-if(ri-evt.sub == 0xf) {
+if (ri-evt.sub == 1) {
+sched_runstate_process(p);
+} else if (ri-evt.sub == 2) {
+sched_class(ri);
+} else {
switch(ri-event)
{
+case TRC_SCHED_DOM_ADD:
+printf( %s sched_add_domain d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_DOM_REM:
+printf( %s sched_rem_domain d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SLEEP:
+printf( %s domain_sleep d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_WAKE:
+printf( %s domain_wake d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_YIELD:
+printf( %s do_yield d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_BLOCK:
+printf( %s do_block d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SHUTDOWN:
+{
+static const char *reason[] = {
+[SHUTDOWN_poweroff] = poweroff,
+[SHUTDOWN_reboot] = reboot,
+[SHUTDOWN_suspend] = suspend,
+[SHUTDOWN_crash] = crash,
+[SHUTDOWN_watchdog] = watchdog,
+};
+printf( %s domain_shutdown d%uv%u reason %x (%s)\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2],
+ ri-d[2] SHUTDOWN_MAX ? unknown : reason[ri-d[2]]);
+break;
+}
+case TRC_SCHED_SHUTDOWN_CODE:
+{
+printf( %s domain_shutdown_code d%uv%u reason %x\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2]);
+break;
+}
+case TRC_SCHED_ADJDOM:
+printf( %s sched_adjdom domid d%u\n,
+ ri-dump_header, ri-d[0]);
+break;
case TRC_SCHED_SWITCH:
sched_switch_process(p);
break;
+case TRC_SCHED_SWITCH_INFPREV:
+printf( %s switch_infprev old_domid %x runtime %d\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SWITCH_INFNEXT:
+printf( %s switch_infnext new_domid %x time %d r_time %d\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2]);
+break;
default:
-process_generic(p-ri);
-}
-} else {
-if(ri-evt.sub == 1)
-sched_runstate_process(p);
-else {
+fprintf(warn, %s: event:%x (min:%x sub:%x main:%x)\n,
+__func__, ri-event, ri-evt.minor, ri-evt.sub,
ri-evt.main);
UPDATE_VOLUME(p, sched_verbose, ri-size);
process_generic(p-ri);
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86: move syscall trampolines off the stack
On 22.05.15 at 10:25, jbeul...@suse.com wrote: On 21.05.15 at 13:48, jbeul...@suse.com wrote: On 21.05.15 at 13:08, andrew.coop...@citrix.com wrote: It might be wise to have a BUILD_BUG_ON() which confirms that STUBS_PER_PAGE is a power of two, which is a requirement given the way it is used. Good idea. Sadly this can't be a BUILD_BUG_ON(), as STUBS_PER_PAGE isn't a compile time constant (due to the use of max()). I made it an ASSERT() for the time being. Or actually no, since the other two would need to become ASSERT()s too, I'll rather open code the max() instead. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/2] xen/block: add multi-page ring support
On 05/22/2015 04:31 PM, Paul Durrant wrote:
-Original Message-
From: Bob Liu [mailto:bob@oracle.com]
Sent: 22 May 2015 01:00
To: xen-devel@lists.xen.org
Cc: David Vrabel; just...@spectralogic.com; konrad.w...@oracle.com; Roger
Pau Monne; Paul Durrant; Julien Grall; boris.ostrov...@oracle.com; linux-
ker...@vger.kernel.org; Bob Liu
Subject: [PATCH v5 2/2] xen/block: add multi-page ring support
Extend xen/block to support multi-page ring, so that more requests can be
issued by using more than one pages as the request ring between blkfront
and backend.
As a result, the performance can get improved significantly.
We got some impressive improvements on our highend iscsi storage cluster
backend. If using 64 pages as the ring, the IOPS increased about 15 times
for the throughput testing and above doubled for the latency testing.
The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical
drives, 32 was really not enough to keep them busy.
Changes in v2:
- Rebased to 4.0-rc6.
- Document on how multi-page ring feature working to linux io/blkif.h.
Changes in v3:
- Remove changes to linux io/blkif.h and follow the protocol defined
in io/blkif.h of XEN tree.
- Rebased to 4.1-rc3
Changes in v4:
- Turn to use 'ring-page-order' and 'max-ring-page-order'.
- A few comments from Roger.
Changes in v5:
- Clarify 4k granularity to comment.
- Address more comments from Roger.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 13
drivers/block/xen-blkback/common.h | 3 +-
drivers/block/xen-blkback/xenbus.c | 88 +--
drivers/block/xen-blkfront.c| 135 +---
4 files changed, 179 insertions(+), 60 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-
blkback/blkback.c
index 713fc9f..2126842 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,13 @@ MODULE_PARM_DESC(max_persistent_grants,
Maximum number of grants to map persistently);
/*
+ * Maximum order of pages to be used for the shared ring between front
and
+ * backend, 4KB page granularity is used.
+ */
+unsigned int xen_blkif_max_ring_order =
XENBUS_MAX_RING_PAGE_ORDER;
+module_param_named(max_ring_page_order, xen_blkif_max_ring_order,
int, S_IRUGO);
+MODULE_PARM_DESC(max_ring_page_order, Maximum order of pages
to be used for the shared ring);
+/*
* The LRU mechanism to clean the lists of persistent grants needs to
* be executed periodically. The time interval between consecutive
executions
* of the purge mechanism is set in ms.
@@ -1438,6 +1445,12 @@ static int __init xen_blkif_init(void)
if (!xen_domain())
return -ENODEV;
+if (xen_blkif_max_ring_order XENBUS_MAX_RING_PAGE_ORDER)
{
+pr_info(Invalid max_ring_order (%d), will use default max:
%d.\n,
+xen_blkif_max_ring_order,
XENBUS_MAX_RING_PAGE_ORDER);
+xen_blkif_max_ring_order =
XENBUS_MAX_RING_PAGE_ORDER;
+}
+
rc = xen_blkif_interface_init();
if (rc)
goto failed_init;
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-
blkback/common.h
index f620b5d..919a1ab 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
#include xen/interface/io/blkif.h
#include xen/interface/io/protocols.h
+extern unsigned int xen_blkif_max_ring_order;
/*
* This is the maximum number of segments that would be allowed in
indirect
* requests. This value will also be passed to the frontend.
@@ -248,7 +249,7 @@ struct backend_info;
#define PERSISTENT_GNT_WAS_ACTIVE 1
/* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_MAX_BLKIF_REQS (32 *
XENBUS_MAX_RING_PAGES)
struct persistent_gnt {
struct page *page;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-
blkback/xenbus.c
index 6ab69ad..bc33888 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@
/* Enlarge the array size in order to fully show blkback name. */
#define BLKBACK_NAME_LEN (20)
+#define RINGREF_NAME_LEN (20)
struct backend_info {
struct xenbus_device*dev;
@@ -152,7 +153,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t
domid)
INIT_LIST_HEAD(blkif-pending_free);
INIT_WORK(blkif-free_work, xen_blkif_deferred_free);
-for (i = 0; i XEN_BLKIF_REQS; i++) {
+for (i = 0; i XEN_MAX_BLKIF_REQS; i++) {
How big is XEN_MAX_BLKIF_REQS? These allocations are per-instance so I'd be
concerned that the increase in the number of allocations would hit system
scalability.
Right, Roger and I have
Re: [Xen-devel] [PATCH] xen: Use ULL for GB macro
On 22.05.15 at 01:16, julien.gr...@citrix.com wrote: --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -992,7 +992,7 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; set_fixmap_nocache(FIX_APIC_BASE, apic_phys); -apic_printk(APIC_VERBOSE, mapped APIC to %08lx (%08lx)\n, APIC_BASE, +apic_printk(APIC_VERBOSE, mapped APIC to %08llx (%08lx)\n, APIC_BASE, Please use 'L' as the shorter equivalent. --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -70,7 +70,7 @@ #define __bitwise #define MB(_mb) (_AC(_mb, UL) 20) -#define GB(_gb) (_AC(_gb, UL) 30) +#define GB(_gb) (_AC(_gb, ULL) 30) So why do you leave MB() alone? It obviously suffers from the same problem (perhaps only latent at this point, but anyway). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.5-testing test] 56898: regressions - FAIL
On Fri, 2015-05-22 at 08:11 +0100, Jan Beulich wrote: On 21.05.15 at 21:30, osst...@xenbits.xen.org wrote: flight 56898 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56898/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 This is recurring (i.e. presumably real), but none of the few changes under test appear to be related in any way. And going through the logs I can't spot anything suspicious either. Does anyone else have a clue? For a long time this test was marked never passed. However I recently added osstest support for using the ACPI shutdown method against certain guests when configured to do so and configured win7. However it is starting to look like the ACPI shutdown method is unreliable, since this now seems to be failing intermittently. I haven't had a chance to analyse it yet, but it seems like it might also be specific to Windows 7. In this case, as with the other one I looked at earlier in the week, the guest vnc screenshot shows no sign that it is considering shutting down. test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728 I suppose this (also recurring, and also seemingly unrelated to any of the commits under test) Correct, this is a long standing heisenbug. I recently increased the number of iterations used in this test to (hopefully) reduce the incidences of false passes. I would force push any flight which failed only this case. (As a side note - can anyone explain why elbling0---var-log-xen-console-guest-xenstorels.log.gz is gzip-ed twice?) osstest zips logs over some size threshold. I'm not sure what would be responsible for the other one -- perhaps either logrotate on the original host or something in the webserver giving out the logs? Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 56821 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 56728 It is interesting to see that these seem to intermittently fail, so perhaps the problem above is an older one... I think so (and more evidence that it is win7 only). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/shadow: fix uninitialized rc shadow_track_dirty_vram()
On 22/05/2015 07:29, Jan Beulich wrote:
Commit bd1b4a71b3 (x86/shadow: fix shadow_track_dirty_vram to work on
hvm guests), trying to mirror its HAP counterpart, deleted a couple of
assignments to rc without making sure rc is initialized on all paths.
Coverity ID: 1299410
Signed-off-by: Jan Beulich jbeul...@suse.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3518,7 +3518,7 @@ int shadow_track_dirty_vram(struct domain
unsigned long nr,
XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
{
-int rc;
+int rc = 0;
unsigned long end_pfn = begin_pfn + nr;
unsigned long dirty_size = (nr + 7) / 8;
int flush_tlb = 0;
@@ -3550,10 +3550,7 @@ int shadow_track_dirty_vram(struct domain
}
if ( !nr )
-{
-rc = 0;
goto out;
-}
dirty_bitmap = vzalloc(dirty_size);
if ( dirty_bitmap == NULL )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Regression due to device property: Make it possible to use secondary firmware nodes Re: Xen-unstable + linux 4.1-mergewindow: problems with PV guest pci passthrough: pcifront pci-0:
Hello Sander, Friday, May 15, 2015, 12:47:27 AM, you wrote: Sorry for the resend, i messed up the to's en from's. Hi Konrad / David, One big snip on this thread, got some more debug info, hopefully this will lead to something: On a working kernel (with the two seemingly non related patches reverted) i get: [0.717796] pcifront pci-0: Allocated pdev @ 0x880019e11780 pdev-sh_info @ 0x880018f58000 [0.717848] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.717871] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.717892] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.717915] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.717984] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.721640] pcifront pci-0: publishing successful! [0.723684] usbcore: registered new interface driver udlfb [0.724664] xen:xen_evtchn: Event-channel device installed [0.726597] pcifront pci-0: Installing PCI frontend [0.726853] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.727059] pcifront pci-0: Creating PCI Frontend Bus :00 [0.727363] pcifront pci-0: PCI host bridge to bus :00 [0.727391] pci_bus :00: root bus resource [io 0x-0x] [0.727417] pci_bus :00: root bus resource [mem 0x-0x] [0.727452] pci_bus :00: root bus resource [bus 00-ff] [0.727475] pci_bus :00: scanning bus [0.727503] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.728253] Linux agpgart interface v0.103 [0.728387] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.728474] [drm] Initialized drm 1.1.0 20060810 [0.728551] [drm] radeon kernel modesetting enabled. [0.730319] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 143164178555170 ns_timeout: 1431641787541235000 evtchn:17 gnt_ref:8 [0.730319] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: read got back value 3f6 [0.738845] pcifront pci-0: read dev=:00:00.0 - offset e size 1 [0.744976] brd: module loaded [0.745204] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785562852000 ns_timeout: 143164178755258 evtchn:17 gnt_ref:8 [0.745204] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: read got back value 0 [0.749204] pcifront pci-0: read dev=:00:00.0 - offset 6 size 2 [0.750155] loop: module loaded [0.752527] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785570841000 ns_timeout: 1431641787562917000 evtchn:17 gnt_ref:8 [0.752527] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: read got back value 210 [0.757187] pcifront pci-0: read dev=:00:00.0 - offset 34 size 1 Were as in the non-working situation i get: [0.751244] pcifront pci-0: Allocated pdev @ 0x880019ec2e00 pdev-sh_info @ 0x88001aa51000 [0.751295] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.751315] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.751334] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.751355] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.751422] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.755215] pcifront pci-0: publishing successful! [0.757341] usbcore: registered new interface driver udlfb [0.758365] xen:xen_evtchn: Event-channel device installed [0.760419] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.760819] pcifront pci-0: Installing PCI frontend [0.761518] pcifront pci-0: Creating PCI Frontend Bus :00 [0.761684] pcifront pci-0: PCI host bridge to bus :00 [0.761710] pci_bus :00: root bus resource [io 0x-0x] [0.761733] pci_bus :00: root bus resource [mem 0x-0x] [0.761763] pci_bus :00: root bus resource [bus 00-ff] [0.761783] pci_bus :00: scanning bus [0.761805] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.767207] Linux agpgart interface v0.103 [0.767362] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.767439] [drm] Initialized drm 1.1.0 20060810 [0.767515] [drm] radeon kernel modesetting enabled. [0.766948] pcifront pci-0: pciback not responding!!! irq:31 irq_flags:880019ec0028 ns: 1431641983026498000 ns_timeout: 1431641983026497000 evtchn:0 gnt_ref:0 [0.766948] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0
Re: [Xen-devel] [PATCH v2 1/4] x86: move syscall trampolines off the stack
On 21.05.15 at 13:48, jbeul...@suse.com wrote: On 21.05.15 at 13:08, andrew.coop...@citrix.com wrote: On 21/05/15 11:15, Jan Beulich wrote: This is needed as stacks are going to become non-executable. Use separate stub pages (shared among suitable CPUs on the same node) instead. Stub areas (currently 128 bytes each) are being split into two parts - a fixed usage one (the syscall ones) and dynamically usable space, which will be used by subsequent changes to hold dynamically generated code during instruction eumlation. While sharing physical pages among certain CPUs on the same node, for now the virtual mappings get established in distinct pages for each CPU. This isn't a strict requirement, but simplifies VA space management for this initial implementation: Sharing VA space would require additional tracking of which areas are currently in use. If the VA and/or TLB overhead turned out to be a problem, such extra code could easily be added. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com It might be wise to have a BUILD_BUG_ON() which confirms that STUBS_PER_PAGE is a power of two, which is a requirement given the way it is used. Good idea. Sadly this can't be a BUILD_BUG_ON(), as STUBS_PER_PAGE isn't a compile time constant (due to the use of max()). I made it an ASSERT() for the time being. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.5-testing test] 56898: regressions - FAIL
On Fri, 2015-05-22 at 08:48 +0100, Jan Beulich wrote: On 22.05.15 at 09:19, ian.campb...@citrix.com wrote: On Fri, 2015-05-22 at 08:11 +0100, Jan Beulich wrote: On 21.05.15 at 21:30, osst...@xenbits.xen.org wrote: flight 56898 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56898/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 This is recurring (i.e. presumably real), but none of the few changes under test appear to be related in any way. And going through the logs I can't spot anything suspicious either. Does anyone else have a clue? For a long time this test was marked never passed. However I recently added osstest support for using the ACPI shutdown method against certain guests when configured to do so and configured win7. However it is starting to look like the ACPI shutdown method is unreliable, since this now seems to be failing intermittently. I haven't had a chance to analyse it yet, but it seems like it might also be specific to Windows 7. In this case, as with the other one I looked at earlier in the week, the guest vnc screenshot shows no sign that it is considering shutting down. test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728 I suppose this (also recurring, and also seemingly unrelated to any of the commits under test) Correct, this is a long standing heisenbug. I recently increased the number of iterations used in this test to (hopefully) reduce the incidences of false passes. I would force push any flight which failed only this case. Together with your explanation on the other failure this then perhaps is enough reason to actually do a force push here (which iiuc will at once make both of them allowable failures going forward). Until the next spurious pass, which looks to be about 1 in 10. But yes, I think force pushing the win7 shutdown issue while we discuss in the other thread would be reasonable, pending a decision there whether to whitelist this particular failure or not when Ian gets back. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.5-testing test] 56898: regressions - FAIL
On 21.05.15 at 21:30, osst...@xenbits.xen.org wrote: flight 56898 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56898/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 This is recurring (i.e. presumably real), but none of the few changes under test appear to be related in any way. And going through the logs I can't spot anything suspicious either. Does anyone else have a clue? test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 56728 I suppose this (also recurring, and also seemingly unrelated to any of the commits under test) is due to device/vif =(n0,r49) device/vif/0 =(n49,r0) device/vif/0/backend = /local/domain/0/backend/vif/49/0 (n49,r0) device/vif/0/backend-id = 0 (n49,r0) device/vif/0/state = 1 (n49,r0) device/vif/0/handle = 0 (n49,r0) rumpxenstack: xs_directory (device/vif/0/handle): Invalid argument but I have no idea what conclusion to draw from that as to where the problem might be. (As a side note - can anyone explain why elbling0---var-log-xen-console-guest-xenstorels.log.gz is gzip-ed twice?) Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 56821 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 56728 It is interesting to see that these seem to intermittently fail, so perhaps the problem above is an older one... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Windows 2008 R2 virtual machines blue screen on xen4.1.2
Hi, all Recently, we encountered the problem that Windows 2008 R2 virtual machines blue screen when running on xen4.1.2, Mircrosoft engineer said it's a known issue with Intel Xeon processors: . Intel Xeon Processor E5 v2 Product Family: CA135 May 2014 -Incorrect Page Translation when EPT is enabled http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v2-spec-update.pdf And this issue has been fixed on Hyper-v and VMware: Hyper-V: Host Microcode update for Intel processors to improve the reliability of Windows Server https://support.microsoft.com/en-us/kb/2970215 VMware: Windows 2008 R2, Red Hat Enterprise Linux and Solaris 10 64-bit virtual machines blue screen or kernel panic when running on ESXi 5.x with an Intel E5/E7/E3 v2 series processor (2073791) http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=displayKCexternalId=2073791 Anybody know whether this issue has been fixed on the lastest xen or not? If so, could you please send me the patch, thanks! By the way, I can't reproduce this issue. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Earlier embargoed pre-disclosure without patches
On 21.05.15 at 15:03, major.hay...@rackspace.com wrote: Would it be possible to send out a pre-disclosure notice as soon as permission is granted from the discoverer and the vulnerability is verified as valid? In other words, could a pre-disclosure email be sent to parties on the pre-disclosure list *PRIOR* to patches being available? There is a significant amount of value for larger organizations in receiving a notice earlier -- even if it's without patches -- so that preparations can be made. As an example, v1 of a pre-disclosure email may discuss the vulnerability, affected versions, and potential impact without including patches. Once patches are developed/tested, a v2 email could be released. This would give organizations more time to determine how much of their fleet is potentially vulnerable and develop a plan for patching or mitigation. I realize this is being written under the impression of XSA-133, where the usual 2 week window between pre-disclosure and public disclosure was (almost) missing. But that's an exception, not the rule. Are you saying that the usual 2 week advance notice is not enough? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/4] x86: move syscall trampolines off the stack
On 22/05/2015 09:25, Jan Beulich wrote: On 21.05.15 at 13:48, jbeul...@suse.com wrote: On 21.05.15 at 13:08, andrew.coop...@citrix.com wrote: On 21/05/15 11:15, Jan Beulich wrote: This is needed as stacks are going to become non-executable. Use separate stub pages (shared among suitable CPUs on the same node) instead. Stub areas (currently 128 bytes each) are being split into two parts - a fixed usage one (the syscall ones) and dynamically usable space, which will be used by subsequent changes to hold dynamically generated code during instruction eumlation. While sharing physical pages among certain CPUs on the same node, for now the virtual mappings get established in distinct pages for each CPU. This isn't a strict requirement, but simplifies VA space management for this initial implementation: Sharing VA space would require additional tracking of which areas are currently in use. If the VA and/or TLB overhead turned out to be a problem, such extra code could easily be added. Signed-off-by: Jan Beulich jbeul...@suse.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com It might be wise to have a BUILD_BUG_ON() which confirms that STUBS_PER_PAGE is a power of two, which is a requirement given the way it is used. Good idea. Sadly this can't be a BUILD_BUG_ON(), as STUBS_PER_PAGE isn't a compile time constant (due to the use of max()). I made it an ASSERT() for the time being. In some copious free time, I shall see about borrowing some of the Linux constants infrastructure. We have quite a few examples of calculations which should be able to be evaluated by the compiler, but cant given our current setup. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/shadow: fix uninitialized rc shadow_track_dirty_vram()
At 07:29 +0100 on 22 May (1432279746), Jan Beulich wrote: Commit bd1b4a71b3 (x86/shadow: fix shadow_track_dirty_vram to work on hvm guests), trying to mirror its HAP counterpart, deleted a couple of assignments to rc without making sure rc is initialized on all paths. Coverity ID: 1299410 Signed-off-by: Jan Beulich jbeul...@suse.com Acked-by: Tim Deegan t...@xen.org ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Windows 2008 R2 virtual machines blue screen on xen4.1.2
On 22.05.15 at 09:08, xuzhichu...@huawei.com wrote: Recently, we encountered the problem that Windows 2008 R2 virtual machines blue screen when running on xen4.1.2, Mircrosoft engineer said it's a known issue with Intel Xeon processors: . Intel Xeon Processor E5 v2 Product Family: CA135 May 2014 -Incorrect Page Translation when EPT is enabled http://www.intel.com/content/dam/www/public/us/en/documents/specification-upd ates/xeon-e5-v2-spec-update.pdf And this issue has been fixed on Hyper-v and VMware: Hyper-V: Host Microcode update for Intel processors to improve the reliability of Windows Server https://support.microsoft.com/en-us/kb/2970215 VMware: Windows 2008 R2, Red Hat Enterprise Linux and Solaris 10 64-bit virtual machines blue screen or kernel panic when running on ESXi 5.x with an Intel E5/E7/E3 v2 series processor (2073791) http://kb.vmware.com/selfservice/microsites/search.do?language=en_UScmd=disp layKCexternalId=2073791 Anybody know whether this issue has been fixed on the lastest xen or not? If so, could you please send me the patch, thanks! So both Microsoft and VMware agree about this needing a micrcode update, and Xen doesn't include any CPU microcode. How come you ask for a Xen patch in this context? Providing CPU microcode updates are first of all a BIOS vendor responsibility, with distro-s often trying to cover for BIOS vendors to fail to do their job (in time). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4] xen/vm_event: Clean up control-register-write vm_events
On 22.05.15 at 09:50, rcojoc...@bitdefender.com wrote: On 05/22/2015 10:36 AM, Jan Beulich wrote: On 21.05.15 at 15:00, rcojoc...@bitdefender.com wrote: Should I drop the introduction of the XR0 event from this patch and come back to it in the following iteration of the series? Or simply adjust the title of the patch. Also, for readability I wonder whether an identically named macro wrapper around hvm_event_cr() wouldn't be a good idea, eliminating the need to spell out VM_EVENT_X86_ at each use site. #define hvm_event_cr0(new, old) hvm_event_cr(VM_EVENT_X86_XCR0, new, old)? Sure. Maybe this way. But specifically said identically named, i.e. envisioned #define hvm_event_cr(what, new, old) hvm_event_cr(VM_EVENT_X86_##what, new, old) --- a/xen/include/asm-x86/domain.h +++ b/xen/include/asm-x86/domain.h @@ -249,6 +249,8 @@ struct pv_domain struct mapcache_domain mapcache; }; +#define monitor_ctrlreg_bitmask(ctrlreg_index) (1 ctrlreg_index) (1U (ctrlreg_index)) would seem better to me. Also - does this need to be in this header (which gets included basically everywhere)? Ack. As for the header, that's where the fields are (write_ctrlreg_enabled, sync and onchangeonly), and since several .c files use the fields it seemed the natural place to put the macros. A monitor/event specific header would seem more natural to me. If everything relating to field in struct domain and struct vcpu got put in this one header, we'd end up with a mess. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 56967: regressions - FAIL
flight 56967 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/56967/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] ACPI shutdown unreliable with win7?
In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. Some random examples which I looked at: http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-amd64-xl-qemut-win7-amd64/info.html http://logs.test-lab.xenproject.org/osstest/logs/56929/test-amd64-i386-xl-qemuu-win7-amd64/info.html http://logs.test-lab.xenproject.org/osstest/logs/56718/test-amd64-amd64-xl-qemut-win7-amd64/info.html all showed in there vnc screenshot a guest which is showing no indication of shutting down. Looking a bit closer at the first 56929 one xl list shows the windows domain 18 in state blocked. The host serial log shows an apparently successful restore into dom18, then the debug key output after failure show CPU1, corresponding to d18v0, sat in hvm_io_pending: May 22 01:27:58.889074 (XEN) *** Dumping CPU1 host state: *** May 22 01:27:58.897025 (XEN) [ Xen-4.6-unstable x86_64 debug=y Not tainted ] May 22 01:27:58.904993 (XEN) CPU:1 May 22 01:27:58.905036 (XEN) RIP:e008:[82d0801bdce5] hvm_io_pending+0/0x52 May 22 01:27:58.912996 (XEN) RFLAGS: 0297 CONTEXT: hypervisor (d18v0) May 22 01:27:58.913056 (XEN) rax: rbx: 8300cceeb000 rcx: fed000f0 May 22 01:27:58.920996 (XEN) rdx: 0004 rsi: fed000f4 rdi: 8300cceeb000 May 22 01:27:58.928997 (XEN) rbp: 83022b4bf5b8 rsp: 83022b4bf520 r8: 0001 May 22 01:27:58.936987 (XEN) r9: r10: r11: f8b9c9e8 May 22 01:27:58.944986 (XEN) r12: 830219db5000 r13: 0004 r14: 82e0024433a0 May 22 01:27:58.953029 (XEN) r15: cr0: 80050033 cr4: 001526f0 May 22 01:27:58.960994 (XEN) cr3: 00010c38e000 cr2: f8a0007d1538 May 22 01:27:58.968987 (XEN) ds: es: fs: gs: ss: cs: e008 May 22 01:27:58.969027 (XEN) Xen stack trace from rsp=83022b4bf520: May 22 01:27:58.976990 (XEN)82d0801b8300 0001 83022b4bfb60 83022b4bf628 May 22 01:27:58.985003 (XEN)00010002 fed000f0 0101 83022b4bf578 May 22 01:27:58.993017 (XEN)801b8d1c fed000f0 0004 May 22 01:27:59.001010 (XEN)0120 83022b4bf630 0004 0004 May 22 01:27:59.009040 (XEN)00f0 83022b4bf9a8 0002 83022b4bf5d8 May 22 01:27:59.017016 (XEN)82d0801b85fb 8302 83022b4bf9a8 83022b4bf668 May 22 01:27:59.025011 (XEN)82d0801b9086 83022b4bf9a8 82d0801b85fb 8302 May 22 01:27:59.033009 (XEN)00022900 83022b4bfb60 83f4 83022b4bf978 May 22 01:27:59.040990 (XEN)fed000f0 0001 ffd090f0 83022b4bf688 May 22 01:27:59.041030 (XEN)008b 82d08028d900 May 22 01:27:59.048993 (XEN)83022b4bfb60 83022b4bf678 82d0801b92b8 83022b4bf688 May 22 01:27:59.057007 (XEN)82d0801958de 83022b4bfac8 82d080197875 83022b4bf6c8 May 22 01:27:59.064999 (XEN)82d0801f7b1c 83012c9ea008 0001 0080 May 22 01:27:59.073007 (XEN)01d9
Re: [Xen-devel] [PATCHv9 3/4] gnttab: make the grant table lock a read-write lock
On 22/05/15 07:37, Jan Beulich wrote: On 21.05.15 at 17:16, david.vra...@citrix.com wrote: On 21/05/15 15:53, Jan Beulich wrote: On 21.05.15 at 15:36, david.vra...@citrix.com wrote: On 21/05/15 11:32, Jan Beulich wrote: On 20.05.15 at 17:54, david.vra...@citrix.com wrote: @@ -827,9 +828,11 @@ __gnttab_map_grant_ref( if ( (wrc + rdc) == 0 ) err = iommu_map_page(ld, frame, frame, IOMMUF_readable); } + +double_gt_lock(lgt, rgt); unlock. And with this code path actually used (due to the bug it's pretty clear it didn't get exercised in your testing), how does performance look like? I think it will be no worse than what it was before -- this path already really sucks (mapcount() loops over 1000s of entries). I don't care about this path at all. It's kind of strange that you don't care about this case - afaict we're not getting there by default solely because dom0-strict mode is not currently the default (albeit arguably it should be). What's your point? Are you going to refuse this series unless it also optimizes dom0-strict mode? No, I'm certainly not going to be. But this series of I don't care worry me to a certain degree (apart from making me wonder why, as so far I thought an as secure as possible environment is key for XenServer, and iommu=dom0-strict is certainly helping with that, which is also why I said that this should arguably become the default). dom0-strict mode doesn't align with our PV-IOMMU plans to make BFN == PFN (including for grants). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/shadow: fix uninitialized rc shadow_track_dirty_vram()
Commit bd1b4a71b3 (x86/shadow: fix shadow_track_dirty_vram to work on
hvm guests), trying to mirror its HAP counterpart, deleted a couple of
assignments to rc without making sure rc is initialized on all paths.
Coverity ID: 1299410
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3518,7 +3518,7 @@ int shadow_track_dirty_vram(struct domain
unsigned long nr,
XEN_GUEST_HANDLE_64(uint8) guest_dirty_bitmap)
{
-int rc;
+int rc = 0;
unsigned long end_pfn = begin_pfn + nr;
unsigned long dirty_size = (nr + 7) / 8;
int flush_tlb = 0;
@@ -3550,10 +3550,7 @@ int shadow_track_dirty_vram(struct domain
}
if ( !nr )
-{
-rc = 0;
goto out;
-}
dirty_bitmap = vzalloc(dirty_size);
if ( dirty_bitmap == NULL )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/4] xen/shadow: fix shadow_track_dirty_vram to work on hvm guests
On 14.05.15 at 17:06, roger@citrix.com wrote:
@@ -3584,12 +3591,8 @@ int shadow_track_dirty_vram(struct domain *d,
rc = -ENODATA;
}
else if (dirty_vram-last_dirty == -1)
-{
/* still completely clean, just copy our empty bitmap */
-rc = -EFAULT;
-if ( copy_to_guest(dirty_bitmap, dirty_vram-dirty_bitmap,
dirty_size) == 0 )
-rc = 0;
-}
+memcpy(dirty_bitmap, dirty_vram-dirty_bitmap, dirty_size);
Btw, having looked at this again in the context of the coverity issue
it causes - wouldn't this (according to the retained comment) be a
memset()? And if so, in turn a loop over clear_page()?
Which gets me to a second thing: With the large amounts of data
being pushed through copy_to_guest() here and in its HAP
counterpart, wouldn't it make sense to have a specialized function
avoiding cache thrashing along the lines of clear_page() and
copy_page()?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 2/2] xen/block: add multi-page ring support
-Original Message-
From: Bob Liu [mailto:bob@oracle.com]
Sent: 22 May 2015 01:00
To: xen-devel@lists.xen.org
Cc: David Vrabel; just...@spectralogic.com; konrad.w...@oracle.com; Roger
Pau Monne; Paul Durrant; Julien Grall; boris.ostrov...@oracle.com; linux-
ker...@vger.kernel.org; Bob Liu
Subject: [PATCH v5 2/2] xen/block: add multi-page ring support
Extend xen/block to support multi-page ring, so that more requests can be
issued by using more than one pages as the request ring between blkfront
and backend.
As a result, the performance can get improved significantly.
We got some impressive improvements on our highend iscsi storage cluster
backend. If using 64 pages as the ring, the IOPS increased about 15 times
for the throughput testing and above doubled for the latency testing.
The reason was the limit on outstanding requests is 32 if use only one-page
ring, but in our case the iscsi lun was spread across about 100 physical
drives, 32 was really not enough to keep them busy.
Changes in v2:
- Rebased to 4.0-rc6.
- Document on how multi-page ring feature working to linux io/blkif.h.
Changes in v3:
- Remove changes to linux io/blkif.h and follow the protocol defined
in io/blkif.h of XEN tree.
- Rebased to 4.1-rc3
Changes in v4:
- Turn to use 'ring-page-order' and 'max-ring-page-order'.
- A few comments from Roger.
Changes in v5:
- Clarify 4k granularity to comment.
- Address more comments from Roger.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/block/xen-blkback/blkback.c | 13
drivers/block/xen-blkback/common.h | 3 +-
drivers/block/xen-blkback/xenbus.c | 88 +--
drivers/block/xen-blkfront.c| 135 +---
4 files changed, 179 insertions(+), 60 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c b/drivers/block/xen-
blkback/blkback.c
index 713fc9f..2126842 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -84,6 +84,13 @@ MODULE_PARM_DESC(max_persistent_grants,
Maximum number of grants to map persistently);
/*
+ * Maximum order of pages to be used for the shared ring between front
and
+ * backend, 4KB page granularity is used.
+ */
+unsigned int xen_blkif_max_ring_order =
XENBUS_MAX_RING_PAGE_ORDER;
+module_param_named(max_ring_page_order, xen_blkif_max_ring_order,
int, S_IRUGO);
+MODULE_PARM_DESC(max_ring_page_order, Maximum order of pages
to be used for the shared ring);
+/*
* The LRU mechanism to clean the lists of persistent grants needs to
* be executed periodically. The time interval between consecutive
executions
* of the purge mechanism is set in ms.
@@ -1438,6 +1445,12 @@ static int __init xen_blkif_init(void)
if (!xen_domain())
return -ENODEV;
+ if (xen_blkif_max_ring_order XENBUS_MAX_RING_PAGE_ORDER)
{
+ pr_info(Invalid max_ring_order (%d), will use default max:
%d.\n,
+ xen_blkif_max_ring_order,
XENBUS_MAX_RING_PAGE_ORDER);
+ xen_blkif_max_ring_order =
XENBUS_MAX_RING_PAGE_ORDER;
+ }
+
rc = xen_blkif_interface_init();
if (rc)
goto failed_init;
diff --git a/drivers/block/xen-blkback/common.h b/drivers/block/xen-
blkback/common.h
index f620b5d..919a1ab 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -44,6 +44,7 @@
#include xen/interface/io/blkif.h
#include xen/interface/io/protocols.h
+extern unsigned int xen_blkif_max_ring_order;
/*
* This is the maximum number of segments that would be allowed in
indirect
* requests. This value will also be passed to the frontend.
@@ -248,7 +249,7 @@ struct backend_info;
#define PERSISTENT_GNT_WAS_ACTIVE1
/* Number of requests that we can fit in a ring */
-#define XEN_BLKIF_REQS 32
+#define XEN_MAX_BLKIF_REQS (32 *
XENBUS_MAX_RING_PAGES)
struct persistent_gnt {
struct page *page;
diff --git a/drivers/block/xen-blkback/xenbus.c b/drivers/block/xen-
blkback/xenbus.c
index 6ab69ad..bc33888 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -25,6 +25,7 @@
/* Enlarge the array size in order to fully show blkback name. */
#define BLKBACK_NAME_LEN (20)
+#define RINGREF_NAME_LEN (20)
struct backend_info {
struct xenbus_device*dev;
@@ -152,7 +153,7 @@ static struct xen_blkif *xen_blkif_alloc(domid_t
domid)
INIT_LIST_HEAD(blkif-pending_free);
INIT_WORK(blkif-free_work, xen_blkif_deferred_free);
- for (i = 0; i XEN_BLKIF_REQS; i++) {
+ for (i = 0; i XEN_MAX_BLKIF_REQS; i++) {
How big is XEN_MAX_BLKIF_REQS? These allocations are per-instance so I'd be
concerned that the increase in the number of allocations would hit system
scalability.
Paul
req =
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 22.05.15 at 10:54, ian.campb...@citrix.com wrote:
May 22 01:28:33.149028 (XEN) VCPU information and callbacks for
domain 18:
May 22 01:28:33.156972 (XEN) VCPU0: CPU2 [has=F] poll=0
upcall_pend=00 upcall_mask=00 dirty_cpus={2}
May 22 01:28:33.165038 (XEN) cpu_hard_affinity={0-47}
cpu_soft_affinity={0-3}
May 22 01:28:33.173029 (XEN) pause_count=0 pause_flags=1
May 22 01:28:33.173064 (XEN) paging assistance: hap, 4 levels
May 22 01:28:33.181020 (XEN) No periodic timer
May 22 01:28:33.181052 (XEN) VCPU1: CPU1 [has=F] poll=0
upcall_pend=00 upcall_mask=00 dirty_cpus={1}
May 22 01:28:33.189031 (XEN) cpu_hard_affinity={0-47}
cpu_soft_affinity={0-3}
May 22 01:28:33.197069 (XEN) pause_count=0 pause_flags=1
May 22 01:28:33.197105 (XEN) paging assistance: hap, 4 levels
May 22 01:28:33.205013 (XEN) No periodic timer
At least this last part certainly isn't the same as in e.g. flight 56898,
where pause_flags=0 for both guest vCPU-s.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 56936: regressions - FAIL
flight 56936 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/56936/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: ovmf b965bd99c533b24bec56647a8c9b1fa2c2ed8bd8 baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Liming Gao liming@intel.com Ruiyu Ni ruiyu...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 500 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 56932: tolerable FAIL - PUSHED
flight 56932 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56932/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail like 55291
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never
pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never
pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
seabios 3752bf44be8931f86523ed538555b170a52d09dc
baseline version:
seabios 92f9b9189eb00da42a8bfcf26c664f48ee8d2868
People who touched revisions under test:
Vladimir Serbinenko phco...@gmail.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=seabios
+ revision=3752bf44be8931f86523ed538555b170a52d09dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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 seabios
3752bf44be8931f86523ed538555b170a52d09dc
+ branch=seabios
+ revision=3752bf44be8931f86523ed538555b170a52d09dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : 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/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : 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
Re: [Xen-devel] [PATCH V4] xen/vm_event: Clean up control-register-write vm_events
On 21.05.15 at 15:00, rcojoc...@bitdefender.com wrote:
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -88,55 +88,29 @@ static int hvm_event_traps(uint8_t sync,
vm_event_request_t *req)
return 1;
}
-static inline
-void hvm_event_cr(uint32_t reason, unsigned long value,
- unsigned long old, bool_t onchangeonly, bool_t sync)
+void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old)
{
-if ( onchangeonly value == old )
+struct arch_domain *currad = current-domain-arch;
+unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
+
+if ( !(currad-monitor.write_ctrlreg_enabled ctrlreg_bitmask) )
return;
-else
+
+if ( !(currad-monitor.write_ctrlreg_onchangeonly ctrlreg_bitmask) ||
+ value != old )
{
While this is now better than the previous if/else pair, I still don't
see why this can't be just a single if().
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2965,11 +2965,14 @@ out:
int hvm_handle_xsetbv(u32 index, u64 new_bv)
{
struct segment_register sreg;
+struct vcpu *curr = current;
-hvm_get_segment_register(current, x86_seg_ss, sreg);
+hvm_get_segment_register(curr, x86_seg_ss, sreg);
if ( sreg.attr.fields.dpl != 0 )
goto err;
+hvm_event_cr(VM_EVENT_X86_XCR0, new_bv, curr-arch.xcr0);
+
if ( handle_xsetbv(index, new_bv) )
goto err;
So this is a pre event now, contrary to all others. Is that really a
good idea? And is it a good idea in the first place to introduce new
events in a patch titled cleanup?
Also, for readability I wonder whether an identically named macro
wrapper around hvm_event_cr() wouldn't be a good idea, eliminating
the need to spell out VM_EVENT_X86_ at each use site.
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -67,59 +67,41 @@ int monitor_domctl(struct domain *d, struct
xen_domctl_monitor_op *mop)
switch ( mop-event )
{
-case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0:
+case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
{
-bool_t status = ad-monitor.mov_to_cr0_enabled;
-
-rc = status_check(mop, status);
-if ( rc )
-return rc;
-
-ad-monitor.mov_to_cr0_sync = mop-u.mov_to_cr.sync;
-ad-monitor.mov_to_cr0_onchangeonly = mop-u.mov_to_cr.onchangeonly;
-
-domain_pause(d);
-ad-monitor.mov_to_cr0_enabled = !status;
-domain_unpause(d);
-break;
-}
-
-case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3:
-{
-bool_t status = ad-monitor.mov_to_cr3_enabled;
+unsigned int ctrlreg_bitmask =
+monitor_ctrlreg_bitmask(mop-u.mov_to_cr.index);
+bool_t status = ad-monitor.write_ctrlreg_enabled ctrlreg_bitmask;
!!(ad-monitor.write_ctrlreg_enabled ctrlreg_bitmask)
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -249,6 +249,8 @@ struct pv_domain
struct mapcache_domain mapcache;
};
+#define monitor_ctrlreg_bitmask(ctrlreg_index) (1 ctrlreg_index)
(1U (ctrlreg_index)) would seem better to me. Also - does this
need to be in this header (which gets included basically everywhere)?
@@ -1050,6 +1048,8 @@ struct xen_domctl_monitor_op {
*/
union {
struct {
+/* Which control register */
+uint8_t index;
Okay, 8 bits here (which is reasonable), but ...
@@ -156,7 +158,8 @@ struct vm_event_mem_access {
uint32_t _pad;
};
-struct vm_event_mov_to_cr {
+struct vm_event_write_ctrlreg {
+uint64_t index;
uint64_t new_value;
uint64_t old_value;
};
... a full 64 bits here? 32 bits surely would do (with 32 bits of padding),
allowing slightly better accessing code on both the consumer and
producer sides.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4] xen/vm_event: Clean up control-register-write vm_events
On 05/22/2015 10:36 AM, Jan Beulich wrote:
On 21.05.15 at 15:00, rcojoc...@bitdefender.com wrote:
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -88,55 +88,29 @@ static int hvm_event_traps(uint8_t sync,
vm_event_request_t *req)
return 1;
}
-static inline
-void hvm_event_cr(uint32_t reason, unsigned long value,
- unsigned long old, bool_t onchangeonly, bool_t
sync)
+void hvm_event_cr(unsigned int index, unsigned long value, unsigned long
old)
{
-if ( onchangeonly value == old )
+struct arch_domain *currad = current-domain-arch;
+unsigned int ctrlreg_bitmask = monitor_ctrlreg_bitmask(index);
+
+if ( !(currad-monitor.write_ctrlreg_enabled ctrlreg_bitmask) )
return;
-else
+
+if ( !(currad-monitor.write_ctrlreg_onchangeonly ctrlreg_bitmask) ||
+ value != old )
{
While this is now better than the previous if/else pair, I still don't
see why this can't be just a single if().
Ack, will change it to a single if.
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2965,11 +2965,14 @@ out:
int hvm_handle_xsetbv(u32 index, u64 new_bv)
{
struct segment_register sreg;
+struct vcpu *curr = current;
-hvm_get_segment_register(current, x86_seg_ss, sreg);
+hvm_get_segment_register(curr, x86_seg_ss, sreg);
if ( sreg.attr.fields.dpl != 0 )
goto err;
+hvm_event_cr(VM_EVENT_X86_XCR0, new_bv, curr-arch.xcr0);
+
if ( handle_xsetbv(index, new_bv) )
goto err;
So this is a pre event now, contrary to all others. Is that really a
good idea? And is it a good idea in the first place to introduce new
events in a patch titled cleanup?
While it is indeed different from the rest of the CR events in that it
is a pre-write, it is not however different from the MSR event, which is
currently pre-write.
As for introducing the new event, it's a trivial one-line change if we
don't count the VM_EVENT_X86_XCR0 constant and the extra bit in the
enabled, sync and onchangeonly fields.
Should I drop the introduction of the XR0 event from this patch and come
back to it in the following iteration of the series?
Also, for readability I wonder whether an identically named macro
wrapper around hvm_event_cr() wouldn't be a good idea, eliminating
the need to spell out VM_EVENT_X86_ at each use site.
#define hvm_event_cr0(new, old) hvm_event_cr(VM_EVENT_X86_XCR0, new,
old)? Sure.
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -67,59 +67,41 @@ int monitor_domctl(struct domain *d, struct
xen_domctl_monitor_op *mop)
switch ( mop-event )
{
-case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0:
+case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
{
-bool_t status = ad-monitor.mov_to_cr0_enabled;
-
-rc = status_check(mop, status);
-if ( rc )
-return rc;
-
-ad-monitor.mov_to_cr0_sync = mop-u.mov_to_cr.sync;
-ad-monitor.mov_to_cr0_onchangeonly = mop-u.mov_to_cr.onchangeonly;
-
-domain_pause(d);
-ad-monitor.mov_to_cr0_enabled = !status;
-domain_unpause(d);
-break;
-}
-
-case XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3:
-{
-bool_t status = ad-monitor.mov_to_cr3_enabled;
+unsigned int ctrlreg_bitmask =
+monitor_ctrlreg_bitmask(mop-u.mov_to_cr.index);
+bool_t status = ad-monitor.write_ctrlreg_enabled ctrlreg_bitmask;
!!(ad-monitor.write_ctrlreg_enabled ctrlreg_bitmask)
Ack.
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -249,6 +249,8 @@ struct pv_domain
struct mapcache_domain mapcache;
};
+#define monitor_ctrlreg_bitmask(ctrlreg_index) (1 ctrlreg_index)
(1U (ctrlreg_index)) would seem better to me. Also - does this
need to be in this header (which gets included basically everywhere)?
Ack. As for the header, that's where the fields are
(write_ctrlreg_enabled, sync and onchangeonly), and since several .c
files use the fields it seemed the natural place to put the macros.
@@ -1050,6 +1048,8 @@ struct xen_domctl_monitor_op {
*/
union {
struct {
+/* Which control register */
+uint8_t index;
Okay, 8 bits here (which is reasonable), but ...
@@ -156,7 +158,8 @@ struct vm_event_mem_access {
uint32_t _pad;
};
-struct vm_event_mov_to_cr {
+struct vm_event_write_ctrlreg {
+uint64_t index;
uint64_t new_value;
uint64_t old_value;
};
... a full 64 bits here? 32 bits surely would do (with 32 bits of padding),
allowing slightly better accessing code on both the consumer and
producer sides.
Ack, will modify it. I set it to 64 bits there because I thought I'd get
free padding, but you're right, it's better to be explicit.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
[Xen-devel] [PATCH v3 3/8] xenalyze: print newline after unknown hvm events
Signed-off-by: Olaf Hering o...@aepfle.de Acked-by: George Dunlap george.dun...@eu.citrix.com Acked-by: Wei Liu wei.l...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/xentrace/xenalyze.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c index 5f0757b..51a2d1d 100644 --- a/tools/xentrace/xenalyze.c +++ b/tools/xentrace/xenalyze.c @@ -5435,7 +5435,7 @@ void hvm_process(struct pcpu_info *p) hvm_vmentry_process(ri, p-current-hvm); break; default: -fprintf(warn, Unknown hvm event: %x, ri-event); +fprintf(warn, Unknown hvm event: %x\n, ri-event); } } } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/8] add xenalyze to staging
Having xenalyze in the source tree makes it much easier to keep private debug code in hypervisor and xenalyze in sync. It helped alot while debugging the root cause for commit 607e8494c42397fb249191904066cace6ac9a880. changes between v2 and v3: - move to tools/xentrace changes between v1 and v2: - move to tools/xentrace/xenalyze - drop patch which touches sched_switch_process - add patch to remove argp_program_version - add patch to bump NR_CPUS Olaf Olaf Hering (8): xenalyze: add to tools/xentrace/ xenalyze: increase NR_CPUS to 256 xenalyze: print newline after unknown hvm events xenalyze: include odd mmio states in default output xenalyze: handle TRC_TRACE_WRAP_BUFFER xenalyze: handle more events in sched_process xenalyze: remove traling whitespaces xenalyze: remove argp_program_version .gitignore| 1 + tools/xentrace/Makefile | 9 +- tools/xentrace/analyze.h | 107 + tools/xentrace/mread.c| 160 + tools/xentrace/mread.h|18 + tools/xentrace/pv.h |41 + tools/xentrace/xenalyze.c | 10469 7 files changed, 10804 insertions(+), 1 deletion(-) create mode 100644 tools/xentrace/analyze.h create mode 100644 tools/xentrace/mread.c create mode 100644 tools/xentrace/mread.h create mode 100644 tools/xentrace/pv.h create mode 100644 tools/xentrace/xenalyze.c ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/8] xenalyze: increase NR_CPUS to 256
To match the hypervisor default which was introduced in 9da0c5b63933b9912e3903190601661813954d0d, bump the limit. Signed-off-by: Olaf Hering o...@aepfle.de Acked-by: George Dunlap george.dun...@eu.citrix.com Acked-by: Wei Liu wei.l...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/xentrace/analyze.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/xentrace/analyze.h b/tools/xentrace/analyze.h index 40ee551..64b1911 100644 --- a/tools/xentrace/analyze.h +++ b/tools/xentrace/analyze.h @@ -16,7 +16,7 @@ #define TRC_LOST_RECORDS_END(TRC_GEN + 50) -#define NR_CPUS 128 +#define NR_CPUS 256 #if __x86_64__ # define BITS_PER_LONG 64 #else ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/8] xenalyze: include odd mmio states in default output
Signed-off-by: Olaf Hering o...@aepfle.de
Acked-by: George Dunlap george.dun...@eu.citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 51a2d1d..58e8456 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -3740,7 +3740,7 @@ void hvm_mmio_assist_postprocess(struct hvm_data *h)
static int warned = 0;
if (!warned)
{
-fprintf(stderr, %s: Strange, MMIO with unexpected exit reason
%d\n,
+fprintf(warn, %s: Strange, MMIO with unexpected exit reason %d\n,
__func__, h-exit_reason);
warned=1;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On 22/05/15 09:54, Ian Campbell wrote: In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. This is because there is no such thing as ACPI shutdown. There is ACPI Someone pressed the power button and ACPI Someone closed the laptop lid. I believe Win7 attempts to sleep by default, rather than to shut down, although IIRC this does depend on which S states are offered in the ACPI tables. One thing to try would be to boot windows without any S3 or S4 SSDT tables, which should persuade windows into believing that someone pressed the power button should mean S5 shutdown. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] ACPI shutdown unreliable with win7?
On Fri, 2015-05-22 at 09:59 +0100, Andrew Cooper wrote: On 22/05/15 09:54, Ian Campbell wrote: In osstest self gate flight 56412 a change to make HVM guests configurably use xl shutdown -F (-F == use ACPI fallback if PV drivers absent) and apply the option to the win7 and winxpsp3 tests went into production. On winxpsp3 this appears to have been a success and things are working pretty well since that flight: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-winxpsp3-vcpus1.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-winxpsp3-vcpus1.html However win7 seems to be in somewhat poorer shape: http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemuu-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-amd64-xl-qemut-win7-amd64.html http://logs.test-lab.xenproject.org/osstest/results/history.test-amd64-i386-xl-qemut-win7-amd64.html it passes less than one time in 10 (of the ones which don't get blocked earlier on). The problem seems to be independent of the qemu version and with qemuu of seabios vs rombios. dom0 kernel also seems irrelevant. This is because there is no such thing as ACPI shutdown. There is ACPI Someone pressed the power button and ACPI Someone closed the laptop lid. Understood, however this did work in my manual testing and does occasionally pass. e.g. in http://logs.test-lab.xenproject.org/osstest/logs/56759/test-amd64-amd64-xl-qemut-win7-amd64/info.html which was successful the qemu log shows: shutdown requested in cpu_handle_ioreq Issued domain 18 poweroff Log-dirty: no command yet. In the failure cases there is no indication in the logs or screenshots that windows is either hibernating or shutting down, or doing anything else at all. I believe Win7 attempts to sleep by default, rather than to shut down, although IIRC this does depend on which S states are offered in the ACPI tables. osstest ought to be providing the exact same thing each time, so unless there is some non-determinism in win7's logic (I would hope not) I think it ought to be making the same choice each time. One thing to try would be to boot windows without any S3 or S4 SSDT tables, which should persuade windows into believing that someone pressed the power button should mean S5 shutdown. If win7 doesn't shutdown given a power button request I'd be more inclined to remove the setting in osstest for those flights and let guest-stop go back to being never pass than to start making such changes to the VM config which I think would probably break the preceding suspend and migration tests (which aren't completely reliable, but are far more so than this shutdown one). Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [seabios test] 56972: tolerable FAIL - PUSHED
flight 56972 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56972/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never
pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never
pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
seabios 67643955c7467781c28c4da1669775d7564dc74a
baseline version:
seabios 3752bf44be8931f86523ed538555b170a52d09dc
People who touched revisions under test:
Kevin O'Connor ke...@koconnor.net
Quan Xu quan...@intel.com
Stefan Berger stef...@linux.vnet.ibm.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=seabios
+ revision=67643955c7467781c28c4da1669775d7564dc74a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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 seabios
67643955c7467781c28c4da1669775d7564dc74a
+ branch=seabios
+ revision=67643955c7467781c28c4da1669775d7564dc74a
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ 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=seabios
+ xenbranch=xen-unstable
+ '[' xseabios = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : 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/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : 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
Re: [Xen-devel] Regression due to device property: Make it possible to use secondary firmware nodes Re: Xen-unstable + linux 4.1-mergewindow: problems with PV guest pci passthrough: pcifront pci-0:
On 05/22/2015 04:11 AM, Sander Eikelenboom wrote: Hello Sander, Friday, May 15, 2015, 12:47:27 AM, you wrote: Sorry for the resend, i messed up the to's en from's. Hi Konrad / David, One big snip on this thread, got some more debug info, hopefully this will lead to something: On a working kernel (with the two seemingly non related patches reverted) i get: [0.717796] pcifront pci-0: Allocated pdev @ 0x880019e11780 pdev-sh_info @ 0x880018f58000 [0.717848] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.717871] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.717892] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.717915] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.717984] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.721640] pcifront pci-0: publishing successful! [0.723684] usbcore: registered new interface driver udlfb [0.724664] xen:xen_evtchn: Event-channel device installed [0.726597] pcifront pci-0: Installing PCI frontend [0.726853] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.727059] pcifront pci-0: Creating PCI Frontend Bus :00 [0.727363] pcifront pci-0: PCI host bridge to bus :00 [0.727391] pci_bus :00: root bus resource [io 0x-0x] [0.727417] pci_bus :00: root bus resource [mem 0x-0x] [0.727452] pci_bus :00: root bus resource [bus 00-ff] [0.727475] pci_bus :00: scanning bus [0.727503] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.728253] Linux agpgart interface v0.103 [0.728387] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.728474] [drm] Initialized drm 1.1.0 20060810 [0.728551] [drm] radeon kernel modesetting enabled. [0.730319] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 143164178555170 ns_timeout: 1431641787541235000 evtchn:17 gnt_ref:8 [0.730319] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:0 size:4 [0.730319] pcifront pci-0: read got back value 3f6 [0.738845] pcifront pci-0: read dev=:00:00.0 - offset e size 1 [0.744976] brd: module loaded [0.745204] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785562852000 ns_timeout: 143164178755258 evtchn:17 gnt_ref:8 [0.745204] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:14 size:1 [0.745204] pcifront pci-0: read got back value 0 [0.749204] pcifront pci-0: read dev=:00:00.0 - offset 6 size 2 [0.750155] loop: module loaded [0.752527] pcifront pci-0: ?!?!? pciback responded !!! irq:31 irq_flags:880019e100a8 ns: 1431641785570841000 ns_timeout: 1431641787562917000 evtchn:17 gnt_ref:8 [0.752527] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: ?!?!? active_op cmd:0 err:0 info:0 offset:6 size:2 [0.752527] pcifront pci-0: read got back value 210 [0.757187] pcifront pci-0: read dev=:00:00.0 - offset 34 size 1 Were as in the non-working situation i get: [0.751244] pcifront pci-0: Allocated pdev @ 0x880019ec2e00 pdev-sh_info @ 0x88001aa51000 [0.751295] pcifront pci-0: ?!?!? before alloc gntref: 0 [0.751315] pcifront pci-0: ?!?!? after alloc gntref: 8 [0.751334] pcifront pci-0: ?!?!? before alloc evtchn: -1 [0.751355] pcifront pci-0: ?!?!? after alloc evtchn: 17 [0.751422] pcifront pci-0: ?!?!? bound evtchn:17 to irqhandler:-1 err:31 [0.755215] pcifront pci-0: publishing successful! [0.757341] usbcore: registered new interface driver udlfb [0.758365] xen:xen_evtchn: Event-channel device installed [0.760419] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.760819] pcifront pci-0: Installing PCI frontend [0.761518] pcifront pci-0: Creating PCI Frontend Bus :00 [0.761684] pcifront pci-0: PCI host bridge to bus :00 [0.761710] pci_bus :00: root bus resource [io 0x-0x] [0.761733] pci_bus :00: root bus resource [mem 0x-0x] [0.761763] pci_bus :00: root bus resource [bus 00-ff] [0.761783] pci_bus :00: scanning bus [0.761805] pcifront pci-0: read dev=:00:00.0 - offset 0 size 4 [0.767207] Linux agpgart interface v0.103 [0.767362] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.767439] [drm] Initialized drm 1.1.0 20060810 [0.767515] [drm] radeon kernel modesetting enabled. [0.766948] pcifront pci-0: pciback not responding!!! irq:31 irq_flags:880019ec0028 ns: 1431641983026498000 ns_timeout: 1431641983026497000 evtchn:0 gnt_ref:0 [0.766948] pcifront pci-0: ?!?!? op cmd:0 err:0 info:0 offset:0 size:4 [
[Xen-devel] [linux-3.4 test] 56979: regressions - FAIL
flight 56979 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/56979/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all 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 fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail
[Xen-devel] [ovmf test] 56974: regressions - FAIL
flight 56974 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/56974/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-installfail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: ovmf e7401ee1af263ff946a57f047124241fa4f01cd5 baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Liming Gao liming@intel.com Ruiyu Ni ruiyu...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-amd64-i386-qemuu-rhel6hvm-intel pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass test-amd64-amd64-xl-qemuu-winxpsp3 pass test-amd64-i386-xl-qemuu-winxpsp3pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 527 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 3/4] pci: add wrapper for parse_pci
From: Elena Ufimtseva elena.ufimts...@oracle.com
For sbdf'si parsing in rmrr command line add __parse_pci with addtional
parameter def_seg. __parse_pci will help to identify if segment was found
in string being parsed or default segment was used.
Make a wrapper parse_pci so the rest of the callers are not affected.
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/drivers/pci/pci.c | 11 +++
xen/include/xen/pci.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/xen/drivers/pci/pci.c b/xen/drivers/pci/pci.c
index ca07ed0..d41696a 100644
--- a/xen/drivers/pci/pci.c
+++ b/xen/drivers/pci/pci.c
@@ -119,11 +119,21 @@ const char *__init parse_pci(const char *s, unsigned int
*seg_p,
unsigned int *bus_p, unsigned int *dev_p,
unsigned int *func_p)
{
+int def_seg;
+__parse_pci(s, seg_p, bus_p, dev_p, func_p, def_seg);
+return s;
+}
+
+const char *__init __parse_pci(const char *s, unsigned int *seg_p,
+ unsigned int *bus_p, unsigned int *dev_p,
+ unsigned int *func_p, int *def_seg)
+{
unsigned long seg = simple_strtoul(s, s, 16), bus, dev, func;
if ( *s != ':' )
return NULL;
bus = simple_strtoul(s + 1, s, 16);
+def_seg = 0;
if ( *s == ':' )
dev = simple_strtoul(s + 1, s, 16);
else
@@ -131,6 +141,7 @@ const char *__init parse_pci(const char *s, unsigned int
*seg_p,
dev = bus;
bus = seg;
seg = 0;
+*def_seg = 1;
}
if ( func_p )
{
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 4ddf791..fb24107 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -149,6 +149,9 @@ int pci_find_ext_capability(int seg, int bus, int devfn,
int cap);
int pci_find_next_ext_capability(int seg, int bus, int devfn, int pos, int
cap);
const char *parse_pci(const char *, unsigned int *seg, unsigned int *bus,
unsigned int *dev, unsigned int *func);
+const char *__parse_pci(const char *, unsigned int *seg, unsigned int *bus,
+ unsigned int *dev, unsigned int *func, int *def_seg);
+
bool_t pcie_aer_get_firmware_first(const struct pci_dev *);
--
2.1.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 1/4] pci: add PCI_SBDF macro
From: Elena Ufimtseva elena.ufimts...@oracle.com
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/include/xen/pci.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 4377f3e..4ddf791 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -33,6 +33,7 @@
#define PCI_DEVFN2(bdf) ((bdf) 0xff)
#define PCI_BDF(b,d,f) b) 0xff) 8) | PCI_DEVFN(d,f))
#define PCI_BDF2(b,df) b) 0xff) 8) | ((df) 0xff))
+#define PCI_SBDF(s,b,d,f) s) 0x) 16) | PCI_BDF(b,d,f))
struct pci_dev_info {
bool_t is_extfn;
--
2.1.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 2/4] iommu VT-d: separate rmrr addition function
From: Elena Ufimtseva elena.ufimts...@oracle.com
In preparation for auxiliary RMRR data provided on Xen
command line, make RMRR adding a separate function.
Also free memery for rmrr device scope in error path.
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/drivers/passthrough/vtd/dmar.c | 130 -
1 file changed, 69 insertions(+), 61 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index b735f80..fa19ba7 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -571,6 +571,72 @@ out:
return ret;
}
+static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
+{
+bool_t ignore = 0;
+unsigned int i = 0;
+int ret = 0;
+
+/* Skip checking if segment is not accessible yet. */
+if ( !pci_known_segment(rmrru-segment) )
+{
+dprintk(XENLOG_WARNING VTDPREFIX, UNKNOWN Prefix! %04x,
rmrru-segment);
+i = UINT_MAX;
+}
+
+for ( ; i rmrru-scope.devices_cnt; i++ )
+{
+u8 b = PCI_BUS(rmrru-scope.devices[i]);
+u8 d = PCI_SLOT(rmrru-scope.devices[i]);
+u8 f = PCI_FUNC(rmrru-scope.devices[i]);
+
+if ( pci_device_detect(rmrru-segment, b, d, f) == 0 )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ Non-existent device (%04x:%02x:%02x.%u) is reported
+ in RMRR (%PRIx64, %PRIx64)'s scope!\n,
+rmrru-segment, b, d, f,
+rmrru-base_address, rmrru-end_address);
+ignore = 1;
+}
+else
+{
+ignore = 0;
+break;
+}
+}
+
+if ( ignore )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ Ignore the RMRR (%PRIx64, %PRIx64) due to
+devices under its scope are not PCI discoverable!\n,
+rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
+xfree(rmrru);
+}
+else if ( rmrru-base_address rmrru-end_address )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
+rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
+xfree(rmrru);
+ret = -EFAULT;
+}
+else
+{
+if ( iommu_verbose )
+dprintk(VTDPREFIX,
+ RMRR region: base_addr %PRIx64
+ end_address %PRIx64\n,
+rmrru-base_address, rmrru-end_address);
+acpi_register_rmrr_unit(rmrru);
+}
+
+return ret;
+}
+
static int __init
acpi_parse_one_rmrr(struct acpi_dmar_header *header)
{
@@ -621,68 +687,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
rmrru-scope, RMRR_TYPE, rmrr-segment);
-if ( ret || (rmrru-scope.devices_cnt == 0) )
-xfree(rmrru);
+if ( !ret (rmrru-scope.devices_cnt != 0) )
+return register_one_rmrr(rmrru);
else
-{
-u8 b, d, f;
-bool_t ignore = 0;
-unsigned int i = 0;
-
-/* Skip checking if segment is not accessible yet. */
-if ( !pci_known_segment(rmrr-segment) )
-i = UINT_MAX;
-
-for ( ; i rmrru-scope.devices_cnt; i++ )
-{
-b = PCI_BUS(rmrru-scope.devices[i]);
-d = PCI_SLOT(rmrru-scope.devices[i]);
-f = PCI_FUNC(rmrru-scope.devices[i]);
-
-if ( pci_device_detect(rmrr-segment, b, d, f) == 0 )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- Non-existent device (%04x:%02x:%02x.%u) is reported
- in RMRR (%PRIx64, %PRIx64)'s scope!\n,
-rmrr-segment, b, d, f,
-rmrru-base_address, rmrru-end_address);
-ignore = 1;
-}
-else
-{
-ignore = 0;
-break;
-}
-}
-
-if ( ignore )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- Ignore the RMRR (%PRIx64, %PRIx64) due to
-devices under its scope are not PCI discoverable!\n,
-rmrru-base_address, rmrru-end_address);
-xfree(rmrru-scope.devices);
-xfree(rmrru);
-}
-else if ( base_addr end_addr )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
-rmrru-base_address, rmrru-end_address);
-xfree(rmrru-scope.devices);
-xfree(rmrru);
-ret = -EFAULT;
-}
-else
-{
-if ( iommu_verbose )
-dprintk(VTDPREFIX,
- RMRR region: base_addr %PRIx64
- end_address %PRIx64\n,
-
[Xen-devel] [PATCH v5 0/4] iommu: add rmrr Xen command line option
From: Elena Ufimtseva elena.ufimts...@oracle.com Add Xen command line option rmrr to specify RMRR regions for devices that are not defined in ACPI thus causing IO Page Fault while booting dom0 in PVH mode. These additional regions will be added to the list of RMRR regions parsed from ACPI. Changes in v5: - make parse_pci a wrapper and add __parse_pci with additional def_seg param to identify if segment was specified; - make possible not to define segment for each device within same rmrr; - limit number of pages for one RMRR by 16; - run mfn_valid check for every address in RMRR range; - add PCI_SBDF macro; - remove list for extra rmrrs as they are kept in static array; Changes in v4 after comments by Jan Beulich: - keep sbdf per device instead of bdf and one segment per RMRR when parsing and compare later; - add check for segment values and make sure they are same for one RMRR; - move RMRR parameters checks and add error messages if RMRRs are incorrect; - make relevant variables and functions static; - mention requirement for segment values in rmrr documentation; Changes in v3: - use ';' instead of '#' in command line and add proper notes for grub ';' special treatment; Changes in v2: - move rmrr parser to dmar.c and make it custom_param; - change of rmrr command line oprion format; since adding multiple device per range support needs to utilize more special characters and offered from the previous review ';' is not supported, '[' ']' are reserved, ':' and used in pci format, range and devices are separated by '#'; Suggestions are welcome; - added support for multiple devices per range; - moved adding misc RMRRs before ACPI RMRR parsing; - make parser fail if pci device is specified incorrectly; Elena Ufimtseva (4): pci: add PCI_SBDF macro iommu VT-d: separate rmrr addition function pci: add wrapper for parse_pci iommu: add rmrr Xen command line option for extra rmrrs docs/misc/xen-command-line.markdown | 13 ++ xen/drivers/passthrough/vtd/dmar.c | 270 xen/drivers/passthrough/vtd/dmar.h | 10 ++ xen/drivers/pci/pci.c | 11 ++ xen/include/xen/pci.h | 4 + 5 files changed, 247 insertions(+), 61 deletions(-) -- 2.1.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 56922: regressions - FAIL
On Fri, 2015-05-22 at 15:21 +0100, Ian Campbell wrote:
On Fri, 2015-05-22 at 14:42 +0100, Ian Campbell wrote:
From my particular grub.cfg. For real usage setupboot_grub2 will
obviously need to become cleverer to count things correctly.
I've not tested extensively but the following incremental patch seems to
do the right thing, at least by inspection of the resulting grub.cfg.
Needs more testing (e.g. I haven't tried non-XSM yet) and review from
Ian I think, since there may be a more idiomatically Perl way to
manipulate the @offsets array (in particular shrinking it).
Thanks Ian. You are so quick. I wrote that piece of code almost a year
ago; was just about to warm up.
We're to test your fix in our environment as well on non-XSM.
Ian.
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 282175b..b5148fd 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -393,8 +393,6 @@ sub setupboot_grub1 () {
# Note on running OSSTest on Squeeze with old Xen kernel: check out
# Debian bug #633127 /etc/grub/20_linux does not recognise some old
# Xen kernels
-# Currently setupboot_grub2 relies on Grub menu not having submenu.
-# Check Debian bug #690538.
sub setupboot_grub2 () {
my ($ho,$want_kernver,$want_xsm,$xenhopt,$xenkopt) = @_;
my $bl= { };
@@ -405,7 +403,7 @@ sub setupboot_grub2 () {
my $parsemenu= sub {
my $f= bl_getmenu_open($ho, $rmenu,
$stash/$ho-{Name}--grub.cfg.1);
-my $count= 0;
+my @offsets = (0);
my $entry;
my $submenu;
while ($f) {
@@ -417,6 +415,8 @@ sub setupboot_grub2 () {
$submenu-{StartLine}. .
Our want kern is $want_kernver);
$submenu=undef;
+$#offsets = $#offsets-1;
+$offsets[$#offsets]++;
next;
}
my (@missing) =
@@ -446,11 +446,12 @@ sub setupboot_grub2 () {
}
if (m/^menuentry\s+[\'\](.*)[\'\].*\{\s*$/) {
die $entry-{StartLine} if $entry;
-$entry= { Title = $1, StartLine = $., Number = $count };
-$count++;
+$entry= { Title = $1, StartLine = $., MenuEntryPath =
join , @offsets };
+$offsets[$#offsets]++;
}
if (m/^submenu\s+[\'\](.*)[\'\].*\{\s*$/) {
-$submenu={ StartLine =$.};
+$submenu={ StartLine =$., MenuEntryPath = join ,
@offsets };
+$offsets[$#offsets+1] = 0;
}
if (m/^\s*multiboot\s*(?:\/boot)?\/(xen\S+)/) {
die unless $entry;
@@ -511,7 +512,7 @@ sub setupboot_grub2 () {
}
print ::EO END or die $!;
-GRUB_DEFAULT=$entry-{Number}
+GRUB_DEFAULT=$entry-{MenuEntryPath}
END
print ::EO END or die $! if defined $xenhopt;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
Hi Dario, 2015-05-22 3:19 GMT-07:00 Dario Faggioli dario.faggi...@citrix.com: [ Adding to Cc the people that I though I added when sending the patch, but that apparently I haven't...sorry :-( ] Thanks for cc.ing us. :-) On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. It therefore makes sense to stop smoke testing the former in favour of the latter. Note that the -sedf-pin jobs where only added in order to try to debug a long standing issue with SEDF; it is not necessary to have anything like that for RTDS. For now, as RTDS is still marked as experimental, test failures are allowed, as it was for SEDF. [1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html Oh, and here's the diff of the generated runvars that IanJ usually asks about: :-) I'm not so familiar with osstest. (Maybe I should have a look at it so that we can know how to use it for some auto tests.) I just have a quick (probably dummy) question: Do we have any document that describes the coverage of the test? The reason I asked this is: 1) The document could make it easier for users to know which functionalities of the feature (i.e., RTDS scheduler here) have been tested. 2) I didn't see the toolstack functionality of RTDS scheduler is called in the test. So I'm wondering about the first question. :-) (probably I missed something?) Thanks, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 56978: tolerable FAIL
flight 56978 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/56978/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 56791 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 56791 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 56791 test-amd64-amd64-libvirt 11 guest-start fail like 56791 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass version targeted for testing: linux7b00d66851e86b4a579c3354bde19333de10ee98 baseline version: linux1113cdfe7d2c1fe08b64caa3affe19260e66dd95 jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm fail test-armhf-armhf-xl-xsm fail test-amd64-i386-xl-xsm fail 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 fail test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
[Xen-devel] [PATCH] dmar: device scope mem leak fix
From: Elena Ufimtseva elena.ufimts...@oracle.com
Release memory allocated for scope.devices when disabling
dmar units. Also set device count after memory allocation when
device scope parsing.
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/drivers/passthrough/vtd/dmar.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 18d7903..b735f80 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -90,16 +90,19 @@ static void __init disable_all_dmar_units(void)
list_for_each_entry_safe ( drhd, _drhd, acpi_drhd_units, list )
{
list_del(drhd-list);
+xfree(drhd-scope.devices);
xfree(drhd);
}
list_for_each_entry_safe ( rmrr, _rmrr, acpi_rmrr_units, list )
{
list_del(rmrr-list);
+xfree(rmrr-scope.devices);
xfree(rmrr);
}
list_for_each_entry_safe ( atsr, _atsr, acpi_atsr_units, list )
{
list_del(atsr-list);
+xfree(atsr-scope.devices);
xfree(atsr);
}
}
@@ -318,13 +321,13 @@ static int __init acpi_parse_dev_scope(
if ( (cnt = scope_device_count(start, end)) 0 )
return cnt;
-scope-devices_cnt = cnt;
if ( cnt 0 )
{
scope-devices = xzalloc_array(u16, cnt);
if ( !scope-devices )
return -ENOMEM;
}
+scope-devices_cnt = cnt;
while ( start end )
{
@@ -658,6 +661,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
Ignore the RMRR (%PRIx64, %PRIx64) due to
devices under its scope are not PCI discoverable!\n,
rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
xfree(rmrru);
}
else if ( base_addr end_addr )
@@ -665,6 +669,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
dprintk(XENLOG_WARNING VTDPREFIX,
The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
xfree(rmrru);
ret = -EFAULT;
}
--
2.1.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [rumpuserxen test] 57033: regressions - FAIL
flight 57033 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/57033/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 5/5] libxl/FreeBSD: add support for disk hotplug scripts
Allow FreeBSD to execute hotplug scripts when attaching disk devices.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl_freebsd.c | 114
1 file changed, 83 insertions(+), 31 deletions(-)
diff --git a/tools/libxl/libxl_freebsd.c b/tools/libxl/libxl_freebsd.c
index 47c3391..5ff3388 100644
--- a/tools/libxl/libxl_freebsd.c
+++ b/tools/libxl/libxl_freebsd.c
@@ -59,14 +59,36 @@ static int libxl__hotplug_env_nic(libxl__gc *gc,
libxl__device *dev, char ***env
return 0;
}
-static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev, char ***args,
- libxl__device_action action)
+static int libxl__hotplug_nic(libxl__gc *gc, libxl__device *dev,
+ char ***args, char ***env,
+ libxl__device_action action,
+ int num_exec)
{
+libxl_nic_type nictype;
char *be_path = libxl__device_backend_path(gc, dev);
char *script;
-int nr = 0, rc = 0, arraysize = 4;
+int nr = 0, rc;
-assert(dev-backend_kind == LIBXL__DEVICE_KIND_VIF);
+rc = libxl__nic_type(gc, dev, nictype);
+if (rc) {
+LOG(ERROR, error when fetching nic type);
+rc = ERROR_FAIL;
+goto out;
+}
+
+/*
+ * For PV domains only one pass is needed (because there's no emulated
+ * interface). For HVM domains two passes are needed in order to add
+ * both the PV and the tap interfaces to the bridge.
+ */
+if (nictype == LIBXL_NIC_TYPE_VIF num_exec != 0) {
+rc = 0;
+goto out;
+}
+
+rc = libxl__hotplug_env_nic(gc, dev, env, num_exec);
+if (rc)
+goto out;
script = libxl__xs_read(gc, XBT_NULL,
GCSPRINTF(%s/%s, be_path, script));
@@ -76,53 +98,83 @@ static int libxl__hotplug_nic(libxl__gc *gc, libxl__device
*dev, char ***args,
goto out;
}
+const int arraysize = 4;
GCNEW_ARRAY(*args, arraysize);
(*args)[nr++] = script;
(*args)[nr++] = be_path;
-(*args)[nr++] = GCSPRINTF(%s, action == LIBXL__DEVICE_ACTION_ADD ?
-add : remove);
+(*args)[nr++] = (char *) libxl__device_action_to_string(action);
(*args)[nr++] = NULL;
assert(nr == arraysize);
+rc = 1;
+
out:
return rc;
}
+static int libxl__hotplug_disk(libxl__gc *gc, libxl__device *dev,
+ char ***args, char ***env,
+ libxl__device_action action)
+{
+char *be_path = libxl__device_backend_path(gc, dev);
+char *script;
+int nr = 0, rc;
+
+script = libxl__xs_read(gc, XBT_NULL,
+GCSPRINTF(%s/%s, be_path, script));
+if (!script) {
+LOGEV(ERROR, errno, unable to read script from %s, be_path);
+rc = ERROR_FAIL;
+goto error;
+}
+
+const int arraysize = 4;
+GCNEW_ARRAY(*args, arraysize);
+(*args)[nr++] = script;
+(*args)[nr++] = be_path;
+(*args)[nr++] = (char *) libxl__device_action_to_string(action);
+(*args)[nr++] = NULL;
+assert(nr == arraysize);
+
+rc = 1;
+
+error:
+return rc;
+}
+
int libxl__get_hotplug_script_info(libxl__gc *gc, libxl__device *dev,
char ***args, char ***env,
libxl__device_action action,
int num_exec)
{
-libxl_nic_type nictype;
int rc;
-if (dev-backend_kind != LIBXL__DEVICE_KIND_VIF || num_exec == 2)
-return 0;
-
-rc = libxl__nic_type(gc, dev, nictype);
-if (rc) {
-LOG(ERROR, error when fetching nic type);
-rc = ERROR_FAIL;
-goto out;
-}
-
-/*
- * For PV domains only one pass is needed (because there's no emulated
- * interface). For HVM domains two passes are needed in order to add
- * both the PV and the tap interfaces to the bridge.
- */
-if (nictype == LIBXL_NIC_TYPE_VIF num_exec != 0) {
+switch (dev-backend_kind) {
+case LIBXL__DEVICE_KIND_VBD:
+if (num_exec != 0) {
+rc = 0;
+goto out;
+}
+rc = libxl__hotplug_disk(gc, dev, args, env, action);
+break;
+case LIBXL__DEVICE_KIND_VIF:
+/*
+ * If domain has a stubdom we don't have to execute hotplug scripts
+ * for emulated interfaces
+ */
+if ((num_exec 1) ||
+(libxl_get_stubdom_id(CTX, dev-domid) num_exec)) {
+rc = 0;
+goto out;
+}
+rc = libxl__hotplug_nic(gc, dev, args, env, action, num_exec);
+break;
+default:
+/* No need to execute any hotplug scripts */
rc = 0;
-goto out;
+break;
}
-rc = libxl__hotplug_env_nic(gc, dev, env,
[Xen-devel] [PATCH RFC 3/5] libxl/FreeBSD: write blkback path node
FreeBSD blkback doesn't use the physical-device xenstore node because it can handle both block devices and raw files directly. Instead introduce a new xenstore blkback node that is used by hotplug scripts to write the path to the block device or raw image. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/libxl/libxl.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 8c47cff..a5a8999 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2477,7 +2477,13 @@ static void device_disk_add(libxl__egc *egc, uint32_t domid, if (!libxl__device_physdisk_major_minor(dev, major, minor)) flexarray_append_pair(back, physical-device, libxl__sprintf(gc, %x:%x, major, minor)); -#endif /* __linux__ || __NetBSD__ */ +#elif defined(__FreeBSD__) +/* + * FreeBSD blkback supports raw image files, so we + * cannot reuse the physical-device node. + */ +flexarray_append_pair(back, path, dev); +#endif } assert(device-backend_kind == LIBXL__DEVICE_KIND_VBD); -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 0/5] tools/FreeBSD: enable disk hotplug scripts
This series enables the execution of disk hotplug scripts on FreeBSD. In order for this to work a patch for the FreeBSD kernel is also needed, which can be found at: https://people.freebsd.org/~royger/freebsd-hotplug/ This series introduces a new xenstore blkback node, called path that's used by FreeBSD hotplug scripts in order to write the path to the physical device or raw image backing the vbd. The rationale behind the addition of this node can be found at patches 2 and 3 of this series. Thanks, Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 1/5] libxl: only write physical-device on Linux and NetBSD
physical-device is only used by Linux and NetBSD blkback, there's no need to
write it when the host is using a different OS.
Signed-off-by: Roger Pau Monné roger@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/libxl/libxl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index a6eb2df..8c47cff 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2472,10 +2472,12 @@ static void device_disk_add(libxl__egc *egc, uint32_t
domid,
*/
if (!disk-script
disk-backend_domid == LIBXL_TOOLSTACK_DOMID) {
+#if defined(__linux__) || defined(__NetBSD__)
int major, minor;
if (!libxl__device_physdisk_major_minor(dev, major,
minor))
flexarray_append_pair(back, physical-device,
libxl__sprintf(gc, %x:%x,
major, minor));
+#endif /* __linux__ || __NetBSD__ */
}
assert(device-backend_kind == LIBXL__DEVICE_KIND_VBD);
--
1.9.5 (Apple Git-50.3)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 4/5] hotplug/FreeBSD: add block hotplug script
This is the default hotplug script for block devices. Its only job is to copy the params blkback xenstore node to path. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/hotplug/FreeBSD/Makefile | 2 +- tools/hotplug/FreeBSD/block| 25 + 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 tools/hotplug/FreeBSD/block diff --git a/tools/hotplug/FreeBSD/Makefile b/tools/hotplug/FreeBSD/Makefile index 8dfc90a..52a95c8 100644 --- a/tools/hotplug/FreeBSD/Makefile +++ b/tools/hotplug/FreeBSD/Makefile @@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../.. include $(XEN_ROOT)/tools/Rules.mk # Xen script dir and scripts to go there. -XEN_SCRIPTS = vif-bridge +XEN_SCRIPTS = vif-bridge block XEN_SCRIPT_DATA = diff --git a/tools/hotplug/FreeBSD/block b/tools/hotplug/FreeBSD/block new file mode 100644 index 000..782e5c6 --- /dev/null +++ b/tools/hotplug/FreeBSD/block @@ -0,0 +1,25 @@ +#!/bin/sh -e +# +# FreeBSD hotplug script for attaching disks +# +# Parameters: +# $1: xenstore backend path of the vbd +# $2: action, either add or remove +# +# Environment variables: +# None +# + +path=$1 +action=$2 +params=$(xenstore-read $path/params) + +case $action in +add) + xenstore-write $path/path $params + exit 0 + ;; +*) + exit 0 + ;; +esac -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 56922: regressions - FAIL
Hi Robert and Longtao, On Fri, 2015-05-22 at 02:08 +, osstest service user wrote: flight 56922 osstest real [real] http://logs.test-lab.xenproject.org/osstest/logs/56922/ Regressions :-( This flight was testing: 477a9aa grub: remove patch to disable submenu from 20_linux_xen overla cc0a60a Move the code for setting memory size into prep() 3d1ff6d Edit some APIs in TestSupport.pm for nested test 46bba78 Refactor installation of overlays 3cc3ef3 Changes to support '/boot' leading paths of kernel, xen, in gr 9419ffe Parsing grub which has 'submenu' primitive Looking at http://logs.test-lab.xenproject.org/osstest/logs/56922/test-amd64-amd64-xl-xsm/info.html and the serial log at http://logs.test-lab.xenproject.org/osstest/logs/56922/test-amd64-amd64-xl-xsm/serial-italia1.log It seems it has picked the wrong entry to boot. It has picked entry 21 which seems to be 'Debian GNU/Linux, with Xen 4.6-unstable and Linux 3.14.43+' whereas I think it ought to have picked entry 22 which is 'Debian GNU/Linux, with Xen 4.6-unstable (XSM enabled) and Linux 3.14.43 +' I think the problem is most likely in the new code which copes with the submenu primitive. Ian. Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 56857 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-i386-freebsd10-amd64 14 guest-saverestore.2fail REGR. vs. 56857 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 56857 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 56857 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 56857 test-armhf-armhf-libvirt 11 guest-start fail REGR. vs. 56857 test-armhf-armhf-xl-xsm 11 guest-start fail blocked in 56857 test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 56857 test-amd64-i386-libvirt 11 guest-start fail like 56857 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 56857 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 56857 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 56857 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 56857 test-amd64-amd64-libvirt 11 guest-start fail like 56857 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass version targeted for testing: osstest 477a9aa4fa8ff5eb3b0a2e286585665007bb9795 baseline version: osstest ecf4cb76b15396c85fed5a2eb0a6a60e381225c5 jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass
[Xen-devel] [PATCH v2] xen: Use ULL for GB and MB macros
On 32bit, GB(4) doesn't fit on an unsigned long. Modify MB to avoid further issue. Also, fix a couple of printf format in x86 which breaks after using unsigned long long. Signed-off-by: Julien Grall julien.gr...@citrix.com --- Changes in v2: - Use %Lx rather than %llx - Use ULL in the MB macro too --- xen/arch/x86/apic.c | 2 +- xen/arch/x86/io_apic.c | 2 +- xen/include/xen/config.h | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/x86/apic.c b/xen/arch/x86/apic.c index 499e70f..2c9ae4e 100644 --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -992,7 +992,7 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; set_fixmap_nocache(FIX_APIC_BASE, apic_phys); -apic_printk(APIC_VERBOSE, mapped APIC to %08lx (%08lx)\n, APIC_BASE, +apic_printk(APIC_VERBOSE, mapped APIC to %08Lx (%08lx)\n, APIC_BASE, apic_phys); __next: diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c index 6f66562..7d4ee5d 100644 --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -2546,7 +2546,7 @@ void __init init_ioapic_mappings(void) clear_page(__va(ioapic_phys)); } set_fixmap_nocache(idx, ioapic_phys); -apic_printk(APIC_VERBOSE, mapped IOAPIC to %08lx (%08lx)\n, +apic_printk(APIC_VERBOSE, mapped IOAPIC to %08Lx (%08lx)\n, __fix_to_virt(idx), ioapic_phys); idx++; diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index 6478a0a..f7258c7 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -69,8 +69,8 @@ #define __force #define __bitwise -#define MB(_mb) (_AC(_mb, UL) 20) -#define GB(_gb) (_AC(_gb, UL) 30) +#define MB(_mb) (_AC(_mb, ULL) 20) +#define GB(_gb) (_AC(_gb, ULL) 30) #define __STR(...) #__VA_ARGS__ #define STR(...) __STR(__VA_ARGS__) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 05/10] xsm: add XENMEM_soft_reset support
On 13.05.15 at 11:49, vkuzn...@redhat.com wrote:
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -193,6 +193,13 @@ static XSM_INLINE int
xsm_memory_exchange(XSM_DEFAULT_ARG struct domain *d)
return xsm_default_action(action, current-domain, d);
}
+static XSM_INLINE int xsm_memory_soft_reset(XSM_DEFAULT_ARG struct domain
*d1,
+ struct domain *d2)
+{
+XSM_ASSERT_ACTION(XSM_PRIV);
+return xsm_default_action(action, current-domain, NULL);
+}
Why XSM_PRIV instead of XSM_TARGET against _both_ domains?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 00/13] Persistent grant maps for xen net drivers
On 19 May 2015, at 17:39, Wei Liu wei.l...@citrix.com wrote:
On Tue, May 12, 2015 at 07:18:24PM +0200, Joao Martins wrote:
There have been recently[3] some discussions and issues raised on
persistent grants for the block layer, though the numbers above
show some significant improvements specially on more network intensive
workloads and provide a margin for comparison against future map/unmap
improvements.
Any comments or suggestions are welcome,
Thanks!
Thanks, the numbers certainly look interesting.
I'm just a bit concerned about the complexity of netback. I've
commented on individual patches, we can discuss the issues there.
Thanks a lot for the review! It does add more complexity, mainly for
the TX path, but I also would like to mention that a portion of this
changeset is also the persistent grants ops that could potentially live
outside.
Joao
[1] http://article.gmane.org/gmane.linux.network/249383
[2] http://bit.ly/1IhJfXD
[3] http://lists.xen.org/archives/html/xen-devel/2015-02/msg02292.html
Joao Martins (13):
xen-netback: add persistent grant tree ops
xen-netback: xenbus feature persistent support
xen-netback: implement TX persistent grants
xen-netback: implement RX persistent grants
xen-netback: refactor xenvif_rx_action
xen-netback: copy buffer on xenvif_start_xmit()
xen-netback: add persistent tree counters to debugfs
xen-netback: clone skb if skb-xmit_more is set
xen-netfront: move grant_{ref,page} to struct grant
xen-netfront: refactor claim/release grant
xen-netfront: feature-persistent xenbus support
xen-netfront: implement TX persistent grants
xen-netfront: implement RX persistent grants
drivers/net/xen-netback/common.h| 79
drivers/net/xen-netback/interface.c | 78 +++-
drivers/net/xen-netback/netback.c | 873
++--
drivers/net/xen-netback/xenbus.c| 24 +
drivers/net/xen-netfront.c | 362 ---
5 files changed, 1216 insertions(+), 200 deletions(-)
--
2.1.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [linux-next test] 56810: regressions - FAIL
(I thought I'd hit send on this already, sorry if it is a repeat)
On Fri, 2015-05-22 at 10:17 +0100, Ian Campbell wrote:
On Thu, 2015-05-21 at 18:05 +0100, Ian Campbell wrote:
Assuming this flight produces something useful (i.e. a pass) then I'll
look into a bisect.
With this and a couple more adhoc tests I've narrowed it down to
somewhere between v3.15 and v3.16, which is 13830 commits. That might be
a few too many for the bisector to cope but I'll see what it says.
With a minor tweak (below) and telling it to consider 14000 rather than
the default of 1000 commits it did seem to produce an answer.
The resulting bisection.png was 12M and opening it oomed my workstation!
bisection.ps was only 2M and opening it produced a frankly hilarious
graph, but I suppose it will eventually produce an answer so I set
something going.
I've spared you the barrage of mails this would normally generate. You
can see the progress in:
osstest.xs.citrite.net/~osstest/testlogs/results-adhoc/bisect.linux-linus.test-amd64-i386-freebsd10-amd64..html
but I would recommend looking directly at:
osstest.xs.citrite.net/~osstest/testlogs/results-adhoc/bisect.linux-linus.test-amd64-i386-freebsd10-amd64..ps
Since the html includes the png...
log2(14000) is 17 and a bit, so I guess we might see an answer by
Tuesday (Monday is a holiday in the UK). I'll try and keep and eye on it
over the weekend and if it looks to be going mad I'll stop it.
Ian.
diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index 2b04c11..1f5b97a 100755
--- a/adhoc-revtuple-generator
+++ b/adhoc-revtuple-generator
@@ -549,7 +549,7 @@ sub main () {
my @trees_continuous;
foreach my $tree (@trees) {
my $gen= tree_get_gen($tree);
-my $count= 1000;
+my $count= $num;
my $found= 0;
my $top= undef;
while ($count-- 0) {
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC][v2][PATCH 08/14] tools: extend xc_assign_device() to support rdm reservation policy
This patch passes rdm reservation policy to xc_assign_device() so the policy
is checked when assigning devices to a VM.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
tools/libxc/include/xenctrl.h | 3 ++-
tools/libxc/xc_domain.c | 4 +++-
tools/libxl/libxl_pci.c | 11 ++-
tools/libxl/xl_cmdimpl.c| 23 +++
tools/libxl/xl_cmdtable.c | 2 +-
tools/ocaml/libs/xc/xenctrl_stubs.c | 18 ++
tools/python/xen/lowlevel/xc/xc.c | 29 +++--
xen/drivers/passthrough/pci.c | 3 ++-
8 files changed, 70 insertions(+), 23 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5f84a62..2a447b9 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2078,7 +2078,8 @@ int xc_hvm_destroy_ioreq_server(xc_interface *xch,
/* HVM guest pass-through */
int xc_assign_device(xc_interface *xch,
uint32_t domid,
- uint32_t machine_sbdf);
+ uint32_t machine_sbdf,
+ uint32_t flag);
int xc_get_device_group(xc_interface *xch,
uint32_t domid,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index c17a5a8..9761e5a 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1704,7 +1704,8 @@ int xc_domain_setdebugging(xc_interface *xch,
int xc_assign_device(
xc_interface *xch,
uint32_t domid,
-uint32_t machine_sbdf)
+uint32_t machine_sbdf,
+uint32_t flag)
{
DECLARE_DOMCTL;
@@ -1712,6 +1713,7 @@ int xc_assign_device(
domctl.domain = domid;
domctl.u.assign_device.dev = XEN_DOMCTL_DEV_PCI;
domctl.u.assign_device.u.pci.machine_sbdf = machine_sbdf;
+domctl.u.assign_device.flag = flag;
return do_domctl(xch, domctl);
}
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 07e84f2..ac70edc 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -894,6 +894,7 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
FILE *f;
unsigned long long start, end, flags, size;
int irq, i, rc, hvm = 0;
+uint32_t flag;
if (type == LIBXL_DOMAIN_TYPE_INVALID)
return ERROR_FAIL;
@@ -987,7 +988,15 @@ static int do_pci_add(libxl__gc *gc, uint32_t domid,
libxl_device_pci *pcidev, i
out:
if (!libxl_is_stubdom(ctx, domid, NULL)) {
-rc = xc_assign_device(ctx-xch, domid, pcidev_encode_bdf(pcidev));
+if (pcidev-rdm_reserve == LIBXL_RDM_RESERVE_FLAG_RELAXED) {
+flag = XEN_DOMCTL_DEV_RDM_RELAXED;
+} else if (pcidev-rdm_reserve == LIBXL_RDM_RESERVE_FLAG_STRICT) {
+flag = XEN_DOMCTL_DEV_RDM_STRICT;
+} else {
+LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, unkwon rdm check flag.);
+return ERROR_FAIL;
+}
+rc = xc_assign_device(ctx-xch, domid, pcidev_encode_bdf(pcidev),
flag);
if (rc 0 (hvm || errno != ENOSYS)) {
LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, xc_assign_device failed);
return ERROR_FAIL;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2dfa106..0816186 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3341,7 +3341,8 @@ int main_pcidetach(int argc, char **argv)
pcidetach(domid, bdf, force);
return 0;
}
-static void pciattach(uint32_t domid, const char *bdf, const char *vs)
+static void pciattach(uint32_t domid, const char *bdf, const char *vs,
+ uint32_t flag)
{
libxl_device_pci pcidev;
XLU_Config *config;
@@ -3351,6 +3352,7 @@ static void pciattach(uint32_t domid, const char *bdf,
const char *vs)
config = xlu_cfg_init(stderr, command line);
if (!config) { perror(xlu_cfg_inig); exit(-1); }
+pcidev.rdm_reserve = flag;
if (xlu_pci_parse_bdf(config, pcidev, bdf)) {
fprintf(stderr, pci-attach: malformed BDF specification \%s\\n,
bdf);
exit(2);
@@ -3363,9 +3365,9 @@ static void pciattach(uint32_t domid, const char *bdf,
const char *vs)
int main_pciattach(int argc, char **argv)
{
-uint32_t domid;
+uint32_t domid, flag;
int opt;
-const char *bdf = NULL, *vs = NULL;
+const char *bdf = NULL, *vs = NULL, *rdm_policy = NULL;
SWITCH_FOREACH_OPT(opt, , NULL, pci-attach, 2) {
/* No options */
@@ -3377,7 +3379,20 @@ int main_pciattach(int argc, char **argv)
if (optind + 1 argc)
vs = argv[optind + 2];
-pciattach(domid, bdf, vs);
+if (optind + 2 argc) {
+rdm_policy = argv[optind + 3];
+}
+if (!strcmp(rdm_policy, strict)) {
+flag = LIBXL_RDM_RESERVE_FLAG_STRICT;
+} else if (!strcmp(rdm_policy, relaxed)) {
+flag = LIBXL_RDM_RESERVE_FLAG_RELAXED;
+} else {
+fprintf(stderr, %s is an invalid rdm policy: 'strict'|'relaxed'\n,
+
[Xen-devel] [RFC][v2][PATCH 14/14] xen/vtd: enable USB device assignment
Before we refine RMRR mechanism, USB RMRR may conflict with guest bios
region so we always ignore USB RMRR. Now this can be gone when we enable
pci_force to check/reserve RMRR.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/drivers/passthrough/vtd/dmar.h | 1 -
xen/drivers/passthrough/vtd/iommu.c | 11 ++-
xen/drivers/passthrough/vtd/utils.c | 7 ---
3 files changed, 2 insertions(+), 17 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.h
b/xen/drivers/passthrough/vtd/dmar.h
index af1feef..af205f5 100644
--- a/xen/drivers/passthrough/vtd/dmar.h
+++ b/xen/drivers/passthrough/vtd/dmar.h
@@ -129,7 +129,6 @@ do {\
int vtd_hw_check(void);
void disable_pmr(struct iommu *iommu);
-int is_usb_device(u16 seg, u8 bus, u8 devfn);
int is_igd_drhd(struct acpi_drhd_unit *drhd);
#endif /* _DMAR_H_ */
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index d7c9e1c..d3233b8 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2229,11 +2229,9 @@ static int reassign_device_ownership(
/*
* If the device belongs to the hardware domain, and it has RMRR, don't
* remove it from the hardware domain, because BIOS may use RMRR at
- * booting time. Also account for the special casing of USB below (in
- * intel_iommu_assign_device()).
+ * booting time.
*/
-if ( !is_hardware_domain(source)
- !is_usb_device(pdev-seg, pdev-bus, pdev-devfn) )
+if ( !is_hardware_domain(source) )
{
const struct acpi_rmrr_unit *rmrr;
u16 bdf;
@@ -2283,13 +2281,8 @@ static int intel_iommu_assign_device(
if ( ret )
return ret;
-/* FIXME: Because USB RMRR conflicts with guest bios region,
- * ignore USB RMRR temporarily.
- */
seg = pdev-seg;
bus = pdev-bus;
-if ( is_usb_device(seg, bus, pdev-devfn) )
-return 0;
/* Setup rmrr identity mapping */
for_each_rmrr_device( rmrr, bdf, i )
diff --git a/xen/drivers/passthrough/vtd/utils.c
b/xen/drivers/passthrough/vtd/utils.c
index bd14c02..b8a077f 100644
--- a/xen/drivers/passthrough/vtd/utils.c
+++ b/xen/drivers/passthrough/vtd/utils.c
@@ -29,13 +29,6 @@
#include extern.h
#include asm/io_apic.h
-int is_usb_device(u16 seg, u8 bus, u8 devfn)
-{
-u16 class = pci_conf_read16(seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
-PCI_CLASS_DEVICE);
-return (class == 0xc03);
-}
-
/* Disable vt-d protected memory registers. */
void disable_pmr(struct iommu *iommu)
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 04/10] xen: Introduce XENMEM_soft_reset operation
On 13.05.15 at 11:49, vkuzn...@redhat.com wrote:
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -580,6 +580,234 @@ static long
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
return rc;
}
+static long
memory_soft_reset(XEN_GUEST_HANDLE_PARAM(xen_memory_soft_reset_t) arg)
+{
+long rc = 0;
The way it's coded right now, I don't see the need for this or the
function return type being long (but see the comments on the
public header change).
+struct xen_memory_soft_reset softr;
+struct domain *source_d, *dest_d;
+unsigned long mfn, mfn_new, gmfn, last_gmfn, count;
+unsigned int order;
+p2m_type_t p2mt;
+struct page_info *page, *new_page, *next_page;
+int drop_dom_ref;
+
+if ( copy_from_guest(softr, arg, 1) )
+return -EFAULT;
+
+if ( softr.source_domid == softr.dest_domid )
+return -EINVAL;
+
+source_d = rcu_lock_domain_by_any_id(softr.source_domid);
+if ( source_d == NULL )
+{
+rc = -ESRCH;
+goto fail_early;
+}
+
+dest_d = rcu_lock_domain_by_any_id(softr.dest_domid);
+if ( dest_d == NULL )
+{
+rc = -ESRCH;
+rcu_unlock_domain(source_d);
+goto fail_early;
+}
+
+if ( dest_d-is_dying )
+{
+rc = -EINVAL;
+goto fail;
+}
+
+if ( !source_d-is_dying )
+{
+/*
+ * Make sure no allocation/remapping for the source domain is ongoing
+ * and set is_dying flag to prevent such actions in future.
+ */
+spin_lock(source_d-page_alloc_lock);
+source_d-is_dying = DOMDYING_locked;
You need to repeat the is_dying check with the lock held, and act
accordingly if it isn't zero anymore.
Furthermore I don't see how this prevents there being further
changes to the GFN - MFN mappings for the guest (yet you rely
on them to be stable below afaict).
+spin_unlock(source_d-page_alloc_lock);
+}
+
+last_gmfn = domain_get_maximum_gpfn(source_d);
+gmfn = softr.gmfn_start;
+while ( gmfn = last_gmfn )
By now you should have done a privilege check.
+{
+page = get_page_from_gfn(source_d, gmfn, p2mt, 0);
+if ( unlikely(page == NULL) )
+{
+#ifdef CONFIG_X86
+count = 0;
+while ( p2m_is_pod(p2mt) )
+{
+count++;
+if ( gmfn + count last_gmfn )
+break;
+page = get_page_from_gfn(source_d, gmfn + count, p2mt, 0);
+if ( page )
+{
+put_page(page);
+page = NULL;
Why? You don't use the value further down.
+break;
+}
+}
+
+if ( !count )
+gmfn++;
+
+while ( count )
+{
+order = get_order_from_pages(count);
+if ( (1ul order) count )
+order -= 1;
--
+rc = guest_physmap_mark_populate_on_demand(dest_d, gmfn,
order);
+if ( rc )
+goto fail;
+count -= 1ul order;
+gmfn += 1ul order;
+}
+#else
+gmfn++;
+#endif
+goto preempt_check;
+}
+
+mfn = page_to_mfn(page);
+if ( unlikely(!mfn_valid(mfn)) )
+{
+put_page(page);
+gmfn++;
+goto preempt_check;
I guess this should never happen, and hence issuing a warning may be
warranted?
+}
+
+next_page = page;
+
+/*
+ * A normal page is supposed to have count_info = 2 (1 from the
domain
+ * and 1 from get_page_from_gfn() above). All other pages need to be
+ * copied.
+ */
I'm afraid this isn't precise enough: _PGC_allocated implies one
refcount, i.e. if that flag turns out to be clear, you should expect
just 1. And then I'd wonder whether a !_PGC_allocated page
needs any handling here in the first place (or perhaps, once the
GFN - MFN mapping is ensured to be stable, this case can't
happen anyway).
+count = 0;
+while ( next_page !is_xen_heap_page(next_page)
+(next_page-count_info PGC_count_mask) == 2
+page_to_mfn(next_page) == mfn + count )
+{
+count++;
+drop_dom_ref = 0;
+spin_lock(source_d-page_alloc_lock);
+page_set_owner(next_page, NULL);
+page_list_del(next_page, source_d-page_list);
+source_d-tot_pages -= 1;
--
+if ( unlikely(source_d-tot_pages == 0) )
+drop_dom_ref = 1;
+spin_unlock(source_d-page_alloc_lock);
+put_page(next_page);
+if ( drop_dom_ref )
+put_domain(source_d);
+
+if (
[Xen-devel] [RFC][v2][PATCH 13/14] hvmloader/e820: construct guest e820 table
Now we can use that memory map to build our final
e820 table but it may need to reorder all e820
entries.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
tools/firmware/hvmloader/e820.c | 62 +++--
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 2e05e93..c39b0aa 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -73,7 +73,8 @@ int build_e820_table(struct e820entry *e820,
unsigned int lowmem_reserved_base,
unsigned int bios_image_base)
{
-unsigned int nr = 0;
+unsigned int nr = 0, i, j;
+uint64_t low_mem_pgend = hvm_info-low_mem_pgend PAGE_SHIFT;
if ( !lowmem_reserved_base )
lowmem_reserved_base = 0xA;
@@ -117,13 +118,6 @@ int build_e820_table(struct e820entry *e820,
e820[nr].type = E820_RESERVED;
nr++;
-/* Low RAM goes here. Reserve space for special pages. */
-BUG_ON((hvm_info-low_mem_pgend PAGE_SHIFT) (2u 20));
-e820[nr].addr = 0x10;
-e820[nr].size = (hvm_info-low_mem_pgend PAGE_SHIFT) - e820[nr].addr;
-e820[nr].type = E820_RAM;
-nr++;
-
/*
* Explicitly reserve space for special pages.
* This space starts at RESERVED_MEMBASE an extends to cover various
@@ -159,16 +153,56 @@ int build_e820_table(struct e820entry *e820,
nr++;
}
-
-if ( hvm_info-high_mem_pgend )
+/*
+ * Construct the remaining according memory_map.
+ *
+ * Note memory_map includes,
+ *
+ * #1. Low memory region
+ *
+ * Low RAM starts at least from 1M to make sure all standard regions
+ * of the PC memory map, like BIOS, VGA memory-mapped I/O and vgabios,
+ * have enough space.
+ *
+ * #2. RDM region if it exists
+ *
+ * #3. High memory region if it exists
+ */
+for ( i = 0; i memory_map.nr_map; i++ )
{
-e820[nr].addr = ((uint64_t)1 32);
-e820[nr].size =
-((uint64_t)hvm_info-high_mem_pgend PAGE_SHIFT) - e820[nr].addr;
-e820[nr].type = E820_RAM;
+e820[nr] = memory_map.map[i];
nr++;
}
+/* Low RAM goes here. Reserve space for special pages. */
+BUG_ON(low_mem_pgend (2u 20));
+/*
+ * We may need to adjust real lowmem end since we may
+ * populate RAM to get enough MMIO previously.
+ */
+for ( i = 0; i memory_map.nr_map; i++ )
+{
+uint64_t end = e820[i].addr + e820[i].size;
+if ( e820[i].type == E820_RAM
+ low_mem_pgend e820[i].addr low_mem_pgend end )
+e820[i].size = low_mem_pgend - e820[i].addr;
+}
+
+/* Finally we need to reorder all e820 entries. */
+for ( j = 0; j nr-1; j++ )
+{
+for ( i = j+1; i nr; i++ )
+{
+if ( e820[j].addr e820[i].addr )
+{
+struct e820entry tmp;
+tmp = e820[j];
+e820[j] = e820[i];
+e820[i] = tmp;
+}
+}
+}
+
return nr;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
On Fri, 2015-05-22 at 11:02 +0100, Ian Campbell wrote: On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. It therefore makes sense to stop smoke testing the former in favour of the latter. Note that the -sedf-pin jobs where only added in order to try to debug a long standing issue with SEDF; it is not necessary to have anything like that for RTDS. Does the RTDS scheduler work out of the box? I had a feeling that it required per domain config settings to be worked out? It does, your feeling is about ARINC653 :-) Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 02/13] xen-netback: xenbus feature persistent support
On 19 May 2015, at 17:19, Wei Liu wei.l...@citrix.com wrote: On Tue, May 12, 2015 at 07:18:26PM +0200, Joao Martins wrote: Checks for feature-persistent that indicates persistent grants support. Adds max_persistent_grants module param that specifies the max number of persistent grants, which if set to zero disables persistent grants. Signed-off-by: Joao Martins joao.mart...@neclab.eu This patch needs to be moved later. The feature needs to be implemented first. Also you need to patch netif.h to document this new feature. To do this, you need to patch the master netif.h in Xen tree then sync the change to Linux. Of course I don't mind if we discuss wording in the Linux copy then you devise a patch for Xen. Ok, I will do that. I made the same mistake on xen-netfront. Joao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC][v2][PATCH 10/14] tools: extend XENMEM_set_memory_map
Hi,
On 22/05/2015 10:35, Tiejun Chen wrote:
Here we'll construct a basic guest e820 table via
XENMEM_set_memory_map. This table includes lowmem, highmem
and RDMs if they exist. And hvmloader would need this info
later.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
tools/libxl/libxl_dom.c | 87 +
1 file changed, 87 insertions(+)
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 84d5465..cc4b1a6 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -913,6 +913,87 @@ out:
return rc;
}
+/*
+ * Here we're just trying to set these kinds of e820 mappings:
+ *
+ * #1. Low memory region
+ *
+ * Low RAM starts at least from 1M to make sure all standard regions
+ * of the PC memory map, like BIOS, VGA memory-mapped I/O and vgabios,
+ * have enough space.
+ * Note: Those stuffs below 1M are still constructed with multiple
+ * e820 entries by hvmloader. At this point we don't change anything.
+ *
+ * #2. RDM region if it exists
+ *
+ * #3. High memory region if it exists
+ *
+ * Note: these regions are not overlapping since we already check
+ * to adjust them. Please refer to libxl__domain_device_construct_rdm().
+ */
+#define GUEST_LOW_MEM_START_DEFAULT 0x10
+static int libxl__domain_construct_memmap(libxl__gc *gc,
+ libxl_domain_config *d_config,
+ uint32_t domid,
+ struct xc_hvm_build_args *args)
The code within this function is x86 specific. Shouldn't it be moved in
libxl_x86.c?
+{
+libxl_ctx *ctx = libxl__gc_owner(gc);
+unsigned int nr = 0, i;
+/* We always own at least one lowmem entry. */
+unsigned int e820_entries = 1;
+uint64_t highmem_end = 0, highmem_size = args-mem_size -
args-lowmem_size;
+struct e820entry *e820 = NULL;
+
+/* Add all rdm entries. */
+e820_entries += d_config-num_rdms;
+
+/* If we should have a highmem range. */
+if (highmem_size)
+{
+highmem_end = (1ull32) + highmem_size;
+e820_entries++;
+}
+
+if (e820_entries = E820MAX) {
+LOG(ERROR, Ooops! Too many entries in the memory map!\n);
+return -1;
+}
+
+e820 = libxl__malloc(gc, sizeof(struct e820entry) * e820_entries);
+
+/* Low memory */
+e820[nr].addr = GUEST_LOW_MEM_START_DEFAULT;
+e820[nr].size = args-lowmem_size - GUEST_LOW_MEM_START_DEFAULT;
+e820[nr].type = E820_RAM;
+nr++;
+
+/* RDM mapping */
+for (i = 0; i d_config-num_rdms; i++) {
+/*
+ * We should drop this kind of rdm entry.
+ */
+if (d_config-rdms[i].flag == LIBXL_RDM_RESERVE_FLAG_INVALID)
+continue;
+
+e820[nr].addr = d_config-rdms[i].start;
+e820[nr].size = d_config-rdms[i].size;
+e820[nr].type = E820_RESERVED;
+nr++;
+}
+
+/* High memory */
+if (highmem_size) {
+e820[nr].addr = ((uint64_t)1 32);
+e820[nr].size = highmem_size;
+e820[nr].type = E820_RAM;
+}
+
+if (xc_domain_set_memory_map(ctx-xch, domid, e820, e820_entries) != 0)
+return -1;
+
+return 0;
+}
+
int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
libxl_domain_config *d_config,
libxl__domain_build_state *state)
@@ -1016,6 +1097,12 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
ret = set_vnuma_info(gc, domid, info, state);
if (ret) goto out;
}
+
+if (libxl__domain_construct_memmap(gc, d_config, domid, args)) {
+LOG(ERROR, setting domain rdm memory map failed);
+goto out;
+}
+
ret = hvm_build_set_params(ctx-xch, domid, info, state-store_port,
state-store_mfn, state-console_port,
state-console_mfn, state-store_domid,
regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 04/13] xen-netback: implement RX persistent grants
On 19 May 2015, at 17:32, Wei Liu wei.l...@citrix.com wrote:
On Tue, May 12, 2015 at 07:18:28PM +0200, Joao Martins wrote:
It starts by doing a lookup in the tree for a gref. If no persistent
grant is found on the tree, it will do grant copy and prepare
the grant maps. Finally valides the grant map and adds it to the tree.
validates?
After mapped these grants can be pulled from the tree in the subsequent
requests. If it's out of pages in the tree pool, it will fallback to
grant copy.
Again, this looks complicated. Why use combined scheme? I will do
detailed reviews after we're sure we need such scheme.
When we don't have the gref in tree we need to map it and then copying
afterwards into the newly mapped page (and this only happens once until
the grant is in tree). My options here were to either do this explicitly,
after we add the persistent grant in which we would need to save to
dst/src address and len to copy. The other option is to reuse the grant
copy (since it's only once until the grant is in the tree) and use memcpy
in followings requests. Additionally I allow the fallback to grant copy in
case the guest provides providing more grefs max_grants.
Note that this is also the case for TX as well, with regard to grant
copying the header. I was unsure about which one is the most correct way
of doing it, but ultimately the latter involved a smaller codepath, and
that's why I chose it. What do you think?
It adds four new fields in the netrx_pending_operations: copy_done
to track how many copies were made; map_prod and map_cons to track
how many maps are outstanding validation and finally copy_page for
the correspondent page (in tree) for copy_gref.
Results are 1.04 Mpps measured with pktgen (pkt_size 64, burst 1)
with persistent grants versus 1.23 Mpps with grant copy (20%
regression). With persistent grants it adds up contention on
queue-wq as the kthread_guest_rx goes to sleep more often. If we
speed up the sender (burst 2,4 and 8) it goes up to 1.7 Mpps with
persistent grants. This issue is addressed in later a commit, by
copying the skb on xenvif_start_xmit() instead of going through
the RX kthread.
Signed-off-by: Joao Martins joao.mart...@neclab.eu
---
drivers/net/xen-netback/common.h| 7 ++
drivers/net/xen-netback/interface.c | 14 ++-
drivers/net/xen-netback/netback.c | 190
++--
3 files changed, 178 insertions(+), 33 deletions(-)
diff --git a/drivers/net/xen-netback/common.h
b/drivers/net/xen-netback/common.h
index e5ee220..23deb6a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -235,6 +235,13 @@ struct xenvif_queue { /* Per-queue data for xenvif */
struct gnttab_copy grant_copy_op[MAX_GRANT_COPY_OPS];
+/* To map the grefs to be added to the tree */
+struct gnttab_map_grant_ref rx_map_ops[XEN_NETIF_RX_RING_SIZE];
+struct page *rx_pages_to_map[XEN_NETIF_RX_RING_SIZE];
+/* Only used if feature-persistent = 1 */
This comment applies to rx_map_ops and rx_pages_to_map as well. Could
you move it up?
Ok.
+struct persistent_gnt_tree rx_gnts_tree;
+struct page *rx_gnts_pages[XEN_NETIF_RX_RING_SIZE];
+
/* We create one meta structure per ring request we consume, so
* the maximum number is the same as the ring size.
*/
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
[...]
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 529d7c3..738b6ee 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -413,14 +413,62 @@ static void xenvif_rx_queue_drop_expired(struct
xenvif_queue *queue)
}
struct netrx_pending_operations {
+unsigned map_prod, map_cons;
unsigned copy_prod, copy_cons;
unsigned meta_prod, meta_cons;
struct gnttab_copy *copy;
struct xenvif_rx_meta *meta;
int copy_off;
grant_ref_t copy_gref;
+struct page *copy_page;
+unsigned copy_done;
};
+static void xenvif_create_rx_map_op(struct xenvif_queue *queue,
+struct gnttab_map_grant_ref *mop,
+grant_ref_t ref,
+struct page *page)
Rename it to xenvif_rx_create_map_op to be consistent with
xenvif_tx_create_map_op?
+{
+queue-rx_pages_to_map[mop - queue-rx_map_ops] = page;
+gnttab_set_map_op(mop,
+ (unsigned long)page_to_kaddr(page),
+ GNTMAP_host_map,
+ ref, queue-vif-domid);
+}
+
[...]
+
+persistent_gnt = xenvif_pgrant_new(tree, gop_map);
+if (unlikely(!persistent_gnt)) {
+netdev_err(queue-vif-dev,
+ Couldn't add gref to the tree! ref: %d,
+ gop_map-ref);
+
Re: [Xen-devel] [RFC PATCH 03/13] xen-netback: implement TX persistent grants
On 19 May 2015, at 17:23, Wei Liu wei.l...@citrix.com wrote:
On Tue, May 12, 2015 at 07:18:27PM +0200, Joao Martins wrote:
Introduces persistent grants for TX path which follows similar code path
as the grant mapping.
It starts by checking if there's a persistent grant available for header
and frags grefs and if so setting it in tx_pgrants. If no persistent grant
is found in the tree for the header it will resort to grant copy (but
preparing the map ops and add them laster). For the frags it will use the
^
later
tree page pool, and in case of no pages it fallbacks to grant map/unmap
using mmap_pages. When skb destructor callback gets called we release the
slot and persistent grant within the callback to avoid waking up the
dealloc thread. As long as there are no unmaps to done the dealloc thread
will remain inactive.
This scheme looks complicated. Can we just only use one
scheme at a time? What's the rationale for using this combined scheme?
Maybe you're thinking about using a max_grants ring_size to save
memory?
Yes, my purpose was to allow a max_grants ring_size to save amount of
memory mapped. I did a bulk transfer test with iperf and the max amount of
grants in tree was 160 TX gnts, without affecting the max performance;
tough using pktgen fills the tree completely.
The second reason is to handle the case for a (malicious?) frontend providing
more grefs than the max allowed in which I would fallback to grant map/unmap.
Only skim the patch. I will do detailed reviews after we're sure this is
the right way to go.
Results show an improvement of 46% (1.82 vs 1.24 Mpps, 64 pkt size)
measured with pktgen and up to over 48% (21.6 vs 14.5 Gbit/s) measured
with iperf (TCP) with 4 parallel flows 1 queue vif, DomU to Dom0.
Tests ran on a Intel Xeon E5-1650 v2 with HT disabled.
[…]
int xenvif_init_queue(struct xenvif_queue *queue)
{
int err, i;
@@ -496,9 +524,23 @@ int xenvif_init_queue(struct xenvif_queue *queue)
.ctx = NULL,
.desc = i };
queue-grant_tx_handle[i] = NETBACK_INVALID_HANDLE;
+queue-tx_pgrants[i] = NULL;
+}
+
+if (queue-vif-persistent_grants) {
+err = init_persistent_gnt_tree(queue-tx_gnts_tree,
+ queue-tx_gnts_pages,
+ XEN_NETIF_TX_RING_SIZE);
+if (err)
+goto err_disable;
}
return 0;
+
+err_disable:
+netdev_err(queue-vif-dev, Could not reserve tree pages.);
+queue-vif-persistent_grants = 0;
You can just move the above two lines under `if (err)'.
Also see below.
In the next patch this is also common cleanup path. I did it this way to
avoid moving this hunk around.
+return 0;
}
void xenvif_carrier_on(struct xenvif *vif)
@@ -654,6 +696,10 @@ void xenvif_disconnect(struct xenvif *vif)
}
xenvif_unmap_frontend_rings(queue);
+
+if (queue-vif-persistent_grants)
+deinit_persistent_gnt_tree(queue-tx_gnts_tree,
+ queue-tx_gnts_pages);
If the init function fails on queue N (N0) you now leak resources.
Correct. I should return -ENOMEM (on init) and not 0.
}
}
diff --git a/drivers/net/xen-netback/netback.c
b/drivers/net/xen-netback/netback.c
index 332e489..529d7c3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -269,6 +269,11 @@ static inline unsigned long idx_to_kaddr(struct
xenvif_queue *queue,
return (unsigned long)pfn_to_kaddr(idx_to_pfn(queue, idx));
}
+static inline void *page_to_kaddr(struct page *page)
+{
+return pfn_to_kaddr(page_to_pfn(page));
+}
+
#define callback_param(vif, pending_idx) \
(vif-pending_tx_info[pending_idx].callback_struct)
@@ -299,6 +304,29 @@ static inline pending_ring_idx_t pending_index(unsigned
i)
return i (MAX_PENDING_REQS-1);
}
+/* Creates a new persistent grant and add it to the tree.
+ */
+static struct persistent_gnt *xenvif_pgrant_new(struct persistent_gnt_tree
*tree,
+struct gnttab_map_grant_ref
*gop)
+{
+struct persistent_gnt *persistent_gnt;
+
+persistent_gnt = kmalloc(sizeof(*persistent_gnt), GFP_KERNEL);
xenvif_pgrant_new can be called in NAPI which runs in softirq context
which doesn't allow you to sleep.
Silly mistake, I will fix this. The whole point of the tree page pool was that
we
aren't allowed to sleep both here and in ndo_start_xmit (in patch #6).
[…]
+/* Checks if there's a persistent grant available for gref and
+ * if so, set it also in the tx_pgrants array that keeps the ones
+ * in use.
+ */
+static bool xenvif_tx_pgrant_available(struct xenvif_queue *queue,
+
[Xen-devel] [PATCH v1] x86/pvh: disable posted interrupts
Enabling posted interrupts requires the virtual interrupt delivery feature, which is disabled for PVH guests, so make sure posted interrupts are also disabled or else vmlaunch will fail. Signed-off-by: Roger Pau Monné roger@citrix.com Reported-and-Tested-by: Lars Eggert l...@netapp.com Acked-by: Kevin Tian kevin.t...@intel.com Cc: Jun Nakajima jun.nakaj...@intel.com Cc: Eddie Dong eddie.d...@intel.com Cc: Kevin Tian kevin.t...@intel.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- xen/arch/x86/hvm/vmx/vmcs.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index a714549..9827a8e 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -980,6 +980,10 @@ static int construct_vmcs(struct vcpu *v) v-arch.hvm_vmx.secondary_exec_control = ~SECONDARY_EXEC_UNRESTRICTED_GUEST; +/* Disable posted interrupts */ +__vmwrite(PIN_BASED_VM_EXEC_CONTROL, +vmx_pin_based_exec_control ~PIN_BASED_POSTED_INTERRUPT); + /* Start in 64-bit mode. PVH 32bitfixme. */ vmentry_ctl |= VM_ENTRY_IA32E_MODE; /* GUEST_EFER.LME/LMA ignored */ -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH RFC 2/5] blkif: document new blkback path xenstore node
FreeBSD blkback uses the path xenstore node in order to fetch the path to the underlying backing storage (either a block device or raw image). This node is set by the hotplug scripts. Signed-off-by: Roger Pau Monné roger@citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Tim Deegan t...@xen.org --- xen/include/public/io/blkif.h | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h index 6baf7fb..b1e2245 100644 --- a/xen/include/public/io/blkif.h +++ b/xen/include/public/io/blkif.h @@ -89,8 +89,15 @@ * Values: string * * A free formatted string providing sufficient information for the - * backend driver to open the backing device. (e.g. the path to the - * file or block device representing the backing store.) + * hotplug script to attach the device and provide a suitable + * handler (ie: a block device) for blkback to use. + * + * path + * Values: string + * Notes: 11 + * + * A free formatted string that contains the path to the backing device + * for this blkback instance. * * type * Values: file, phy, tap @@ -385,6 +392,7 @@ * than RING_SIZE * BLKIF_MAX_SEGMENTS_PER_REQUEST. *(10) The discard-secure property may be present and will be set to 1 if the * backing device supports secure discard. + *(11) This node is only present on FreeBSD. */ /* -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Use ULL for GB macro
Hi Jan, On 22/05/2015 07:53, Jan Beulich wrote: On 22.05.15 at 01:16, julien.gr...@citrix.com wrote: --- a/xen/arch/x86/apic.c +++ b/xen/arch/x86/apic.c @@ -992,7 +992,7 @@ void __init init_apic_mappings(void) apic_phys = mp_lapic_addr; set_fixmap_nocache(FIX_APIC_BASE, apic_phys); -apic_printk(APIC_VERBOSE, mapped APIC to %08lx (%08lx)\n, APIC_BASE, +apic_printk(APIC_VERBOSE, mapped APIC to %08llx (%08lx)\n, APIC_BASE, Please use 'L' as the shorter equivalent. I didn't know this shorthand. I will use %Lx --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -70,7 +70,7 @@ #define __bitwise #define MB(_mb) (_AC(_mb, UL) 20) -#define GB(_gb) (_AC(_gb, UL) 30) +#define GB(_gb) (_AC(_gb, ULL) 30) So why do you leave MB() alone? It obviously suffers from the same problem (perhaps only latent at this point, but anyway). Because I haven't had any problem with MB. I will resend a new version with the 2 fixes. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 56937: regressions - FAIL
flight 56937 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/56937/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all 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 fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-amd64-i386-libvirt-xsm
Re: [Xen-devel] [RFC PATCH 06/13] xen-netback: copy buffer on xenvif_start_xmit()
On 19 May 2015, at 17:35, Wei Liu wei.l...@citrix.com wrote:
On Tue, May 12, 2015 at 07:18:30PM +0200, Joao Martins wrote:
By introducing persistent grants we speed up the RX thread with the
decreased copy cost, that leads to a throughput decrease of 20%.
It is observed that the rx_queue stays mostly at 10% of its capacity,
as opposed to full capacity when using grant copy. And a finer measure
with lock_stat (below with pkt_size 64, burst 1) shows much higher wait
queue contention on queue-wq, which hints that the RX kthread is
waits/wake_up more often, that is actually doing work.
Without persistent grants:
class namecon-bouncescontentions waittime-min waittime-max
waittime-total waittime-avgacq-bounces acquisitions holdtime-min
holdtime-max holdtime-total holdtime-avg
--
queue-wq: 792792 0.36 24.36
1140.30 1.44 42081002671 0.00
46.75 538164.02 0.54
--
queue-wq326 [8115949f] __wake_up+0x2f/0x80
queue-wq410 [811592bf] finish_wait+0x4f/0xa0
queue-wq 56 [811593eb] prepare_to_wait+0x2b/0xb0
--
queue-wq202 [811593eb] prepare_to_wait+0x2b/0xb0
queue-wq467 [8115949f] __wake_up+0x2f/0x80
queue-wq123 [811592bf] finish_wait+0x4f/0xa0
With persistent grants:
queue-wq: 61834 61836 0.32 30.12
99710.27 1.61 2414001125308 0.00
75.61 1106578.82 0.98
--
queue-wq 5079[8115949f] __wake_up+0x2f/0x80
queue-wq56280[811592bf] finish_wait+0x4f/0xa0
queue-wq 479[811593eb] prepare_to_wait+0x2b/0xb0
--
queue-wq 1005[811592bf] finish_wait+0x4f/0xa0
queue-wq56761[8115949f] __wake_up+0x2f/0x80
queue-wq 4072[811593eb] prepare_to_wait+0x2b/0xb0
Also, with persistent grants, we don't require batching grant copy ops
(besides the initial copy+map) which makes me believe that deferring
the skb to the RX kthread just adds up unnecessary overhead (for this
particular case). This patch proposes copying the buffer on
xenvif_start_xmit(), which lets us both remove the contention on
queue-wq and lock on rx_queue. Here, an alternative to
xenvif_rx_action routine is added namely xenvif_rx_map() that maps
and copies the buffer to the guest. This is only used when persistent
grants are used, since it would otherwise mean an hypercall per
packet.
Improvements are up to a factor of 2.14 with a single queue getting us
from 1.04 Mpps to 1.7 Mpps (burst 1, pkt_size 64) and 1.5 to 2.6 Mpps
(burst 2, pkt_size 64) compared to using the kthread. Maximum with grant
copy is 1.2 Mpps, irrespective of the burst. All of this, measured on
an Intel(R) Xeon(R) CPU E5-1650 v2 @ 3.50GHz.
Signed-off-by: Joao Martins joao.mart...@neclab.eu
---
drivers/net/xen-netback/common.h| 2 ++
drivers/net/xen-netback/interface.c | 11 +---
drivers/net/xen-netback/netback.c | 52
+
3 files changed, 51 insertions(+), 14 deletions(-)
diff --git a/drivers/net/xen-netback/common.h
b/drivers/net/xen-netback/common.h
index 23deb6a..f3ece12 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -363,6 +363,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
int xenvif_dealloc_kthread(void *data);
+int xenvif_rx_map(struct xenvif_queue *queue, struct sk_buff *skb);
+
void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
/* Determine whether the needed number of slots (req) are available,
diff --git a/drivers/net/xen-netback/interface.c
b/drivers/net/xen-netback/interface.c
index 1103568..dfe2b7b 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -109,7 +109,8 @@ static irqreturn_t xenvif_rx_interrupt(int irq, void
*dev_id)
{
struct xenvif_queue *queue = dev_id;
-xenvif_kick_thread(queue);
+if (!queue-vif-persistent_grants)
+xenvif_kick_thread(queue);
return IRQ_HANDLED;
}
@@ -168,8 +169,12 @@ static int xenvif_start_xmit(struct sk_buff *skb,
struct net_device *dev)
cb = XENVIF_RX_CB(skb);
cb-expires = jiffies + vif-drain_timeout;
-xenvif_rx_queue_tail(queue, skb);
-xenvif_kick_thread(queue);
+if (!queue-vif-persistent_grants) {
+xenvif_rx_queue_tail(queue, skb);
+xenvif_kick_thread(queue);
+} else if (xenvif_rx_map(queue, skb)) {
+return NETDEV_TX_BUSY;
+}
We now have two different functions for guest RX, one is xenvif_rx_map,
the other is xenvif_rx_action. They look very similar. Can
Re: [Xen-devel] [RFC][v2][PATCH 07/14] xen/passthrough: extend hypercall to support rdm reservation policy
Hi,
On 22/05/2015 10:35, Tiejun Chen wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 0c0ea4a..203c80e 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -499,6 +499,11 @@ struct xen_domctl_assign_device {
XEN_GUEST_HANDLE_64(char) path; /* path to the device tree node */
} dt;
} u;
+/* IN */
+#define XEN_DOMCTL_DEV_NO_RDM 0
+#define XEN_DOMCTL_DEV_RDM_RELAXED 1
+#define XEN_DOMCTL_DEV_RDM_STRICT 2
+uint32_t flag; /* flag of assigned device */
You don't plumb this value for DT neither in the toolstack (see
xc_assign_dt_device) and Xen. Please add a comment saying it's only used
by PCI and/or the value should always be XEN_DOMCTL_DEV_NO_RDM for DT.
Regards,
--
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 56922: regressions - FAIL
On Fri, 2015-05-22 at 10:57 +0100, Ian Campbell wrote:
Hi Robert and Longtao,
On Fri, 2015-05-22 at 02:08 +, osstest service user wrote:
flight 56922 osstest real [real]
http://logs.test-lab.xenproject.org/osstest/logs/56922/
Regressions :-(
This flight was testing:
477a9aa grub: remove patch to disable submenu from 20_linux_xen overla
cc0a60a Move the code for setting memory size into prep()
3d1ff6d Edit some APIs in TestSupport.pm for nested test
46bba78 Refactor installation of overlays
3cc3ef3 Changes to support '/boot' leading paths of kernel, xen, in gr
9419ffe Parsing grub which has 'submenu' primitive
Looking at
http://logs.test-lab.xenproject.org/osstest/logs/56922/test-amd64-amd64-xl-xsm/info.html
and the serial log at
http://logs.test-lab.xenproject.org/osstest/logs/56922/test-amd64-amd64-xl-xsm/serial-italia1.log
It seems it has picked the wrong entry to boot. It has picked entry 21
which seems to be 'Debian GNU/Linux, with Xen 4.6-unstable and Linux
3.14.43+' whereas I think it ought to have picked entry 22 which is
'Debian GNU/Linux, with Xen 4.6-unstable (XSM enabled) and Linux 3.14.43
+'
I think the problem is most likely in the new code which copes with the
submenu primitive.
I think grub2 considers submenu entries to be entries, and therefore
when determining which entry to use we should include those in the
offset.
I think you didn't see this in your testing because without XSM the
entry we want is the first item in the first submenu, so there is an off
by one in the entry we ask for, which turns out to correspond to the
first submenu itself, and then the grub timeout means that it then
selects the first entry in that submenu, so it works.
I'm currently testing the patch below, if it works then I intend to fold
it into Parsing grub which has 'submenu' primitive and will re-push
the result.
Ian.
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 282175b..0b731c3 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -451,6 +451,7 @@ sub setupboot_grub2 () {
}
if (m/^submenu\s+[\'\](.*)[\'\].*\{\s*$/) {
$submenu={ StartLine =$.};
+$count++;
}
if (m/^\s*multiboot\s*(?:\/boot)?\/(xen\S+)/) {
die unless $entry;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/8] xenalyze: add to tools/xentrace/
On Fri, May 22, Wei Liu wrote: On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote: BIN = xentrace xentrace_setsize +SBIN = xenalyze Why is xenalyze not placed in the same directory as xentrace? My impression is that they are closely related. What did I miss? And given that xenalyze only analyse the log it shouldn't require privilege to run so it should be placed in BIN? Perhaps that should be flipped then, xentrace needs be run as root AFAIK. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/8] xenalyze: add to tools/xentrace/
On Fri, May 22, 2015 at 01:32:01PM +0200, Olaf Hering wrote: On Fri, May 22, Wei Liu wrote: On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote: BIN = xentrace xentrace_setsize +SBIN = xenalyze Why is xenalyze not placed in the same directory as xentrace? My impression is that they are closely related. What did I miss? And given that xenalyze only analyse the log it shouldn't require privilege to run so it should be placed in BIN? Perhaps that should be flipped then, xentrace needs be run as root AFAIK. Right. Fine by me. Wei. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote:
the SEDF scheduler is about to be deprecated and go
away (see [1]). OTOH, the RTDS scheduler is here to
stay.
It therefore makes sense to stop smoke testing the
former in favour of the latter. Note that the
-sedf-pin jobs where only added in order to try to
debug a long standing issue with SEDF; it is not
necessary to have anything like that for RTDS.
Does the RTDS scheduler work out of the box? I had a feeling that it
required per domain config settings to be worked out?
For now, as RTDS is still marked as experimental,
test failures are allowed, as it was for SEDF.
[1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
---
allow.all |2 +-
make-flight | 31 +--
2 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/allow.all b/allow.all
index 6715b2e..2897b2e 100644
--- a/allow.all
+++ b/allow.all
@@ -1,4 +1,4 @@
-test-@@-sedf@@
+test-@@-rtds@@
build-@@logs-capture@@
test-@@-pcipt@@
test-@@-qemuu-@@ guest-localmigrate
diff --git a/make-flight b/make-flight
index 8a1fceb..837f372 100755
--- a/make-flight
+++ b/make-flight
@@ -262,30 +262,16 @@ do_hvm_rhel6_tests () {
done
}
-do_sedf_tests () {
+do_nondef_sched_tests () {
if [ $xenarch != $dom0arch ]; then
return
fi
- for pin in '' -pin; do
-job_create_test test-$xenarch$kern-$dom0arch-xl-sedf$pin \
- test-debian xl $xenarch $dom0arch \
-guests_vcpus=4\
-xen_boot_append=sched=sedf loglvl=all ${pin:+dom0_vcpus_pin} \
-linux_boot_append='loglevel=9 debug' \
-$debian_runvars all_hostflags=$most_hostflags
- done
-}
-
-do_credit2_tests () {
- if [ $xenarch != $dom0arch ]; then
-return
- fi
-
- job_create_test test-$xenarch$kern-$dom0arch-xl-credit2 \
- test-debian xl $xenarch $dom0arch \
-guests_vcpus=4 xen_boot_append='sched=credit2'\
-$debian_runvars all_hostflags=$most_hostflags
+ sched=$1
+ job_create_test test-$xenarch$kern-$dom0arch-xl-$sched \
+ test-debian xl $xenarch $dom0arch \
+ guests_vcpus=4 xen_boot_append=sched=$sched \
+ $debian_runvars all_hostflags=$most_hostflags
}
do_multivcpu_tests () {
@@ -350,8 +336,9 @@ test_matrix_do_one () {
do_pv_debian_tests
do_multivcpu_tests
- do_sedf_tests
- do_credit2_tests
+ for s in credit2 rtds; do
+do_nondef_sched_tests $s
+ done
# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
[ Adding to Cc the people that I though I added when sending the patch, but that apparently I haven't...sorry :-( ] On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. It therefore makes sense to stop smoke testing the former in favour of the latter. Note that the -sedf-pin jobs where only added in order to try to debug a long standing issue with SEDF; it is not necessary to have anything like that for RTDS. For now, as RTDS is still marked as experimental, test failures are allowed, as it was for SEDF. [1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html Oh, and here's the diff of the generated runvars that IanJ usually asks about: :-) dariof@drall:~/osstest.git$ diff -Nru runvar.prepatch runvar.patched --- runvar.prepatch 2015-05-21 17:13:51.328281000 +0100 +++ runvar.patched 2015-05-21 17:15:51.112202000 +0100 @@ -370,30 +370,17 @@ test-amd64-amd64-xl-qemuu-winxpsp3win_acpi_shutdown true test-amd64-amd64-xl-qemuu-winxpsp3win_image winxpsp3.iso test-amd64-amd64-xl-qemuu-winxpsp3xenbuildjob build-amd64 -test-amd64-amd64-xl-sedf all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test -test-amd64-amd64-xl-sedf arch amd64 -test-amd64-amd64-xl-sedf buildjob build-amd64 -test-amd64-amd64-xl-sedf debian_arch amd64 -test-amd64-amd64-xl-sedf debian_kernkind pvops -test-amd64-amd64-xl-sedf guests_vcpus4 -test-amd64-amd64-xl-sedf kernbuildjob build-amd64-pvops -test-amd64-amd64-xl-sedf kernkind pvops -test-amd64-amd64-xl-sedf linux_boot_append loglevel=9 debug -test-amd64-amd64-xl-sedf-pin all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test -test-amd64-amd64-xl-sedf-pin arch amd64 -test-amd64-amd64-xl-sedf-pin buildjob build-amd64 -test-amd64-amd64-xl-sedf-pin debian_arch amd64 -test-amd64-amd64-xl-sedf-pin debian_kernkind pvops -test-amd64-amd64-xl-sedf-pin guests_vcpus4 -test-amd64-amd64-xl-sedf-pin kernbuildjob build-amd64-pvops -test-amd64-amd64-xl-sedf-pin kernkind pvops -test-amd64-amd64-xl-sedf-pin linux_boot_append loglevel=9 debug -test-amd64-amd64-xl-sedf-pin toolstack xl -test-amd64-amd64-xl-sedf-pin xen_boot_append sched=sedf loglvl=all dom0_vcpus_pin -test-amd64-amd64-xl-sedf-pin xenbuildjob build-amd64 -test-amd64-amd64-xl-sedf toolstack xl -test-amd64-amd64-xl-sedf xen_boot_append sched=sedf loglvl=all -test-amd64-amd64-xl-sedf xenbuildjob
[Xen-devel] xen-netfront crash when detaching network while some network activity
Hi all, I'm experiencing xen-netfront crash when doing xl network-detach while some network activity is going on at the same time. It happens only when domU has more than one vcpu. Not sure if this matters, but the backend is in another domU (not dom0). I'm using Xen 4.2.2. It happens on kernel 3.9.4 and 4.1-rc1 as well. Steps to reproduce: 1. Start the domU with some network interface 2. Call there 'ping -f some-IP' 3. Call 'xl network-detach NAME 0' The crash message: [ 54.163670] page:ea4bddc0 count:0 mapcount:0 mapping: (null) index:0x0 [ 54.163692] flags: 0x3fff808000(tail) [ 54.163704] page dumped because: VM_BUG_ON_PAGE(atomic_read(page-_count) == 0) [ 54.163726] [ cut here ] [ 54.163734] kernel BUG at include/linux/mm.h:343! [ 54.163742] invalid opcode: [#1] SMP [ 54.163752] Modules linked in: [ 54.163762] CPU: 1 PID: 24 Comm: xenwatch Not tainted 4.1.0-rc1-1.pvops.qubes.x86_64 #4 [ 54.163773] task: 8800133c4c00 ti: 880012c94000 task.ti: 880012c94000 [ 54.163782] RIP: e030:[811843cc] [811843cc] __free_pages+0x4c/0x50 [ 54.163800] RSP: e02b:880012c97be8 EFLAGS: 00010292 [ 54.163808] RAX: 0044 RBX: 77ff8000 RCX: 0044 [ 54.163817] RDX: RSI: RDI: 880013d0ea00 [ 54.163826] RBP: 880012c97be8 R08: 00f2 R09: [ 54.163835] R10: 00f2 R11: 8185efc0 R12: [ 54.163844] R13: 880011814200 R14: 880012f77000 R15: 0004 [ 54.163860] FS: 7f735f0d8740() GS:880013d0() knlGS: [ 54.163870] CS: e033 DS: ES: CR0: 8005003b [ 54.163878] CR2: 01652c50 CR3: 12112000 CR4: 2660 [ 54.163892] Stack: [ 54.163901] 880012c97c08 81184430 0011 0004 [ 54.163922] 880012c97c38 814100c6 87ff 880011f20d88 [ 54.163943] 880011814200 880011f2 880012c97ca8 814d34e6 [ 54.163964] Call Trace: [ 54.163977] [81184430] free_pages+0x60/0x70 [ 54.163994] [814100c6] gnttab_end_foreign_access+0x136/0x170 [ 54.164012] [814d34e6] xennet_disconnect_backend.isra.24+0x166/0x390 [ 54.164030] [814d37a8] xennet_remove+0x38/0xd0 [ 54.164045] [8141a009] xenbus_dev_remove+0x59/0xc0 [ 54.164059] [81479d27] __device_release_driver+0x87/0x120 [ 54.164528] [81479de3] device_release_driver+0x23/0x30 [ 54.164528] [81479658] bus_remove_device+0x108/0x180 [ 54.164528] [81475861] device_del+0x141/0x270 [ 54.164528] [814186a0] ? unregister_xenbus_watch+0x1d0/0x1d0 [ 54.164528] [814759b2] device_unregister+0x22/0x80 [ 54.164528] [81419e5f] xenbus_dev_changed+0xaf/0x200 [ 54.164528] [816ad346] ? _raw_spin_unlock_irqrestore+0x16/0x20 [ 54.164528] [814186a0] ? unregister_xenbus_watch+0x1d0/0x1d0 [ 54.164528] [8141bdb9] frontend_changed+0x29/0x60 [ 54.164528] [814186a0] ? unregister_xenbus_watch+0x1d0/0x1d0 [ 54.164528] [8141872e] xenwatch_thread+0x8e/0x150 [ 54.164528] [810be2b0] ? wait_woken+0x90/0x90 [ 54.164528] [81099958] kthread+0xd8/0xf0 [ 54.164528] [81099880] ? kthread_create_on_node+0x1b0/0x1b0 [ 54.164528] [816adde2] ret_from_fork+0x42/0x70 [ 54.164528] [81099880] ? kthread_create_on_node+0x1b0/0x1b0 [ 54.164528] Code: f6 74 0c e8 67 f5 ff ff 5d c3 0f 1f 44 00 00 31 f6 e8 99 fd ff ff 5d c3 0f 1f 80 00 00 00 00 48 c7 c6 78 29 a1 81 e8 d4 37 02 00 0f 0b 66 90 66 66 66 66 90 48 85 ff 75 06 f3 c3 0f 1f 40 00 55 [ 54.164528] RIP [811843cc] __free_pages+0x4c/0x50 [ 54.164528] RSP 880012c97be8 [ 54.166002] ---[ end trace 6b847bc27fec6d36 ]--- Any ideas how to fix this? I guess xennet_disconnect_backend should take some lock. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? pgpMz0nWHYgnp.pgp Description: PGP signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
On Fri, 2015-05-22 at 12:13 +0200, Dario Faggioli wrote: On Fri, 2015-05-22 at 11:02 +0100, Ian Campbell wrote: On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. It therefore makes sense to stop smoke testing the former in favour of the latter. Note that the -sedf-pin jobs where only added in order to try to debug a long standing issue with SEDF; it is not necessary to have anything like that for RTDS. Does the RTDS scheduler work out of the box? I had a feeling that it required per domain config settings to be worked out? It does, your feeling is about ARINC653 :-) Great, thanks! Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 56941: regressions - FAIL
flight 56941 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/56941/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 56728 Tests which are failing intermittently (not blocking): test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 56898 pass in 56941 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 56821 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 56898 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail pass in 56898 test-armhf-armhf-libvirt 11 guest-start fail pass in 56898 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 56898 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 56898 like 56728 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 12 migrate-support-check fail in 56898 never pass 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 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass version targeted for testing: xen ddfe333aef87e6c5f52b84c8beb3277be4663313 baseline version: xen 0c4e0ef608c98abef6220b0b027d9ce8ec65fd5f People who touched revisions under test: Eugene Korenevsky ekorenev...@gmail.com Jan Beulich jbeul...@suse.com Paul Durrant paul.durr...@citrix.com Ross Lagerwall ross.lagerw...@citrix.com Suravee Suthikulpanit suravee.suthikulpa...@amd.com jobs: build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass 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-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 fail test-armhf-armhf-xl-cubietruck pass
Re: [Xen-devel] [PATCH v3 8/8] xenalyze: remove argp_program_version
On Fri, May 22, 2015 at 08:19:39AM +, Olaf Hering wrote:
Since xenalyze is now upstream its Open Source and part of the given
release.
Signed-off-by: Olaf Hering o...@aepfle.de
Acked-by: George Dunlap george.dun...@eu.citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Acked-by: Wei Liu wei.l...@citrix.com
---
tools/xentrace/xenalyze.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index bc233c0..bfb7e2c 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -10407,7 +10407,6 @@ const struct argp parser_def = {
.doc = ,
};
-const char *argp_program_version = xenalyze - Open-source xen-unstable
(3.4);
const char *argp_program_bug_address = George Dunlap
george.dun...@eu.citrix.com;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/8] xenalyze: add to tools/xentrace/
On Fri, May 22, 2015 at 08:19:32AM +, Olaf Hering wrote: This merges xenalyze.hg, changeset 150:24308507be1d, into tools/xentrace/xenalyze.c to have the tool and public/trace.h in one place. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- .gitignore| 1 + tools/xentrace/Makefile | 9 +- tools/xentrace/analyze.h | 107 + tools/xentrace/mread.c| 160 + tools/xentrace/mread.h|18 + tools/xentrace/pv.h |41 + tools/xentrace/xenalyze.c | 10407 7 files changed, 10742 insertions(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 3bc9cd9..3f42ded 100644 --- a/.gitignore +++ b/.gitignore @@ -173,6 +173,7 @@ tools/misc/gtracestat tools/misc/xenlockprof tools/misc/lowmemd tools/misc/xencov +tools/xentrace/xenalyze tools/pygrub/build/* tools/python/build/* tools/security/secpol_tool diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile index 8b80541..57691af 100644 --- a/tools/xentrace/Makefile +++ b/tools/xentrace/Makefile @@ -7,6 +7,7 @@ CFLAGS += $(CFLAGS_libxenctrl) LDLIBS += $(LDLIBS_libxenctrl) BIN = xentrace xentrace_setsize +SBIN = xenalyze Why is xenalyze not placed in the same directory as xentrace? My impression is that they are closely related. What did I miss? And given that xenalyze only analyse the log it shouldn't require privilege to run so it should be placed in BIN? LIBBIN = xenctx SCRIPTS = xentrace_format MAN1 = $(wildcard *.1) @@ -16,15 +17,17 @@ MAN8 = $(wildcard *.8) all: build .PHONY: build -build: $(BIN) $(LIBBIN) +build: $(BIN) $(SBIN) $(LIBBIN) .PHONY: install install: build $(INSTALL_DIR) $(DESTDIR)$(bindir) + $(INSTALL_DIR) $(DESTDIR)$(sbindir) [ -z $(LIBBIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN) $(INSTALL_DIR) $(DESTDIR)$(MAN1DIR) $(INSTALL_DIR) $(DESTDIR)$(MAN8DIR) $(INSTALL_PROG) $(BIN) $(DESTDIR)$(bindir) + $(INSTALL_PROG) $(SBIN) $(DESTDIR)$(sbindir) $(INSTALL_PYTHON_PROG) $(SCRIPTS) $(DESTDIR)$(bindir) [ -z $(LIBBIN) ] || $(INSTALL_PROG) $(LIBBIN) $(DESTDIR)$(LIBEXEC_BIN) $(INSTALL_DATA) $(MAN1) $(DESTDIR)$(MAN1DIR) And of course if it is placed under BIN you won't need the above hunk anymore. Wei. @@ -46,5 +49,9 @@ xenctx: xenctx.o xentrace_setsize: setsize.o $(CC) $(LDFLAGS) -o $@ $ $(LDLIBS) $(APPEND_LDFLAGS) +xenalyze.o: CFLAGS += -I$(XEN_ROOT)/xen/include +xenalyze: xenalyze.o mread.o + $(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS) $(APPEND_LDFLAGS) + -include $(DEPS) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC][v2][PATCH 05/14] xen/x86/p2m: introduce set_identity_p2m_entry
We will create this sort of identity mapping as follows:
If the gfn space is unoccupied, we just set the mapping. If the space
is already occupied by 1:1 mappings, do nothing. Failed for any
other cases.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/arch/x86/mm/p2m.c | 30 ++
xen/include/asm-x86/p2m.h | 4
2 files changed, 34 insertions(+)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 1fd1194..c674201 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -898,6 +898,36 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long
gfn, mfn_t mfn,
return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct, access);
}
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+ p2m_access_t p2ma)
+{
+p2m_type_t p2mt;
+p2m_access_t a;
+mfn_t mfn;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+int ret = -EBUSY;
+
+gfn_lock(p2m, gfn, 0);
+
+mfn = p2m-get_entry(p2m, gfn, p2mt, a, 0, NULL);
+
+if ( p2mt == p2m_invalid )
+ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
+p2m_mmio_direct, p2ma);
+else if ( mfn_x(mfn) == gfn p2mt == p2m_mmio_direct a == p2ma )
+ret = 0;
+else
+{
+printk(XENLOG_G_WARNING
+ Cannot identity map d%d:%lx, already mapped to %lx.\n,
+ d-domain_id, gfn, mfn_x(mfn));
+}
+
+gfn_unlock(p2m, gfn, 0);
+
+return ret;
+}
+
/* Returns: 0 for success, -errno for failure */
int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
{
diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
index b49c09b..95b6266 100644
--- a/xen/include/asm-x86/p2m.h
+++ b/xen/include/asm-x86/p2m.h
@@ -543,6 +543,10 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long
gfn, mfn_t mfn,
p2m_access_t access);
int clear_mmio_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn);
+/* Set identity addresses in the p2m table (for pass-through) */
+int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
+ p2m_access_t p2ma);
+
/* Add foreign mapping to the guest's p2m table. */
int p2m_add_foreign(struct domain *tdom, unsigned long fgfn,
unsigned long gpfn, domid_t foreign_domid);
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC][v2][PATCH 00/14] Fix RMRR
v2: * Instead of that fixed predefined rdm memory boundary, we'd like to introduce a parameter, rdm_mem_boundary, to set this threshold value. * Remove that existing USB hack. * Make sure the MMIO regions all fit in the available resource window * Rename our policy, force/try - strict/relaxed * Indeed, Wei and Jan gave me more and more comments to refine codes * Code style * Better and reasonable code implementation * Correct or improve code comments. * A little bit to work well with ARM. Open: * We should fail assigning device which has a shared RMRR with another device. We can only do group assignment when RMRR is shared among devices. We need more time to figure a good policy/way out because something is not clear to me. As you know all devices are owned by Dom0 firstly before we create any DomU, right? Do we allow Dom0 still own a group device while assign another device in the same group? Really appreciate any comments to policy. v1: RMRR is an acronym for Reserved Memory Region Reporting, expected to be used for legacy usages (such as USB, UMA Graphics, etc.) requiring reserved memory. Special treatment is required in system software to setup those reserved regions in IOMMU translation structures, otherwise passing through a device with RMRR reported may not work correctly. This patch set tries to enhance existing Xen RMRR implementation to fix various reported and theoretical problems. Most noteworthy changes are to setup identity mapping in p2m layer and handle possible conflicts between reported regions and gfn space. Initial proposal can be found at: http://lists.xenproject.org/archives/html/xen-devel/2015-01/msg00524.html and after a long discussion a summarized agreement is here: http://lists.xen.org/archives/html/xen-devel/2015-01/msg01580.html Below is a key summary of this patch set according to agreed proposal: 1. Use RDM (Reserved Device Memory) name in user space as a general description instead of using ACPI RMRR name directly. 2. Introduce configuration parameters to allow user control both per-device and global RDM resources along with desired policies upon a detected conflict. 3. Introduce a new hypercall to query global and per-device RDM resources. 4. Extend libxl to be a central place to manage RDM resources and handle potential conflicts between reserved regions and gfn space. One simplification goal is made to keep existing lowmem / mmio / highmem layout which is passed around various function blocks. So a reasonable assumption is made, that conflicts falling into below areas are not re-arranged otherwise it will result in a more scattered layout: a) in highmem region (4G) b) in lowmem region, and below a predefined boundary (default 2G) a) is a new assumption not discussed before. From VT-d spec this is possible but no such observation in real-world. So we can make this reasonable assumption until there's real usage on it. 5. Extend XENMEM_set_memory_map usable for HVM guest, and then have libxl to use that hypercall to carry RDM information to hvmloader. There is one difference from original discussion. Previously we discussed to introduce a new E820 type specifically for RDM entries. After more thought we think it's OK to just tag them as E820_reserved. Actually hvmloader doesn't need to know whether the reserved entries come from RDM or from other purposes. 6. Then in hvmloader the change is generic for XENMEM_memory_map change. Given a predefined memory layout, hvmloader should avoid allocating all reserved entries for other usages (opregion, mmio, etc.) 7. Extend existing device passthrough hypercall to carry conflict handling policy. 8. Setup identity map in p2m layer for RMRRs reported for the given device. And conflicts are handled according to specified policy in hypercall. Current patch set contains core enhancements calling for comments. There are still several tasks not implemented now. We'll include them in final version after RFC is agreed: - remove existing USB hack - detect and fail assigning device which has a shared RMRR with another device - add a config parameter to configure that memory boundary flexibly - In the case of hotplug we also need to figure out a way to fix that policy conflict between the per-pci policy and the global policy but firstly we think we'd better collect some good or correct ideas to step next in RFC. So here I made this as RFC to collect your any comments. Jan Beulich (1): introduce XENMEM_reserved_device_memory_map Tiejun Chen (13): tools: introduce some new parameters to set rdm policy tools/libxc: Expose new hypercall xc_reserved_device_memory_map tools/libxl: detect and avoid conflicts with RDM xen/x86/p2m: introduce set_identity_p2m_entry xen:vtd: create RMRR mapping xen/passthrough: extend hypercall to support rdm reservation policy tools: extend
[Xen-devel] [RFC][v2][PATCH 01/14] tools: introduce some new parameters to set rdm policy
This patch introduces user configurable parameters to specify RDM resource and according policies, Global RDM parameter: rdm = [ 'type=none/host, reserve=strict/relaxed' ] Per-device RDM parameter: pci = [ 'sbdf, rdm_reserve=strict/relaxed' ] Global RDM parameter, type, allows user to specify reserved regions explicitly, e.g. using 'host' to include all reserved regions reported on this platform which is good to handle hotplug scenario. In the future this parameter may be further extended to allow specifying random regions, e.g. even those belonging to another platform as a preparation for live migration with passthrough devices. Instead, 'none' means we have nothing to do all reserved regions and ignore all policies, so guest work as before. 'strict/relaxed' policy decides how to handle conflict when reserving RDM regions in pfn space. If conflict exists, 'strict' means an immediate error so VM will be killed, while 'relaxed' allows moving forward with a warning message thrown out. Default per-device RDM policy is 'strict', while default global RDM policy is 'relaxed'. When both policies are specified on a given region, 'strict' is always preferred. Signed-off-by: Tiejun Chen tiejun.c...@intel.com --- docs/man/xl.cfg.pod.5| 57 +++ docs/misc/vtd.txt| 24 tools/libxl/libxl_create.c | 13 +++ tools/libxl/libxl_internal.h | 2 + tools/libxl/libxl_pci.c | 2 + tools/libxl/libxl_types.idl | 18 + tools/libxl/libxlu_pci.c | 92 tools/libxl/libxlutil.h | 4 ++ tools/libxl/xl_cmdimpl.c | 10 + 9 files changed, 222 insertions(+) diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5 index 8e4154f..12c34c4 100644 --- a/docs/man/xl.cfg.pod.5 +++ b/docs/man/xl.cfg.pod.5 @@ -645,6 +645,49 @@ assigned slave device. =back +=item Brdm= RDM_RESERVE_STRING + +(HVM/x86 only) Specifies the information about Reserved Device Memory (RDM), +which is necessary to enable robust device passthrough usage. One example of +RDM is reported through ACPI Reserved Memory Region Reporting (RMRR) +structure on x86 platform. + +BRDM_RESERVE_STRING has the form C[KEY=VALUE,KEY=VALUE,... where: + +=over 4 + +=item BKEY=VALUE + +Possible BKEYs are: + +=over 4 + +=item Btype=STRING + +Currently we just have two types: + +host means all reserved device memory on this platform should be reserved +in this VM's pfn space. This global RDM parameter allows user to specify +reserved regions explicitly. And using host to include all reserved regions +reported on this platform which is good to handle hotplug scenario. In the +future this parameter may be further extended to allow specifying random +regions, e.g. even those belonging to another platform as a preparation +for live migration with passthrough devices. + +none means we have nothing to do all reserved regions and ignore all policies, +so guest work as before. + +=over 4 + +=item Breserve=STRING + +Conflict may be detected when reserving reserved device memory in gfn space. +strict means an unsolved conflict leads to immediate VM crash, while +relaxed allows VM moving forward with a warning message thrown out. relaxed +is default. + +Note this may be overrided by another sub item, rdm_reserve, in pci device. + =item Bpci=[ PCI_SPEC_STRING, PCI_SPEC_STRING, ... ] Specifies the host PCI devices to passthrough to this guest. Each BPCI_SPEC_STRING @@ -707,6 +750,20 @@ dom0 without confirmation. Please use with care. D0-D3hot power management states for the PCI device. False (0) by default. +=item Brdm_reserv=STRING + +(HVM/x86 only) Specifies the information about Reserved Device Memory (RDM), +which is necessary to enable robust device passthrough usage. One example of +RDM is reported through ACPI Reserved Memory Region Reporting (RMRR) +structure on x86 platform. + +Conflict may be detected when reserving reserved device memory in gfn space. +strict means an unsolved conflict leads to immediate VM crash, while +relaxed allows VM moving forward with a warning message thrown out. strict +is default. + +Note this would override global Brdm option. + =back =back diff --git a/docs/misc/vtd.txt b/docs/misc/vtd.txt index 9af0e99..7d63c47 100644 --- a/docs/misc/vtd.txt +++ b/docs/misc/vtd.txt @@ -111,6 +111,30 @@ in the config file: To override for a specific device: pci = [ '01:00.0,msitranslate=0', '03:00.0' ] +RDM, 'reserved device memory', for PCI Device Passthrough +- + +There are some devices the BIOS controls, for e.g. USB devices to perform +PS2 emulation. The regions of memory used for these devices are marked +reserved in the e820 map. When we turn on DMA translation, DMA to those +regions will fail. Hence BIOS uses RMRR to specify these regions along with +devices that need to access these regions. OS is expected to setup +identity mappings for
[Xen-devel] [RFC][v2][PATCH 02/14] introduce XENMEM_reserved_device_memory_map
From: Jan Beulich jbeul...@suse.com
This is a prerequisite for punching holes into HVM and PVH guests' P2M
to allow passing through devices that are associated with (on VT-d)
RMRRs.
Signed-off-by: Jan Beulich jbeul...@suse.com
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/common/compat/memory.c | 66
xen/common/memory.c | 64 ++
xen/drivers/passthrough/iommu.c | 10 ++
xen/drivers/passthrough/vtd/dmar.c | 32 +
xen/drivers/passthrough/vtd/extern.h | 1 +
xen/drivers/passthrough/vtd/iommu.c | 1 +
xen/include/public/memory.h | 32 -
xen/include/xen/iommu.h | 10 ++
xen/include/xen/pci.h| 2 ++
xen/include/xlat.lst | 3 +-
10 files changed, 219 insertions(+), 2 deletions(-)
diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c
index b258138..b608496 100644
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
@@ -17,6 +17,45 @@ CHECK_TYPE(domid);
CHECK_mem_access_op;
CHECK_vmemrange;
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+struct compat_reserved_device_memory_map map;
+unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+ u32 id, void *ctxt)
+{
+struct get_reserved_device_memory *grdm = ctxt;
+u32 sbdf;
+struct compat_reserved_device_memory rdm = {
+.start_pfn = start, .nr_pages = nr
+};
+
+sbdf = PCI_SBDF2(grdm-map.seg, grdm-map.bus, grdm-map.devfn);
+if ( (grdm-map.flag PCI_DEV_RDM_ALL) || (sbdf == id) )
+{
+if ( grdm-used_entries grdm-map.nr_entries )
+{
+if ( rdm.start_pfn != start || rdm.nr_pages != nr )
+return -ERANGE;
+
+if ( __copy_to_compat_offset(grdm-map.buffer,
+ grdm-used_entries,
+ rdm,
+ 1) )
+{
+return -EFAULT;
+}
+}
+++grdm-used_entries;
+return 1;
+}
+
+return 0;
+}
+#endif
+
int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat)
{
int split, op = cmd MEMOP_CMD_MASK;
@@ -303,6 +342,33 @@ int compat_memory_op(unsigned int cmd,
XEN_GUEST_HANDLE_PARAM(void) compat)
break;
}
+#ifdef HAS_PASSTHROUGH
+case XENMEM_reserved_device_memory_map:
+{
+struct get_reserved_device_memory grdm;
+
+if ( copy_from_guest(grdm.map, compat, 1) ||
+ !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
+return -EFAULT;
+
+grdm.used_entries = 0;
+rc = iommu_get_reserved_device_memory(get_reserved_device_memory,
+ grdm);
+
+if ( !rc grdm.map.nr_entries grdm.used_entries )
+rc = -ENOBUFS;
+
+grdm.map.nr_entries = grdm.used_entries;
+if ( grdm.map.nr_entries )
+{
+if ( __copy_to_guest(compat, grdm.map, 1) )
+rc = -EFAULT;
+}
+
+return rc;
+}
+#endif
+
default:
return compat_arch_memory_op(cmd, compat);
}
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 063a1c5..c789f72 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -748,6 +748,43 @@ static int construct_memop_from_reservation(
return 0;
}
+#ifdef HAS_PASSTHROUGH
+struct get_reserved_device_memory {
+struct xen_reserved_device_memory_map map;
+unsigned int used_entries;
+};
+
+static int get_reserved_device_memory(xen_pfn_t start, xen_ulong_t nr,
+ u32 id, void *ctxt)
+{
+struct get_reserved_device_memory *grdm = ctxt;
+u32 sbdf;
+
+sbdf = PCI_SBDF2(grdm-map.seg, grdm-map.bus, grdm-map.devfn);
+if ( (grdm-map.flag PCI_DEV_RDM_ALL) || (sbdf == id) )
+{
+if ( grdm-used_entries grdm-map.nr_entries )
+{
+struct xen_reserved_device_memory rdm = {
+.start_pfn = start, .nr_pages = nr
+};
+
+if ( __copy_to_guest_offset(grdm-map.buffer,
+grdm-used_entries,
+rdm,
+1) )
+{
+return -EFAULT;
+}
+}
+++grdm-used_entries;
+return 1;
+}
+
+return 0;
+}
+#endif
+
long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
struct domain *d;
@@ -1162,6 +1199,33 @@ long do_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
break;
}
+#ifdef HAS_PASSTHROUGH
+case
[Xen-devel] [RFC][v2][PATCH 09/14] xen: enable XENMEM_memory_map in hvm
This patch enables XENMEM_memory_map in hvm. So we can use it to
setup the e820 mappings.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
Reviewed-by: Tim Deegan t...@xen.org
---
xen/arch/x86/hvm/hvm.c | 2 --
xen/arch/x86/mm.c | 6 --
2 files changed, 8 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 689e402..0dedd3b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4705,7 +4705,6 @@ static long hvm_memory_op(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd MEMOP_CMD_MASK )
{
-case XENMEM_memory_map:
case XENMEM_machine_memory_map:
case XENMEM_machphys_mapping:
return -ENOSYS;
@@ -4781,7 +4780,6 @@ static long hvm_memory_op_compat32(int cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
switch ( cmd MEMOP_CMD_MASK )
{
-case XENMEM_memory_map:
case XENMEM_machine_memory_map:
case XENMEM_machphys_mapping:
return -ENOSYS;
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 034de22..d6fa080 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4715,12 +4715,6 @@ long arch_memory_op(unsigned long cmd,
XEN_GUEST_HANDLE_PARAM(void) arg)
return rc;
}
-if ( is_hvm_domain(d) )
-{
-rcu_unlock_domain(d);
-return -EPERM;
-}
-
e820 = xmalloc_array(e820entry_t, fmap.map.nr_entries);
if ( e820 == NULL )
{
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC][v2][PATCH 11/14] hvmloader: get guest memory map into memory_map[]
Now we get this map layout by call XENMEM_memory_map then
save them into one global variable memory_map[]. It should
include lowmem range, rdm range and highmem range. Note
rdm range and highmem range may not exist in some cases.
And here we need to check if any reserved memory conflicts with
[RESERVED_MEMORY_DYNAMIC_START - 1, RESERVED_MEMORY_DYNAMIC_END].
This range is used to allocate memory in hvmloder level, and
we would lead hvmloader failed in case of conflict since its
another rare possibility in real world.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
tools/firmware/hvmloader/e820.h | 7 +++
tools/firmware/hvmloader/hvmloader.c | 36
tools/firmware/hvmloader/util.c | 26 ++
tools/firmware/hvmloader/util.h | 11 +++
4 files changed, 80 insertions(+)
diff --git a/tools/firmware/hvmloader/e820.h b/tools/firmware/hvmloader/e820.h
index b2ead7f..8b5a9e0 100644
--- a/tools/firmware/hvmloader/e820.h
+++ b/tools/firmware/hvmloader/e820.h
@@ -15,6 +15,13 @@ struct e820entry {
uint32_t type;
} __attribute__((packed));
+#define E820MAX128
+
+struct e820map {
+unsigned int nr_map;
+struct e820entry map[E820MAX];
+};
+
#endif /* __HVMLOADER_E820_H__ */
/*
diff --git a/tools/firmware/hvmloader/hvmloader.c
b/tools/firmware/hvmloader/hvmloader.c
index 25b7f08..33da5b5 100644
--- a/tools/firmware/hvmloader/hvmloader.c
+++ b/tools/firmware/hvmloader/hvmloader.c
@@ -107,6 +107,8 @@ asm (
.text \n
);
+struct e820map memory_map;
+
unsigned long scratch_start = SCRATCH_PHYSICAL_ADDRESS;
static void init_hypercalls(void)
@@ -199,6 +201,38 @@ static void apic_setup(void)
ioapic_write(0x11, SET_APIC_ID(LAPIC_ID(0)));
}
+void memory_map_setup(void)
+{
+unsigned int nr_entries = E820MAX, i;
+int rc;
+uint64_t alloc_addr = RESERVED_MEMORY_DYNAMIC_START - 1;
+uint64_t alloc_size = RESERVED_MEMORY_DYNAMIC_END - alloc_addr;
+
+rc = get_mem_mapping_layout(memory_map.map, nr_entries);
+
+if ( rc )
+{
+printf(Failed to get guest memory map.\n);
+BUG();
+}
+
+memory_map.nr_map = nr_entries;
+
+for ( i = 0; i nr_entries; i++ )
+{
+if ( memory_map.map[i].type == E820_RESERVED )
+{
+if ( check_overlap(alloc_addr, alloc_size,
+ memory_map.map[i].addr,
+ memory_map.map[i].size) )
+{
+printf(RDM conflicts Memory allocation.\n);
+BUG();
+}
+}
+}
+}
+
struct bios_info {
const char *key;
const struct bios_config *bios;
@@ -262,6 +296,8 @@ int main(void)
init_hypercalls();
+memory_map_setup();
+
xenbus_setup();
bios = detect_bios();
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 80d822f..122e3fa 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -27,6 +27,17 @@
#include xen/memory.h
#include xen/sched.h
+/*
+ * Check whether there exists overlap in the specified memory range.
+ * Returns true if exists, else returns false.
+ */
+bool check_overlap(uint64_t start, uint64_t size,
+ uint64_t reserved_start, uint64_t reserved_size)
+{
+return (start + size reserved_start)
+(start reserved_start + reserved_size);
+}
+
void wrmsr(uint32_t idx, uint64_t v)
{
asm volatile (
@@ -368,6 +379,21 @@ uuid_to_string(char *dest, uint8_t *uuid)
*p = '\0';
}
+int get_mem_mapping_layout(struct e820entry entries[], uint32_t *max_entries)
+{
+int rc;
+struct xen_memory_map memmap = {
+.nr_entries = *max_entries
+};
+
+set_xen_guest_handle(memmap.buffer, entries);
+
+rc = hypercall_memory_op(XENMEM_memory_map, memmap);
+*max_entries = memmap.nr_entries;
+
+return rc;
+}
+
void mem_hole_populate_ram(xen_pfn_t mfn, uint32_t nr_mfns)
{
static int over_allocated;
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index a70e4aa..70e19c4 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -4,8 +4,10 @@
#include stdarg.h
#include stdint.h
#include stddef.h
+#include stdbool.h
#include xen/xen.h
#include xen/hvm/hvm_info_table.h
+#include e820.h
#define __STR(...) #__VA_ARGS__
#define STR(...) __STR(__VA_ARGS__)
@@ -222,6 +224,9 @@ int hvm_param_set(uint32_t index, uint64_t value);
/* Setup PCI bus */
void pci_setup(void);
+/* Setup memory map */
+void memory_map_setup(void);
+
/* Prepare the 32bit BIOS */
uint32_t rombios_highbios_setup(void);
@@ -249,6 +254,12 @@ void perform_tests(void);
extern char _start[], _end[];
+int get_mem_mapping_layout(struct e820entry entries[], uint32_t *max_entries);
+
+extern struct e820map memory_map;
+bool check_overlap(uint64_t start, uint64_t size,
+
[Xen-devel] [RFC][v2][PATCH 06/14] xen:vtd: create RMRR mapping
RMRR reserved regions must be setup in the pfn space with an identity
mapping to reported mfn. However existing code has problem to setup
correct mapping when VT-d shares EPT page table, so lead to problem
when assigning devices (e.g GPU) with RMRR reported. So instead, this
patch aims to setup identity mapping in p2m layer, regardless of
whether EPT is shared or not. And we still keep creating VT-d table.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/arch/x86/mm/p2m.c | 5 +
xen/drivers/passthrough/vtd/iommu.c | 3 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c674201..3574521 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -925,6 +925,11 @@ int set_identity_p2m_entry(struct domain *d, unsigned long
gfn,
gfn_unlock(p2m, gfn, 0);
+if( ret == 0 )
+{
+ret = iommu_map_page(d, gfn, gfn, IOMMUF_readable|IOMMUF_writable);
+}
+
return ret;
}
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 6a37624..31ce1af 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1856,8 +1856,7 @@ static int rmrr_identity_mapping(struct domain *d, bool_t
map,
while ( base_pfn end_pfn )
{
-int err = intel_iommu_map_page(d, base_pfn, base_pfn,
- IOMMUF_readable|IOMMUF_writable);
+int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw);
if ( err )
return err;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC][v2][PATCH 07/14] xen/passthrough: extend hypercall to support rdm reservation policy
This patch extends the existing hypercall to support rdm reservation policy.
We return error or just throw out a warning message depending on whether
the policy is 'force' or 'try'. And in some cases, e.g. add a device to
hwdomain, and remove a device from user domain, 'try' is fine enough since
this is always safe to hwdomain.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
xen/arch/x86/mm/p2m.c | 8 +++-
xen/drivers/passthrough/amd/pci_amd_iommu.c | 3 ++-
xen/drivers/passthrough/arm/smmu.c | 2 +-
xen/drivers/passthrough/device_tree.c | 3 ++-
xen/drivers/passthrough/pci.c | 9 +
xen/drivers/passthrough/vtd/iommu.c | 20
xen/include/asm-x86/p2m.h | 2 +-
xen/include/public/domctl.h | 5 +
xen/include/xen/iommu.h | 2 +-
9 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 3574521..89473b9 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -899,7 +899,7 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long gfn,
mfn_t mfn,
}
int set_identity_p2m_entry(struct domain *d, unsigned long gfn,
- p2m_access_t p2ma)
+ p2m_access_t p2ma, u32 flag)
{
p2m_type_t p2mt;
p2m_access_t a;
@@ -921,6 +921,12 @@ int set_identity_p2m_entry(struct domain *d, unsigned long
gfn,
printk(XENLOG_G_WARNING
Cannot identity map d%d:%lx, already mapped to %lx.\n,
d-domain_id, gfn, mfn_x(mfn));
+
+if ( flag == XEN_DOMCTL_DEV_RDM_RELAXED )
+{
+ret = 0;
+printk(XENLOG_G_WARNING Some devices may work failed .\n);
+}
}
gfn_unlock(p2m, gfn, 0);
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index e83bb35..920b35a 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -394,7 +394,8 @@ static int reassign_device(struct domain *source, struct
domain *target,
}
static int amd_iommu_assign_device(struct domain *d, u8 devfn,
- struct pci_dev *pdev)
+ struct pci_dev *pdev,
+ u32 flag)
{
struct ivrs_mappings *ivrs_mappings = get_ivrs_mappings(pdev-seg);
int bdf = PCI_BDF2(pdev-bus, devfn);
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 6cc4394..9a667e9 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2605,7 +2605,7 @@ static void arm_smmu_destroy_iommu_domain(struct
iommu_domain *domain)
}
static int arm_smmu_assign_dev(struct domain *d, u8 devfn,
- struct device *dev)
+ struct device *dev, u32 flag)
{
struct iommu_domain *domain;
struct arm_smmu_xen_domain *xen_domain;
diff --git a/xen/drivers/passthrough/device_tree.c
b/xen/drivers/passthrough/device_tree.c
index 5d3842a..d4ff7f0 100644
--- a/xen/drivers/passthrough/device_tree.c
+++ b/xen/drivers/passthrough/device_tree.c
@@ -52,7 +52,8 @@ int iommu_assign_dt_device(struct domain *d, struct
dt_device_node *dev)
goto fail;
}
-rc = hd-platform_ops-assign_device(d, 0, dt_to_dev(dev));
+rc = hd-platform_ops-assign_device(d, 0, dt_to_dev(dev),
+ XEN_DOMCTL_DEV_NO_RDM);
if ( rc )
goto fail;
diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 862e20f..c06f038 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -1338,7 +1338,7 @@ static int device_assigned(u16 seg, u8 bus, u8 devfn)
return pdev ? 0 : -EBUSY;
}
-static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
+static int assign_device(struct domain *d, u16 seg, u8 bus, u8 devfn, u32 flag)
{
struct hvm_iommu *hd = domain_hvm_iommu(d);
struct pci_dev *pdev;
@@ -1374,7 +1374,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
pdev-fault.count = 0;
-if ( (rc = hd-platform_ops-assign_device(d, devfn, pci_to_dev(pdev))) )
+if ( (rc = hd-platform_ops-assign_device(d, devfn, pci_to_dev(pdev),
flag)) )
goto done;
for ( ; pdev-phantom_stride; rc = 0 )
@@ -1382,7 +1382,7 @@ static int assign_device(struct domain *d, u16 seg, u8
bus, u8 devfn)
devfn += pdev-phantom_stride;
if ( PCI_SLOT(devfn) != PCI_SLOT(pdev-devfn) )
break;
-rc = hd-platform_ops-assign_device(d, devfn, pci_to_dev(pdev));
+rc = hd-platform_ops-assign_device(d, devfn, pci_to_dev(pdev), flag);
if ( rc )
printk(XENLOG_G_WARNING d%d: assign %04x:%02x:%02x.%u failed
(%d)\n,
[Xen-devel] [RFC][v2][PATCH 04/14] tools/libxl: detect and avoid conflicts with RDM
While building a VM, HVM domain builder provides struct hvm_info_table{}
to help hvmloader. Currently it includes two fields to construct guest
e820 table by hvmloader, low_mem_pgend and high_mem_pgend. So we should
check them to fix any conflict with RAM.
RMRR can reside in address space beyond 4G theoretically, but we never
see this in real world. So in order to avoid breaking highmem layout
we don't solve highmem conflict. Note this means highmem rmrr could still
be supported if no conflict.
But in the case of lowmem, RMRR probably scatter the whole RAM space.
Especially multiple RMRR entries would worsen this to lead a complicated
memory layout. And then its hard to extend hvm_info_table{} to work
hvmloader out. So here we're trying to figure out a simple solution to
avoid breaking existing layout. So when a conflict occurs,
#1. Above a predefined boundary (default 2G)
- move lowmem_end below reserved region to solve conflict;
#2. Below a predefined boundary (default 2G)
- Check strict/relaxed policy.
strict policy leads to fail libxl. Note when both policies
are specified on a given region, 'strict' is always preferred.
relaxed policy issue a warning message and also mask this entry
INVALID
to indicate we shouldn't expose this entry to hvmloader.
Note this predefined boundary can be changes with the parameter
rdm_mem_boundary in .cfg file.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
docs/man/xl.cfg.pod.5 | 21
tools/libxc/include/xenguest.h | 1 +
tools/libxc/xc_hvm_build_x86.c | 25 ++--
tools/libxl/libxl_create.c | 2 +-
tools/libxl/libxl_dm.c | 253 +
tools/libxl/libxl_dom.c| 27 -
tools/libxl/libxl_internal.h | 11 +-
tools/libxl/libxl_types.idl| 8 ++
tools/libxl/xl_cmdimpl.c | 3 +
9 files changed, 337 insertions(+), 14 deletions(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 12c34c4..80e3930 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -764,6 +764,27 @@ is default.
Note this would override global Brdm option.
+=item Brdm_mem_boundary=MBYTES
+
+Number of megabytes to set a boundary for checking rdm conflict.
+
+When RDM conflicts with RAM, RDM probably scatter the whole RAM space.
+Especially multiple RMRR entries would worsen this to lead a complicated
+memory layout. So here we're trying to figure out a simple solution to
+avoid breaking existing layout. So when a conflict occurs,
+
+#1. Above a predefined boundary
+- move lowmem_end below reserved region to solve conflict;
+
+#2. Below a predefined boundary
+- Check strict/relaxed policy.
+strict policy leads to fail libxl. Note when both policies
+are specified on a given region, 'strict' is always preferred.
+relaxed policy issue a warning message and also mask this entry
INVALID
+to indicate we shouldn't expose this entry to hvmloader.
+
+Her the default is 2G.
+
=back
=back
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..4cb7e9f 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -234,6 +234,7 @@ struct xc_hvm_firmware_module {
};
struct xc_hvm_build_args {
+uint64_t lowmem_size;/* All low memory size in bytes. */
uint64_t mem_size; /* Memory size in bytes. */
uint64_t mem_target; /* Memory target in bytes. */
uint64_t mmio_size; /* Size of the MMIO hole in bytes. */
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index e45ae4a..9a1567a 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -21,6 +21,7 @@
#include stdlib.h
#include unistd.h
#include zlib.h
+#include assert.h
#include xg_private.h
#include xc_private.h
@@ -98,11 +99,8 @@ static void build_hvm_info(void *hvm_info_page, uint64_t
mem_size,
uint8_t sum;
int i;
-if ( lowmem_end mmio_start )
-{
-highmem_end = (1ull32) + (lowmem_end - mmio_start);
-lowmem_end = mmio_start;
-}
+if ( args-mem_size lowmem_end )
+highmem_end = (1ull32) + (args-mem_size - lowmem_end);
memset(hvm_info_page, 0, PAGE_SIZE);
@@ -279,7 +277,7 @@ static int setup_guest(xc_interface *xch,
elf_parse_binary(elf);
v_start = 0;
-v_end = args-mem_size;
+v_end = args-lowmem_size;
if ( nr_pages target_pages )
memflags |= XENMEMF_populate_on_demand;
@@ -344,8 +342,14 @@ static int setup_guest(xc_interface *xch,
for ( i = 0; i nr_pages; i++ )
page_array[i] = i;
-for ( i = mmio_start PAGE_SHIFT; i nr_pages; i++ )
-page_array[i] += mmio_size PAGE_SHIFT;
+/*
+ * Actually v_end is args-lowmem_size, and we already adjusted
+ * this below mmio_start when we check rdm previously, so here
+ * this
[Xen-devel] [RFC][v2][PATCH 12/14] hvmloader/pci: skip reserved ranges
When allocating mmio address for PCI bars, we need to make
sure they don't overlap with reserved regions.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
tools/firmware/hvmloader/pci.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 5ff87a7..98af568 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -59,8 +59,8 @@ void pci_setup(void)
uint32_t bar_reg;
uint64_t bar_sz;
} *bars = (struct bars *)scratch_start;
-unsigned int i, nr_bars = 0;
-uint64_t mmio_hole_size = 0;
+unsigned int i, j, nr_bars = 0;
+uint64_t mmio_hole_size = 0, reserved_end, max_bar_sz = 0;
const char *s;
/*
@@ -226,6 +226,8 @@ void pci_setup(void)
bars[i].devfn = devfn;
bars[i].bar_reg = bar_reg;
bars[i].bar_sz = bar_sz;
+if ( bar_sz max_bar_sz )
+max_bar_sz = bar_sz;
if ( ((bar_data PCI_BASE_ADDRESS_SPACE) ==
PCI_BASE_ADDRESS_SPACE_MEMORY) ||
@@ -301,6 +303,21 @@ void pci_setup(void)
pci_mem_start = 1;
}
+/* Relocate PCI memory that overlaps reserved space, like RDM. */
+for ( j = 0; j memory_map.nr_map ; j++ )
+{
+if ( memory_map.map[j].type != E820_RAM )
+{
+reserved_end = memory_map.map[j].addr + memory_map.map[j].size;
+if ( check_overlap(pci_mem_start, pci_mem_end,
+ memory_map.map[j].addr,
+ memory_map.map[j].size) )
+pci_mem_start -= memory_map.map[j].size PAGE_SHIFT;
+pci_mem_start = (pci_mem_start + max_bar_sz - 1)
+~(uint64_t)(max_bar_sz - 1);
+}
+}
+
if ( mmio_total (pci_mem_end - pci_mem_start) )
{
printf(Low MMIO hole not large enough for all devices,
@@ -407,8 +424,23 @@ void pci_setup(void)
}
base = (resource-base + bar_sz - 1) ~(uint64_t)(bar_sz - 1);
+ reallocate_mmio:
bar_data |= (uint32_t)base;
bar_data_upper = (uint32_t)(base 32);
+for ( j = 0; j memory_map.nr_map ; j++ )
+{
+if ( memory_map.map[j].type != E820_RAM )
+{
+reserved_end = memory_map.map[j].addr + memory_map.map[j].size;
+if ( check_overlap(base, bar_sz,
+ memory_map.map[j].addr,
+ memory_map.map[j].size) )
+{
+base = (reserved_end + bar_sz - 1) ~(uint64_t)(bar_sz -
1);
+goto reallocate_mmio;
+}
+}
+}
base += bar_sz;
if ( (base resource-base) || (base resource-max) )
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
the SEDF scheduler is about to be deprecated and go
away (see [1]). OTOH, the RTDS scheduler is here to
stay.
It therefore makes sense to stop smoke testing the
former in favour of the latter. Note that the
-sedf-pin jobs where only added in order to try to
debug a long standing issue with SEDF; it is not
necessary to have anything like that for RTDS.
For now, as RTDS is still marked as experimental,
test failures are allowed, as it was for SEDF.
[1] http://lists.xen.org/archives/html/xen-devel/2015-05/msg02874.html
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
---
allow.all |2 +-
make-flight | 31 +--
2 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/allow.all b/allow.all
index 6715b2e..2897b2e 100644
--- a/allow.all
+++ b/allow.all
@@ -1,4 +1,4 @@
-test-@@-sedf@@
+test-@@-rtds@@
build-@@logs-capture@@
test-@@-pcipt@@
test-@@-qemuu-@@ guest-localmigrate
diff --git a/make-flight b/make-flight
index 8a1fceb..837f372 100755
--- a/make-flight
+++ b/make-flight
@@ -262,30 +262,16 @@ do_hvm_rhel6_tests () {
done
}
-do_sedf_tests () {
+do_nondef_sched_tests () {
if [ $xenarch != $dom0arch ]; then
return
fi
- for pin in '' -pin; do
-job_create_test test-$xenarch$kern-$dom0arch-xl-sedf$pin \
- test-debian xl $xenarch $dom0arch \
-guests_vcpus=4\
-xen_boot_append=sched=sedf loglvl=all ${pin:+dom0_vcpus_pin} \
-linux_boot_append='loglevel=9 debug' \
-$debian_runvars all_hostflags=$most_hostflags
- done
-}
-
-do_credit2_tests () {
- if [ $xenarch != $dom0arch ]; then
-return
- fi
-
- job_create_test test-$xenarch$kern-$dom0arch-xl-credit2 \
- test-debian xl $xenarch $dom0arch \
-guests_vcpus=4 xen_boot_append='sched=credit2'\
-$debian_runvars all_hostflags=$most_hostflags
+ sched=$1
+ job_create_test test-$xenarch$kern-$dom0arch-xl-$sched \
+ test-debian xl $xenarch $dom0arch \
+ guests_vcpus=4 xen_boot_append=sched=$sched \
+ $debian_runvars all_hostflags=$most_hostflags
}
do_multivcpu_tests () {
@@ -350,8 +336,9 @@ test_matrix_do_one () {
do_pv_debian_tests
do_multivcpu_tests
- do_sedf_tests
- do_credit2_tests
+ for s in credit2 rtds; do
+do_nondef_sched_tests $s
+ done
# No further arm tests at the moment
if [ $dom0arch = armhf ]; then
--
This happens because I choose it to happen! (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK)
signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 6/8] xenalyze: handle more events in sched_process
On Fri, May 22, 2015 at 08:19:37AM +, Olaf Hering wrote: Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com Acked-by: Wei Liu wei.l...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 56922: regressions - FAIL
On Fri, 2015-05-22 at 20:47 +0800, Robert Hu wrote: On Fri, 2015-05-22 at 13:30 +0100, Ian Campbell wrote: On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote: I'm currently testing the patch below, if it works then I intend to fold it into Parsing grub which has 'submenu' primitive and will re-push the result. It didn't seem to work. I'm trying to repro on a machine I can recover more easily, but perhaps you could also take a look? Yeah. Thanks Ian. I'm to look into it this weekend. From https://help.ubuntu.com/community/Grub2/Submenus it seems like perhaps the syntax is NM where N is the submenu and M is the offset within that submenu. I've not confirmed this though. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [osstest test] 56922: regressions - FAIL
On Fri, 2015-05-22 at 13:58 +0100, Ian Campbell wrote:
On Fri, 2015-05-22 at 20:47 +0800, Robert Hu wrote:
On Fri, 2015-05-22 at 13:30 +0100, Ian Campbell wrote:
On Fri, 2015-05-22 at 12:32 +0100, Ian Campbell wrote:
I'm currently testing the patch below, if it works then I intend to fold
it into Parsing grub which has 'submenu' primitive and will re-push
the result.
It didn't seem to work. I'm trying to repro on a machine I can recover
more easily, but perhaps you could also take a look?
Yeah. Thanks Ian.
I'm to look into it this weekend.
From https://help.ubuntu.com/community/Grub2/Submenus it seems like
perhaps the syntax is NM where N is the submenu and M is the offset
within that submenu.
I've not confirmed this though.
I have now, 81 correctly booted: submenu Xen 4.6-unstable {
menuentry 'Debian GNU/Linux, with Xen 4.6-unstable and Linux 3.14.36+' --class
debian --class gnu-linux --class gnu --class os --class xen {
From my particular grub.cfg. For real usage setupboot_grub2 will
obviously need to become cleverer to count things correctly.
BTW, I just noticed that the comment about setupboot_grub2 is still in
place:
# Note on running OSSTest on Squeeze with old Xen kernel: check out
# Debian bug #633127 /etc/grub/20_linux does not recognise some old
# Xen kernels
# Currently setupboot_grub2 relies on Grub menu not having submenu.
# Check Debian bug #690538.
sub setupboot_grub2 () {
The last bit is no longer true with the patch, so it should be
removed...
I've dropped the following from pretest for now:
Parsing grub which has 'submenu' primitive
Changes to support '/boot' leading paths of kernel, xen, in grub
grub: remove patch to disable submenu from 20_linux_xen overlay
(the /boot one had contextual dependencies on the prior patch).
In pretest now is just:
Refactor installation of overlays
Edit some APIs in TestSupport.pm for nested test
Move the code for setting memory size into prep()
I've pushed that to a new branch nestedhvm-v10-pretest-reduced in my
xenbits repo too so you can base future resends on that.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
