[Xen-devel] 答复: Questions about XenRT
> Hi James, > > I found a PPT file named “XenRT-XenSource’s Xen testing infrastructure” >written by you, I have a few questions and hope you could help me there. > I am looking for a better test tool for Xen, so I recently setup XenRT in a >debian VM according to this website: >http://wiki.xenproject.org/wiki/Getting_Started_with_XenRT . > I downloaded xenrt.tgz and tests.tgz from >http://wiki.xenproject.org/wiki/Category:XenRT . > But I don’t have a xenserver host, the testcases(e.g. >xenserver.tc.host.TC6859) won’t PASS. > What I want to know is: > 1) Does XenRT support opensource xen host?(I’m using libvirt which calls > libxenlight APIs) > 2) Is there any detailed documents which can tell me how to configure and use > this tool? > 3) Is there any other tools(like OSSTest) that we normally use to do xen > tests, including the tools that can provide a set of unit and functional > tests and be executed by any Xen contributors to validate their changes > before committing a patch? > > Looking forward to your reply, thank you! > > Regards, > Jason Ping! Anyone knows that? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] XSA-155: _apparently_ missing blktap1 fix (up to 4.5)
In the course of backporting other XSA fixes to very old trees I had noticed that the XSA-155 had shrunk to just the change to xen/include/public/io/ring.h at some point, which didn't seem right. Clearly up to 4.5 the situation of blktap1 is the same as that of blktap2, i.e. one would think it also needs to be fixed. However, in the course of doing so I stumbled across the code blindly using req->id as an array index (which similarly is the case for blktap2). That alone would be another security issue, if only the first change really addressed one. But it didn't: The rings we're talking about here are those interfacing with the kernel module, and it's only the kernel module which interfaces with the guest ring. Bottom line: No fix is needed to blktap1, and the change to blktap2 didn't really fix anything either. It merely made things slightly slower due to the extra copy operation. (I haven't fully understood the purpose of block-log.c yet, but I can't see how it would manage to bypass the kernel module and interface directly with the frontend in the guest, the more that tdlog_open() sets up its ring using shm_open(), implying host local operation. Hence that part of the change, which has no blktap1 equivalent, should not be needed either.) Therefore, Ian, I'd like to request that the blktap2 change not be backported to any of the stable trees - only the libvchan one should make it there (and the prereq to the blktap2 one, adding RING_COPY_REQUEST(), then isn't needed either). Since that blktap2 change isn't entirely benign, I think we should even consider reverting it from master. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 13/27] tools/libx{l, c}: add postcopy/suspend callback to restore side
From: Wen Congyang
Secondary(restore side) is running under COLO, we also need
postcopy/suspend callbacks.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxc/include/xenguest.h | 10 ++
tools/libxl/libxl_save_msgs_gen.pl | 4 ++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index f598bec..cb0bbcf 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -101,6 +101,16 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t
dom, uint32_t max_iter
/* callbacks provided by xc_domain_restore */
struct restore_callbacks {
+/* Called after a new checkpoint to suspend the guest.
+ */
+int (*suspend)(void* data);
+
+/* Called after the secondary vm is ready to resume.
+ * Callback function resumes the guest & the device model,
+ * returns to xc_domain_restore.
+ */
+int (*postcopy)(void* data);
+
/* A checkpoint record has been found in the stream.
* returns: */
#define XGR_CHECKPOINT_ERROR0 /* Terminate processing */
diff --git a/tools/libxl/libxl_save_msgs_gen.pl
b/tools/libxl/libxl_save_msgs_gen.pl
index 51d004d..6016706 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -23,8 +23,8 @@ our @msgs = (
STRING doing_what),
'unsigned long', 'done',
'unsigned long', 'total'] ],
-[ 3, 'scxA', "suspend", [] ],
-[ 4, 'scxA', "postcopy", [] ],
+[ 3, 'srcxA', "suspend", [] ],
+[ 4, 'srcxA', "postcopy", [] ],
[ 5, 'srcxA', "checkpoint", [] ],
[ 6, 'srcxA', "wait_checkpoint", [] ],
[ 7, 'scxA', "switch_qemu_logdirty", [qw(int domid
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 01/27] tools/libxl: introduction of libxl__qmp_restore to load qemu state
From: Wen Congyang
In normal migration, the qemu state is passed to qemu as a parameter.
With COLO, secondary vm is running. So we will do the following steps
at every checkpoint:
1. suspend both primary vm and secondary vm
2. sync the state
3. resume both primary vm and secondary vm
Primary will send qemu's state in step2, and secondary's qemu should
read it and restore the state before it is resumed. We can not pass the
state to qemu as a parameter because secondary QEMU is already started
at this point, so we introduce libxl__qmp_restore() to do it.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Cc: Anthony Perard
Reviewed-by: Konrad Rzeszutek Wilk
---
tools/libxl/libxl_internal.h | 2 ++
tools/libxl/libxl_qmp.c | 10 ++
2 files changed, 12 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 005fe53..7801385 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1762,6 +1762,8 @@ _hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
_hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
/* Save current QEMU state into fd. */
_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename);
+/* Load current QEMU state from file. */
+_hidden int libxl__qmp_restore(libxl__gc *gc, int domid, const char *filename);
/* Set dirty bitmap logging status */
_hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool
enable);
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c45702e..c0bdfcb 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -906,6 +906,16 @@ int libxl__qmp_save(libxl__gc *gc, int domid, const char
*filename)
NULL, NULL);
}
+int libxl__qmp_restore(libxl__gc *gc, int domid, const char *state_file)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_string(gc, &args, "filename", state_file);
+
+return qmp_run_command(gc, domid, "xen-load-devices-state", args,
+ NULL, NULL);
+}
+
static int qmp_change(libxl__gc *gc, libxl__qmp_handler *qmp,
char *device, char *target, char *arg)
{
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 05/27] tools/libx{l, c}: add back channel to libxc
From: Wen Congyang
In COLO mode, both VMs are running, and are considered in sync if the
visible network traffic is identical. After some time, they fall out of
sync.
At this point, the two VMs have definitely diverged. Lets call the
primary dirty bitmap set A, while the secondary dirty bitmap set B.
Sets A and B are different.
Under normal migration, the page data for set A will be sent from the
primary to the secondary.
However, the set difference B - A (the one in B but not in A, lets
call this C) is out-of-date on the secondary (with respect to the
primary) and will not be sent by the primary (to secondary), as it
was not memory dirtied by the primary. The secondary needs C page data
to reconstruct an exact copy of the primary at the checkpoint.
The secondary cannot calculate C as it doesn't know A. Instead, the
secondary must send B to the primary, at which point the primary
calculates the union of A and B (lets call this D) which is all the
pages dirtied by both the primary and the secondary, and sends all page
data covered by D.
In the general case, D is a superset of both A and B. Without the
backchannel dirty bitmap, a COLO checkpoint can't reconstruct a valid
copy of the primary.
We transfer the dirty bitmap on libxc side, so we need to introduce back
channel to libxc.
Note: it is different from the paper. We change the original design to
the current one, according to our following concerns:
1. The original design needs extra memory on Secondary host. When there's
multiple backups on one host, the memory cost is high.
2. The memory cache code will be another 1k+, it will make the review
more time consuming.
Note: this patch merely adds new parameters to various prototypes and
functions. The new parameters are used in later patch called
"libxc/restore: send dirty pfn list to primary when checkpoint under
COLO".
Signed-off-by: Yang Hongyang
Signed-off-by: Andrew Cooper
Signed-off-by: Changlong Xie
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
Reviewed-by: Konrad Rzeszutek Wilk
---
tools/libxc/include/xenguest.h | 4 ++--
tools/libxc/xc_nomigrate.c | 4 ++--
tools/libxc/xc_sr_restore.c | 2 +-
tools/libxc/xc_sr_save.c | 2 +-
tools/libxl/libxl_save_callout.c | 21 +++--
tools/libxl/libxl_save_helper.c | 8 ++--
6 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index affc42b..8040ac7 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -88,7 +88,7 @@ struct save_callbacks {
int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
max_iters,
uint32_t max_factor, uint32_t flags /* XCFLAGS_xxx */,
struct save_callbacks* callbacks, int hvm,
- int checkpointed_stream);
+ int checkpointed_stream, int recv_fd);
/* callbacks provided by xc_domain_restore */
struct restore_callbacks {
@@ -127,7 +127,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
uint32_t dom,
unsigned long *console_mfn, domid_t console_domid,
unsigned int hvm, unsigned int pae, int superpages,
int checkpointed_stream,
- struct restore_callbacks *callbacks);
+ struct restore_callbacks *callbacks, int send_back_fd);
/**
* This function will create a domain for a paravirtualized Linux
diff --git a/tools/libxc/xc_nomigrate.c b/tools/libxc/xc_nomigrate.c
index c9124df..3634743 100644
--- a/tools/libxc/xc_nomigrate.c
+++ b/tools/libxc/xc_nomigrate.c
@@ -23,7 +23,7 @@
int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t
max_iters,
uint32_t max_factor, uint32_t flags,
struct save_callbacks* callbacks, int hvm,
- int checkpointed_stream)
+ int checkpointed_stream, int recv_fd)
{
errno = ENOSYS;
return -1;
@@ -35,7 +35,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t
dom,
unsigned long *console_mfn, domid_t console_domid,
unsigned int hvm, unsigned int pae, int superpages,
int checkpointed_stream,
- struct restore_callbacks *callbacks)
+ struct restore_callbacks *callbacks, int send_back_fd)
{
errno = ENOSYS;
return -1;
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index d4d33fd..e24560e 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -726,7 +726,7 @@ int xc_domain_restore(xc_interface *xch, int io_fd,
uint32_t dom,
unsigned long *console_gfn, domid_t console_domid,
unsigned int hvm, unsigned int pae, int superpages,
int checkpointed_stream,
- struct restore_callb
[Xen-devel] [PATCH v11 02/27] tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty()
From: Wen Congyang
Secondary vm is running in COLO mode, we need to send secondary
vm's dirty page information to primary host at checkpoint, so we
have to enable qemu logdirty on secondary.
libxl__domain_suspend_common_switch_qemu_logdirty() is to enable
qemu logdirty. But it uses libxl__domain_save_state, and calls
libxl__xc_domain_saverestore_async_callback_done() before exits.
This can not be used for secondary vm.
Update libxl__domain_suspend_common_switch_qemu_logdirty() to
introduce a new API libxl__domain_common_switch_qemu_logdirty().
This API only uses libxl__logdirty_switch, and calls
lds->callback before exits. This new API will be used by the patch:
secondary vm suspend/resume/checkpoint code
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
CC: Andrew Cooper
Acked-by: Ian Campbell
Reviewed-by: Konrad Rzeszutek Wilk
Acked-by: Wei Liu
---
tools/libxl/libxl_dom_save.c | 95
tools/libxl/libxl_internal.h | 8
2 files changed, 60 insertions(+), 43 deletions(-)
diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index f3288b9..4df86c3 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -42,7 +42,7 @@ static void switch_logdirty_timeout(libxl__egc *egc,
libxl__ev_time *ev,
static void switch_logdirty_xswatch(libxl__egc *egc, libxl__ev_xswatch*,
const char *watch_path, const char *event_path);
static void switch_logdirty_done(libxl__egc *egc,
- libxl__domain_save_state *dss, int rc);
+ libxl__logdirty_switch *lds, int rc);
void libxl__logdirty_init(libxl__logdirty_switch *lds)
{
@@ -52,13 +52,10 @@ void libxl__logdirty_init(libxl__logdirty_switch *lds)
}
static void domain_suspend_switch_qemu_xen_traditional_logdirty
- (int domid, unsigned enable,
-libxl__save_helper_state *shs)
+ (libxl__egc *egc, int domid, unsigned enable,
+libxl__logdirty_switch *lds)
{
-libxl__egc *egc = shs->egc;
-libxl__domain_save_state *dss = shs->caller_state;
-libxl__logdirty_switch *lds = &dss->logdirty;
-STATE_AO_GC(dss->ao);
+STATE_AO_GC(lds->ao);
int rc;
xs_transaction_t t = 0;
const char *got;
@@ -120,26 +117,34 @@ static void
domain_suspend_switch_qemu_xen_traditional_logdirty
out:
LOG(ERROR,"logdirty switch failed (rc=%d), abandoning suspend",rc);
libxl__xs_transaction_abort(gc, &t);
-switch_logdirty_done(egc,dss,rc);
+switch_logdirty_done(egc,lds,rc);
}
static void domain_suspend_switch_qemu_xen_logdirty
- (int domid, unsigned enable,
-libxl__save_helper_state *shs)
+ (libxl__egc *egc, int domid, unsigned enable,
+libxl__logdirty_switch *lds)
{
-libxl__egc *egc = shs->egc;
-libxl__domain_save_state *dss = shs->caller_state;
-STATE_AO_GC(dss->ao);
+STATE_AO_GC(lds->ao);
int rc;
rc = libxl__qmp_set_global_dirty_log(gc, domid, enable);
-if (!rc) {
-libxl__xc_domain_saverestore_async_callback_done(egc, shs, 0);
-} else {
+if (rc)
LOG(ERROR,"logdirty switch failed (rc=%d), abandoning suspend",rc);
+
+lds->callback(egc, lds, rc);
+}
+
+static void domain_suspend_switch_qemu_logdirty_done
+(libxl__egc *egc, libxl__logdirty_switch *lds, int rc)
+{
+libxl__domain_save_state *dss = CONTAINER_OF(lds, *dss, logdirty);
+
+if (rc) {
dss->rc = rc;
-libxl__xc_domain_saverestore_async_callback_done(egc, shs, -1);
-}
+libxl__xc_domain_saverestore_async_callback_done(egc,
+ &dss->sws.shs, -1);
+} else
+libxl__xc_domain_saverestore_async_callback_done(egc, &dss->sws.shs,
0);
}
void libxl__domain_suspend_common_switch_qemu_logdirty
@@ -148,42 +153,52 @@ void libxl__domain_suspend_common_switch_qemu_logdirty
libxl__save_helper_state *shs = user;
libxl__egc *egc = shs->egc;
libxl__domain_save_state *dss = shs->caller_state;
-STATE_AO_GC(dss->ao);
+
+/* Convenience aliases. */
+libxl__logdirty_switch *const lds = &dss->logdirty;
+
+lds->callback = domain_suspend_switch_qemu_logdirty_done;
+libxl__domain_common_switch_qemu_logdirty(egc, domid, enable, lds);
+}
+
+void libxl__domain_common_switch_qemu_logdirty(libxl__egc *egc,
+ int domid, unsigned enable,
+ libxl__logdirty_switch *lds)
+{
+STATE_AO_GC(lds->ao);
switch (libxl__device_model_version_running(gc, domid)) {
case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL:
-domain_suspend_switch_qe
[Xen-devel] [PATCH v11 08/27] libxc/migration: Specification update for DIRTY_PFN_LIST records
From: Wen Congyang
Used by secondary to send it's dirty bitmap to primary under COLO.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
docs/specs/libxc-migration-stream.pandoc | 26 +++-
tools/libxc/xc_sr_common.c | 31 ---
tools/libxc/xc_sr_stream_format.h| 31 ---
tools/python/xen/migration/libxc.py | 68 ++--
4 files changed, 95 insertions(+), 61 deletions(-)
diff --git a/docs/specs/libxc-migration-stream.pandoc
b/docs/specs/libxc-migration-stream.pandoc
index 8cd678f..18544e0 100644
--- a/docs/specs/libxc-migration-stream.pandoc
+++ b/docs/specs/libxc-migration-stream.pandoc
@@ -1,6 +1,8 @@
% LibXenCtrl Domain Image Format
% David Vrabel <>
Andrew Cooper <>
+ Wen Congyang <>
+ Yang Hongyang <>
% Revision 1
Introduction
@@ -227,7 +229,9 @@ type 0x: END
0x000E: CHECKPOINT
- 0x000F - 0x7FFF: Reserved for future _mandatory_
+ 0x000F: CHECKPOINT_DIRTY_PFN_LIST (Secondary -> Primary)
+
+ 0x0010 - 0x7FFF: Reserved for future _mandatory_
records.
0x8000 - 0x: Reserved for future _optional_
@@ -599,6 +603,26 @@ CHECKPOINT record or an END record.
\clearpage
+CHECKPOINT_DIRTY_PFN_LIST
+
+
+A checkpoint dirty pfn list record is used to convey information about
+dirty memory in the VM. It is an unordered list of PFNs. Currently only
+applicable in the backchannel of a checkpointed stream.
+
+ 0 1 2 3 4 5 6 7 octet
++-+
+| pfn[0] |
++-+
+...
++-+
+| pfn[C-1]|
++-+
+
+The count of pfns is: record->length/sizeof(uint64_t).
+
+\clearpage
+
Layout
==
diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index 945cfa6..3313a90 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -20,21 +20,22 @@ const char *dhdr_type_to_str(uint32_t type)
static const char *mandatory_rec_types[] =
{
-[REC_TYPE_END] = "End",
-[REC_TYPE_PAGE_DATA]= "Page data",
-[REC_TYPE_X86_PV_INFO] = "x86 PV info",
-[REC_TYPE_X86_PV_P2M_FRAMES]= "x86 PV P2M frames",
-[REC_TYPE_X86_PV_VCPU_BASIC]= "x86 PV vcpu basic",
-[REC_TYPE_X86_PV_VCPU_EXTENDED] = "x86 PV vcpu extended",
-[REC_TYPE_X86_PV_VCPU_XSAVE]= "x86 PV vcpu xsave",
-[REC_TYPE_SHARED_INFO] = "Shared info",
-[REC_TYPE_TSC_INFO] = "TSC info",
-[REC_TYPE_HVM_CONTEXT] = "HVM context",
-[REC_TYPE_HVM_PARAMS] = "HVM params",
-[REC_TYPE_TOOLSTACK]= "Toolstack",
-[REC_TYPE_X86_PV_VCPU_MSRS] = "x86 PV vcpu msrs",
-[REC_TYPE_VERIFY] = "Verify",
-[REC_TYPE_CHECKPOINT] = "Checkpoint",
+[REC_TYPE_END] = "End",
+[REC_TYPE_PAGE_DATA]= "Page data",
+[REC_TYPE_X86_PV_INFO] = "x86 PV info",
+[REC_TYPE_X86_PV_P2M_FRAMES]= "x86 PV P2M frames",
+[REC_TYPE_X86_PV_VCPU_BASIC]= "x86 PV vcpu basic",
+[REC_TYPE_X86_PV_VCPU_EXTENDED] = "x86 PV vcpu extended",
+[REC_TYPE_X86_PV_VCPU_XSAVE]= "x86 PV vcpu xsave",
+[REC_TYPE_SHARED_INFO] = "Shared info",
+[REC_TYPE_TSC_INFO] = "TSC info",
+[REC_TYPE_HVM_CONTEXT] = "HVM context",
+[REC_TYPE_HVM_PARAMS] = "HVM params",
+[REC_TYPE_TOOLSTACK]= "Toolstack",
+[REC_TYPE_X86_PV_VCPU_MSRS] = "x86 PV vcpu msrs",
+[REC_TYPE_VERIFY] = "Verify",
+[REC_TYPE_CHECKPOINT] = "Checkpoint",
+[REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST]= "Checkpoint dirty pfn list",
};
const char *rec_type_to_str(uint32_t type)
diff --git a/tools/libxc/xc_sr_stream_format.h
b/tools/libxc/xc_sr_stream_format.h
index 6d0f8fd..3291b25 100644
--- a/tools/libxc/xc_sr_stream_format.h
+++ b/tools/libxc/xc_sr_stream_format.h
@@ -60,21 +60,22 @@ struct xc_sr_rhdr
/* Somewhat arbitrary - 8MB */
#define REC_LENGTH_MAX(8U << 20)
-#define REC_TYPE_END 0xU
-#define REC_TYPE_PAGE_DATA0x0001U
-#define REC_TYPE_X86_PV_INFO 0x0002U
-#define REC_TYPE_X86_PV_P2M_FRAMES0x0003U
-#define REC_TYPE_X86_PV_VCPU_BASIC0x0004U
-#define REC_TYPE_X86_PV_VCPU_EXTENDED 0x0005U
-#define REC_TYPE_X86_PV_VCPU_XSAVE0x0006U
-#define REC_TYPE_SHARED_INFO 0x0007U
-#defin
[Xen-devel] [PATCH v11 20/27] Support colo mode for qemu disk
From: Wen Congyang
Usage: disk =
['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
For QEMU block replication details:
http://wiki.qemu.org/Features/BlockReplication
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
docs/man/xl.pod.1 | 36 ++-
docs/misc/xl-disk-configuration.txt | 53 +++
tools/libxl/libxl.c | 64 -
tools/libxl/libxl_create.c | 25 -
tools/libxl/libxl_device.c | 54 +++
tools/libxl/libxl_dm.c | 184 ++--
tools/libxl/libxl_types.idl | 7 ++
tools/libxl/libxlu_disk_l.l | 7 ++
8 files changed, 418 insertions(+), 12 deletions(-)
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 1c6dd87..36b093b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -450,11 +450,39 @@ Print huge (!) amount of debug during the migration
process.
Enable Remus HA or COLO HA for domain. By default B relies on ssh as a
transport mechanism between the two hosts.
-N.B: Remus support in xl is still in experimental (proof-of-concept) phase.
- Disk replication support is limited to DRBD disks.
+B
+
+=over 4
+
+Remus support in xl is still in experimental (proof-of-concept) phase.
+Disk replication support is limited to DRBD disks.
+
+COLO support in xl is still in experimental (proof-of-concept) phase.
+There is no support for network at the moment.
+
+=back
+
+B
- COLO support in xl is still in experimental (proof-of-concept) phase.
- There is no support for network or disk at the moment.
+=over 4
+
+(a) An example for COLO replication's configuration: disk =['...,colo,colo-host
+=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
+
+=item B :Secondary host's ip address.
+
+=item B :Secondary host's port, we will run a nbd server on
+secondary host, and the nbd server will listen this port.
+
+=item B:Nbd server's disk export name of secondary host.
+
+=item B:Secondary's guest write will be buffered in this disk,
+and it's used by secondary.
+
+=item B:Primary's modified contents will be buffered in this
+disk, and it's used by secondary.
+
+=back
B
diff --git a/docs/misc/xl-disk-configuration.txt
b/docs/misc/xl-disk-configuration.txt
index 29f6ddb..6e73975 100644
--- a/docs/misc/xl-disk-configuration.txt
+++ b/docs/misc/xl-disk-configuration.txt
@@ -234,6 +234,59 @@ were intentionally created non-sparse to avoid
fragmentation of the
file.
+===
+COLO PARAMETERS
+===
+
+
+colo
+
+
+Enable COLO HA for disk. For better understanding block replication on
+QEMU, please refer to:
+http://wiki.qemu.org/Features/BlockReplication
+
+
+colo-host
+-
+
+Description: Secondary host's address
+Mandatory: Yes when COLO enabled
+
+
+colo-port
+-
+
+Description: Secondary port
+ We will run a nbd server on secondary host,
+ and the nbd server will listen this port.
+Mandatory: Yes when COLO enabled
+
+
+colo-export
+---
+
+Description: We will run a nbd server on secondary host,
+ exportname is the nbd server's disk export name.
+Mandatory: Yes when COLO enabled
+
+
+active-disk
+---
+
+Description: This is used by secondary. Secondary guest's write
+ will be buffered in this disk.
+Mandatory: Yes when COLO enabled
+
+
+hidden-disk
+---
+
+Description: This is used by secondary. It buffers the original
+ content that is modified by the primary VM.
+Mandatory: Yes when COLO enabled
+
+
DEPRECATED PARAMETERS, PREFIXES AND SYNTAXES
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3689dfc..eb1b277 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2307,6 +2307,8 @@ int libxl__device_disk_setdefault(libxl__gc *gc,
libxl_device_disk *disk)
int rc;
libxl_defbool_setdefault(&disk->discard_enable, !!disk->readwrite);
+libxl_defbool_setdefault(&disk->colo_enable, false);
+libxl_defbool_setdefault(&disk->colo_restore_enable, false);
rc = libxl__resolve_domid(gc, disk->backend_domname, &disk->backend_domid);
if (rc < 0) return rc;
@@ -2505,6 +2507,18 @@ static void device_disk_add(libxl__egc *egc, uint32_t
domid,
flexarray_append(back, "params");
flexarray_append(back, GCSPRINTF("%s:%s",
libxl__device_disk_string_of_format(disk->format), disk->pdev_path));
+if (libxl_defbool_val(disk->colo_enable)) {
+flexarray_append(back, "colo-host");
+flexarray_append(back, libxl__sp
[Xen-devel] [PATCH v11 03/27] tools/libxl: Add back channel to allow migration target send data back
From: Wen Congyang
In COLO mode, secondary needs to send the following data to primary:
1. In libxl
Secondary sends the following CHECKPOINT_CONTEXT to primary:
CHECKPOINT_SVM_SUSPENDED, CHECKPOINT_SVM_READY and CHECKPOINT_SVM_RESUMED
2. In libxc
Secondary sends the dirty pfn list to primary
But the io_fd only can be written in primary, and only can be read in
secondary. Save recv_fd in domain_suspend_state, and send_fd in
domain_create_state. Extend libxl_domain_create_restore API, add a
send_fd param to it. Add LIBXL_HAVE_CREATE_RESTORE_SEND_FD to indicate
the API change.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
Acked-by: Wei Liu
---
tools/libxl/libxl.c | 3 +--
tools/libxl/libxl.h | 29 -
tools/libxl/libxl_create.c | 10 ++
tools/libxl/libxl_internal.h | 2 ++
tools/libxl/xl_cmdimpl.c | 8 +++-
tools/ocaml/libs/xl/xenlight_stubs.c | 2 +-
6 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 4cdc169..e9ab78c 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -834,7 +834,6 @@ out:
static void remus_failover_cb(libxl__egc *egc,
libxl__domain_save_state *dss, int rc);
-/* TODO: Explicit Checkpoint acknowledgements via recv_fd. */
int libxl_domain_remus_start(libxl_ctx *ctx, libxl_domain_remus_info *info,
uint32_t domid, int send_fd, int recv_fd,
const libxl_asyncop_how *ao_how)
@@ -871,7 +870,7 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
dss->callback = remus_failover_cb;
dss->domid = domid;
dss->fd = send_fd;
-/* TODO do something with recv_fd */
+dss->recv_fd = recv_fd;
dss->type = type;
dss->live = 1;
dss->debug = 0;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f9e3ef5..5a286ec 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -639,6 +639,15 @@ typedef struct libxl__ctx libxl_ctx;
#define LIBXL_HAVE_DOMAIN_CREATE_RESTORE_PARAMS 1
/*
+ * LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD 1
+ *
+ * If this is defined, libxl_domain_create_restore()'s API has changed to
+ * include a send_back_fd param which used for libxl migration back channel
+ * during COLO.
+ */
+#define LIBXL_HAVE_DOMAIN_CREATE_RESTORE_SEND_BACK_FD 1
+
+/*
* LIBXL_HAVE_CREATEINFO_PVH
* If this is defined, then libxl supports creation of a PVH guest.
*/
@@ -1165,6 +1174,7 @@ int libxl_domain_create_new(libxl_ctx *ctx,
libxl_domain_config *d_config,
LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_create_restore(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid, int restore_fd,
+int send_back_fd,
const libxl_domain_restore_params *params,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
@@ -1185,7 +1195,7 @@ int static inline libxl_domain_create_restore_0x040200(
libxl_domain_restore_params_init(¶ms);
ret = libxl_domain_create_restore(
-ctx, d_config, domid, restore_fd, ¶ms, ao_how, aop_console_how);
+ctx, d_config, domid, restore_fd, -1, ¶ms, ao_how,
aop_console_how);
libxl_domain_restore_params_dispose(¶ms);
return ret;
@@ -1193,6 +1203,23 @@ int static inline libxl_domain_create_restore_0x040200(
#define libxl_domain_create_restore libxl_domain_create_restore_0x040200
+#elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION >= 0x040400 \
+ && LIBXL_API_VERSION < 0x040700
+
+int static inline libxl_domain_create_restore_0x040400(
+libxl_ctx *ctx, libxl_domain_config *d_config,
+uint32_t *domid, int restore_fd,
+const libxl_domain_restore_params *params,
+const libxl_asyncop_how *ao_how,
+const libxl_asyncprogress_how *aop_console_how)
+LIBXL_EXTERNAL_CALLERS_ONLY
+{
+return libxl_domain_create_restore(ctx, d_config, domid, restore_fd,
+ -1, params, ao_how, aop_console_how);
+}
+
+#define libxl_domain_create_restore libxl_domain_create_restore_0x040400
+
#endif
int libxl_domain_soft_reset(libxl_ctx *ctx,
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f1028bc..525bf85 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1572,7 +1572,7 @@ static void domain_create_cb(libxl__egc *egc,
int rc, uint32_t domid);
static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
-uint32_t *domid, int restore_fd,
+uint32_t *domid, int restore_fd, int send_back_fd,
[Xen-devel] [PATCH v11 18/27] implement the cmdline for COLO
From: Wen Congyang
Add a new option -c to the command 'xl remus'. If you want
to use COLO HA instead of Remus HA, please use -c option.
Update man pages to reflect the addition of a new option to
'xl remus' command.
Also add a new option -c to the internal command 'xl migrate-receive'.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
docs/man/xl.pod.1 | 12 --
tools/libxl/libxl.c | 22 --
tools/libxl/xl_cmdimpl.c | 59 ---
tools/libxl/xl_cmdtable.c | 4 +++-
4 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..1c6dd87 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -447,12 +447,15 @@ Print huge (!) amount of debug during the migration
process.
=item B [I] I I
-Enable Remus HA for domain. By default B relies on ssh as a transport
-mechanism between the two hosts.
+Enable Remus HA or COLO HA for domain. By default B relies on ssh as a
+transport mechanism between the two hosts.
N.B: Remus support in xl is still in experimental (proof-of-concept) phase.
Disk replication support is limited to DRBD disks.
+ COLO support in xl is still in experimental (proof-of-concept) phase.
+ There is no support for network or disk at the moment.
+
B
=over 4
@@ -498,6 +501,11 @@ Disable network output buffering. Requires enabling unsafe
mode.
Disable disk replication. Requires enabling unsafe mode.
+=item B<-c>
+
+Enable COLO HA. This conflicts with B<-i> and B<-b>, and memory
+checkpoint compression must be disabled.
+
=back
=item B I
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 305231b..3689dfc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -848,12 +848,27 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
goto out;
}
+/* The caller must set this defbool */
+if (libxl_defbool_is_default(info->colo)) {
+LOG(ERROR, "colo mode must be enabled/disabled");
+rc = ERROR_FAIL;
+goto out;
+}
+
libxl_defbool_setdefault(&info->allow_unsafe, false);
libxl_defbool_setdefault(&info->blackhole, false);
-libxl_defbool_setdefault(&info->compression, true);
+libxl_defbool_setdefault(&info->compression,
+ !libxl_defbool_val(info->colo));
libxl_defbool_setdefault(&info->netbuf, true);
libxl_defbool_setdefault(&info->diskbuf, true);
+if (libxl_defbool_val(info->colo) &&
+libxl_defbool_val(info->compression)) {
+LOG(ERROR, "cannot use memory checkpoint compression in COLO
mode");
+rc = ERROR_FAIL;
+goto out;
+}
+
if (!libxl_defbool_val(info->allow_unsafe) &&
(libxl_defbool_val(info->blackhole) ||
!libxl_defbool_val(info->netbuf) ||
@@ -875,7 +890,10 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
dss->live = 1;
dss->debug = 0;
dss->remus = info;
-dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
+if (libxl_defbool_val(info->colo))
+dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_COLO;
+else
+dss->checkpointed_stream = LIBXL_CHECKPOINTED_STREAM_REMUS;
assert(info);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 523e0e9..30d26bc 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -4445,6 +4445,8 @@ static void migrate_receive(int debug, int daemonize, int
monitor,
char rc_buf;
char *migration_domname;
struct domain_create dom_info;
+const char *ha = checkpointed == LIBXL_CHECKPOINTED_STREAM_COLO ?
+ "COLO" : "Remus";
signal(SIGPIPE, SIG_IGN);
/* if we get SIGPIPE we'd rather just have it as an error */
@@ -4477,11 +4479,12 @@ static void migrate_receive(int debug, int daemonize,
int monitor,
switch (checkpointed) {
case LIBXL_CHECKPOINTED_STREAM_REMUS:
+case LIBXL_CHECKPOINTED_STREAM_COLO:
/* If we are here, it means that the sender (primary) has crashed.
* TODO: Split-Brain Check.
*/
-fprintf(stderr, "migration target: Remus Failover for domain %u\n",
-domid);
+fprintf(stderr, "migration target: %s Failover for domain %u\n",
+ha, domid);
/*
* If domain renaming fails, lets just continue (as we need the domain
@@ -4497,16 +4500,20 @@ static void migrate_receive(int debug, int daemonize,
int monitor,
rc = libxl_domain_rename(ctx, domid, migration_domname,
common_domname);
if (rc)
-fprintf(stderr, "migration target (Remus): "
+fprintf(stderr, "migration target (%s): "
"Failed to rename domain from %s to %s:%d\n",
-mi
[Xen-devel] [PATCH v11 00/27] COarse-grain LOck-stepping Virtual Machines for Non-stop Service
This patchset implemented the COLO feature for Xen.
For detail/install/use of COLO feature, refer to:
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
You can get the codes from here:
https://github.com/Pating/xen/tree/changlox/colo_v11
Changlog from v10 to v11
1. Rebased to then upstream xen
2. Address comments from Liu Wei
p1, update commit message and remove libxl__domain_restore_device_model
p4, add A-B
p5, update commit message
p6, add A-B
p7,p8 add email address and direction info
p10, merged by old p10,p11 and update comments
p11, merged by old p12,p13 and update comments
p14,p15 move colo structures and functions into libxl_colo.h, and list callbacks
in order, also update commit message
p16, merged by old p18,p19,p20 and remove TODOs
p17, use original code for checking postcopy return value
p18, simplify *if* logic, fix wrong comments, and unset dom_info.quiet in COLO
p19, add A-B
p20, fix code style, update comments and man page
p21,p22,p23,p24 move colo structures and functions into libxl_colo.h
Changlog from v9 to v10
1. Rebased to the upstream xen
2. Fix one bug found in the test
3. Merge some patches from prepare series
4. Split patch 5 to two patches(patch 4 and 5) according to the comments from
Wei Liu
Changlog from v8 to v9:
1. Rebased to the upstream xen
2. Fix some bugs found in the test
Changelog from v7 to v8:
1. Rebased to the latest libxl migration v2.
Changelog from v6 to v7:
1. Ported to Libxl migration v2
2. Send dirty bitmap from secondary to primary on libxc side
3. Address review comments
Changelog from v5 to v6:
1. based on migration v2(libxc)
2. split the patchset into prerequisite patchset and this main patchset.
Changelog from v4 to v5:
1. rebase to the latest xen upstream
2. disk replication: blktap2->qdisk
3. nic replication: colo-agent->colo-proxy
Changelog from v3 to v4:
1. rebase to newest xen
2. bug fix
Changlog from v2 to v3:
1. rebase to newest remus
2. add nic replication support
Changlog from v1 to v2:
1. rebase to newest remus
2. add disk replication support
Wen Congyang (27):
tools/libxl: introduction of libxl__qmp_restore to load qemu state
tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty()
tools/libxl: Add back channel to allow migration target send data back
tools/libxl: Introduce new helper function dup_fd_helper()
tools/libx{l,c}: add back channel to libxc
docs: add colo readme
docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo
streams
libxc/migration: Specification update for DIRTY_PFN_LIST records
libxc/migration: export read_record for common use
tools/libxl: add back channel support to write stream
tools/libxl: add back channel support to read stream
tools/libx{l,c}: introduce wait_checkpoint callback
tools/libx{l,c}: add postcopy/suspend callback to restore side
secondary vm suspend/resume/checkpoint code
primary vm suspend/resume/checkpoint code
libxc/restore: support COLO restore
libxc/save: support COLO save
implement the cmdline for COLO
COLO: introduce new API to prepare/start/do/get_error/stop replication
Support colo mode for qemu disk
COLO: use qemu block replication
COLO proxy: implement setup/teardown of COLO proxy module
COLO proxy: preresume, postresume and checkpoint
COLO nic: implement COLO nic subkind
setup and control colo proxy on primary side
setup and control colo proxy on secondary side
cmdline switches and config vars to control colo-proxy
docs/README.colo |9 +
docs/man/xl.conf.pod.5 |6 +
docs/man/xl.pod.1| 48 +-
docs/misc/xl-disk-configuration.txt | 53 ++
docs/specs/libxc-migration-stream.pandoc | 26 +-
docs/specs/libxl-migration-stream.pandoc | 31 +-
tools/hotplug/Linux/Makefile |1 +
tools/hotplug/Linux/colo-proxy-setup | 135
tools/libxc/include/xenguest.h | 40 +-
tools/libxc/xc_nomigrate.c |4 +-
tools/libxc/xc_sr_common.c | 80 ++-
tools/libxc/xc_sr_common.h | 26 +-
tools/libxc/xc_sr_restore.c | 246 +--
tools/libxc/xc_sr_save.c | 100 ++-
tools/libxc/xc_sr_stream_format.h| 31 +-
tools/libxl/Makefile |4 +
tools/libxl/libxl.c | 100 ++-
tools/libxl/libxl.h | 29 +-
tools/libxl/libxl_colo.h | 117
tools/libxl/libxl_colo_nic.c | 315 +
tools/libxl/libxl_colo_proxy.c | 280
tools/libxl/libxl_colo_qdisk.c | 222 ++
tools/libxl/libxl_colo_restore.c | 1078 ++
tools/libxl/libxl_colo_save.c| 720
tools/libxl/libxl_create.c | 85 ++-
tools/libxl/libxl_device.c | 54 ++
tools/libxl/libxl_dm.c | 184 -
tools/libxl/libxl_
[Xen-devel] [PATCH v11 12/27] tools/libx{l, c}: introduce wait_checkpoint callback
From: Wen Congyang
Under COLO, we are doing checkpoint on demand, if this
callback returns 1, we will take another checkpoint.
0 indicates unexpected error.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxc/include/xenguest.h | 18 ++
tools/libxl/libxl_save_msgs_gen.pl | 7 ---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 8040ac7..f598bec 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -68,6 +68,15 @@ struct save_callbacks {
* 1: take another checkpoint */
int (*checkpoint)(void* data);
+/*
+ * Called after the checkpoint callback.
+ *
+ * returns:
+ * 0: terminate checkpointing gracefully
+ * 1: take another checkpoint
+ */
+int (*wait_checkpoint)(void* data);
+
/* Enable qemu-dm logging dirty pages to xen */
int (*switch_qemu_logdirty)(int domid, unsigned enable, void *data); /*
HVM only */
@@ -99,6 +108,15 @@ struct restore_callbacks {
#define XGR_CHECKPOINT_FAILOVER 2 /* Failover and resume VM */
int (*checkpoint)(void* data);
+/*
+ * Called after the checkpoint callback.
+ *
+ * returns:
+ * 0: terminate checkpointing gracefully
+ * 1: take another checkpoint
+ */
+int (*wait_checkpoint)(void* data);
+
/* to be provided as the last argument to each callback function */
void* data;
};
diff --git a/tools/libxl/libxl_save_msgs_gen.pl
b/tools/libxl/libxl_save_msgs_gen.pl
index d6d2967..51d004d 100755
--- a/tools/libxl/libxl_save_msgs_gen.pl
+++ b/tools/libxl/libxl_save_msgs_gen.pl
@@ -26,11 +26,12 @@ our @msgs = (
[ 3, 'scxA', "suspend", [] ],
[ 4, 'scxA', "postcopy", [] ],
[ 5, 'srcxA', "checkpoint", [] ],
-[ 6, 'scxA', "switch_qemu_logdirty", [qw(int domid
+[ 6, 'srcxA', "wait_checkpoint", [] ],
+[ 7, 'scxA', "switch_qemu_logdirty", [qw(int domid
unsigned enable)] ],
-[ 7, 'r', "restore_results", ['unsigned long', 'store_mfn',
+[ 8, 'r', "restore_results", ['unsigned long', 'store_mfn',
'unsigned long', 'console_mfn']
],
-[ 8, 'srW',"complete", [qw(int retval
+[ 9, 'srW',"complete", [qw(int retval
int errnoval)] ],
);
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 13/16] hvmloader: Load ACPI tables from hvm_start_info module
>>> On 03.03.16 at 18:59, wrote:
> On Tue, Mar 01, 2016 at 09:17:25AM -0700, Jan Beulich wrote:
>> >>> On 25.02.16 at 15:56, wrote:
>> > --- a/tools/firmware/hvmloader/hvmloader.c
>> > +++ b/tools/firmware/hvmloader/hvmloader.c
>> > @@ -365,8 +365,26 @@ int main(void)
>> >
>> > if ( bios->acpi_build_tables )
>> > {
>> > +const struct hvm_modlist_entry *acpi_module;
>> > +acpi_module = get_module_entry(hvm_start_info, "acpi");
>> > printf("Loading ACPI ...\n");
>> > -bios->acpi_build_tables();
>> > +if ( acpi_module )
>> > +{
>> > +uint32_t paddr = acpi_module->paddr;
>> > +bios->acpi_build_tables((void*)paddr,
>> > +acpi_module->size);
>> > +}
>>
>> Hmm, so far it was the build process which ensured the right ACPI
>> tables would be used with the corresponding BIOS. The disconnect
>> that gets introduced here worries me a little, since things having
>> got out of sync may be rather hard to diagnose (as they may
>> surface only much later).
>
> So, my ultimate goal with this series was to be able to create a guest with
> QEMU's Q35 machine, which would need a different ACPI tables.
>
> Also, I would say that the ACPI tables are already disconnected from the
> thing they describe, the device model QEMU. I don't think there is much
> information about the BIOS backed into the DSDT table.
But then why would the Q35 model need a different one? Or the
other way around, why wouldn't that other one be usable with
with the current machine type (or more generally, why couldn't
we have one that fits all machine types we mean to support)?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 11/27] tools/libxl: add back channel support to read stream
From: Wen Congyang
This is used by primay to read records sent by secondary.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_internal.h| 4 ++
tools/libxl/libxl_stream_read.c | 94 +
3 files changed, 91 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 525bf85..fc746fb 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1030,6 +1030,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
dcs->srs.dcs = dcs;
dcs->srs.fd = restore_fd;
dcs->srs.legacy = (dcs->restore_params.stream_version == 1);
+dcs->srs.back_channel = false;
dcs->srs.completion_callback = domcreate_stream_done;
if (restore_fd >= 0) {
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index fb8b2fa..6307b71 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3418,6 +3418,7 @@ struct libxl__stream_read_state {
libxl__domain_create_state *dcs;
int fd;
bool legacy;
+bool back_channel;
void (*completion_callback)(libxl__egc *egc,
libxl__stream_read_state *srs,
int rc);
@@ -3429,6 +3430,7 @@ struct libxl__stream_read_state {
bool running;
bool in_checkpoint;
bool sync_teardown; /* Only used to coordinate shutdown on error path. */
+bool in_checkpoint_state;
libxl__save_helper_state shs;
libxl__conversion_helper_state chs;
@@ -3456,6 +3458,8 @@ _hidden void libxl__stream_read_start(libxl__egc *egc,
libxl__stream_read_state *stream);
_hidden void libxl__stream_read_start_checkpoint(libxl__egc *egc,
libxl__stream_read_state
*stream);
+_hidden void libxl__stream_read_checkpoint_state(libxl__egc *egc,
+ libxl__stream_read_state
*stream);
_hidden void libxl__stream_read_abort(libxl__egc *egc,
libxl__stream_read_state *stream, int
rc);
static inline bool
diff --git a/tools/libxl/libxl_stream_read.c b/tools/libxl/libxl_stream_read.c
index f4781eb..302ae53 100644
--- a/tools/libxl/libxl_stream_read.c
+++ b/tools/libxl/libxl_stream_read.c
@@ -118,6 +118,15 @@
*record, and therefore the buffered state is inconsistent. In
*libxl__xc_domain_restore_done(), we just complete the stream and
*stream->completion_callback() will be called to resume the guest
+ *
+ * For back channel stream:
+ * - libxl__stream_read_start()
+ *- Set up the stream to running state
+ *
+ * - libxl__stream_read_continue()
+ * - Set up reading the next record from a started stream.
+ * Add some codes to process_record() to handle the record.
+ * Then call stream->checkpoint_callback() to return.
*/
/* Success/error/cleanup handling. */
@@ -157,6 +166,10 @@ static void write_emulator_done(libxl__egc *egc,
libxl__datacopier_state *dc,
int rc, int onwrite, int errnoval);
+/* Handlers for checkpoint state mini-loop */
+static void checkpoint_state_done(libxl__egc *egc,
+ libxl__stream_read_state *stream, int rc);
+
/*- Helpers -*/
/* Helper to set up reading some data from the stream. */
@@ -221,6 +234,14 @@ void libxl__stream_read_start(libxl__egc *egc,
stream->running = true;
stream->phase = SRS_PHASE_NORMAL;
+dc->ao = stream->ao;
+dc->copywhat = "restore v2 stream";
+dc->readfd = stream->fd;
+dc->writefd = -1;
+
+if (stream->back_channel)
+return;
+
if (stream->legacy) {
/* Convert the legacy stream. */
libxl__conversion_helper_state *chs = &stream->chs;
@@ -241,12 +262,6 @@ void libxl__stream_read_start(libxl__egc *egc,
stream->fd = libxl__carefd_fd(stream->chs.v2_carefd);
stream->dcs->libxc_fd = stream->fd;
}
-/* stream->fd is now a v2 stream. */
-
-dc->ao = stream->ao;
-dc->copywhat = "restore v2 stream";
-dc->readfd = stream->fd;
-dc->writefd = -1;
/* Start reading the stream header. */
rc = setup_read(stream, "stream header",
@@ -532,6 +547,7 @@ static bool process_record(libxl__egc *egc,
STATE_AO_GC(stream->ao);
libxl__domain_create_state *dcs = stream->dcs;
libxl__sr_record_buf *rec;
+libxl_sr_checkpoint_state *srcs;
bool further_action_needed = false;
int rc = 0;
@@ -602,6 +618,17 @@ static bool process_record(libxl__egc *egc,
checkpoint_done(egc, stream, 0);
break;
+case REC_TYPE_CHECKPOINT_STATE:
+if (!stream->in_checkpoint_state) {
+LOG(ERROR, "Unexpected CHECKPOINT_STATE record in stream");
+rc
[Xen-devel] [PATCH v11 04/27] tools/libxl: Introduce new helper function dup_fd_helper()
From: Wen Congyang
It is pure refactoring and no functional changes.
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Acked-by: Wei Liu
---
tools/libxl/libxl_save_callout.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_save_callout.c b/tools/libxl/libxl_save_callout.c
index 7f1f5d4..a885504 100644
--- a/tools/libxl/libxl_save_callout.c
+++ b/tools/libxl/libxl_save_callout.c
@@ -118,6 +118,21 @@ void libxl__save_helper_init(libxl__save_helper_state *shs)
}
/*- helper execution -*/
+static int dup_fd_helper(libxl__gc *gc, int fd, const char *what)
+{
+int dup_fd = fd;
+
+if (fd <= 2) {
+dup_fd = dup(fd);
+if (dup_fd < 0) {
+LOGE(ERROR,"dup %s", what);
+exit(-1);
+}
+}
+libxl_fd_set_cloexec(CTX, dup_fd, 0);
+
+return dup_fd;
+}
/*
* Both save and restore share four parameters:
@@ -186,14 +201,7 @@ static void run_helper(libxl__egc *egc,
libxl__save_helper_state *shs,
pid_t pid = libxl__ev_child_fork(gc, &shs->child, helper_exited);
if (!pid) {
-if (stream_fd <= 2) {
-stream_fd = dup(stream_fd);
-if (stream_fd < 0) {
-LOGE(ERROR,"dup migration stream fd");
-exit(-1);
-}
-}
-libxl_fd_set_cloexec(CTX, stream_fd, 0);
+stream_fd = dup_fd_helper(gc, stream_fd, "migration stream fd");
*stream_fd_arg = GCSPRINTF("%d", stream_fd);
for (i=0; ihttp://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 25/27] setup and control colo proxy on primary side
From: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo_save.c | 124 +++---
tools/libxl/libxl_internal.h | 1 +
2 files changed, 117 insertions(+), 8 deletions(-)
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
index 97efc8d..bb44e66 100644
--- a/tools/libxl/libxl_colo_save.c
+++ b/tools/libxl/libxl_colo_save.c
@@ -18,9 +18,11 @@
#include "libxl_internal.h"
+extern const libxl__checkpoint_device_instance_ops colo_save_device_nic;
extern const libxl__checkpoint_device_instance_ops colo_save_device_qdisk;
static const libxl__checkpoint_device_instance_ops *colo_ops[] = {
+&colo_save_device_nic,
&colo_save_device_qdisk,
NULL,
};
@@ -32,9 +34,15 @@ static int
init_device_subkind(libxl__checkpoint_devices_state *cds)
int rc;
STATE_AO_GC(cds->ao);
-rc = init_subkind_qdisk(cds);
+rc = init_subkind_colo_nic(cds);
if (rc) goto out;
+rc = init_subkind_qdisk(cds);
+if (rc) {
+cleanup_subkind_colo_nic(cds);
+goto out;
+}
+
rc = 0;
out:
return rc;
@@ -45,6 +53,7 @@ static void
cleanup_device_subkind(libxl__checkpoint_devices_state *cds)
/* cleanup device subkind-specific state in the libxl ctx */
STATE_AO_GC(cds->ao);
+cleanup_subkind_colo_nic(cds);
cleanup_subkind_qdisk(cds);
}
@@ -89,9 +98,16 @@ void libxl__colo_save_setup(libxl__egc *egc,
libxl__colo_save_state *css)
css->paused = true;
css->qdisk_setuped = false;
css->qdisk_used = false;
+libxl__ev_child_init(&css->child);
+
+if (dss->remus->netbufscript)
+css->colo_proxy_script = libxl__strdup(gc, dss->remus->netbufscript);
+else
+css->colo_proxy_script = GCSPRINTF("%s/colo-proxy-setup",
+ libxl__xen_script_dir_path());
-/* TODO: nic support */
-cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
+ (1 << LIBXL__DEVICE_KIND_VBD);
cds->ops = colo_ops;
cds->callback = colo_save_setup_done;
cds->ao = ao;
@@ -102,6 +118,12 @@ void libxl__colo_save_setup(libxl__egc *egc,
libxl__colo_save_state *css)
css->srs.fd = css->recv_fd;
css->srs.back_channel = true;
libxl__stream_read_start(egc, &css->srs);
+css->cps.ao = ao;
+if (colo_proxy_setup(&css->cps)) {
+LOG(ERROR, "COLO: failed to setup colo proxy for guest with domid %u",
+cds->domid);
+goto out;
+}
if (init_device_subkind(cds))
goto out;
@@ -189,6 +211,7 @@ static void colo_teardown_done(libxl__egc *egc,
libxl__domain_save_state *dss = CONTAINER_OF(css, *dss, css);
cleanup_device_subkind(cds);
+colo_proxy_teardown(&css->cps);
dss->callback(egc, dss, rc);
}
@@ -381,6 +404,8 @@ static void colo_read_svm_ready_done(libxl__egc *egc,
goto out;
}
+colo_proxy_preresume(&css->cps);
+
css->svm_running = true;
dss->cds.callback = colo_preresume_cb;
libxl__checkpoint_devices_preresume(egc, &dss->cds);
@@ -465,6 +490,8 @@ static void colo_read_svm_resumed_done(libxl__egc *egc,
goto out;
}
+colo_proxy_postresume(&css->cps);
+
ok = 1;
out:
@@ -473,6 +500,91 @@ out:
/* = colo: wait new checkpoint = */
+
+static void colo_start_new_checkpoint(libxl__egc *egc,
+ libxl__checkpoint_devices_state *cds,
+ int rc);
+static void colo_proxy_async_wait_for_checkpoint(libxl__colo_save_state *css);
+static void colo_proxy_async_call_done(libxl__egc *egc,
+ libxl__ev_child *child,
+ int pid,
+ int status);
+
+static void colo_proxy_async_call(libxl__egc *egc,
+ libxl__colo_save_state *css,
+ void func(libxl__colo_save_state *),
+ libxl__ev_child_callback callback)
+{
+libxl__domain_save_state *dss = CONTAINER_OF(css, *dss, css);
+int pid = -1, rc;
+
+STATE_AO_GC(dss->cds.ao);
+
+/* Fork and call */
+pid = libxl__ev_child_fork(gc, &css->child, callback);
+if (pid == -1) {
+LOG(ERROR, "unable to fork");
+rc = ERROR_FAIL;
+goto out;
+}
+
+if (!pid) {
+/* child */
+func(css);
+/* notreached */
+abort();
+}
+
+return;
+
+out:
+callback(egc, &css->child, -1, 1);
+}
+
+static void colo_proxy_wait_for_checkpoint(libxl__egc *egc,
+ libxl__colo_save_state *css)
+{
+colo_proxy_async_call(egc, css,
+ colo_proxy_async_wait_for_checkpoint,
+
[Xen-devel] [PATCH v11 09/27] libxc/migration: export read_record for common use
From: Wen Congyang
read_record() could be used by primary to read dirty bitmap
record sent by secondary under COLO.
When used by save side, we need to pass the backchannel fd
instead of ctx->fd to read_record(), so we added a fd param to
it.
No functional changes.
CC: Andrew Cooper
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxc/xc_sr_common.c | 49 +++
tools/libxc/xc_sr_common.h | 14 ++
tools/libxc/xc_sr_restore.c | 63 +
3 files changed, 64 insertions(+), 62 deletions(-)
diff --git a/tools/libxc/xc_sr_common.c b/tools/libxc/xc_sr_common.c
index 3313a90..b228a15 100644
--- a/tools/libxc/xc_sr_common.c
+++ b/tools/libxc/xc_sr_common.c
@@ -89,6 +89,55 @@ int write_split_record(struct xc_sr_context *ctx, struct
xc_sr_record *rec,
return -1;
}
+int read_record(struct xc_sr_context *ctx, int fd, struct xc_sr_record *rec)
+{
+xc_interface *xch = ctx->xch;
+struct xc_sr_rhdr rhdr;
+size_t datasz;
+
+if ( read_exact(fd, &rhdr, sizeof(rhdr)) )
+{
+PERROR("Failed to read Record Header from stream");
+return -1;
+}
+else if ( rhdr.length > REC_LENGTH_MAX )
+{
+ERROR("Record (0x%08x, %s) length %#x exceeds max (%#x)", rhdr.type,
+ rec_type_to_str(rhdr.type), rhdr.length, REC_LENGTH_MAX);
+return -1;
+}
+
+datasz = ROUNDUP(rhdr.length, REC_ALIGN_ORDER);
+
+if ( datasz )
+{
+rec->data = malloc(datasz);
+
+if ( !rec->data )
+{
+ERROR("Unable to allocate %zu bytes for record data (0x%08x, %s)",
+ datasz, rhdr.type, rec_type_to_str(rhdr.type));
+return -1;
+}
+
+if ( read_exact(fd, rec->data, datasz) )
+{
+free(rec->data);
+rec->data = NULL;
+PERROR("Failed to read %zu bytes of data for record (0x%08x, %s)",
+ datasz, rhdr.type, rec_type_to_str(rhdr.type));
+return -1;
+}
+}
+else
+rec->data = NULL;
+
+rec->type = rhdr.type;
+rec->length = rhdr.length;
+
+return 0;
+};
+
static void __attribute__((unused)) build_assertions(void)
{
XC_BUILD_BUG_ON(sizeof(struct xc_sr_ihdr) != 24);
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 66f595f..5d9f497 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -382,6 +382,20 @@ static inline int write_record(struct xc_sr_context *ctx,
}
/*
+ * Reads a record from the stream, and fills in the record structure.
+ *
+ * Returns 0 on success and non-0 on failure.
+ *
+ * On success, the records type and size shall be valid.
+ * - If size is 0, data shall be NULL.
+ * - If size is non-0, data shall be a buffer allocated by malloc() which must
+ * be passed to free() by the caller.
+ *
+ * On failure, the contents of the record structure are undefined.
+ */
+int read_record(struct xc_sr_context *ctx, int fd, struct xc_sr_record *rec);
+
+/*
* This would ideally be private in restore.c, but is needed by
* x86_pv_localise_page() if we receive pagetables frames ahead of the
* contents of the frames they point at.
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index e24560e..aef9bca 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -69,67 +69,6 @@ static int read_headers(struct xc_sr_context *ctx)
}
/*
- * Reads a record from the stream, and fills in the record structure.
- *
- * Returns 0 on success and non-0 on failure.
- *
- * On success, the records type and size shall be valid.
- * - If size is 0, data shall be NULL.
- * - If size is non-0, data shall be a buffer allocated by malloc() which must
- * be passed to free() by the caller.
- *
- * On failure, the contents of the record structure are undefined.
- */
-static int read_record(struct xc_sr_context *ctx, struct xc_sr_record *rec)
-{
-xc_interface *xch = ctx->xch;
-struct xc_sr_rhdr rhdr;
-size_t datasz;
-
-if ( read_exact(ctx->fd, &rhdr, sizeof(rhdr)) )
-{
-PERROR("Failed to read Record Header from stream");
-return -1;
-}
-else if ( rhdr.length > REC_LENGTH_MAX )
-{
-ERROR("Record (0x%08x, %s) length %#x exceeds max (%#x)", rhdr.type,
- rec_type_to_str(rhdr.type), rhdr.length, REC_LENGTH_MAX);
-return -1;
-}
-
-datasz = ROUNDUP(rhdr.length, REC_ALIGN_ORDER);
-
-if ( datasz )
-{
-rec->data = malloc(datasz);
-
-if ( !rec->data )
-{
-ERROR("Unable to allocate %zu bytes for record data (0x%08x, %s)",
- datasz, rhdr.type, rec_type_to_str(rhdr.type));
-return -1;
-}
-
-if ( read_exact(ctx->fd, rec->data, datasz) )
-{
-free(rec->data);
-rec->data = NULL;
-PERROR("Fail
[Xen-devel] [PATCH v11 15/27] primary vm suspend/resume/checkpoint code
From: Wen Congyang
We will do the following things again and again:
1. Suspend primary vm
a. Suspend primary vm
b. do postsuspend
c. Read CHECKPOINT_SVM_SUSPENDED sent by secondary
2. Checkpoint
a. Write emulator xenstore data and emulator context
b. Write checkpoint end record
3. Resume primary vm
a. Read CHECKPOINT_SVM_READY from slave
b. Do presume
c. Resume primary vm
d. Read CHECKPOINT_SVM_RESUMED from slave
4. Wait a new checkpoint
a. Wait a new checkpoint(not implemented)
b. Send CHECKPOINT_NEW to slave
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
tools/libxl/Makefile | 2 +-
tools/libxl/libxl.c | 5 +-
tools/libxl/libxl_colo.h | 6 +
tools/libxl/libxl_colo_save.c | 562 ++
tools/libxl/libxl_dom_save.c | 7 +-
tools/libxl/libxl_internal.h | 157 ++--
tools/libxl/libxl_types.idl | 1 +
7 files changed, 666 insertions(+), 74 deletions(-)
create mode 100644 tools/libxl/libxl_colo_save.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index d8612eb..2016393 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -65,7 +65,7 @@ LIBXL_OBJS-y += libxl_no_convert_callout.o
endif
LIBXL_OBJS-y += libxl_remus.o libxl_checkpoint_device.o libxl_remus_disk_drbd.o
-LIBXL_OBJS-y += libxl_colo_restore.o
+LIBXL_OBJS-y += libxl_colo_restore.o libxl_colo_save.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e9ab78c..305231b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -880,7 +880,10 @@ int libxl_domain_remus_start(libxl_ctx *ctx,
libxl_domain_remus_info *info,
assert(info);
/* Point of no return */
-libxl__remus_setup(egc, &dss->rs);
+if (libxl_defbool_val(info->colo))
+libxl__colo_save_setup(egc, &dss->css);
+else
+libxl__remus_setup(egc, &dss->rs);
return AO_INPROGRESS;
out:
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index f2b98cc..feec7f1 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -18,6 +18,7 @@
struct libxl__ao;
struct libxl__egc;
+struct libxl__colo_save_state;
enum {
LIBXL_COLO_SETUPED,
@@ -52,4 +53,9 @@ extern void libxl__colo_restore_setup(struct libxl__egc *egc,
libxl__colo_restore_state *crs);
extern void libxl__colo_restore_teardown(struct libxl__egc *egc, void
*dcs_void,
int ret, int retval, int errnoval);
+extern void libxl__colo_save_setup(struct libxl__egc *egc,
+ struct libxl__colo_save_state *css);
+extern void libxl__colo_save_teardown(struct libxl__egc *egc,
+ struct libxl__colo_save_state *css,
+ int rc);
#endif
diff --git a/tools/libxl/libxl_colo_save.c b/tools/libxl/libxl_colo_save.c
new file mode 100644
index 000..e318ea2
--- /dev/null
+++ b/tools/libxl/libxl_colo_save.c
@@ -0,0 +1,562 @@
+/*
+ * Copyright (C) 2014 FUJITSU LIMITED
+ * Author: Wen Congyang
+ * Yang Hongyang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+static const libxl__checkpoint_device_instance_ops *colo_ops[] = {
+NULL,
+};
+
+/* = helper functions = */
+static int init_device_subkind(libxl__checkpoint_devices_state *cds)
+{
+/* init device subkind-specific state in the libxl ctx */
+int rc;
+STATE_AO_GC(cds->ao);
+
+rc = 0;
+return rc;
+}
+
+static void cleanup_device_subkind(libxl__checkpoint_devices_state *cds)
+{
+/* cleanup device subkind-specific state in the libxl ctx */
+STATE_AO_GC(cds->ao);
+}
+
+/* = colo: setup save environment = */
+static void colo_save_setup_done(libxl__egc *egc,
+ libxl__checkpoint_devices_state *cds,
+ int rc);
+static void colo_save_setup_failed(libxl__egc *egc,
+ libxl__checkpoint_devices_state *cds,
+ int rc);
+/*
+ * checkpoint callbacks are called in the following order:
+ * 1. suspend
+ * 2. ch
[Xen-devel] [PATCH v11 27/27] cmdline switches and config vars to control colo-proxy
From: Wen Congyang
Add cmdline switches to 'xl migrate-receive' command to specify
a domain-specific hotplug script to setup COLO proxy.
Add a new config var 'colo.default.agentscript' to xl.conf, that
allows the user to override the default global script used to
setup COLO proxy.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
docs/man/xl.conf.pod.5 | 6 ++
docs/man/xl.pod.1 | 6 +-
tools/libxl/libxl.c | 6 ++
tools/libxl/libxl_create.c | 14 --
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl.c| 3 +++
tools/libxl/xl.h| 1 +
tools/libxl/xl_cmdimpl.c| 47 ++---
8 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/docs/man/xl.conf.pod.5 b/docs/man/xl.conf.pod.5
index 8ae19bb..8f7fd28 100644
--- a/docs/man/xl.conf.pod.5
+++ b/docs/man/xl.conf.pod.5
@@ -111,6 +111,12 @@ Configures the default script used by Remus to setup
network buffering.
Default: C
+=item B
+
+Configures the default script used by COLO to setup colo-proxy.
+
+Default: C
+
=item B
Configures the default output format used by xl when printing "machine
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 36b093b..3977d4b 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -458,7 +458,6 @@ Remus support in xl is still in experimental
(proof-of-concept) phase.
Disk replication support is limited to DRBD disks.
COLO support in xl is still in experimental (proof-of-concept) phase.
-There is no support for network at the moment.
=back
@@ -482,6 +481,11 @@ and it's used by secondary.
=item B:Primary's modified contents will be buffered in this
disk, and it's used by secondary.
+(b) An example for COLO network configuration: vif =[ '...,forwarddev=xxx,...']
+
+=item B :Forward devices for primary and secondary, there are
+directly connected.
+
=back
B
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index eb1b277..4699641 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3392,6 +3392,11 @@ void libxl__device_nic_add(libxl__egc *egc, uint32_t
domid,
flexarray_append(back, nic->ifname);
}
+if (nic->forwarddev) {
+flexarray_append(back, "forwarddev");
+flexarray_append(back, nic->forwarddev);
+}
+
flexarray_append(back, "mac");
flexarray_append(back,GCSPRINTF(LIBXL_MAC_FMT, LIBXL_MAC_BYTES(nic->mac)));
if (nic->ip) {
@@ -3514,6 +3519,7 @@ static int libxl__device_nic_from_xs_be(libxl__gc *gc,
nic->ip = READ_BACKEND(NOGC, "ip");
nic->bridge = READ_BACKEND(NOGC, "bridge");
nic->script = READ_BACKEND(NOGC, "script");
+nic->forwarddev = READ_BACKEND(NOGC, "forwarddev");
/* vif_ioemu nics use the same xenstore entries as vif interfaces */
tmp = READ_BACKEND(gc, "type");
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bff08b0..63e1a0d 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1072,6 +1072,11 @@ static void domcreate_bootloader_done(libxl__egc *egc,
crs->recv_fd = restore_fd;
crs->hvm = (info->type == LIBXL_DOMAIN_TYPE_HVM);
crs->callback = libxl__colo_restore_setup_done;
+if (dcs->colo_proxy_script)
+crs->colo_proxy_script = libxl__strdup(gc,
dcs->colo_proxy_script);
+else
+crs->colo_proxy_script = GCSPRINTF("%s/colo-proxy-setup",
+
libxl__xen_script_dir_path());
libxl__colo_restore_setup(egc, crs);
break;
case LIBXL_CHECKPOINTED_STREAM_REMUS:
@@ -1614,6 +1619,7 @@ static void domain_create_cb(libxl__egc *egc,
static int do_domain_create(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid, int restore_fd, int send_back_fd,
const libxl_domain_restore_params *params,
+const char *colo_proxy_script,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
{
@@ -1637,6 +1643,7 @@ static int do_domain_create(libxl_ctx *ctx,
libxl_domain_config *d_config,
}
cdcs->dcs.callback = domain_create_cb;
cdcs->dcs.domid_soft_reset = INVALID_DOMID;
+cdcs->dcs.colo_proxy_script = colo_proxy_script;
libxl__ao_progress_gethow(&cdcs->dcs.aop_console_how, aop_console_how);
cdcs->domid_out = domid;
@@ -1823,7 +1830,7 @@ int libxl_domain_create_new(libxl_ctx *ctx,
libxl_domain_config *d_config,
const libxl_asyncprogress_how *aop_console_how)
{
unset_disk_colo_restore(d_config);
-return do_domain_create(ctx, d_config, domid, -1, -1, NULL,
+return do_domain_create(ctx, d_config, domid, -1, -1, NULL, NULL,
ao_how, aop_console_how);
[Xen-devel] [PATCH v11 24/27] COLO nic: implement COLO nic subkind
From: Wen Congyang
implement COLO nic subkind.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/hotplug/Linux/Makefile | 1 +
tools/hotplug/Linux/colo-proxy-setup | 135 +++
tools/libxl/Makefile | 1 +
tools/libxl/libxl_colo.h | 10 ++
tools/libxl/libxl_colo_nic.c | 315 +++
tools/libxl/libxl_internal.h | 2 +
tools/libxl/libxl_types.idl | 1 +
7 files changed, 465 insertions(+)
create mode 100755 tools/hotplug/Linux/colo-proxy-setup
create mode 100644 tools/libxl/libxl_colo_nic.c
diff --git a/tools/hotplug/Linux/Makefile b/tools/hotplug/Linux/Makefile
index 6e10118..9bb852b 100644
--- a/tools/hotplug/Linux/Makefile
+++ b/tools/hotplug/Linux/Makefile
@@ -28,6 +28,7 @@ XEN_SCRIPTS += block-iscsi
XEN_SCRIPTS += block-tap
XEN_SCRIPTS += block-drbd-probe
XEN_SCRIPTS += $(XEN_SCRIPTS-y)
+XEN_SCRIPTS += colo-proxy-setup
SUBDIRS-$(CONFIG_SYSTEMD) += systemd
diff --git a/tools/hotplug/Linux/colo-proxy-setup
b/tools/hotplug/Linux/colo-proxy-setup
new file mode 100755
index 000..94e2034
--- /dev/null
+++ b/tools/hotplug/Linux/colo-proxy-setup
@@ -0,0 +1,135 @@
+#! /bin/bash
+
+dir=$(dirname "$0")
+. "$dir/xen-hotplug-common.sh"
+. "$dir/hotplugpath.sh"
+
+findCommand "$@"
+
+if [ "$command" != "setup" -a "$command" != "teardown" ]
+then
+echo "Invalid command: $command"
+log err "Invalid command: $command"
+exit 1
+fi
+
+evalVariables "$@"
+
+: ${vifname:?}
+: ${forwarddev:?}
+: ${mode:?}
+: ${index:?}
+: ${bridge:?}
+
+forwardbr="colobr0"
+
+if [ "$mode" != "primary" -a "$mode" != "secondary" ]
+then
+echo "Invalid mode: $mode"
+log err "Invalid mode: $mode"
+exit 1
+fi
+
+if [ $index -lt 0 ] || [ $index -gt 100 ]; then
+echo "index overflow"
+exit 1
+fi
+
+function setup_primary()
+{
+do_without_error tc qdisc add dev $vifname root handle 1: prio
+do_without_error tc filter add dev $vifname parent 1: protocol ip prio 10 \
+u32 match u32 0 0 flowid 1:2 action mirred egress mirror dev
$forwarddev
+do_without_error tc filter add dev $vifname parent 1: protocol arp prio 11
\
+u32 match u32 0 0 flowid 1:2 action mirred egress mirror dev
$forwarddev
+do_without_error tc filter add dev $vifname parent 1: protocol ipv6 prio \
+12 u32 match u32 0 0 flowid 1:2 action mirred egress mirror \
+dev $forwarddev
+
+do_without_error modprobe nf_conntrack_ipv4
+do_without_error modprobe xt_PMYCOLO sec_dev=$forwarddev
+
+iptables -t mangle -I PREROUTING -m physdev --physdev-in \
+$vifname -j PMYCOLO --index $index
+ip6tables -t mangle -I PREROUTING -m physdev --physdev-in \
+$vifname -j PMYCOLO --index $index
+do_without_error arptables -I INPUT -i $forwarddev -j MARK --set-mark
$index
+}
+
+function teardown_primary()
+{
+do_without_error tc filter del dev $vifname parent 1: protocol ip prio 10
u32 match u32 \
+0 0 flowid 1:2 action mirred egress mirror dev $forwarddev
+do_without_error tc filter del dev $vifname parent 1: protocol arp prio 11
u32 match u32 \
+0 0 flowid 1:2 action mirred egress mirror dev $forwarddev
+do_without_error tc filter del dev $vifname parent 1: protocol ipv6 prio
12 u32 match u32 \
+0 0 flowid 1:2 action mirred egress mirror dev $forwarddev
+do_without_error tc qdisc del dev $vifname root handle 1: prio
+
+do_without_error iptables -t mangle -D PREROUTING -m physdev --physdev-in \
+$vifname -j PMYCOLO --index $index
+do_without_error ip6tables -t mangle -D PREROUTING -m physdev --physdev-in
\
+$vifname -j PMYCOLO --index $index
+do_without_error arptables -F
+do_without_error rmmod xt_PMYCOLO
+}
+
+function setup_secondary()
+{
+do_without_error brctl delif $bridge $vifname
+do_without_error brctl addbr $forwardbr
+do_without_error brctl addif $forwardbr $vifname
+do_without_error brctl addif $forwardbr $forwarddev
+do_without_error ip link set dev $forwardbr up
+do_without_error modprobe xt_SECCOLO
+
+iptables -t mangle -I PREROUTING -m physdev --physdev-in \
+$vifname -j SECCOLO --index $index
+ip6tables -t mangle -I PREROUTING -m physdev --physdev-in \
+$vifname -j SECCOLO --index $index
+}
+
+function teardown_secondary()
+{
+do_without_error brctl delif $forwardbr $forwarddev
+do_without_error brctl delif $forwardbr $vifname
+do_without_error brctl delbr $forwardbr
+do_without_error brctl addif $bridge $vifname
+
+do_without_error iptables -t mangle -D PREROUTING -m physdev --physdev-in \
+$vifname -j SECCOLO --index $index
+do_without_error ip6tables -t mangle -D PREROUTING -m physdev --physdev-in
\
+$vifname -j SECCOLO --index $index
+do_without_error rmmod xt_SECCOLO
+}
+
+case "$command" in
+setup)
+if [ "$mode" = "pri
[Xen-devel] [PATCH v11 26/27] setup and control colo proxy on secondary side
From: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo_restore.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tools/libxl/libxl_colo_restore.c b/tools/libxl/libxl_colo_restore.c
index 8b343c0..52e44a2 100644
--- a/tools/libxl/libxl_colo_restore.c
+++ b/tools/libxl/libxl_colo_restore.c
@@ -37,9 +37,11 @@ struct libxl__colo_restore_checkpoint_state {
int);
};
+extern const libxl__checkpoint_device_instance_ops colo_restore_device_nic;
extern const libxl__checkpoint_device_instance_ops colo_restore_device_qdisk;
static const libxl__checkpoint_device_instance_ops *colo_restore_ops[] = {
+&colo_restore_device_nic,
&colo_restore_device_qdisk,
NULL,
};
@@ -139,8 +141,14 @@ static int
init_device_subkind(libxl__checkpoint_devices_state *cds)
int rc;
STATE_AO_GC(cds->ao);
+rc = init_subkind_colo_nic(cds);
+if (rc) goto out;
+
rc = init_subkind_qdisk(cds);
-if (rc) goto out;
+if (rc) {
+cleanup_subkind_colo_nic(cds);
+goto out;
+}
rc = 0;
out:
@@ -152,6 +160,7 @@ static void
cleanup_device_subkind(libxl__checkpoint_devices_state *cds)
/* cleanup device subkind-specific state in the libxl ctx */
STATE_AO_GC(cds->ao);
+cleanup_subkind_colo_nic(cds);
cleanup_subkind_qdisk(cds);
}
@@ -341,6 +350,8 @@ static void colo_restore_teardown_devices_done(libxl__egc
*egc,
if (crcs->teardown_devices)
cleanup_device_subkind(cds);
+colo_proxy_teardown(&crs->cps);
+
rc = crcs->saved_rc;
if (!rc) {
crcs->callback = do_failover_done;
@@ -592,6 +603,8 @@ static void colo_restore_preresume_cb(libxl__egc *egc,
}
}
+colo_proxy_preresume(&crs->cps);
+
colo_restore_resume_vm(egc, crcs);
return;
@@ -628,6 +641,8 @@ static void colo_resume_vm_done(libxl__egc *egc,
crcs->status = LIBXL_COLO_RESUMED;
+colo_proxy_postresume(&crs->cps);
+
/* avoid calling stream->completion_callback() more than once */
if (crs->saved_cb) {
dcs->callback = crs->saved_cb;
@@ -749,13 +764,20 @@ static void colo_setup_checkpoint_devices(libxl__egc *egc,
STATE_AO_GC(crs->ao);
-/* TODO: nic support */
-cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VBD);
+cds->device_kind_flags = (1 << LIBXL__DEVICE_KIND_VIF) |
+ (1 << LIBXL__DEVICE_KIND_VBD);
cds->callback = colo_restore_setup_cds_done;
cds->ao = ao;
cds->domid = crs->domid;
cds->ops = colo_restore_ops;
+crs->cps.ao = ao;
+if (colo_proxy_setup(&crs->cps)) {
+LOG(ERROR, "COLO: failed to setup colo proxy for guest with domid %u",
+cds->domid);
+goto out;
+}
+
if (init_device_subkind(cds))
goto out;
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 10/27] tools/libxl: add back channel support to write stream
From: Wen Congyang
Add back channel support to write stream. If the write stream is
a back channel stream, this means the write stream is used by
Secondary to send some records back.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_dom_save.c | 1 +
tools/libxl/libxl_internal.h | 6 +++
tools/libxl/libxl_stream_write.c | 99
3 files changed, 96 insertions(+), 10 deletions(-)
diff --git a/tools/libxl/libxl_dom_save.c b/tools/libxl/libxl_dom_save.c
index 4df86c3..cd324bb 100644
--- a/tools/libxl/libxl_dom_save.c
+++ b/tools/libxl/libxl_dom_save.c
@@ -405,6 +405,7 @@ void libxl__domain_save(libxl__egc *egc,
libxl__domain_save_state *dss)
dss->sws.ao = dss->ao;
dss->sws.dss = dss;
dss->sws.fd = dss->fd;
+dss->sws.back_channel = false;
dss->sws.completion_callback = stream_done;
libxl__stream_write_start(egc, &dss->sws);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5314522..fb8b2fa 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3042,6 +3042,7 @@ struct libxl__stream_write_state {
libxl__ao *ao;
libxl__domain_save_state *dss;
int fd;
+bool back_channel;
void (*completion_callback)(libxl__egc *egc,
libxl__stream_write_state *sws,
int rc);
@@ -3053,6 +3054,7 @@ struct libxl__stream_write_state {
bool running;
bool in_checkpoint;
bool sync_teardown; /* Only used to coordinate shutdown on error path. */
+bool in_checkpoint_state;
libxl__save_helper_state shs;
/* Main stream-writing data. */
@@ -3076,6 +3078,10 @@ _hidden void libxl__stream_write_start(libxl__egc *egc,
_hidden void
libxl__stream_write_start_checkpoint(libxl__egc *egc,
libxl__stream_write_state *stream);
+_hidden void
+libxl__stream_write_checkpoint_state(libxl__egc *egc,
+ libxl__stream_write_state *stream,
+ libxl_sr_checkpoint_state *srcs);
_hidden void libxl__stream_write_abort(libxl__egc *egc,
libxl__stream_write_state *stream,
int rc);
diff --git a/tools/libxl/libxl_stream_write.c b/tools/libxl/libxl_stream_write.c
index f6ea55d..8c77d52 100644
--- a/tools/libxl/libxl_stream_write.c
+++ b/tools/libxl/libxl_stream_write.c
@@ -49,6 +49,13 @@
* - if (hvm)
* - Emulator context record
* - Checkpoint end record
+ *
+ * For back channel stream:
+ * - libxl__stream_write_start()
+ *- Set up the stream to running state
+ *
+ * - Use libxl__stream_write_checkpoint_state to write the record. When the
+ * record is written out, call stream->checkpoint_callback() to return.
*/
/* Success/error/cleanup handling. */
@@ -91,6 +98,12 @@ static void write_checkpoint_end_record(libxl__egc *egc,
static void checkpoint_end_record_done(libxl__egc *egc,
libxl__stream_write_state *stream);
+/* checkpoint state */
+static void write_checkpoint_state_done(libxl__egc *egc,
+libxl__stream_write_state *stream);
+static void checkpoint_state_done(libxl__egc *egc,
+ libxl__stream_write_state *stream, int rc);
+
/*- Helpers -*/
static void write_done(libxl__egc *egc,
@@ -225,6 +238,17 @@ void libxl__stream_write_start(libxl__egc *egc,
stream->running = true;
+dc->ao= ao;
+dc->readfd= -1;
+dc->writewhat = "stream header";
+dc->copywhat = "save v2 stream";
+dc->writefd = stream->fd;
+dc->maxsz = -1;
+dc->callback = stream_header_done;
+
+if (stream->back_channel)
+return;
+
if (dss->type == LIBXL_DOMAIN_TYPE_HVM) {
stream->device_model_version =
libxl__device_model_version_running(gc, dss->domid);
@@ -249,14 +273,6 @@ void libxl__stream_write_start(libxl__egc *egc,
stream->emu_sub_hdr.index = 0;
}
-dc->ao= ao;
-dc->readfd= -1;
-dc->writewhat = "stream header";
-dc->copywhat = "save v2 stream";
-dc->writefd = stream->fd;
-dc->maxsz = -1;
-dc->callback = stream_header_done;
-
rc = libxl__datacopier_start(dc);
if (rc)
goto err;
@@ -279,6 +295,7 @@ void libxl__stream_write_start_checkpoint(libxl__egc *egc,
{
assert(stream->running);
assert(!stream->in_checkpoint);
+assert(!stream->back_channel);
stream->in_checkpoint = true;
write_emulator_xenstore_record(egc, stream);
@@ -577,6 +594,21 @@ static void stream_complete(libxl__egc *egc,
return;
}
+if (stream->in_checkpoint_state) {
+assert(rc);
+
+/*
+ * If an error is encountered while in a checkpoint, pass it
+
[Xen-devel] [PATCH v11 19/27] COLO: introduce new API to prepare/start/do/get_error/stop replication
From: Wen Congyang
We will use qemu block replication, and qemu provides some qmp commands
to prepare replication, start replication, get replication error, and
stop replication. Introduce new API to execute these qmp commands.
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
Acked-by: Wei Liu
---
tools/libxl/libxl_internal.h | 20 +
tools/libxl/libxl_qmp.c | 96
2 files changed, 116 insertions(+)
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5160939..8cb9f19 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1771,6 +1771,26 @@ _hidden int libxl__qmp_set_global_dirty_log(libxl__gc
*gc, int domid, bool enabl
_hidden int libxl__qmp_insert_cdrom(libxl__gc *gc, int domid, const
libxl_device_disk *disk);
/* Add a virtual CPU */
_hidden int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int index);
+/* Start NBD server */
+_hidden int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
+const char *host, const char *port);
+/* Add a disk to NBD server */
+_hidden int libxl__qmp_nbd_server_add(libxl__gc *gc, int domid, const char
*disk);
+/* Start replication */
+_hidden int libxl__qmp_start_replication(libxl__gc *gc, int domid, bool
primary);
+/* Get replication error that occurs when the vm is running */
+_hidden int libxl__qmp_get_replication_error(libxl__gc *gc, int domid);
+/* Do checkpoint */
+_hidden int libxl__qmp_do_checkpoint(libxl__gc *gc, int domid);
+/* Stop replication */
+_hidden int libxl__qmp_stop_replication(libxl__gc *gc, int domid, bool
primary);
+/* Stop NBD server */
+_hidden int libxl__qmp_nbd_server_stop(libxl__gc *gc, int domid);
+/* Add or remove a child to/from quorum */
+_hidden int libxl__qmp_x_blockdev_change(libxl__gc *gc, int domid, const char
*parant,
+ const char *child, const char *node);
+/* run a hmp command in qmp mode */
+_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line);
/* close and free the QMP handler */
_hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
/* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c0bdfcb..3eb279a 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -979,6 +979,102 @@ int libxl__qmp_cpu_add(libxl__gc *gc, int domid, int idx)
return qmp_run_command(gc, domid, "cpu-add", args, NULL, NULL);
}
+int libxl__qmp_nbd_server_start(libxl__gc *gc, int domid,
+const char *host, const char *port)
+{
+libxl__json_object *args = NULL;
+libxl__json_object *addr = NULL;
+libxl__json_object *data = NULL;
+
+/* 'addr': {
+ * 'type': 'inet',
+ * 'data': {
+ * 'host': '$nbd_host',
+ * 'port': '$nbd_port'
+ * }
+ * }
+ */
+qmp_parameters_add_string(gc, &data, "host", host);
+qmp_parameters_add_string(gc, &data, "port", port);
+
+qmp_parameters_add_string(gc, &addr, "type", "inet");
+qmp_parameters_common_add(gc, &addr, "data", data);
+
+qmp_parameters_common_add(gc, &args, "addr", addr);
+
+return qmp_run_command(gc, domid, "nbd-server-start", args, NULL, NULL);
+}
+
+int libxl__qmp_nbd_server_add(libxl__gc *gc, int domid, const char *disk)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_string(gc, &args, "device", disk);
+qmp_parameters_add_bool(gc, &args, "writable", true);
+
+return qmp_run_command(gc, domid, "nbd-server-add", args, NULL, NULL);
+}
+
+int libxl__qmp_start_replication(libxl__gc *gc, int domid, bool primary)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_bool(gc, &args, "enable", true);
+qmp_parameters_add_bool(gc, &args, "primary", primary);
+
+return qmp_run_command(gc, domid, "xen-set-replication", args, NULL, NULL);
+}
+
+int libxl__qmp_get_replication_error(libxl__gc *gc, int domid)
+{
+return qmp_run_command(gc, domid, "xen-get-replication-error", NULL,
+ NULL, NULL);
+}
+
+int libxl__qmp_do_checkpoint(libxl__gc *gc, int domid)
+{
+return qmp_run_command(gc, domid, "xen-do-checkpoint", NULL, NULL, NULL);
+}
+
+int libxl__qmp_stop_replication(libxl__gc *gc, int domid, bool primary)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_bool(gc, &args, "enable", false);
+qmp_parameters_add_bool(gc, &args, "primary", primary);
+
+return qmp_run_command(gc, domid, "xen-set-replication", args, NULL, NULL);
+}
+
+int libxl__qmp_nbd_server_stop(libxl__gc *gc, int domid)
+{
+return qmp_run_command(gc, domid, "nbd-server-stop", NULL, NULL, NULL);
+}
+
+int libxl__qmp_x_blockdev_change(libxl__gc *gc, int domid, const char *parent,
+ const char *child, const char *node)
+{
+libxl__json_object *args = NULL;
+
+qmp_parameters_add_st
[Xen-devel] [PATCH v11 16/27] libxc/restore: support COLO restore
From: Wen Congyang
a. call callbacks resume/checkpoint/suspend while secondary vm
status is consistent with primary
b. send dirty pfn list to primary when checkpoint under colo
c. send store gfn and console gfn to xl before resuming secondary vm
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
CC: Andrew Cooper
---
tools/libxc/include/xenguest.h | 8 ++
tools/libxc/xc_sr_common.h | 8 +-
tools/libxc/xc_sr_restore.c| 181 +
tools/libxl/libxl_colo_restore.c | 5 -
tools/libxl/libxl_create.c | 3 +
tools/libxl/libxl_save_msgs_gen.pl | 4 +-
6 files changed, 200 insertions(+), 9 deletions(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index cb0bbcf..67cb540 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -127,6 +127,14 @@ struct restore_callbacks {
*/
int (*wait_checkpoint)(void* data);
+/*
+ * callback to send store gfn and console gfn to xl
+ * if we want to resume vm before xc_domain_save()
+ * exits.
+ */
+void (*restore_results)(xen_pfn_t store_gfn, xen_pfn_t console_gfn,
+void *data);
+
/* to be provided as the last argument to each callback function */
void* data;
};
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 2bfed64..29ab4eb 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -226,6 +226,10 @@ struct xc_sr_context
struct xc_sr_restore_ops ops;
struct restore_callbacks *callbacks;
+int send_back_fd;
+unsigned long p2m_size;
+xc_hypercall_buffer_t dirty_bitmap_hbuf;
+
/* From Image Header. */
uint32_t format_version;
@@ -234,13 +238,13 @@ struct xc_sr_context
uint32_t guest_page_size;
/* Plain VM, or checkpoints over time. */
-bool checkpointed;
+int checkpointed;
/* Currently buffering records between a checkpoint */
bool buffer_all_records;
/*
- * With Remus, we buffer the records sent by the primary at checkpoint,
+ * With Remus/COLO, we buffer the records sent by the primary at checkpoint,
* in case the primary will fail, we can recover from the last
* checkpoint state.
* This should be enough for most of the cases because primary only send
diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
index aef9bca..24c4719 100644
--- a/tools/libxc/xc_sr_restore.c
+++ b/tools/libxc/xc_sr_restore.c
@@ -411,6 +411,92 @@ static int handle_page_data(struct xc_sr_context *ctx,
struct xc_sr_record *rec)
return rc;
}
+/*
+ * Send checkpoint dirty pfn list to primary.
+ */
+static int send_checkpoint_dirty_pfn_list(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+int rc = -1;
+unsigned count, written;
+uint64_t i, *pfns = NULL;
+struct iovec *iov = NULL;
+xc_shadow_op_stats_t stats = { 0, ctx->restore.p2m_size };
+struct xc_sr_record rec =
+{
+.type = REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST,
+};
+DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
+&ctx->restore.dirty_bitmap_hbuf);
+
+if ( xc_shadow_control(
+ xch, ctx->domid, XEN_DOMCTL_SHADOW_OP_CLEAN,
+ HYPERCALL_BUFFER(dirty_bitmap), ctx->restore.p2m_size,
+ NULL, 0, &stats) != ctx->restore.p2m_size )
+{
+PERROR("Failed to retrieve logdirty bitmap");
+goto err;
+}
+
+for ( i = 0, count = 0; i < ctx->restore.p2m_size; i++ )
+{
+if ( test_bit(i, dirty_bitmap) )
+count++;
+}
+
+
+pfns = malloc(count * sizeof(*pfns));
+if ( !pfns )
+{
+ERROR("Unable to allocate %zu bytes of memory for dirty pfn list",
+ count * sizeof(*pfns));
+goto err;
+}
+
+for ( i = 0, written = 0; i < ctx->restore.p2m_size; ++i )
+{
+if ( !test_bit(i, dirty_bitmap) )
+continue;
+
+if ( written > count )
+{
+ERROR("Dirty pfn list exceed");
+goto err;
+}
+
+pfns[written++] = i;
+}
+
+/* iovec[] for writev(). */
+iov = malloc(3 * sizeof(*iov));
+if ( !iov )
+{
+ERROR("Unable to allocate memory for sending dirty bitmap");
+goto err;
+}
+
+rec.length = count * sizeof(*pfns);
+
+iov[0].iov_base = &rec.type;
+iov[0].iov_len = sizeof(rec.type);
+
+iov[1].iov_base = &rec.length;
+iov[1].iov_len = sizeof(rec.length);
+
+iov[2].iov_base = pfns;
+iov[2].iov_len = count * sizeof(*pfns);
+
+if ( writev_exact(ctx->restore.send_back_fd, iov, 3) )
+{
+PERROR("Failed to write dirty bitmap to stream");
+goto err;
+}
+
+rc = 0;
+ err:
+return rc;
+}
+
static int proces
[Xen-devel] [PATCH v11 14/27] secondary vm suspend/resume/checkpoint code
From: Wen Congyang
Secondary vm is running in colo mode. So we will do
the following things again and again:
1. Resume secondary vm
a. Send CHECKPOINT_SVM_READY to master.
b. If it is not the first resume, call libxl__checkpoint_devices_preresume().
c. If it is the first resume(resume right after live migration),
- call libxl__xc_domain_restore_done() to build the secondary vm.
- enable secondary vm's logdirty.
- call libxl__domain_resume() to resume secondary vm.
- call libxl__checkpoint_devices_setup() to setup checkpoint devices.
d. Send CHECKPOINT_SVM_RESUMED to master.
2. Wait a new checkpoint
a. Call libxl__checkpoint_devices_commit().
b. Read CHECKPOINT_NEW from master.
3. Suspend secondary vm
a. Suspend secondary vm.
b. Call libxl__checkpoint_devices_postsuspend().
c. Send CHECKPOINT_SVM_SUSPENDED to master.
4. Checkpoint
a. Read emulator xenstore data and emulator context
b. REC_TYPE_CHECKPOINT_END
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
tools/libxc/xc_sr_common.h |2 +
tools/libxc/xc_sr_save.c |3 +-
tools/libxl/Makefile |1 +
tools/libxl/libxl_colo.h | 55 ++
tools/libxl/libxl_colo_restore.c | 1025 ++
tools/libxl/libxl_create.c | 36 ++
tools/libxl/libxl_internal.h | 11 +-
tools/libxl/libxl_save_callout.c |6 +-
tools/libxl/libxl_stream_read.c | 12 +
tools/libxl/libxl_types.idl |1 +
10 files changed, 1143 insertions(+), 9 deletions(-)
create mode 100644 tools/libxl/libxl_colo.h
create mode 100644 tools/libxl/libxl_colo_restore.c
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 5d9f497..2bfed64 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -184,10 +184,12 @@ struct xc_sr_context
* migration stream
* 0: Plain VM
* 1: Remus
+ * 2: COLO
*/
enum {
MIG_STREAM_NONE, /* plain stream */
MIG_STREAM_REMUS,
+MIG_STREAM_COLO,
} migration_stream;
union /* Common save or restore data. */
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index fe210cc..7393355 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -846,7 +846,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t
dom,
/* If altering migration_stream update this assert too. */
assert(checkpointed_stream == MIG_STREAM_NONE ||
- checkpointed_stream == MIG_STREAM_REMUS);
+ checkpointed_stream == MIG_STREAM_REMUS ||
+ checkpointed_stream == MIG_STREAM_COLO);
/*
* TODO: Find some time to better tweak the live migration algorithm.
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 789a12e..d8612eb 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -65,6 +65,7 @@ LIBXL_OBJS-y += libxl_no_convert_callout.o
endif
LIBXL_OBJS-y += libxl_remus.o libxl_checkpoint_device.o libxl_remus_disk_drbd.o
+LIBXL_OBJS-y += libxl_colo_restore.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
new file mode 100644
index 000..f2b98cc
--- /dev/null
+++ b/tools/libxl/libxl_colo.h
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2016 FUJITSU LIMITED
+ * Author: Wen Congyang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#ifndef LIBXL_COLO_H
+#define LIBXL_COLO_H
+
+struct libxl__ao;
+struct libxl__egc;
+
+enum {
+LIBXL_COLO_SETUPED,
+LIBXL_COLO_SUSPENDED,
+LIBXL_COLO_RESUMED,
+};
+
+typedef struct libxl__domain_create_state libxl__domain_create_state;
+typedef void libxl__domain_create_cb(struct libxl__egc *egc,
+ libxl__domain_create_state *dcs,
+ int rc, uint32_t domid);
+
+typedef struct libxl__colo_restore_state libxl__colo_restore_state;
+typedef void libxl__colo_callback(struct libxl__egc *egc,
+ libxl__colo_restore_state *crs, int rc);
+
+struct libxl__colo_restore_state {
+/* must set by caller of libxl__colo_(setup|teardown) */
+struct libxl__ao *ao;
+uint32_t domid;
+int send_back_fd;
+int recv_fd;
+int hvm;
+libxl__colo_callback *callback;
+
+/* private, colo restore checkpoint state */
+li
[Xen-devel] [PATCH v11 06/27] docs: add colo readme
From: Wen Congyang add colo readme, refer to http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang Signed-off-by: Changlong Xie Acked-by: Ian Campbell Acked-by: Wei Liu --- docs/README.colo | 9 + 1 file changed, 9 insertions(+) create mode 100644 docs/README.colo diff --git a/docs/README.colo b/docs/README.colo new file mode 100644 index 000..466eb72 --- /dev/null +++ b/docs/README.colo @@ -0,0 +1,9 @@ +COLO FT/HA (COarse-grain LOck-stepping Virtual Machines for Non-stop Service) +project is a high availability solution. Both primary VM (PVM) and secondary VM +(SVM) run in parallel. They receive the same request from client, and generate +response in parallel too. If the response packets from PVM and SVM are +identical, they are released immediately. Otherwise, a VM checkpoint (on demand) +is conducted. + +See the website at http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping +for details. -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 22/27] COLO proxy: implement setup/teardown of COLO proxy module
From: Wen Congyang
setup/teardown of COLO proxy module.
we use netlink to communicate with proxy module.
About colo-proxy module:
https://lkml.org/lkml/2015/6/18/32
How to use:
http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/Makefile | 1 +
tools/libxl/libxl_colo.h | 27 +
tools/libxl/libxl_colo_proxy.c | 218 +
tools/libxl/libxl_internal.h | 3 +
4 files changed, 249 insertions(+)
create mode 100644 tools/libxl/libxl_colo_proxy.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 28d54d0..6fea9e0 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -67,6 +67,7 @@ endif
LIBXL_OBJS-y += libxl_remus.o libxl_checkpoint_device.o libxl_remus_disk_drbd.o
LIBXL_OBJS-y += libxl_colo_restore.o libxl_colo_save.o
LIBXL_OBJS-y += libxl_colo_qdisk.o
+LIBXL_OBJS-y += libxl_colo_proxy.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index 90345f4..9e7f99c 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -16,21 +16,42 @@
#ifndef LIBXL_COLO_H
#define LIBXL_COLO_H
+#include
+
struct libxl__ao;
struct libxl__egc;
struct libxl__colo_save_state;
struct libxl__checkpoint_devices_state;
+#define NETLINK_COLO 28
+
enum {
LIBXL_COLO_SETUPED,
LIBXL_COLO_SUSPENDED,
LIBXL_COLO_RESUMED,
};
+enum colo_netlink_op {
+COLO_QUERY_CHECKPOINT = (NLMSG_MIN_TYPE + 1),
+COLO_CHECKPOINT,
+COLO_FAILOVER,
+COLO_PROXY_INIT,
+COLO_PROXY_RESET, /* UNUSED, will be used for continuous FT */
+};
+
typedef struct libxl__colo_qdisk {
bool setuped;
} libxl__colo_qdisk;
+typedef struct libxl__colo_proxy_state libxl__colo_proxy_state;
+struct libxl__colo_proxy_state {
+/* set by caller of colo_proxy_setup */
+struct libxl__ao *ao;
+
+int sock_fd;
+int index;
+};
+
typedef struct libxl__domain_create_state libxl__domain_create_state;
typedef void libxl__domain_create_cb(struct libxl__egc *egc,
libxl__domain_create_state *dcs,
@@ -58,6 +79,9 @@ struct libxl__colo_restore_state {
bool qdisk_setuped;
const char *host;
const char *port;
+
+/* private, used by colo-proxy */
+libxl__colo_proxy_state cps;
};
int init_subkind_qdisk(struct libxl__checkpoint_devices_state *cds);
@@ -73,4 +97,7 @@ extern void libxl__colo_save_setup(struct libxl__egc *egc,
extern void libxl__colo_save_teardown(struct libxl__egc *egc,
struct libxl__colo_save_state *css,
int rc);
+extern int colo_proxy_setup(libxl__colo_proxy_state *cps);
+extern void colo_proxy_teardown(libxl__colo_proxy_state *cps);
+
#endif
diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
new file mode 100644
index 000..2b3baa3
--- /dev/null
+++ b/tools/libxl/libxl_colo_proxy.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright (C) 2015 FUJITSU LIMITED
+ * Author: Yang Hongyang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/* = colo-proxy: helper functions == */
+
+static int colo_proxy_send(libxl__colo_proxy_state *cps, uint8_t *buff,
+ uint64_t size, int type)
+{
+struct sockaddr_nl sa;
+struct nlmsghdr msg;
+struct iovec iov;
+struct msghdr mh;
+int ret;
+
+STATE_AO_GC(cps->ao);
+
+memset(&sa, 0, sizeof(sa));
+sa.nl_family = AF_NETLINK;
+sa.nl_pid = 0;
+sa.nl_groups = 0;
+
+msg.nlmsg_len = NLMSG_SPACE(0);
+msg.nlmsg_flags = NLM_F_REQUEST;
+if (type == COLO_PROXY_INIT) {
+msg.nlmsg_flags |= NLM_F_ACK;
+}
+msg.nlmsg_seq = 0;
+/* This is untrusty */
+msg.nlmsg_pid = cps->index;
+msg.nlmsg_type = type;
+
+iov.iov_base = &msg;
+iov.iov_len = msg.nlmsg_len;
+
+mh.msg_name = &sa;
+mh.msg_namelen = sizeof(sa);
+mh.msg_iov = &iov;
+mh.msg_iovlen = 1;
+mh.msg_control = NULL;
+mh.msg_controllen = 0;
+mh.msg_flags = 0;
+
+ret = sendmsg(cps->sock_fd, &mh, 0);
+if (ret <= 0) {
+LOG(ERROR, "can't send msg to kernel by netlink: %s",
+
[Xen-devel] [PATCH v11 17/27] libxc/save: support COLO save
From: Wen Congyang
After suspend primary vm, get dirty bitmap on secondary vm,
and send pages both dirty on primary/secondary to secondary.
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
CC: Andrew Cooper
---
tools/libxc/xc_sr_common.h | 2 +
tools/libxc/xc_sr_save.c | 95 +-
2 files changed, 95 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_sr_common.h b/tools/libxc/xc_sr_common.h
index 29ab4eb..5301746 100644
--- a/tools/libxc/xc_sr_common.h
+++ b/tools/libxc/xc_sr_common.h
@@ -196,6 +196,8 @@ struct xc_sr_context
{
struct /* Save data. */
{
+int recv_fd;
+
struct xc_sr_save_ops ops;
struct save_callbacks *callbacks;
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index 7393355..c2d30bc 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -517,6 +517,58 @@ static int send_memory_live(struct xc_sr_context *ctx)
return rc;
}
+static int merge_secondary_dirty_bitmap(struct xc_sr_context *ctx)
+{
+xc_interface *xch = ctx->xch;
+struct xc_sr_record rec;
+uint64_t *pfns = NULL;
+uint64_t pfn;
+unsigned count, i;
+int rc;
+DECLARE_HYPERCALL_BUFFER_SHADOW(unsigned long, dirty_bitmap,
+&ctx->save.dirty_bitmap_hbuf);
+
+rc = read_record(ctx, ctx->save.recv_fd, &rec);
+if ( rc )
+goto err;
+
+if ( rec.type != REC_TYPE_CHECKPOINT_DIRTY_PFN_LIST )
+{
+PERROR("Expect dirty bitmap record, but received %u", rec.type );
+rc = -1;
+goto err;
+}
+
+if ( rec.length % sizeof(*pfns) )
+{
+PERROR("Invalid dirty pfn list record length %u", rec.length );
+rc = -1;
+goto err;
+}
+
+count = rec.length / sizeof(*pfns);
+pfns = rec.data;
+
+for ( i = 0; i < count; i++ )
+{
+pfn = pfns[i];
+if (pfn > ctx->save.p2m_size)
+{
+PERROR("Invalid pfn %#lx", pfn );
+rc = -1;
+goto err;
+}
+
+set_bit(pfn, dirty_bitmap);
+}
+
+rc = 0;
+
+ err:
+free(rec.data);
+return rc;
+}
+
/*
* Suspend the domain and send dirty memory.
* This is the last iteration of the live migration and the
@@ -558,6 +610,16 @@ static int suspend_and_send_dirty(struct xc_sr_context
*ctx)
bitmap_or(dirty_bitmap, ctx->save.deferred_pages, ctx->save.p2m_size);
+if ( !ctx->save.live && ctx->save.checkpointed == MIG_STREAM_COLO )
+{
+rc = merge_secondary_dirty_bitmap(ctx);
+if ( rc )
+{
+PERROR("Failed to get secondary vm's dirty pages");
+goto out;
+}
+}
+
rc = send_dirty_pages(ctx, stats.dirty_count +
ctx->save.nr_deferred_pages);
if ( rc )
goto out;
@@ -791,13 +853,39 @@ static int save(struct xc_sr_context *ctx, uint16_t
guest_type)
if ( rc )
goto err;
+if ( ctx->save.checkpointed == MIG_STREAM_COLO )
+{
+rc =
ctx->save.callbacks->checkpoint(ctx->save.callbacks->data);
+if ( !rc )
+{
+rc = -1;
+goto err;
+}
+}
+
rc = ctx->save.callbacks->postcopy(ctx->save.callbacks->data);
if ( rc <= 0 )
goto err;
-rc = ctx->save.callbacks->checkpoint(ctx->save.callbacks->data);
-if ( rc <= 0 )
+if ( ctx->save.checkpointed == MIG_STREAM_COLO )
+{
+rc = ctx->save.callbacks->wait_checkpoint(
+ctx->save.callbacks->data);
+if ( rc <= 0 )
+goto err;
+}
+else if ( ctx->save.checkpointed == MIG_STREAM_REMUS )
+{
+rc =
ctx->save.callbacks->checkpoint(ctx->save.callbacks->data);
+if ( rc <= 0 )
+goto err;
+}
+else
+{
+ERROR("Unknown checkpointed stream");
+rc = -1;
goto err;
+}
}
} while ( ctx->save.checkpointed != MIG_STREAM_NONE );
@@ -843,6 +931,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t
dom,
ctx.save.live = !!(flags & XCFLAGS_LIVE);
ctx.save.debug = !!(flags & XCFLAGS_DEBUG);
ctx.save.checkpointed = checkpointed_stream;
+ctx.save.recv_fd = recv_fd;
/* If altering migration_stream update this assert too. */
assert(checkpointed_stream == MIG_STREAM_NONE ||
@@ -863,6 +952,8 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t
dom,
assert(callbacks->switch_qemu_logdirty);
if ( ctx.save.checkpointed )
assert(callbacks->checkpoint && callbacks->postcopy);
+if ( ctx.save.checkpointed == MIG_STREAM_COLO )
+as
[Xen-devel] [PATCH v11 23/27] COLO proxy: preresume, postresume and checkpoint
From: Wen Congyang
preresume, postresume and checkpoint
Signed-off-by: Yang Hongyang
Signed-off-by: Wen Congyang
Signed-off-by: Changlong Xie
---
tools/libxl/libxl_colo.h | 4 +++
tools/libxl/libxl_colo_proxy.c | 62 ++
2 files changed, 66 insertions(+)
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index 9e7f99c..736927e 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -99,5 +99,9 @@ extern void libxl__colo_save_teardown(struct libxl__egc *egc,
int rc);
extern int colo_proxy_setup(libxl__colo_proxy_state *cps);
extern void colo_proxy_teardown(libxl__colo_proxy_state *cps);
+extern void colo_proxy_preresume(libxl__colo_proxy_state *cps);
+extern void colo_proxy_postresume(libxl__colo_proxy_state *cps);
+extern int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
+ unsigned int timeout_us);
#endif
diff --git a/tools/libxl/libxl_colo_proxy.c b/tools/libxl/libxl_colo_proxy.c
index 2b3baa3..1b1dd40 100644
--- a/tools/libxl/libxl_colo_proxy.c
+++ b/tools/libxl/libxl_colo_proxy.c
@@ -216,3 +216,65 @@ void colo_proxy_teardown(libxl__colo_proxy_state *cps)
cps->sock_fd = -1;
}
}
+
+/* = colo-proxy: preresume, postresume and checkpoint == */
+
+void colo_proxy_preresume(libxl__colo_proxy_state *cps)
+{
+colo_proxy_send(cps, NULL, 0, COLO_CHECKPOINT);
+/* TODO: need to handle if the call fails... */
+}
+
+void colo_proxy_postresume(libxl__colo_proxy_state *cps)
+{
+/* nothing to do... */
+}
+
+typedef struct colo_msg {
+bool is_checkpoint;
+} colo_msg;
+
+/*
+ * Return value:
+ * -1: error
+ * 0: no checkpoint event is received before timeout
+ * 1: do checkpoint
+ */
+int colo_proxy_checkpoint(libxl__colo_proxy_state *cps,
+ unsigned int timeout_us)
+{
+uint8_t *buff;
+int64_t size;
+struct nlmsghdr *h;
+struct colo_msg *m;
+int ret = -1;
+
+STATE_AO_GC(cps->ao);
+
+size = colo_proxy_recv(cps, &buff, timeout_us);
+
+/* timeout, return no checkpoint message. */
+if (size <= 0) {
+return 0;
+}
+
+h = (struct nlmsghdr *) buff;
+
+if (h->nlmsg_type == NLMSG_ERROR) {
+LOG(ERROR, "receive NLMSG_ERROR");
+goto out;
+}
+
+if (h->nlmsg_len < NLMSG_LENGTH(sizeof(*m))) {
+LOG(ERROR, "NLMSG_LENGTH is too short");
+goto out;
+}
+
+m = NLMSG_DATA(h);
+
+ret = m->is_checkpoint ? 1 : 0;
+
+out:
+free(buff);
+return ret;
+}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v11 07/27] docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo streams
From: Wen Congyang
It is the negotiation record for COLO.
Primary->Secondary:
control_id 0x: Secondary VM is out of sync, start a new checkpoint
Secondary->Primary:
0x0001: Secondary VM is suspended
0x0002: Secondary VM is ready
0x0003: Secondary VM is resumed
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
docs/specs/libxl-migration-stream.pandoc | 31 +--
tools/libxl/libxl_sr_stream_format.h | 11 +++
tools/python/xen/migration/libxl.py | 9 +
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/docs/specs/libxl-migration-stream.pandoc
b/docs/specs/libxl-migration-stream.pandoc
index 2c97d86..5d577ac 100644
--- a/docs/specs/libxl-migration-stream.pandoc
+++ b/docs/specs/libxl-migration-stream.pandoc
@@ -1,6 +1,8 @@
% LibXenLight Domain Image Format
% Andrew Cooper <>
-% Revision 1
+ Wen Congyang <>
+ Yang Hongyang <>
+% Revision 2
Introduction
@@ -119,7 +121,9 @@ type 0x: END
0x0004: CHECKPOINT_END
- 0x0005 - 0x7FFF: Reserved for future _mandatory_
+ 0x0005: CHECKPOINT_STATE
+
+ 0x0006 - 0x7FFF: Reserved for future _mandatory_
records.
0x8000 - 0x: Reserved for future _optional_
@@ -249,6 +253,29 @@ A checkpoint end record marks the end of a checkpoint in
the image.
The end record contains no fields; its body_length is 0.
+CHECKPOINT\_STATE
+--
+
+A checkpoint state record contains the control information for checkpoint.
+
+ 0 1 2 3 4 5 6 7 octet
++++
+| control_id | padding|
++++
+
+
+FieldDescription
+ ---
+control_id 0x: Secondary VM is out of sync, start a new
checkpoint
+ (Primary -> Secondary)
+
+ 0x0001: Secondary VM is suspended (Secondary -> Primary)
+
+ 0x0002: Secondary VM is ready (Secondary -> Primary)
+
+ 0x0003: Secondary VM is resumed (Secondary -> Primary)
+
+
Future Extensions
=
diff --git a/tools/libxl/libxl_sr_stream_format.h
b/tools/libxl/libxl_sr_stream_format.h
index 54da360..75f5190 100644
--- a/tools/libxl/libxl_sr_stream_format.h
+++ b/tools/libxl/libxl_sr_stream_format.h
@@ -36,6 +36,7 @@ typedef struct libxl__sr_rec_hdr
#define REC_TYPE_EMULATOR_XENSTORE_DATA 0x0002U
#define REC_TYPE_EMULATOR_CONTEXT 0x0003U
#define REC_TYPE_CHECKPOINT_END 0x0004U
+#define REC_TYPE_CHECKPOINT_STATE 0x0005U
typedef struct libxl__sr_emulator_hdr
{
@@ -47,6 +48,16 @@ typedef struct libxl__sr_emulator_hdr
#define EMULATOR_QEMU_TRADITIONAL0x0001U
#define EMULATOR_QEMU_UPSTREAM 0x0002U
+typedef struct libxl_sr_checkpoint_state
+{
+uint32_t id;
+} libxl_sr_checkpoint_state;
+
+#define CHECKPOINT_NEW 0xU
+#define CHECKPOINT_SVM_SUSPENDED 0x0001U
+#define CHECKPOINT_SVM_READY 0x0002U
+#define CHECKPOINT_SVM_RESUMED 0x0003U
+
#endif /* LIBXL__SR_STREAM_FORMAT_H */
/*
diff --git a/tools/python/xen/migration/libxl.py
b/tools/python/xen/migration/libxl.py
index fc0acf6..d5f54dc 100644
--- a/tools/python/xen/migration/libxl.py
+++ b/tools/python/xen/migration/libxl.py
@@ -37,6 +37,7 @@ REC_TYPE_libxc_context = 0x0001
REC_TYPE_emulator_xenstore_data = 0x0002
REC_TYPE_emulator_context = 0x0003
REC_TYPE_checkpoint_end = 0x0004
+REC_TYPE_checkpoint_state = 0x0005
rec_type_to_str = {
REC_TYPE_end: "End",
@@ -44,6 +45,7 @@ rec_type_to_str = {
REC_TYPE_emulator_xenstore_data : "Emulator xenstore data",
REC_TYPE_emulator_context : "Emulator context",
REC_TYPE_checkpoint_end : "Checkpoint end",
+REC_TYPE_checkpoint_state : "Checkpoint state"
}
# emulator_* header
@@ -212,6 +214,11 @@ class VerifyLibxl(VerifyBase):
if len(content) != 0:
raise RecordError("Checkpoint end record with non-zero length")
+def verify_record_checkpoint_state(self, content):
+""" Checkpoint state """
+if len(content) == 0:
+raise RecordError("Checkpoint state record with zero length")
+
record_verifiers = {
REC_TYPE_end:
@@ -224,4 +231,6 @@ record_verifiers = {
VerifyLibxl.verify_record_emulator_context,
REC_TYPE_checkpoint_end:
VerifyLibxl.verify_record_checkpoint_end,
+
[Xen-devel] [PATCH v11 21/27] COLO: use qemu block replication
From: Wen Congyang
Use qemu block replication as our block replication solution.
Note that guest must be paused before starting COLO, otherwise,
the disk won't be consistent between primary and secondary.
Signed-off-by: Wen Congyang
Signed-off-by: Yang Hongyang
Signed-off-by: Changlong Xie
---
tools/libxl/Makefile | 1 +
tools/libxl/libxl_colo.h | 15 +++
tools/libxl/libxl_colo_qdisk.c | 222 +++
tools/libxl/libxl_colo_restore.c | 42 +++-
tools/libxl/libxl_colo_save.c| 54 +-
tools/libxl/libxl_internal.h | 5 +
6 files changed, 334 insertions(+), 5 deletions(-)
create mode 100644 tools/libxl/libxl_colo_qdisk.c
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 2016393..28d54d0 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -66,6 +66,7 @@ endif
LIBXL_OBJS-y += libxl_remus.o libxl_checkpoint_device.o libxl_remus_disk_drbd.o
LIBXL_OBJS-y += libxl_colo_restore.o libxl_colo_save.o
+LIBXL_OBJS-y += libxl_colo_qdisk.o
LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
diff --git a/tools/libxl/libxl_colo.h b/tools/libxl/libxl_colo.h
index feec7f1..90345f4 100644
--- a/tools/libxl/libxl_colo.h
+++ b/tools/libxl/libxl_colo.h
@@ -19,6 +19,7 @@
struct libxl__ao;
struct libxl__egc;
struct libxl__colo_save_state;
+struct libxl__checkpoint_devices_state;
enum {
LIBXL_COLO_SETUPED,
@@ -26,6 +27,10 @@ enum {
LIBXL_COLO_RESUMED,
};
+typedef struct libxl__colo_qdisk {
+bool setuped;
+} libxl__colo_qdisk;
+
typedef struct libxl__domain_create_state libxl__domain_create_state;
typedef void libxl__domain_create_cb(struct libxl__egc *egc,
libxl__domain_create_state *dcs,
@@ -47,8 +52,18 @@ struct libxl__colo_restore_state {
/* private, colo restore checkpoint state */
libxl__domain_create_cb *saved_cb;
void *crcs;
+
+/* private, used by qdisk block replication */
+bool qdisk_used;
+bool qdisk_setuped;
+const char *host;
+const char *port;
};
+int init_subkind_qdisk(struct libxl__checkpoint_devices_state *cds);
+
+void cleanup_subkind_qdisk(struct libxl__checkpoint_devices_state *cds);
+
extern void libxl__colo_restore_setup(struct libxl__egc *egc,
libxl__colo_restore_state *crs);
extern void libxl__colo_restore_teardown(struct libxl__egc *egc, void
*dcs_void,
diff --git a/tools/libxl/libxl_colo_qdisk.c b/tools/libxl/libxl_colo_qdisk.c
new file mode 100644
index 000..7af7ac1
--- /dev/null
+++ b/tools/libxl/libxl_colo_qdisk.c
@@ -0,0 +1,222 @@
+/*
+ * Copyright (C) 2015 FUJITSU LIMITED
+ * Author: Wen Congyang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h" /* must come before any other headers */
+
+#include "libxl_internal.h"
+
+/* == init() and cleanup() == */
+int init_subkind_qdisk(libxl__checkpoint_devices_state *cds)
+{
+/*
+ * We don't know if we use qemu block replication, so
+ * we cannot start block replication here.
+ */
+return 0;
+}
+
+void cleanup_subkind_qdisk(libxl__checkpoint_devices_state *cds)
+{
+}
+
+/* == setup() and teardown() == */
+static void colo_qdisk_setup(libxl__egc *egc, libxl__checkpoint_device *dev,
+ bool primary)
+{
+const libxl_device_disk *disk = dev->backend_dev;
+int ret, rc = 0;
+libxl__colo_qdisk *colo_qdisk = NULL;
+
+/* Convenience aliases */
+libxl__checkpoint_devices_state *const cds = dev->cds;
+const char *host = disk->colo_host;
+const char *port = disk->colo_port;
+const char *export_name = disk->colo_export;
+const int domid = cds->domid;
+
+STATE_AO_GC(dev->cds->ao);
+
+if (disk->backend != LIBXL_DISK_BACKEND_QDISK ||
+!libxl_defbool_val(disk->colo_enable)) {
+rc = ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH;
+goto out;
+}
+
+dev->matched = true;
+
+GCNEW(colo_qdisk);
+dev->concrete_data = colo_qdisk;
+
+if (primary) {
+libxl__colo_save_state *css = cds->concrete_data;
+
+css->qdisk_used = true;
+/* NBD server is not ready, so we cannot start block replication now */
+goto out;
+} else {
+libxl__colo_restore_state *crs = cds->concrete_data;
+
+if (!crs->qdisk_used) {
+/* start
Re: [Xen-devel] Prototype Code Review Dashboards (input required)
>>> On 03.03.16 at 19:55, wrote: >> On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote: >> On 01/03/16 18:04, Lars Kurth wrote: >>> Q2: What is the scope? Do the number count >>> - the # files someone reviewed >>> - the # patches someone reviewed >>> - the # series someone reviewed >> >> The number counts the number of reviews accomplished by a developer or by a > domain. A review is accomplished when the flag 'reviewed-by' is detected in a > email replying a patch. >> >> If a developer reviews several patches or several versions of the same > patch, each of those is counted as a different review. > > So this is basically the number of reviewed by flags aggregated per > developer. > >>> If a reviewer is solely defined by the reviewed-by tags, the data does not >>> provide a correct picture. >> This is how this works so far. >> >>> It may be better to use the following definition (although, others may >>> disagree) >>> A reviewer is someone who did one of the following for a patch or series: >>> - Added a reviewed-by flag >>> - Added an acked-by flag (maintainers tend to use acked-by) >>> - Made a comment, but is NOT the author >> >> We can update that definition. Do we want to have extra discussion with this >> respect? > > I think that would be more correct. In particular, as we still will be able > @Jan, what is your view? This use-case was primarily created because of Two of your reply sentences seem to be missing their tails, so it's really hard for me to tell my view, as it's not really clear what you're asking for. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable-smoke test] 85295: regressions - FAIL
flight 85295 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/85295/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 03720ea541382a3ca80eaaec2aa11932b03aacaf baseline version: xen 7ba900efe5f526c941b1ca055e5347947bb7eb4b Last test of basis85080 2016-03-02 16:00:54 Z1 days Testing same since85178 2016-03-03 09:20:13 Z0 days 11 attempts People who touched revisions under test: Andrew Cooper Aravind Gopalakrishnan Boris Ostrovsky Dario Faggioli Hanjun Guo Jan Beulich Juergen Gross Naresh Bhat Parth Dixit Shannon Zhao Shannon Zhao Stefano Stabellini Tomasz Nowicki jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 323 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Prototype Code Review Dashboards (input required)
> On 4 Mar 2016, at 08:42, Jan Beulich wrote: > On 03.03.16 at 19:55, wrote: >>> On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote: >>> On 01/03/16 18:04, Lars Kurth wrote: Q2: What is the scope? Do the number count - the # files someone reviewed - the # patches someone reviewed - the # series someone reviewed >>> >>> The number counts the number of reviews accomplished by a developer or by a >> domain. A review is accomplished when the flag 'reviewed-by' is detected in >> a >> email replying a patch. >>> >>> If a developer reviews several patches or several versions of the same >> patch, each of those is counted as a different review. >> >> So this is basically the number of reviewed by flags aggregated per >> developer. >> If a reviewer is solely defined by the reviewed-by tags, the data does not provide a correct picture. >>> This is how this works so far. >>> It may be better to use the following definition (although, others may disagree) A reviewer is someone who did one of the following for a patch or series: - Added a reviewed-by flag - Added an acked-by flag (maintainers tend to use acked-by) - Made a comment, but is NOT the author >>> >>> We can update that definition. Do we want to have extra discussion with >>> this respect? >> >> I think that would be more correct. In particular, as we still will be able >> @Jan, what is your view? This use-case was primarily created because of > Two of your reply sentences seem to be missing their tails, so it's > really hard for me to tell my view, as it's not really clear what > you're asking for. Apologies I think that would be more correct. In particular, as we still will be able to get the reviewed-by and acked-by flags from the tools we already have (and they are also covered in graphs). They represent an outcome, but not really the effort that is spent on reviews. And the comments as used in the other panels, do not differentiate between people reviewing and responding to reviews. @Jan, the use-case to measure real review contributions was primarily added on your request. Do you think the proposed definition above, is good enough? Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Prototype Code Review Dashboards (input required)
>>> On 04.03.16 at 10:05, wrote: >> On 4 Mar 2016, at 08:42, Jan Beulich wrote: > On 03.03.16 at 19:55, wrote: On 2 Mar 2016, at 22:45, Daniel Izquierdo wrote: On 01/03/16 18:04, Lars Kurth wrote: > It may be better to use the following definition (although, others may > disagree) > A reviewer is someone who did one of the following for a patch or series: > - Added a reviewed-by flag > - Added an acked-by flag (maintainers tend to use acked-by) > - Made a comment, but is NOT the author We can update that definition. Do we want to have extra discussion with this respect? >>> >>> I think that would be more correct. In particular, as we still will be able >>> @Jan, what is your view? This use-case was primarily created because of > > >> Two of your reply sentences seem to be missing their tails, so it's >> really hard for me to tell my view, as it's not really clear what >> you're asking for. > > Apologies > > I think that would be more correct. In particular, as we still will be able > to get the reviewed-by and acked-by flags from the tools we already have (and > they are also covered in graphs). They represent an outcome, but not really > the effort that is spent on reviews. And the comments as used in the other > panels, do not differentiate between people reviewing and responding to > reviews. > > @Jan, the use-case to measure real review contributions was primarily added > on your request. Do you think the proposed definition above, is good enough? Yes, the last bullet point should be what mostly addresses my original concern. Some differentiation between Acked-by and Reviewed-by may also help - remember that in the case of maintainers we generally mean the latter to imply the former, and that in the case of non-maintainers the former doesn't really mean much. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one
>>> On 04.03.16 at 03:45, wrote: > On March 04, 2016 7:59am, wrote: >> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote: >> > @@ -788,10 +787,10 @@ static bool_t __init >> > set_iommu_interrupt_handler(struct amd_iommu *iommu) >> > return 0; >> > } >> > >> > -spin_lock_irqsave(&pcidevs_lock, flags); >> > +pcidevs_lock(); >> > >> So, spin_lock_irqsave() does: >> local_irq_save() >> local_save_flags() >> local_irq_disable() >> _spin_lock() >> >> i.e., it saves the flags and disable interrupts. >> >> pcidevs_lock() does: >> spin_lock_recursive() >> ... //handle recursion >> _spin_lock() >> >> i.e., it does not disable interrupts. >> >> And therefore it is possible that we are actually skipping disabling > interrupts (if >> they're not disabled already), isn't it? >> >> And, of course, the same reasoning --mutatis mutandis-- applies to the unlock >> side of things. >> >> > iommu->msi.dev = pci_get_pdev(iommu->seg, PCI_BUS(iommu->bdf), >> >PCI_DEVFN2(iommu->bdf)); >> > -spin_unlock_irqrestore(&pcidevs_lock, flags); >> > +pcidevs_unlock(); >> > >> i.e., spin_unlock_irqrestore() restore the flags, including the interrupt >> enabled/disabled status, which means it can re-enable the interrupts or not, >> depending on whether they were enabled at the time of the previous >> spin_lock_irqsave(); pcidevs_unlock() just don't affect interrupt >> enabling/disabling at all. >> >> So, if the original code is correct in using >> spin_lock_irqsave()/spin_unlock_irqrestore(), I think that we need >> _irqsave() and _irqrestore() variants of recursive spinlocks, in order to >> deal with >> this case. >> >> However, from a quick inspection, it looks to me that: >> - this can only be called (during initialization), with interrupt >>enabled, so least saving & restoring flags shouldn't be necessary >>(unless I missed where they can be disabled in the call chain >>from iommu_setup() toward set_iommu_interrupt_handler()). >> - This protects pci_get_dev(); looking at other places where >>pci_get_dev() is called, I don't think it is really necessary to >>disable interrupts. >> >> If I'm right, it means that the original code could well have been using > just plain >> spin_lock() and spin_unlock(), and it would then be fine to turn them into >> pcidevs_lock() and pcidevs_unlock(), and so no need to add more >> spin_[un]lock_recursive() variants. >> >> That would also mean that the patch is indeed ok, > > Yes, I fully agree your analysis and conclusion. > I tried to implement _irqsave() and _irqrestore() variants of recursive > spinlocks, but I found that it is no need to add them. > > Also I'd highlight the below modification: > -if ( !spin_trylock(&pcidevs_lock) ) > -return -ERESTART; > - > +pcidevs_lock(); > > IMO, it is right too. Well, I'll have to see where exactly this is (pulling such out of context is pretty unhelpful), but I suspect it can't be replaced like this. >> but I'd add a mention of this in the changelog. > > In git log? To be honest, changes like this would better not be buried in a big rework like the one here. Make it a prereq patch, where you then will kind of automatically describe why it's correct. (I agree current code is bogus, and we're not hitting the respective BUG_ON() in check_lock() only because spin_debug gets set to true only after most __init code has run.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 4/5] VT-d: Reduce spin timeout to 1ms, which can be boot-time changed
>>> On 04.03.16 at 01:11, wrote:
> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote:
>> @@ -167,10 +176,12 @@ static int queue_invalidate_wait(struct iommu
>> *iommu,
>> start_time = NOW();
>> while ( poll_slot != QINVAL_STAT_DONE )
>> {
>> -if ( NOW() > (start_time + DMAR_OPERATION_TIMEOUT) )
>> +if ( NOW() > (start_time + IOMMU_QI_TIMEOUT) )
>>
> Since this now involves a time unit conversion, can't we:
> - instead of start_time, above, compute, once and for all:
> timeout = NOW() + IOMMU_QI_TIMEOUT;
> - check whether ( NOW() > timeout )
>
> I appreciate that the default for vtd_qi_timeout is 1, so it's most
> likely not that a big deal, but it still looks better to me.
The code might look a little neater, but it really isn't relevant from
a performance pov: We're trying to lose time here anyway.
>> {
>> print_qi_regs(iommu);
>> -panic("queue invalidate wait descriptor was not
>> executed");
>> +printk(XENLOG_WARNING VTDPREFIX
>> + "Queue invalidate wait descriptor was
>> timeout.\n");
>>
> "Queue invalidate wait descriptor timed out" ?
Indeed - Quan, I'm sure Kevin and/or I have been mentioning this
before. If not for this specific instance, then for another one, in
which case I'd like to remind you to apply review comments not
just to the single instance they're being given for.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled
On Mon, Feb 29, 2016 at 03:50:19PM -0800, Andy Lutomirski wrote: > x86_64 has very clean espfix handling on paravirt: espfix64 is set > up in native_iret, so paravirt systems that override iret bypass > espfix64 automatically. This is robust and straightforward. > > x86_32 is messier. espfix is set up before the IRET paravirt patch > point, so it can't be directly conditionalized on whether we use > native_iret. We also can't easily move it into native_iret without > regressing performance due to a bizarre consideration. Specifically, > on 64-bit kernels, the logic is: > > if (regs->ss & 0x4) > setup_espfix; > > On 32-bit kernels, the logic is: > > if ((regs->ss & 0x4) && (regs->cs & 0x3) == 3 && > (regs->flags & X86_EFLAGS_VM) == 0) > setup_espfix; > > The performance of setup_espfix itself is essentially irrelevant, but > the comparison happens on every IRET so its performance matters. On > x86_64, there's no need for any registers except flags to implement > the comparison, so we fold the whole thing into native_iret. On > x86_32, we don't do that because we need a free register to > implement the comparison efficiently. We therefore do espfix setup > before restoring registers on x86_32. > > This patch gets rid of the explicit paravirt_enabled check by > introducing X86_BUG_ESPFIX on 32-bit systems and using an ALTERNATIVE > to skip espfix on paravirt systems where iret != native_iret. This is > also messy, but it's at least in line with other things we do. > > This improves espfix performance by removing a branch, but no one > cares. More importantly, it removes a paravirt_enabled user, which is > good because paravirt_enabled is ill-defined and is going away. > > Signed-off-by: Andy Lutomirski > --- > arch/x86/entry/entry_32.S | 15 ++- > arch/x86/include/asm/cpufeatures.h | 8 > arch/x86/kernel/cpu/common.c | 25 + > 3 files changed, 35 insertions(+), 13 deletions(-) Reviewed-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/2] x86/asm-offsets: Remove PARAVIRT_enabled
On Mon, Feb 29, 2016 at 03:50:20PM -0800, Andy Lutomirski wrote:
> It no longer has any users.
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/kernel/asm-offsets.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
> index 84a7524b202c..5c042466f274 100644
> --- a/arch/x86/kernel/asm-offsets.c
> +++ b/arch/x86/kernel/asm-offsets.c
> @@ -59,7 +59,6 @@ void common(void) {
>
> #ifdef CONFIG_PARAVIRT
> BLANK();
> - OFFSET(PARAVIRT_enabled, pv_info, paravirt_enabled);
> OFFSET(PARAVIRT_PATCH_pv_cpu_ops, paravirt_patch_template, pv_cpu_ops);
> OFFSET(PARAVIRT_PATCH_pv_irq_ops, paravirt_patch_template, pv_irq_ops);
> OFFSET(PV_IRQ_irq_disable, pv_irq_ops, irq_disable);
> --
Reviewed-by: Borislav Petkov
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/6] xen, cpupool: correct error handling when removing cpu from cpupool
>>> On 03.03.16 at 17:48, wrote:
> if ( !ret )
> {
> ret = schedule_cpu_switch(cpu, NULL);
> if ( ret )
> -{
> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
> -goto out;
> +else
> +{
> +cpupool_moving_cpu = -1;
> +cpupool_put(cpupool_cpu_moving);
> +cpupool_cpu_moving = NULL;
> }
> -cpupool_moving_cpu = -1;
> -cpupool_put(cpupool_cpu_moving);
> -cpupool_cpu_moving = NULL;
> }
>
> for_each_domain_in_cpupool(d, c)
So this now also eliminates the bypass of the loop the beginning of
which we can still see here - is that really intended, or wouldn't
this better be made conditional upon !ret?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/6] xen: add hypercall option to override and restore vcpu affinity
>>> On 03.03.16 at 17:48, wrote: > Some hardware (e.g. Dell studio 1555 laptops) require SMIs to be > called on physical cpu 0 only. Linux drivers like dcdbas or i8k try > to achieve this by pinning the running thread to cpu 0, but in Dom0 > this is not enough: the vcpu must be pinned to physical cpu 0 via > Xen, too. > > Add a stable hypercall option SCHEDOP_pin_override to the sched_op > hypercall to achieve this. It is taking a physical cpu number as > parameter. If pinning is possible (the calling domain has the > privilege to make the call and the cpu is available in the domain's > cpupool) the calling vcpu is pinned to the specified cpu. The old > cpu affinity is saved. To undo the override pinning a negative cpu > value is specified. This will restore the original cpu affinity of > the vcpu. > > Cc: George Dunlap > Cc: Dario Faggioli > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Ian Jackson > Cc: David Vrabel > Cc: Stefano Stabellini > Cc: Wei Liu > > Signed-off-by: Juergen Gross Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 3/6] xen: add force flag to xen_domctl_vcpuaffinity for undoing pin override
>>> On 03.03.16 at 17:48, wrote: > Add a XEN_VCPUAFFINITY_FORCE flag to xen_domctl_vcpuaffinity structure > which will allow to undo a SCHEDOP_pin_override in case of a driver > error of the hardware domain which didn't do the expected > SCHEDOP_pin_override with cpu < 0 which would have done the undo > operation. > > Cc: Jan Beulich > Cc: Andrew Cooper > Cc: Ian Jackson > Cc: David Vrabel > Cc: Stefano Stabellini > Cc: Wei Liu > Signed-off-by: Juergen Gross Acked-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/6] xen, cpupool: correct error handling when removing cpu from cpupool
On 04/03/16 10:42, Jan Beulich wrote:
On 03.03.16 at 17:48, wrote:
>> if ( !ret )
>> {
>> ret = schedule_cpu_switch(cpu, NULL);
>> if ( ret )
>> -{
>> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
>> -goto out;
>> +else
>> +{
>> +cpupool_moving_cpu = -1;
>> +cpupool_put(cpupool_cpu_moving);
>> +cpupool_cpu_moving = NULL;
>> }
>> -cpupool_moving_cpu = -1;
>> -cpupool_put(cpupool_cpu_moving);
>> -cpupool_cpu_moving = NULL;
>> }
>>
>> for_each_domain_in_cpupool(d, c)
>
> So this now also eliminates the bypass of the loop the beginning of
> which we can still see here - is that really intended, or wouldn't
> this better be made conditional upon !ret?
Did you look at the commit message? It is explaining exactly this
behaviour.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/6] xen, cpupool: correct error handling when removing cpu from cpupool
>>> On 04.03.16 at 10:54, wrote:
> On 04/03/16 10:42, Jan Beulich wrote:
> On 03.03.16 at 17:48, wrote:
>>> if ( !ret )
>>> {
>>> ret = schedule_cpu_switch(cpu, NULL);
>>> if ( ret )
>>> -{
>>> cpumask_clear_cpu(cpu, &cpupool_free_cpus);
>>> -goto out;
>>> +else
>>> +{
>>> +cpupool_moving_cpu = -1;
>>> +cpupool_put(cpupool_cpu_moving);
>>> +cpupool_cpu_moving = NULL;
>>> }
>>> -cpupool_moving_cpu = -1;
>>> -cpupool_put(cpupool_cpu_moving);
>>> -cpupool_cpu_moving = NULL;
>>> }
>>>
>>> for_each_domain_in_cpupool(d, c)
>>
>> So this now also eliminates the bypass of the loop the beginning of
>> which we can still see here - is that really intended, or wouldn't
>> this better be made conditional upon !ret?
>
> Did you look at the commit message? It is explaining exactly this
> behaviour.
Argh - I had looked, even twice (once before writing the
comment, and once before hitting the send button), but
nevertheless managed to not connect things together.
I'm sorry.
And I think this aspect (and only it) makes this a backport
candidate.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/22] arm/acpi: Estimate memory required for acpi/efi tables
>>> On 04.03.16 at 07:15, wrote:
> From: Shannon Zhao
>
> Estimate the memory required for loading acpi/efi tables in Dom0. Make
> the length of each table aligned with 64bit. Alloc the pages to store
> the new created EFI and ACPI tables and free these pages when
> destroying domain.
>
> Cc: Jan Beulich
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
Since the pattern repeats I finally have to ask: Who is the author
of a patch with such a set of tag? You (From:) or Parth (first S-o-b)?
> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -1151,6 +1151,13 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> *SystemTable)
> for( ; ; ); /* not reached */
> }
>
> +#if defined (CONFIG_ACPI) && defined (CONFIG_ARM)
> +struct meminfo __init *get_acpi_meminfo(void)
> +{
> +return &acpi_mem;
> +}
> +#endif
No such hackery in common code please, if at all avoidable. If ARM
maintainers are fine with this in their code, it could be put into
ARM's efi-boot.h.
> --- a/xen/common/efi/efi.h
> +++ b/xen/common/efi/efi.h
> @@ -39,3 +39,7 @@ extern UINT64 efi_boot_max_var_store_size,
> efi_boot_remain_var_store_size,
>
> unsigned long efi_rs_enter(void);
> void efi_rs_leave(unsigned long);
> +
> +#ifdef CONFIG_ARM
> +struct meminfo *get_acpi_meminfo(void);
> +#endif
Similarly this should be put in an ARM specific header, which
efi-boot.h then should include (if it doesn't already).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01
create ^ thanks On Fri, Mar 04, 2016 at 03:37:10AM +, Xu, Quan wrote: > On February 16, 2016 1:08am, wrote: > > On Mon, Feb 15, 2016 at 10:45:48AM -0600, Doug Goldstein wrote: > > > On 2/15/16 10:28 AM, Wei Liu wrote: > > > > On Sun, Feb 14, 2016 at 07:39:35PM +1100, Steven Haigh wrote: > > > >> Hi all, > > > >> > > > >> Just been looking at the polarssl parts in Xen 4.6 and others - > > > >> seems like we're hard coded to version 1.1.4 which was released on 31st > > May 2012. > > > >> > > > >> Branch 1.1.x has been EOL for a number of years, 1.2.x has been EOL > > > >> since Jan. > > > >> > > > >> It's now called mbedtls and current versions are 2.2.1 released in > > > >> Jan this year. > > > >> > > > >> I'm not exactly clear on what polarssl is used for (and why not > > > >> openssl?) - but is it time this was shown some loving? > > > >> > > > > > > > > I grep'ed for polarssl in tree and the only user seems to be vtpm. > > > > I've CC'ed Daniel and Quan for you. > > > > > > > > Wei. > > > > > > > > > > Looks like pv-grub has a build dependency on it as well based on the > > > snippet from stubdom/Makefile. > > > > > > .PHONY: grub > > > grub: cross-polarssl grub-upstream $(CROSS_ROOT) > > > > > > > Oh, yes, you're right. > > > > Looking at the source code pv-grub only needs the sha1 function from > > polarssl > > which might be easy to dealt with though. On the other hand, if there is no > > critical bug fix to the sha1 function, I wouldn't bother upgrading polarssl. > > > > In fact, I think vtpm also only cares about some crypto algorithms like AES > > and > > SHA. We'd better check if there is any critical update to those functions > > before > > doing anything. > > > > > Agreed. > If you really want to upgrade it, IMO this change would be backward > compatible. > btw, it may be not an easy task to build the test env, and I can help you > test your patch. > Right. To be honest the chance of me working on it soon is rather low. To prevent this issue falling through the crack I've created an entry in bug tracker. Wei. > Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Processed: Re: Fixation on polarssl 1.1.4 - EOL was 2013-10-01
Processing commands for x...@bugs.xenproject.org: > create ^ Created new bug #52 rooted at `<945ca011ad5f084cbea3e851c0ab28894b859...@shsmsx101.ccr.corp.intel.com>' Title: `Re: [Xen-devel] Fixation on polarssl 1.1.4 - EOL was 2013-10-01' > thanks Finished processing. Modified/created Bugs: - 52: http://bugs.xenproject.org/xen/bug/52 (new) --- Xen Hypervisor Bug Tracker See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact xen-bugs-ow...@bugs.xenproject.org with any infrastructure issues ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
>>> On 04.03.16 at 07:15, wrote: > From: Shannon Zhao > > Add a new delivery type: > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI. > To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and > bit 9 stands the interrupt polarity is active low(1) or high(0). > > Cc: Jan Beulich > Signed-off-by: Shannon Zhao The set of Cc-s is too narrow - all REST maintainers should be copied. > --- a/xen/include/public/hvm/params.h > +++ b/xen/include/public/hvm/params.h > @@ -55,6 +55,16 @@ > * if this delivery method is available. > */ > > +#define HVM_PARAM_CALLBACK_TYPE_EVENT3 > +/* > + * val[55:16] need to be zero. > + * val[15:8] is flag of event-channel interrupt: > + * bit 8: interrupt is edge(1) or level(0) triggered > + * bit 9: interrupt is active low(1) or high(0) > + * val[7:0] is PPI number used by event-channel. > + * This is only used by ARM/ARM64. > + */ I think the name of the constant needs improvement. The low 8 bits make this extremely ARM specific, so perhaps HVM_PARAM_CALLBACK_TYPE_PPI? Albeit - wouldn't the vector and/or GSI ones be re-usable for this purpose? (I don't know enough about ARM to be certain.) And then I'm now also wondering about the description of bits 8 and 9 - event channels don't know of edge/level triggering or high/low polarity, so it looks to me as if the comment is at least misleading too. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping
>>> On 04.03.16 at 07:15, wrote:
> From: Shannon Zhao
>
> It needs to map platform or amba device mmio to Dom0 on ARM. But when
> booting with ACPI, it can't get the mmio region in Xen due to lack of
> AML interpreter to parse DSDT table. Therefore, let Dom0 call a
> hypercall to map mmio region when it adds the devices.
>
> Here we add a new map space like the XEN_DOMCTL_memory_mapping to map
> mmio region for Dom0.
>
> Cc: Jan Beulich
> Signed-off-by: Shannon Zhao
Same remark regarding the Cc list.
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1138,6 +1138,9 @@ int xenmem_add_to_physmap_one(
> rcu_unlock_domain(od);
> break;
> }
> +case XENMAPSPACE_dev_mmio:
> +rc = map_dev_mmio_region(d, gpfn, 1, idx);
This being the only caller, ...
> +int map_dev_mmio_region(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr,
> +unsigned long mfn)
> +{
... what's the "nr" parameter good for? Or alternatively - wouldn't
you want to make it possible to have larger areas mapped by large
pages?
> +int res;
> +
> +if(!iomem_access_permitted(d, start_gfn, start_gfn + nr))
> +return 0;
This would seem to belong into common code
Also - coding style.
> +res = map_mmio_regions(d, start_gfn, nr, mfn);
> +if ( res < 0 )
> +{
> +printk(XENLOG_ERR "Unable to map 0x%lx - 0x%lx in domain %d\n",
%#lx
> + start_gfn << PAGE_SHIFT, (start_gfn + nr) << PAGE_SHIFT,
I see no reason for the shifts.
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -980,6 +980,14 @@ long do_memory_op(unsigned long cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> if ( d == NULL )
> return -ESRCH;
>
> +/*
> + * XENMAPSPACE_dev_mmio mapping is only supported for hardware Domain
> + * to map this kind of space to itself.
> + */
> +if ( (xatp.space == XENMAPSPACE_dev_mmio) &&
> + (!is_hardware_domain(current->domain) || (d !=
> current->domain)) )
Readability would benefit if you used "d" twice and "current->domain"
just once, preferable after swapping the two sides of the ||.
Overall I wonder whether this wouldn't help PVH on x86 too,
where we currently do some hackery to (not even completely)
map MMIO into Dom0's p2m. In such a case perhaps
map_dev_mmio_regions() should become a general per-arch
function right away (declared in a common header and stubbed
out in x86 code for now). Boris, Roger?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 22/22] xen/arm64: Add ACPI support
>>> On 04.03.16 at 07:15, wrote: > From: Naresh Bhat > > Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM. > > Cc: Jan Beulich > Signed-off-by: Naresh Bhat > Signed-off-by: Shannon Zhao > --- > v5: make ACPI selectable option > --- > xen/arch/arm/Kconfig | 9 + > xen/common/efi/runtime.c | 12 +++- For the change to this file: Acked-by: Jan Beulich However ... > +++ b/xen/arch/arm/Kconfig > @@ -33,6 +33,15 @@ menu "Architecture Features" > > source "arch/Kconfig" > > +config ACPI > + bool "ACPI (Advanced Configuration and Power Interface) Support" > + depends on ARM_64 > + default y ... I recall Stefano having asked for this, but - are both of you sure? Have you seen the earlier discussion about the introduction of new user selectable config options? I.e. shouldn't the prompt at least become conditional on EXPERT = "y", just like done elsewhere? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/6] x86/HVM: cache attribute pinning adjustments
At 09:28 -0700 on 03 Mar (1456997339), Jan Beulich wrote: > 1: honor cache attribute pinning for RAM only > 2: remove unnecessary indirection from hvm_get_mem_pinned_cacheattr() > 3: adjust hvm_set_mem_pinned_cacheattr() error indications > 4: limit flushing on cache attribute pinning adjustments > 5: adjust hvm_get_mem_pinned_cacheattr() GFN parameter > 6: re-format cache attribute pinning code > > Signed-off-by: Jan Beulich All the shadow-pagetable bits: Acked-by: Tim Deegan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/timer: fix panic when booting with DT
>>> On 04.03.16 at 02:17, wrote:
> On 2016/3/3 23:44, Stefano Stabellini wrote:
>> On Thu, 3 Mar 2016, Shannon Zhao wrote:
>>> > From: Shannon Zhao
>>> >
>>> > While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
>>> > refactors the functions preinit_xen_time and init_xen_time. But it
>>> > wrongly moves the platform_get_irq from init_xen_time to
>>> > preinit_dt_xen_time and this will cause booting failure.
>>> >
>>> > So move platform_get_irq back to init_xen_time to fix it.
>>> >
>>> > Signed-off-by: Shannon Zhao
>> Shannon,
>> thank you for fixing the issue so quickly, very appreciated!
>>
>>
>>> > xen/arch/arm/time.c | 27 ---
>>> > 1 file changed, 16 insertions(+), 11 deletions(-)
>>> >
>>> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
>>> > index 5f8f974..66a4520 100644
>>> > --- a/xen/arch/arm/time.c
>>> > +++ b/xen/arch/arm/time.c
>>> > @@ -119,7 +119,6 @@ static void __init preinit_dt_xen_time(void)
>>> > };
>>> > int res;
>>> > u32 rate;
>>> > -unsigned int i;
>>> >
>>> > timer = dt_find_matching_node(NULL, timer_ids);
>>> > if ( !timer )
>>> > @@ -133,16 +132,6 @@ static void __init preinit_dt_xen_time(void)
>>> > cpu_khz = rate / 1000;
>>> > timer_dt_clock_frequency = rate;
>>> > }
>>> > -
>>> > -/* Retrieve all IRQs for the timer */
>>> > -for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
>>> > -{
>>> > -res = platform_get_irq(timer, i);
>>> > -
>>> > -if ( res < 0 )
>>> > -panic("Timer: Unable to retrieve IRQ %u from the device
>>> > tree", i);
>>> > -timer_irq[i] = res;
>>> > -}
>>> > }
>>> >
>>> > void __init preinit_xen_time(void)
>>> > @@ -168,6 +157,22 @@ void __init preinit_xen_time(void)
>>> > /* Set up the timer on the boot CPU (late init function) */
>>> > int __init init_xen_time(void)
>>> > {
>>> > +int res;
>>> > +unsigned int i;
>>> > +
>>> > +if ( acpi_disabled )
>>> > +{
>>> > +/* Retrieve all IRQs for the timer */
>>> > +for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
>>> > +{
>>> > +res = platform_get_irq(timer, i);
>>> > +
>>> > +if ( res < 0 )
>>> > +panic("Timer: Unable to retrieve IRQ %u from the device
>>> > tree", i);
>>> > +timer_irq[i] = res;
>>> > +}
>>> > +}
>> Could you please introduce a small little init_dt_xen_time function and
>> call that instead from here? Thanks!
>>
> Not sure if it's necessary since it's only used here. But if you really
> want that I'll add.
Can both of you please aim at getting to an agreement relatively
quickly, to stop the flood of smoke test failure reports? (In general,
Shannon, I would say that if you were asked by the maintainer to
do a certain transformation, there's not overly much reason to ask
back again.) Or alternatively please indicate how far back the
previous series would need to be reverted.
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm/timer: fix panic when booting with DT
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/3 23:44, Stefano Stabellini wrote:
> > On Thu, 3 Mar 2016, Shannon Zhao wrote:
> >> > From: Shannon Zhao
> >> >
> >> > While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
> >> > refactors the functions preinit_xen_time and init_xen_time. But it
> >> > wrongly moves the platform_get_irq from init_xen_time to
> >> > preinit_dt_xen_time and this will cause booting failure.
> >> >
> >> > So move platform_get_irq back to init_xen_time to fix it.
> >> >
> >> > Signed-off-by: Shannon Zhao
> > Shannon,
> > thank you for fixing the issue so quickly, very appreciated!
> >
> >
> >> > xen/arch/arm/time.c | 27 ---
> >> > 1 file changed, 16 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> >> > index 5f8f974..66a4520 100644
> >> > --- a/xen/arch/arm/time.c
> >> > +++ b/xen/arch/arm/time.c
> >> > @@ -119,7 +119,6 @@ static void __init preinit_dt_xen_time(void)
> >> > };
> >> > int res;
> >> > u32 rate;
> >> > -unsigned int i;
> >> >
> >> > timer = dt_find_matching_node(NULL, timer_ids);
> >> > if ( !timer )
> >> > @@ -133,16 +132,6 @@ static void __init preinit_dt_xen_time(void)
> >> > cpu_khz = rate / 1000;
> >> > timer_dt_clock_frequency = rate;
> >> > }
> >> > -
> >> > -/* Retrieve all IRQs for the timer */
> >> > -for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
> >> > -{
> >> > -res = platform_get_irq(timer, i);
> >> > -
> >> > -if ( res < 0 )
> >> > -panic("Timer: Unable to retrieve IRQ %u from the device
> >> > tree", i);
> >> > -timer_irq[i] = res;
> >> > -}
> >> > }
> >> >
> >> > void __init preinit_xen_time(void)
> >> > @@ -168,6 +157,22 @@ void __init preinit_xen_time(void)
> >> > /* Set up the timer on the boot CPU (late init function) */
> >> > int __init init_xen_time(void)
> >> > {
> >> > +int res;
> >> > +unsigned int i;
> >> > +
> >> > +if ( acpi_disabled )
> >> > +{
> >> > +/* Retrieve all IRQs for the timer */
> >> > +for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
> >> > +{
> >> > +res = platform_get_irq(timer, i);
> >> > +
> >> > +if ( res < 0 )
> >> > +panic("Timer: Unable to retrieve IRQ %u from the device
> >> > tree", i);
> >> > +timer_irq[i] = res;
> >> > +}
> >> > +}
> > Could you please introduce a small little init_dt_xen_time function and
> > call that instead from here? Thanks!
> >
> Not sure if it's necessary since it's only used here. But if you really
> want that I'll add.
Please do, it is not necessary in terms of fixing the issue, but it
would make things nicer.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 14/24] arm/acpi: Prepare EFI system table for Dom0
On Fri, 4 Mar 2016, Shannon Zhao wrote: > On 2016/3/1 20:49, Stefano Stabellini wrote: > > On Tue, 1 Mar 2016, Jan Beulich wrote: > > > >>> On 01.03.16 at 03:35, wrote: > >> > > >>> > > > >>> > > On 2016/2/29 22:36, Jan Beulich wrote: > >>> > > On 29.02.16 at 15:25, > >>> > > wrote: > >> > >>> > On Mon, 29 Feb 2016, Jan Beulich wrote: > > >> Also it doesn't look very nice to me to (ab)use xz's CRC32 > > >> code > > >> here; I don't know who has suggested doing so. > >> > >>> > > >> > >>> > It was suggested by Julien. > >> > >>> > > >> > >>> > I agree that including ../../../common/xz/crc32.c seems a bit > >> > >>> > fragile > >> > >>> > but introducing another copy of xz_crc32 seems even worse to > >> > >>> > me (see > >> > >>> > http://marc.info/?l=xen-devel&m=144775375427921&w=2). Maybe > >> > >>> > you have a > >> > >>> > better suggestion? > > >> Well, at some point there was talk of ARM not wanting to > > >> ExitBootServices() as early as x86 does. In that case there > > >> would be a CRC32 function among the various boot services > > >> ones. > > >> > >>> > > At this point, I think it already ExitBootServices() while it's > >>> > > creating > >>> > > Dom0. > >> > > >> > I understand that's the case today, hence my saying "at some > >> > point there was talk of ...". > >> > > > >> The other option would be to have a generic crc32() function, > > >> and maybe make xz use it. > >>> > > Ok, I'll go for this way. > >> > > >> > Well, for the avoidance of doubt: With the code moving into an > >> > ARM specific file, if Stefano is fine with the xz hack, I certainly > >> > won't insist on you adding a separate crc32(). > > Having a generic crc32() function like you suggested would be nicer than > > the xz hack. If Shannon is OK with doing that, it would be best. > Since this will introduce more changes, I want to stay with current way. OK ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 09/22] arm/p2m: Add helper functions to map memory regions
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Parth Dixit
>
> Create a helper function for mapping with cached attributes and
> read-write range.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: use p2m_access_rw and rename to map_regions_rw
Reviewed-by: Stefano Stabellini
> xen/arch/arm/p2m.c| 26 ++
> xen/include/asm-arm/p2m.h | 10 ++
> 2 files changed, 36 insertions(+)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index a2a9c4b..d206616 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -1218,6 +1218,32 @@ int p2m_populate_ram(struct domain *d,
> d->arch.p2m.default_access);
> }
>
> +int map_regions_rw(struct domain *d,
> + unsigned long start_gfn,
> + unsigned long nr,
> + unsigned long mfn)
> +{
> +return apply_p2m_changes(d, INSERT,
> + pfn_to_paddr(start_gfn),
> + pfn_to_paddr(start_gfn + nr),
> + pfn_to_paddr(mfn),
> + MATTR_MEM, 0, p2m_mmio_direct,
> + p2m_access_rw);
> +}
> +
> +int unmap_regions_rw(struct domain *d,
> + unsigned long start_gfn,
> + unsigned long nr,
> + unsigned long mfn)
> +{
> +return apply_p2m_changes(d, REMOVE,
> + pfn_to_paddr(start_gfn),
> + pfn_to_paddr(start_gfn + nr),
> + pfn_to_paddr(mfn),
> + MATTR_MEM, 0, p2m_invalid,
> + p2m_access_rw);
> +}
> +
> int map_mmio_regions(struct domain *d,
> unsigned long start_gfn,
> unsigned long nr,
> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
> index 433952a..17be6ad 100644
> --- a/xen/include/asm-arm/p2m.h
> +++ b/xen/include/asm-arm/p2m.h
> @@ -144,6 +144,16 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t
> start_mfn, xen_pfn_t end_mfn);
> /* Setup p2m RAM mapping for domain d from start-end. */
> int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
>
> +int map_regions_rw(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr_mfns,
> +unsigned long mfn);
> +
> +int unmap_regions_rw(struct domain *d,
> +unsigned long start_gfn,
> +unsigned long nr_mfns,
> +unsigned long mfn);
> +
> int guest_physmap_add_entry(struct domain *d,
> unsigned long gfn,
> unsigned long mfn,
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/22] arm/acpi: Estimate memory required for acpi/efi tables
On Fri, 4 Mar 2016, Jan Beulich wrote:
> >>> On 04.03.16 at 07:15, wrote:
> > From: Shannon Zhao
> >
> > Estimate the memory required for loading acpi/efi tables in Dom0. Make
> > the length of each table aligned with 64bit. Alloc the pages to store
> > the new created EFI and ACPI tables and free these pages when
> > destroying domain.
> >
> > Cc: Jan Beulich
> > Signed-off-by: Parth Dixit
> > Signed-off-by: Shannon Zhao
>
> Since the pattern repeats I finally have to ask: Who is the author
> of a patch with such a set of tag? You (From:) or Parth (first S-o-b)?
>
> > --- a/xen/common/efi/boot.c
> > +++ b/xen/common/efi/boot.c
> > @@ -1151,6 +1151,13 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
> > *SystemTable)
> > for( ; ; ); /* not reached */
> > }
> >
> > +#if defined (CONFIG_ACPI) && defined (CONFIG_ARM)
> > +struct meminfo __init *get_acpi_meminfo(void)
> > +{
> > +return &acpi_mem;
> > +}
> > +#endif
>
> No such hackery in common code please, if at all avoidable. If ARM
> maintainers are fine with this in their code, it could be put into
> ARM's efi-boot.h.
I am OK with that. If you move it under arch/arm, then drop the ifdef
CONFIG_ARM.
> > --- a/xen/common/efi/efi.h
> > +++ b/xen/common/efi/efi.h
> > @@ -39,3 +39,7 @@ extern UINT64 efi_boot_max_var_store_size,
> > efi_boot_remain_var_store_size,
> >
> > unsigned long efi_rs_enter(void);
> > void efi_rs_leave(unsigned long);
> > +
> > +#ifdef CONFIG_ARM
> > +struct meminfo *get_acpi_meminfo(void);
> > +#endif
>
> Similarly this should be put in an ARM specific header, which
> efi-boot.h then should include (if it doesn't already).
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
On 03/03/16 18:03, Anthony PERARD wrote: > In this series, there are plenty of places where one blob loaded by libxl > to be consume by hvmloader is called acpi_module or acpi_table... where in > fact it is only the DSDT table. I think I'm going to do some renaming to > include "dsdt" into those names. The DSDT cannot possibly come from anywhere other than hvmloader (as a logic extension of Xen). It is very hardware specific, including bits of ACPI emulated by Xen itself. There are plenty of improvements which can be made over the current status quo by splitting out the optional parts into extra SSDTs, but having the DSDT itself come from another source will cause all kinds of problems for the domain. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 02/22] arm/acpi: Add a helper function to get the acpi table offset
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> These tables are aligned with 64bit.
>
> Signed-off-by: Shannon Zhao
> ---
> v5: make the return value type and variable type consistent
> ---
> xen/arch/arm/acpi/lib.c| 15 +++
> xen/include/asm-arm/acpi.h | 6 ++
> 2 files changed, 21 insertions(+)
>
> diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> index db5c4d8..79f7edd 100644
> --- a/xen/arch/arm/acpi/lib.c
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -60,3 +60,18 @@ bool_t __init acpi_psci_hvc_present(void)
> {
> return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
> }
> +
> +paddr_t __init acpi_get_table_offset(struct membank tbl_add[],
> + EFI_MEM_RES index)
> +{
> +int i;
> +paddr_t offset = 0;
> +
> +for ( i = 0; i < index; i++ )
> +{
> +/* Aligned with 64bit (8 bytes) */
> +offset += ROUNDUP(tbl_add[i].size, 8);
> +}
> +
> +return offset;
> +}
> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> index 7f59761..6db3711 100644
> --- a/xen/include/asm-arm/acpi.h
> +++ b/xen/include/asm-arm/acpi.h
> @@ -25,6 +25,7 @@
>
> #include
> #include
> +#include
>
> #define COMPILER_DEPENDENT_INT64 long long
> #define COMPILER_DEPENDENT_UINT64 unsigned long long
> @@ -58,10 +59,15 @@ static inline void enable_acpi(void)
> {
> acpi_disabled = 0;
> }
> +
> +paddr_t acpi_get_table_offset(struct membank tbl_add[], EFI_MEM_RES index);
> #else
> #define acpi_disabled (1)
> #define disable_acpi()
> #define enable_acpi()
> +paddr_t inline acpi_get_table_offset(struct membank tbl_add[],
> + EFI_MEM_RES index)
> +{ return 0; }
Why did you move the declaration of acpi_get_table_offset to within the
ifdef? It was just above the ifdef in the previous version of the
patch.
> #endif
>
> #endif /*_ASM_ARM_ACPI_H*/
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping
On Fri, 4 Mar 2016, Jan Beulich wrote: > >>> On 04.03.16 at 07:15, wrote: > Overall I wonder whether this wouldn't help PVH on x86 too, > where we currently do some hackery to (not even completely) > map MMIO into Dom0's p2m. In such a case perhaps > map_dev_mmio_regions() should become a general per-arch > function right away (declared in a common header and stubbed > out in x86 code for now). Boris, Roger? I though that we agreed that Xen will take care of doing all the MMIO mappings for HVMlite/PVHv2 guests: http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01609.html My first idea was to use the MMIO device mapping hypercall (just like ARM) on the hardware domain, but I think we can get away without it on x86. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 11/22] arm/acpi: Prepare EFI system table for Dom0
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Prepare EFI system table for Dom0 to describe the information of UEFI.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
Reviewed-by: Stefano Stabellini
> v5: move to efi-dom0.c
> ---
> xen/arch/arm/domain_build.c | 2 ++
> xen/arch/arm/efi/efi-dom0.c | 44
> xen/include/asm-arm/setup.h | 3 +++
> 3 files changed, 49 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c71976c..613551c 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1686,6 +1686,8 @@ static int prepare_acpi(struct domain *d, struct
> kernel_info *kinfo)
> return rc;
>
> acpi_map_other_tables(d);
> +acpi_create_efi_system_table(d->arch.efi_acpi_gpa,
> d->arch.efi_acpi_table,
> + tbl_add);
>
> return 0;
> }
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index d54c38f..36a1283 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -46,3 +46,47 @@ size_t __init estimate_efi_size(int mem_nr_banks)
>
> return size;
> }
> +
> +#include "../../../common/decompress.h"
> +#define XZ_EXTERN STATIC
> +#include "../../../common/xz/crc32.c"
> +
> +void __init acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
> + struct membank tbl_add[])
> +{
> +u64 table_addr, table_size, offset = 0;
> +u8 *base_ptr;
> +EFI_CONFIGURATION_TABLE *efi_conf_tbl;
> +EFI_SYSTEM_TABLE *efi_sys_tbl;
> +
> +table_addr = paddr + acpi_get_table_offset(tbl_add, TBL_EFIT);
> +table_size = sizeof(EFI_SYSTEM_TABLE) + sizeof(EFI_CONFIGURATION_TABLE)
> + + sizeof(xen_efi_fw_vendor);
> +base_ptr = efi_acpi_table + acpi_get_table_offset(tbl_add, TBL_EFIT);
> +efi_sys_tbl = (EFI_SYSTEM_TABLE *)base_ptr;
> +
> +efi_sys_tbl->Hdr.Signature = EFI_SYSTEM_TABLE_SIGNATURE;
> +/* Specify the revision as 2.5 */
> +efi_sys_tbl->Hdr.Revision = (2 << 16 | 50);
> +efi_sys_tbl->Hdr.HeaderSize = table_size;
> +
> +efi_sys_tbl->FirmwareRevision = 1;
> +efi_sys_tbl->NumberOfTableEntries = 1;
> +offset += sizeof(EFI_SYSTEM_TABLE);
> +memcpy((CHAR16 *)(base_ptr + offset), xen_efi_fw_vendor,
> + sizeof(xen_efi_fw_vendor));
> +efi_sys_tbl->FirmwareVendor = (CHAR16 *)(table_addr + offset);
> +
> +offset += sizeof(xen_efi_fw_vendor);
> +efi_conf_tbl = (EFI_CONFIGURATION_TABLE *)(base_ptr + offset);
> +efi_conf_tbl->VendorGuid = (EFI_GUID)ACPI_20_TABLE_GUID;
> +efi_conf_tbl->VendorTable = (VOID *)tbl_add[TBL_RSDP].start;
> +efi_sys_tbl->ConfigurationTable = (EFI_CONFIGURATION_TABLE *)(table_addr
> + + offset);
> +xz_crc32_init();
> +efi_sys_tbl->Hdr.CRC32 = xz_crc32((uint8_t *)efi_sys_tbl,
> + efi_sys_tbl->Hdr.HeaderSize, 0);
> +
> +tbl_add[TBL_EFIT].start = table_addr;
> +tbl_add[TBL_EFIT].size = table_size;
> +}
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 7f233a1..e423b15 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -53,6 +53,9 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned
> long len);
>
> size_t estimate_efi_size(int mem_nr_banks);
>
> +void acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
> + struct membank tbl_add[]);
> +
> int construct_dom0(struct domain *d);
>
> void discard_initial_modules(void);
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [V3] x86/xsaves: calculate the xstate_comp_offsets base on xcomp_bv
Previous patch using all available features calculate xstate_comp_offsets.
This is wrong.This patch fix this bug by calculating the xstate_comp_offset
based on xcomp_bv of current guest.
Also, the xstate_comp_offset should take alignment into consideration.
Signed-off-by: Shuai Ruan
Reported-by: Jan Beulich
---
V3: Address comments from Jan:
1. fix xstate_comp_offsets used as static array problem.
2. change xstate_align from array to u64 and used as bitmap.
3. change calculating xstate_comp_offsets into three step.
1) whether component is set in xsavearea
2) whether component need align
3) add xstate_size[i-1]
V2: Address comments from Jan:
1. code style fix.
2. setup_xstate_comp take xcomp_bv as param.
xen/arch/x86/domctl.c| 21 +++---
xen/arch/x86/xstate.c| 66 +++-
xen/include/asm-x86/xstate.h | 6 ++--
3 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 55aecdc..3f891b4 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -934,8 +934,14 @@ long arch_do_domctl(
goto vcpuextstate_out;
}
-expand_xsave_states(v, xsave_area,
-size - 2 * sizeof(uint64_t));
+ret = expand_xsave_states(v, xsave_area,
+ size - 2 * sizeof(uint64_t));
+if ( ret )
+{
+xfree(xsave_area);
+vcpu_unpause(v);
+goto vcpuextstate_out;
+}
if ( copy_to_guest_offset(evc->buffer, offset, xsave_area,
size - 2 * sizeof(uint64_t)) )
@@ -1000,8 +1006,15 @@ long arch_do_domctl(
v->arch.xcr0_accum = _xcr0_accum;
if ( _xcr0_accum & XSTATE_NONLAZY )
v->arch.nonlazy_xstate_used = 1;
-compress_xsave_states(v, _xsave_area,
- evc->size - 2 * sizeof(uint64_t));
+ret = compress_xsave_states(v, _xsave_area,
+evc->size - 2 * sizeof(uint64_t));
+if ( ret )
+{
+xfree(receive_buf);
+vcpu_unpause(v);
+goto vcpuextstate_out;
+}
+
vcpu_unpause(v);
}
else
diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
index 8316bd9..d25f045 100644
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -26,8 +26,8 @@ u64 __read_mostly xfeature_mask;
static unsigned int *__read_mostly xstate_offsets;
unsigned int *__read_mostly xstate_sizes;
+static u64 __read_mostly xstate_align;
static unsigned int __read_mostly xstate_features;
-static unsigned int __read_mostly xstate_comp_offsets[sizeof(xfeature_mask)*8];
static uint32_t __read_mostly mxcsr_mask = 0xffbf;
@@ -94,7 +94,7 @@ static bool_t xsave_area_compressed(const struct xsave_struct
*xsave_area)
static int setup_xstate_features(bool_t bsp)
{
-unsigned int leaf, tmp, eax, ebx;
+unsigned int leaf, eax, ebx, ecx, edx;
if ( bsp )
{
@@ -111,21 +111,27 @@ static int setup_xstate_features(bool_t bsp)
for ( leaf = 2; leaf < xstate_features; leaf++ )
{
if ( bsp )
+{
cpuid_count(XSTATE_CPUID, leaf, &xstate_sizes[leaf],
-&xstate_offsets[leaf], &tmp, &tmp);
+&xstate_offsets[leaf], &ecx, &edx);
+if ( ecx & XSTATE_ALIGN64 )
+set_bit(leaf, &xstate_align);
+}
else
{
cpuid_count(XSTATE_CPUID, leaf, &eax,
-&ebx, &tmp, &tmp);
+&ebx, &ecx, &edx);
BUG_ON(eax != xstate_sizes[leaf]);
BUG_ON(ebx != xstate_offsets[leaf]);
+BUG_ON((ecx & XSTATE_ALIGN64) != test_bit(leaf, &xstate_align));
}
}
return 0;
}
-static void __init setup_xstate_comp(void)
+static void setup_xstate_comp(unsigned int *xstate_comp_offsets,
+ const u64 xcomp_bv)
{
unsigned int i;
@@ -134,22 +140,26 @@ static void __init setup_xstate_comp(void)
* in the fixed offsets in the xsave area in either compacted form
* or standard form.
*/
-xstate_comp_offsets[0] = 0;
xstate_comp_offsets[1] = XSAVE_SSE_OFFSET;
xstate_comp_offsets[2] = FXSAVE_SIZE + XSAVE_HDR_SIZE;
for ( i = 3; i < xstate_features; i++ )
{
-xstate_comp_offsets[i] = xstate_comp_offsets[i - 1] +
- (((1ul << i) & xfeature_mask)
- ? xstate_sizes[i - 1] : 0);
-ASSERT(xstate_comp_offsets[i] + xstate_sizes[i] <= xsave_cntxt_size);
+if ( (1ul << i) & xcomp
[Xen-devel] [xen-unstable-smoke test] 85306: regressions - FAIL
flight 85306 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/85306/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 03720ea541382a3ca80eaaec2aa11932b03aacaf baseline version: xen 7ba900efe5f526c941b1ca055e5347947bb7eb4b Last test of basis85080 2016-03-02 16:00:54 Z1 days Testing same since85178 2016-03-03 09:20:13 Z1 days 12 attempts People who touched revisions under test: Andrew Cooper Aravind Gopalakrishnan Boris Ostrovsky Dario Faggioli Hanjun Guo Jan Beulich Juergen Gross Naresh Bhat Parth Dixit Shannon Zhao Shannon Zhao Stefano Stabellini Tomasz Nowicki jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 323 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/4] x86: accommodate 32-bit PV guests with SMAP/SMEP handling
As was previously explained[1], SMAP (and with less relevance also SMEP) is not compatible with 32-bit PV guests which aren't aware/ prepared to be run with that feature enabled. Andrew's original approach either sacrificed architectural correctness for making 32-bit guests work again or by disabling SMAP also for not insignificant portions of hypervisor code, both by allowing to control the workaround mode via command line option. This alternative approach disables SMAP and SMEP only while running 32-bit PV guest code plus a few hypervisor instructions early after entering hypervisor context or later before leaving it. The 4th patch really is unrelated except for not applying cleanly without the earlier ones, and the potential having been noticed while putting together the 2nd one. 1: alternatives: correct near branch check 2: suppress SMAP and SMEP while running 32-bit PV guest code 3: use optimal NOPs to fill the SMAP/SMEP placeholders 4: use 32-bit loads for 32-bit PV guest state reload Signed-off-by: Jan Beulich [1] http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03888.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping
>>> On 04.03.16 at 12:00, wrote: > On Fri, 4 Mar 2016, Jan Beulich wrote: >> >>> On 04.03.16 at 07:15, wrote: >> Overall I wonder whether this wouldn't help PVH on x86 too, >> where we currently do some hackery to (not even completely) >> map MMIO into Dom0's p2m. In such a case perhaps >> map_dev_mmio_regions() should become a general per-arch >> function right away (declared in a common header and stubbed >> out in x86 code for now). Boris, Roger? > > I though that we agreed that Xen will take care of doing all the MMIO > mappings for HVMlite/PVHv2 guests: > > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01609.html > > My first idea was to use the MMIO device mapping hypercall (just like > ARM) on the hardware domain, but I think we can get away without it on x86. Oh, you're right (albeit that doesn't cover MMIO regions not represented by BARs, which will need taking care of). Question back to the ARM folks then: Would such a model work for you too? (I'd really like to avoid having two different models, if we can avoid it.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 12/22] arm/acpi: Prepare EFI memory descriptor for Dom0
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Create a few EFI memory descriptors to tell Dom0 the RAM region
> information, ACPI table regions and EFI tables reserved resions.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: move to efi-dom0.c
> ---
> xen/arch/arm/domain_build.c | 2 ++
> xen/arch/arm/efi/efi-dom0.c | 47
> +
> xen/include/asm-arm/setup.h | 5 +
> 3 files changed, 54 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 613551c..008fc76 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1688,6 +1688,8 @@ static int prepare_acpi(struct domain *d, struct
> kernel_info *kinfo)
> acpi_map_other_tables(d);
> acpi_create_efi_system_table(d->arch.efi_acpi_gpa,
> d->arch.efi_acpi_table,
> tbl_add);
> +acpi_create_efi_mmap_table(d->arch.efi_acpi_gpa, d->arch.efi_acpi_len,
> + d->arch.efi_acpi_table, &kinfo->mem, tbl_add);
>
> return 0;
> }
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index 36a1283..0ff6309 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -22,6 +22,7 @@
> */
>
> #include "efi.h"
> +#include
> #include
> #include
>
> @@ -90,3 +91,49 @@ void __init acpi_create_efi_system_table(paddr_t paddr,
> void *efi_acpi_table,
> tbl_add[TBL_EFIT].start = table_addr;
> tbl_add[TBL_EFIT].size = table_size;
> }
> +
> +void __init acpi_create_efi_mmap_table(paddr_t paddr, paddr_t size,
> + void *efi_acpi_table,
> + const struct meminfo *mem,
> + struct membank tbl_add[])
> +{
> +EFI_MEMORY_DESCRIPTOR *memory_map;
> +struct meminfo *acpi_mem;
> +int acpi_mem_nr_banks = 0;
> +unsigned int i, offset;
> +u8 *base_ptr;
> +
> +base_ptr = efi_acpi_table + acpi_get_table_offset(tbl_add, TBL_MMAP);
> +memory_map = (EFI_MEMORY_DESCRIPTOR *)(base_ptr);
> +
> +offset = 0;
> +for( i = 0; i < mem->nr_banks; i++, offset++ )
> +{
> +memory_map[offset].Type = EfiConventionalMemory;
> +memory_map[offset].PhysicalStart = mem->bank[i].start;
> +memory_map[offset].NumberOfPages = PFN_UP(mem->bank[i].size);
> +memory_map[offset].Attribute = EFI_MEMORY_WB;
> +}
> +
> +if ( !acpi_disabled )
> +{
Isn't this check redundant, givem that the function is name is
acpi_create_efi_mmap_table and is called by prepare_acpi?
> +acpi_mem = get_acpi_meminfo();
Would it be possible to call get_acpi_meminfo from prepare_acpi and pass
acpi_mem to this function?
> +acpi_mem_nr_banks = acpi_mem->nr_banks;
> +for( i = 0; i < acpi_mem_nr_banks; i++, offset++ )
> +{
> +memory_map[offset].Type = EfiACPIReclaimMemory;
> +memory_map[offset].PhysicalStart = acpi_mem->bank[i].start;
> +memory_map[offset].NumberOfPages =
> PFN_UP(acpi_mem->bank[i].size);
> +memory_map[offset].Attribute = EFI_MEMORY_WB;
> +}
> +}
> +
> +memory_map[offset].Type = EfiACPIReclaimMemory;
> +memory_map[offset].PhysicalStart = paddr;
> +memory_map[offset].NumberOfPages = PFN_UP(size);
> +memory_map[offset].Attribute = EFI_MEMORY_WB;
> +
> +tbl_add[TBL_MMAP].start = paddr + acpi_get_table_offset(tbl_add,
> TBL_MMAP);
> +tbl_add[TBL_MMAP].size = sizeof(EFI_MEMORY_DESCRIPTOR)
> + * (mem->nr_banks + acpi_mem_nr_banks + 1);
> +}
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index e423b15..b2899f2 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -56,6 +56,11 @@ size_t estimate_efi_size(int mem_nr_banks);
> void acpi_create_efi_system_table(paddr_t paddr, void *efi_acpi_table,
>struct membank tbl_add[]);
>
> +void acpi_create_efi_mmap_table(paddr_t paddr, paddr_t size,
> +void *efi_acpi_table,
> +const struct meminfo *mem,
> +struct membank tbl_add[]);
> +
> int construct_dom0(struct domain *d);
>
> void discard_initial_modules(void);
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 14/22] arm/acpi: Create min DT stub for Dom0
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Create a DT for Dom0 for ACPI-case only. DT contains minimal required
> informations such as Dom0 bootargs, initrd, efi description table and
> address of uefi memory table.
>
> Also port the document of this device tree bindings from Linux.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: change the file name
Reviewed-by: Stefano Stabellini
> docs/misc/arm/device-tree/uefi.txt | 58 +++
> xen/arch/arm/domain_build.c| 143
> +
> xen/arch/arm/efi/efi-dom0.c| 48 +
> xen/include/asm-arm/setup.h| 2 +
> 4 files changed, 251 insertions(+)
> create mode 100644 docs/misc/arm/device-tree/uefi.txt
>
> diff --git a/docs/misc/arm/device-tree/uefi.txt
> b/docs/misc/arm/device-tree/uefi.txt
> new file mode 100644
> index 000..41a8be0
> --- /dev/null
> +++ b/docs/misc/arm/device-tree/uefi.txt
> @@ -0,0 +1,58 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +the following properties:
> +
> +- compatible:
> + compatible = "xen,xen-", "xen,xen";
> + where is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> + memory where the grant table should be mapped to, using an
> + HYPERVISOR_memory_op hypercall. The memory region is large enough to map
> + the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
> + A GIC node is also required.
> +
> +To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi"
> node
> +under /hypervisor with following parameters:
> +
> +
> +Name | Size | Description
> +
> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI
> System
> + || Table.
> +
> +xen,uefi-mmap-start | 64-bit | Guest physical address of the UEFI
> memory
> + || map.
> +
> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
> + || pointed to in previous entry.
> +
> +xen,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
> + || memory map.
> +
> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
> +
> +
> +Example (assuming #address-cells = <2> and #size-cells = <2>):
> +
> +hypervisor {
> + compatible = "xen,xen-4.3", "xen,xen";
> + reg = <0 0xb000 0 0x2>;
> + interrupts = <1 15 0xf08>;
> + uefi {
> + xen,uefi-system-table = <0x>;
> + xen,uefi-mmap-start = <0x>;
> + xen,uefi-mmap-size = <0x>;
> + xen,uefi-mmap-desc-size = <0x>;
> + xen,uefi-mmap-desc-ver = <0x>;
> +};
> +};
> +
> +The format and meaning of the "xen,uefi-*" parameters are similar to those in
> +Documentation/arm/uefi.txt in Linux, which are provided by the regular Linux
> +UEFI stub. However they differ because they are provided by the Xen
> hypervisor,
> +together with a set of UEFI runtime services implemented via hypercalls, see
> +xen/include/public/platform.h.
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index e036887..6726e45 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1357,6 +1357,145 @@ static int prepare_dtb(struct domain *d, struct
> kernel_info *kinfo)
> }
>
> #ifdef CONFIG_ACPI
> +#define ACPI_DOM0_FDT_MIN_SIZE 4096
> +
> +static int make_chosen_node(const struct kernel_info *kinfo,
> +struct membank tbl_add[])
> +{
> +int res;
> +const char *bootargs = NULL;
> +const struct bootmodule *mod = kinfo->kernel_bootmodule;
> +void *fdt = kinfo->fdt;
> +
> +DPRINT("Create chosen node\n");
> +res = fdt_begin_node(fdt, "chosen");
> +if ( res )
> +return res;
> +
> +if ( mod && mod->cmdline[0] )
> +{
> +bootargs = &mod->cmdline[0];
> +res = fdt_property(fdt, "bootargs", bootargs, strlen(bootargs) + 1);
> +if ( res )
> + return res;
> +}
> +
> +/*
> + *
[Xen-devel] [V2] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
The offset at which components xsaved by xsave[sc] are not fixed. So when when a save with v->fpu_dirtied set is followed by one with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data written by the lazy one. The solution is when xsave[sc] is enabled and taking xcr0_accum into consideration, if guest has ever used lazy states, vcpu_xsave_mask will return XSTATE_ALL. Otherwise vcpu_xsave_mask will return XSTATE_NONLAZY. This may cause overhead save on lazy states which will cause performance impact. As xsavec support code will be cleaned up(reason is list below), so the patch only take xsaves into consideration. After doing some performance test on xsavec and xsaveopt(suggested by jan), the result show xsaveopt performs better than xsavec. So next step clean up xsavec suppot code in xen and disable xsaves (xsaves should be used when supervised state is introduced). Signed-off-by: Shuai Ruan Reported-by: Jan Beulich --- V2: Address comments from Jan: Add performance impact and future steps in description. xen/arch/x86/i387.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/i387.c b/xen/arch/x86/i387.c index c29d0fa..0084578 100644 --- a/xen/arch/x86/i387.c +++ b/xen/arch/x86/i387.c @@ -118,7 +118,8 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu *v) if ( v->fpu_dirtied ) return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY; -return v->arch.nonlazy_xstate_used ? XSTATE_NONLAZY : 0; +return cpu_has_xsaves && (v->arch.xcr0_accum & XSTATE_LAZY & ~XSTATE_FP_SSE) ? + XSTATE_ALL : XSTATE_NONLAZY; } /* Save x87 extended state */ -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 16/22] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Interrupt information is described in DSDT and is not available at the
> time of booting. Check if the interrupt is permitted to access and set
> the interrupt type, route it to guest dynamically only for SPI
> and Dom0.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> v5: add a small function to get the irq type from ICFG
> ---
> xen/arch/arm/vgic.c | 38 ++
> 1 file changed, 38 insertions(+)
>
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index ee35683..52378a3 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -25,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -334,6 +336,21 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
> }
> }
>
> +#ifdef CONFIG_ACPI
> +#define VGIC_ICFG_MASK(intr) ( 1 << ( ( 2 * ( intr % 16 ) ) + 1 ) )
remove spaces: ^ ^ ^ ^
> +static unsigned int get_the_irq_type(struct vcpu *v, int n, int index)
static inline
> +{
> +struct vgic_irq_rank *vr = vgic_get_rank(v, n);
> +uint32_t tr = vr->icfg[index >> 4];
> +
> +if ( tr & VGIC_ICFG_MASK(index) )
> +return IRQ_TYPE_EDGE_BOTH;
> +else
> +return IRQ_TYPE_LEVEL_MASK;
> +}
> +#endif
> +
> void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> {
> const unsigned long mask = r;
> @@ -342,9 +359,30 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> unsigned long flags;
> int i = 0;
> struct vcpu *v_target;
> +#ifdef CONFIG_ACPI
> +struct domain *d = v->domain;
> +int ret;
> +#endif
>
> while ( (i = find_next_bit(&mask, 32, i)) < 32 ) {
> irq = i + (32 * n);
> +#ifdef CONFIG_ACPI
> +/* Set the irq type and route it to guest only for SPI and Dom0 */
> +if( irq_access_permitted(d, irq) && is_hardware_domain(d) &&
> +( irq >= 32 ) && ( !acpi_disabled ) )
Is there a reason why we need to have this code inside an ifdef? It
looks like we can remove all ifdefs from this patch.
> +{
> +ret = irq_set_spi_type(irq, get_the_irq_type(v, n, i));
> +if ( ret )
> +printk(XENLOG_WARNING "The irq type is not correct\n");
> +
> +vgic_reserve_virq(d, irq);
> +
> +ret = route_irq_to_guest(d, irq, irq, NULL);
> +if ( ret )
> +printk(XENLOG_ERR "Unable to route IRQ %u to domain %u\n",
> + irq, d->domain_id);
> +}
> +#endif
> v_target = __vgic_get_target_vcpu(v, irq);
> p = irq_to_pending(v_target, irq);
> set_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] x86/alternatives: correct near branch check
Make sure the near JMP/CALL check doesn't consume uninitialized data, not even in a benign way. And relax the length check at once. Signed-off-by: Jan Beulich --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -174,7 +174,7 @@ static void __init apply_alternatives(st memcpy(insnbuf, replacement, a->replacementlen); /* 0xe8/0xe9 are relative branches; fix the offset. */ -if ( (*insnbuf & 0xfe) == 0xe8 && a->replacementlen == 5 ) +if ( a->replacementlen >= 5 && (*insnbuf & 0xfe) == 0xe8 ) *(s32 *)(insnbuf + 1) += replacement - instr; add_nops(insnbuf + a->replacementlen, x86/alternatives: correct near branch check Make sure the near JMP/CALL check doesn't consume uninitialized data, not even in a benign way. And relax the length check at once. Signed-off-by: Jan Beulich --- a/xen/arch/x86/alternative.c +++ b/xen/arch/x86/alternative.c @@ -174,7 +174,7 @@ static void __init apply_alternatives(st memcpy(insnbuf, replacement, a->replacementlen); /* 0xe8/0xe9 are relative branches; fix the offset. */ -if ( (*insnbuf & 0xfe) == 0xe8 && a->replacementlen == 5 ) +if ( a->replacementlen >= 5 && (*insnbuf & 0xfe) == 0xe8 ) *(s32 *)(insnbuf + 1) += replacement - instr; add_nops(insnbuf + a->replacementlen, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] x86: suppress SMAP and SMEP while running 32-bit PV guest code
Since such guests' kernel code runs in ring 1, their memory accesses,
at the paging layer, are supervisor mode ones, and hence subject to
SMAP/SMEP checks. Such guests cannot be expected to be aware of those
two features though (and so far we also don't expose the respective
feature flags), and hence may suffer page faults they cannot deal with.
While the placement of the re-enabling slightly weakens the intended
protection, it was selected such that 64-bit paths would remain
unaffected where possible. At the expense of a further performance hit
the re-enabling could be put right next to the CLACs.
Note that this introduces a number of extra TLB flushes - CR4.SMEP
transitioning from 0 to 1 always causes a flush, and it transitioning
from 1 to 0 may also do.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -67,6 +67,8 @@ boolean_param("smep", opt_smep);
static bool_t __initdata opt_smap = 1;
boolean_param("smap", opt_smap);
+unsigned long __read_mostly cr4_smep_smap_mask;
+
/* Boot dom0 in pvh mode */
static bool_t __initdata opt_dom0pvh;
boolean_param("dom0pvh", opt_dom0pvh);
@@ -1335,6 +1337,8 @@ void __init noreturn __start_xen(unsigne
if ( cpu_has_smap )
set_in_cr4(X86_CR4_SMAP);
+cr4_smep_smap_mask = mmu_cr4_features & (X86_CR4_SMEP | X86_CR4_SMAP);
+
if ( cpu_has_fsgsbase )
set_in_cr4(X86_CR4_FSGSBASE);
@@ -1471,7 +1475,10 @@ void __init noreturn __start_xen(unsigne
* copy_from_user().
*/
if ( cpu_has_smap )
+{
+cr4_smep_smap_mask &= ~X86_CR4_SMAP;
write_cr4(read_cr4() & ~X86_CR4_SMAP);
+}
printk("%sNX (Execute Disable) protection %sactive\n",
cpu_has_nx ? XENLOG_INFO : XENLOG_WARNING "Warning: ",
@@ -1488,7 +1495,10 @@ void __init noreturn __start_xen(unsigne
panic("Could not set up DOM0 guest OS");
if ( cpu_has_smap )
+{
write_cr4(read_cr4() | X86_CR4_SMAP);
+cr4_smep_smap_mask |= X86_CR4_SMAP;
+}
/* Scrub RAM that is still free and so may go to an unprivileged domain. */
scrub_heap_pages();
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -16,14 +16,16 @@ ENTRY(compat_hypercall)
ASM_CLAC
pushq $0
SAVE_VOLATILE type=TRAP_syscall compat=1
+SMEP_SMAP_RESTORE
cmpb $0,untrusted_msi(%rip)
UNLIKELY_START(ne, msi_check)
movl $HYPERCALL_VECTOR,%edi
call check_for_unexpected_msi
-LOAD_C_CLOBBERED
+LOAD_C_CLOBBERED compat=1 ax=0
UNLIKELY_END(msi_check)
+movl UREGS_rax(%rsp),%eax
GET_CURRENT(%rbx)
cmpl $NR_hypercalls,%eax
@@ -33,7 +35,6 @@ UNLIKELY_END(msi_check)
pushq UREGS_rbx(%rsp); pushq %rcx; pushq %rdx; pushq %rsi; pushq %rdi
pushq UREGS_rbp+5*8(%rsp)
leaq compat_hypercall_args_table(%rip),%r10
-movl %eax,%eax
movl $6,%ecx
subb (%r10,%rax,1),%cl
movq %rsp,%rdi
@@ -48,7 +49,6 @@ UNLIKELY_END(msi_check)
#define SHADOW_BYTES 16 /* Shadow EIP + shadow hypercall # */
#else
/* Relocate argument registers and zero-extend to 64 bits. */
-movl %eax,%eax /* Hypercall # */
xchgl %ecx,%esi /* Arg 2, Arg 4 */
movl %edx,%edx /* Arg 3*/
movl %edi,%r8d /* Arg 5*/
@@ -174,10 +174,43 @@ compat_bad_hypercall:
/* %rbx: struct vcpu, interrupts disabled */
ENTRY(compat_restore_all_guest)
ASSERT_INTERRUPTS_DISABLED
+.Lcr4_orig:
+ASM_NOP3 /* mov %cr4, %rax */
+ASM_NOP6 /* and $..., %rax */
+ASM_NOP3 /* mov %rax, %cr4 */
+.pushsection .altinstr_replacement, "ax"
+.Lcr4_alt:
+mov %cr4, %rax
+and $~(X86_CR4_SMEP|X86_CR4_SMAP), %rax
+mov %rax, %cr4
+.Lcr4_alt_end:
+.section .altinstructions, "a"
+altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMEP, 12, \
+ (.Lcr4_alt_end - .Lcr4_alt)
+altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMAP, 12, \
+ (.Lcr4_alt_end - .Lcr4_alt)
+.popsection
RESTORE_ALL adj=8 compat=1
.Lft0: iretq
_ASM_PRE_EXTABLE(.Lft0, handle_exception)
+/* This mustn't modify registers other than %rax. */
+ENTRY(cr4_smep_smap_restore)
+mov %cr4, %rax
+test $X86_CR4_SMEP|X86_CR4_SMAP,%eax
+jnz 0f
+orcr4_smep_smap_mask(%rip), %rax
+mov %rax, %cr4
+ret
+0:
+and cr4_smep_smap_mask(%rip), %eax
+cmp cr4_smep_smap_mask(%rip), %eax
+je1f
+BUG
+1:
+xor %eax, %eax
+ret
+
/* %rdx: trap_bounce, %rbx: struct vcpu */
ENTRY(compat_post_handle_exception)
testb $TBF_EXCEPTION,TRAPBOUNCE_flags(%rdx)
@@ -190,6 +223,7 @@ ENTRY(compat_post_handle_exception)
/* See lstar_enter for entry
[Xen-devel] [PATCH 3/4] x86: use optimal NOPs to fill the SMAP/SMEP placeholders
Alternatives patching code picks the most suitable NOPs for the running system, so simply use it to replace the pre-populated ones. Use an arbitrary, always available feature to key off from. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -185,6 +185,7 @@ ENTRY(compat_restore_all_guest) mov %rax, %cr4 .Lcr4_alt_end: .section .altinstructions, "a" +altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_LM, 12, 0 altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMEP, 12, \ (.Lcr4_alt_end - .Lcr4_alt) altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMAP, 12, \ --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -204,6 +204,7 @@ void ret_from_intr(void); 662: __ASM_##op; \ .popsection; \ .pushsection .altinstructions, "a";\ +altinstruction_entry 661b, 661b, X86_FEATURE_LM, 3, 0; \ altinstruction_entry 661b, 662b, X86_FEATURE_SMAP, 3, 3; \ .popsection @@ -215,6 +216,7 @@ void ret_from_intr(void); .pushsection .altinstr_replacement, "ax"; \ 668: call cr4_smep_smap_restore; \ .section .altinstructions, "a";\ +altinstruction_entry 667b, 667b, X86_FEATURE_LM, 5, 0; \ altinstruction_entry 667b, 668b, X86_FEATURE_SMEP, 5, 5; \ altinstruction_entry 667b, 668b, X86_FEATURE_SMAP, 5, 5; \ .popsection x86: use optimal NOPs to fill the SMAP/SMEP placeholders Alternatives patching code picks the most suitable NOPs for the running system, so simply use it to replace the pre-populated ones. Use an arbitrary, always available feature to key off from. Signed-off-by: Jan Beulich --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -185,6 +185,7 @@ ENTRY(compat_restore_all_guest) mov %rax, %cr4 .Lcr4_alt_end: .section .altinstructions, "a" +altinstruction_entry .Lcr4_orig, .Lcr4_orig, X86_FEATURE_LM, 12, 0 altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMEP, 12, \ (.Lcr4_alt_end - .Lcr4_alt) altinstruction_entry .Lcr4_orig, .Lcr4_alt, X86_FEATURE_SMAP, 12, \ --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -204,6 +204,7 @@ void ret_from_intr(void); 662: __ASM_##op; \ .popsection; \ .pushsection .altinstructions, "a";\ +altinstruction_entry 661b, 661b, X86_FEATURE_LM, 3, 0; \ altinstruction_entry 661b, 662b, X86_FEATURE_SMAP, 3, 3; \ .popsection @@ -215,6 +216,7 @@ void ret_from_intr(void); .pushsection .altinstr_replacement, "ax"; \ 668: call cr4_smep_smap_restore; \ .section .altinstructions, "a";\ +altinstruction_entry 667b, 667b, X86_FEATURE_LM, 5, 0; \ altinstruction_entry 667b, 668b, X86_FEATURE_SMEP, 5, 5; \ altinstruction_entry 667b, 668b, X86_FEATURE_SMAP, 5, 5; \ .popsection ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] x86: use 32-bit loads for 32-bit PV guest state reload
This is slightly more efficient than loading 64-bit quantities. Signed-off-by: Jan Beulich --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -313,6 +313,13 @@ static always_inline void stac(void) 987: .endm +#define LOAD_ONE_REG(reg, compat) \ +.if !(compat); \ +movq UREGS_r##reg(%rsp),%r##reg; \ +.else; \ +movl UREGS_r##reg(%rsp),%e##reg; \ +.endif + /* * Reload registers not preserved by C code from frame. * @@ -326,16 +333,14 @@ static always_inline void stac(void) movq UREGS_r10(%rsp),%r10 movq UREGS_r9(%rsp),%r9 movq UREGS_r8(%rsp),%r8 -.if \ax -movq UREGS_rax(%rsp),%rax .endif -.elseif \ax -movl UREGS_rax(%rsp),%eax +.if \ax +LOAD_ONE_REG(ax, \compat) .endif -movq UREGS_rcx(%rsp),%rcx -movq UREGS_rdx(%rsp),%rdx -movq UREGS_rsi(%rsp),%rsi -movq UREGS_rdi(%rsp),%rdi +LOAD_ONE_REG(cx, \compat) +LOAD_ONE_REG(dx, \compat) +LOAD_ONE_REG(si, \compat) +LOAD_ONE_REG(di, \compat) .endm /* @@ -372,8 +377,9 @@ static always_inline void stac(void) .subsection 0 #endif .endif -987:movq UREGS_rbp(%rsp),%rbp -movq UREGS_rbx(%rsp),%rbx +987: +LOAD_ONE_REG(bp, \compat) +LOAD_ONE_REG(bx, \compat) subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp .endm x86: use 32-bit loads for 32-bit PV guest state reload This is slightly more efficient than loading 64-bit quantities. Signed-off-by: Jan Beulich --- a/xen/include/asm-x86/asm_defns.h +++ b/xen/include/asm-x86/asm_defns.h @@ -313,6 +313,13 @@ static always_inline void stac(void) 987: .endm +#define LOAD_ONE_REG(reg, compat) \ +.if !(compat); \ +movq UREGS_r##reg(%rsp),%r##reg; \ +.else; \ +movl UREGS_r##reg(%rsp),%e##reg; \ +.endif + /* * Reload registers not preserved by C code from frame. * @@ -326,16 +333,14 @@ static always_inline void stac(void) movq UREGS_r10(%rsp),%r10 movq UREGS_r9(%rsp),%r9 movq UREGS_r8(%rsp),%r8 -.if \ax -movq UREGS_rax(%rsp),%rax .endif -.elseif \ax -movl UREGS_rax(%rsp),%eax +.if \ax +LOAD_ONE_REG(ax, \compat) .endif -movq UREGS_rcx(%rsp),%rcx -movq UREGS_rdx(%rsp),%rdx -movq UREGS_rsi(%rsp),%rsi -movq UREGS_rdi(%rsp),%rdi +LOAD_ONE_REG(cx, \compat) +LOAD_ONE_REG(dx, \compat) +LOAD_ONE_REG(si, \compat) +LOAD_ONE_REG(di, \compat) .endm /* @@ -372,8 +377,9 @@ static always_inline void stac(void) .subsection 0 #endif .endif -987:movq UREGS_rbp(%rsp),%rbp -movq UREGS_rbx(%rsp),%rbx +987: +LOAD_ONE_REG(bp, \compat) +LOAD_ONE_REG(bx, \compat) subq $-(UREGS_error_code-UREGS_r15+\adj), %rsp .endm ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 21/22] xen/arm: Add a hypercall for device mmio mapping
On Fri, 4 Mar 2016, Jan Beulich wrote: > >>> On 04.03.16 at 12:00, wrote: > > On Fri, 4 Mar 2016, Jan Beulich wrote: > >> >>> On 04.03.16 at 07:15, wrote: > >> Overall I wonder whether this wouldn't help PVH on x86 too, > >> where we currently do some hackery to (not even completely) > >> map MMIO into Dom0's p2m. In such a case perhaps > >> map_dev_mmio_regions() should become a general per-arch > >> function right away (declared in a common header and stubbed > >> out in x86 code for now). Boris, Roger? > > > > I though that we agreed that Xen will take care of doing all the MMIO > > mappings for HVMlite/PVHv2 guests: > > > > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01609.html > > > > My first idea was to use the MMIO device mapping hypercall (just like > > ARM) on the hardware domain, but I think we can get away without it on x86. > > Oh, you're right (albeit that doesn't cover MMIO regions not > represented by BARs, which will need taking care of). This. On ARM there can MMIO regions of non-PCI devices which need to be mapped and can only be discovered via DSDT. > Question > back to the ARM folks then: Would such a model work for you > too? (I'd really like to avoid having two different models, if we > can avoid it.) It doesn't cover non-PCI devices. But once you extend your model to deal with non-PCI devices and MMIO regions not represented by BARs, then potentually yes. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 22/22] xen/arm64: Add ACPI support
On Fri, 4 Mar 2016, Jan Beulich wrote: > >>> On 04.03.16 at 07:15, wrote: > > From: Naresh Bhat > > > > Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM. > > > > Cc: Jan Beulich > > Signed-off-by: Naresh Bhat > > Signed-off-by: Shannon Zhao > > --- > > v5: make ACPI selectable option > > --- > > xen/arch/arm/Kconfig | 9 + > > xen/common/efi/runtime.c | 12 +++- > > For the change to this file: > Acked-by: Jan Beulich > However ... > > > +++ b/xen/arch/arm/Kconfig > > @@ -33,6 +33,15 @@ menu "Architecture Features" > > > > source "arch/Kconfig" > > > > +config ACPI > > + bool "ACPI (Advanced Configuration and Power Interface) Support" > > + depends on ARM_64 > > + default y > > ... I recall Stefano having asked for this, but - are both of you sure? > Have you seen the earlier discussion about the introduction of new > user selectable config options? I.e. shouldn't the prompt at least > become conditional on EXPERT = "y", just like done elsewhere? ACPI is big chunk of code which people might want to reasonably disable when booting on anything but servers. Think of all the small dev boards (Cubieboard), or embedded use cases (set top boxes, etc): none of these make sense with ACPI. On the other hand for arm64 distros is a must have. This is why I think it is a good idea to have it selectable. I am fine with it being conditional on EXPERT = "y", though. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 22/22] xen/arm64: Add ACPI support
On Fri, 4 Mar 2016, Shannon Zhao wrote: > From: Naresh Bhat > > Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM. > > Cc: Jan Beulich > Signed-off-by: Naresh Bhat > Signed-off-by: Shannon Zhao Reviewed-by: Stefano Stabellini > v5: make ACPI selectable option > --- > xen/arch/arm/Kconfig | 9 + > xen/common/efi/runtime.c | 12 +++- > xen/include/asm-arm/config.h | 4 > 3 files changed, 20 insertions(+), 5 deletions(-) > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig > index cb99df5..25cec31 100644 > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig > @@ -33,6 +33,15 @@ menu "Architecture Features" > > source "arch/Kconfig" > > +config ACPI > + bool "ACPI (Advanced Configuration and Power Interface) Support" > + depends on ARM_64 > + default y > + ---help--- > + > + Advanced Configuration and Power Interface (ACPI) support for Xen is > + an alternative to device tree on ARM64. > + > # Select HAS_GICV3 if GICv3 is supported > config HAS_GICV3 > bool > diff --git a/xen/common/efi/runtime.c b/xen/common/efi/runtime.c > index ae87557..c256814 100644 > --- a/xen/common/efi/runtime.c > +++ b/xen/common/efi/runtime.c > @@ -10,14 +10,16 @@ DEFINE_XEN_GUEST_HANDLE(CHAR16); > > #ifndef COMPAT > > -#ifdef CONFIG_ARM /* Disabled until runtime services implemented */ > -const bool_t efi_enabled = 0; > -#else > +/* > + * Currently runtime services are not implemented on ARM. To boot Xen with > ACPI, > + * set efi_enabled to 1, so that Xen can get the ACPI root pointer from EFI. > + */ > +const bool_t efi_enabled = 1; > + > +#ifndef CONFIG_ARM > # include > # include > # include > - > -const bool_t efi_enabled = 1; > #endif > > unsigned int __read_mostly efi_num_ct; > diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h > index 7ceb5c5..5fc9aa2 100644 > --- a/xen/include/asm-arm/config.h > +++ b/xen/include/asm-arm/config.h > @@ -31,6 +31,10 @@ > > #define CONFIG_ARM_L1_CACHE_SHIFT 7 /* XXX */ > > +#ifdef CONFIG_ACPI > +#define CONFIG_ACPI_BOOT 1 > +#endif > + > #define CONFIG_SMP 1 > > #define CONFIG_IRQ_HAS_MULTIPLE_ACTION 1 > -- > 2.0.4 > > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one
On March 04, 2016 5:29pm, wrote: > >>> On 04.03.16 at 03:45, wrote: > > On March 04, 2016 7:59am, wrote: > >> On Wed, 2016-03-02 at 22:31 +0800, Quan Xu wrote: > >> > @@ -788,10 +787,10 @@ static bool_t __init > >> > set_iommu_interrupt_handler(struct amd_iommu *iommu) > >> > return 0; > >> > } > >> > > >> > -spin_lock_irqsave(&pcidevs_lock, flags); > >> > +pcidevs_lock(); > >> > > >> So, spin_lock_irqsave() does: > >> local_irq_save() > >> local_save_flags() > >> local_irq_disable() > >> _spin_lock() > >> > >> i.e., it saves the flags and disable interrupts. > >> > >> pcidevs_lock() does: > >> spin_lock_recursive() > >> ... //handle recursion > >> _spin_lock() > >> > >> i.e., it does not disable interrupts. > >> > >> And therefore it is possible that we are actually skipping disabling > > interrupts (if > >> they're not disabled already), isn't it? > >> > >> And, of course, the same reasoning --mutatis mutandis-- applies to > >> the unlock side of things. > >> > >> > iommu->msi.dev = pci_get_pdev(iommu->seg, > PCI_BUS(iommu->bdf), > >> >PCI_DEVFN2(iommu->bdf)); > >> > -spin_unlock_irqrestore(&pcidevs_lock, flags); > >> > +pcidevs_unlock(); > >> > > >> i.e., spin_unlock_irqrestore() restore the flags, including the > >> interrupt enabled/disabled status, which means it can re-enable the > >> interrupts or not, depending on whether they were enabled at the time > >> of the previous spin_lock_irqsave(); pcidevs_unlock() just don't > >> affect interrupt enabling/disabling at all. > >> > >> So, if the original code is correct in using > >> spin_lock_irqsave()/spin_unlock_irqrestore(), I think that we need > >> _irqsave() and _irqrestore() variants of recursive spinlocks, in > >> order to deal with this case. > >> > >> However, from a quick inspection, it looks to me that: > >> - this can only be called (during initialization), with interrupt > >>enabled, so least saving & restoring flags shouldn't be necessary > >>(unless I missed where they can be disabled in the call chain > >>from iommu_setup() toward set_iommu_interrupt_handler()). > >> - This protects pci_get_dev(); looking at other places where > >>pci_get_dev() is called, I don't think it is really necessary to > >>disable interrupts. > >> > >> If I'm right, it means that the original code could well have been > >> using > > just plain > >> spin_lock() and spin_unlock(), and it would then be fine to turn them > >> into > >> pcidevs_lock() and pcidevs_unlock(), and so no need to add more > >> spin_[un]lock_recursive() variants. > >> > >> That would also mean that the patch is indeed ok, > > > > Yes, I fully agree your analysis and conclusion. > > I tried to implement _irqsave() and _irqrestore() variants of > > recursive spinlocks, but I found that it is no need to add them. > > > > Also I'd highlight the below modification: > > -if ( !spin_trylock(&pcidevs_lock) ) > > -return -ERESTART; > > - > > +pcidevs_lock(); > > > > IMO, it is right too. > > Well, I'll have to see where exactly this is (pulling such out of context is > pretty > unhelpful), but I suspect it can't be replaced like this. > Jan, I am looking forward to your review. btw, It is in the assign_device(), in the xen/drivers/passthrough/pci.c file. > >> but I'd add a mention of this in the changelog. > > > > In git log? > > To be honest, changes like this would better not be buried in a big rework > like > the one here. Make it a prereq patch, where you then will kind of > automatically > describe why it's correct. (I agree current code is bogus, and we're not > hitting > the respective > BUG_ON() in check_lock() only because spin_debug gets set to true only after > most __init code has run.) Agreed, I would make a prereq patch in v7. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 17/22] arm/gic: Add a new callback to deny Dom0 access to GIC regions
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new member in gic_hw_operations which is used to deny Dom0 access
> to GIC regions.
>
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/gic-v2.c | 31 +++
> xen/arch/arm/gic-v3.c | 44
> xen/arch/arm/gic.c| 5 +
> xen/include/asm-arm/gic.h | 3 +++
> 4 files changed, 83 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index d9fce4b..67797f2 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1278,6 +1279,44 @@ static u32 gicv3_make_hwdom_madt(const struct domain
> *d, u32 offset)
> return table_len;
> }
>
> +static int gicv3_iomem_deny_access(const struct domain *d)
> +{
> +int rc, i;
> +unsigned long gfn, nr;
> +
> +gfn = dbase >> PAGE_SHIFT;
> +rc = iomem_deny_access(d, gfn, gfn + 1);
The size of the gicv3 distributor is 64k.
The rest looks good.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 18/22] arm/acpi: Permit MMIO access of Xen unused devices for Dom0
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Firstly it permits full MMIO capabilities for Dom0. Then deny MMIO
> access of Xen used devices, such as UART, GIC, SMMU. Currently, it only
> denies the MMIO access of UART and GIC regions. For other Xen used
> devices it could be added later when they are supported.
>
> Signed-off-by: Shannon Zhao
> ---
> v5: deny access to GIC regions
Thank you!
Reviewed-by: Stefano Stabellini
> xen/arch/arm/domain_build.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 1e5ee0e..a4abf28 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1359,6 +1359,38 @@ static int prepare_dtb(struct domain *d, struct
> kernel_info *kinfo)
> #ifdef CONFIG_ACPI
> #define ACPI_DOM0_FDT_MIN_SIZE 4096
>
> +static int acpi_iomem_deny_access(struct domain *d)
> +{
> +acpi_status status;
> +struct acpi_table_spcr *spcr = NULL;
> +unsigned long gfn;
> +int rc;
> +
> +/* Firstly permit full MMIO capabilities. */
> +rc = iomem_permit_access(d, 0UL, ~0UL);
> +if ( rc )
> +return rc;
> +
> +/* TODO: Deny MMIO access for SMMU, GIC ITS */
> +status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +(struct acpi_table_header **)&spcr);
> +
> +if ( ACPI_FAILURE(status) )
> +{
> +printk("Failed to get SPCR table\n");
> +return -EINVAL;
> +}
> +
> +gfn = spcr->serial_port.address >> PAGE_SHIFT;
> +/* Deny MMIO access for UART */
> +rc = iomem_deny_access(d, gfn, gfn + 1);
> +if ( rc )
> +return rc;
> +
> +/* Deny MMIO access for GIC regions */
> +return gic_iomem_deny_access(d);
> +}
> +
> static int acpi_permit_spi_access(struct domain *d)
> {
> int i, res;
> @@ -1880,6 +1912,10 @@ static int prepare_acpi(struct domain *d, struct
> kernel_info *kinfo)
> if ( rc != 0 )
> return rc;
>
> +rc = acpi_iomem_deny_access(d);
> +if ( rc != 0 )
> +return rc;
> +
> return 0;
> }
> #else
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
On Fri, 4 Mar 2016, Jan Beulich wrote: > >>> On 04.03.16 at 07:15, wrote: > > From: Shannon Zhao > > > > Add a new delivery type: > > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI. > > To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and > > bit 9 stands the interrupt polarity is active low(1) or high(0). > > > > Cc: Jan Beulich > > Signed-off-by: Shannon Zhao > > The set of Cc-s is too narrow - all REST maintainers should be copied. > > > --- a/xen/include/public/hvm/params.h > > +++ b/xen/include/public/hvm/params.h > > @@ -55,6 +55,16 @@ > > * if this delivery method is available. > > */ > > > > +#define HVM_PARAM_CALLBACK_TYPE_EVENT3 > > +/* > > + * val[55:16] need to be zero. > > + * val[15:8] is flag of event-channel interrupt: > > + * bit 8: interrupt is edge(1) or level(0) triggered > > + * bit 9: interrupt is active low(1) or high(0) > > + * val[7:0] is PPI number used by event-channel. > > + * This is only used by ARM/ARM64. > > + */ > > I think the name of the constant needs improvement. The low 8 > bits make this extremely ARM specific, so perhaps > HVM_PARAM_CALLBACK_TYPE_PPI? That would be OK for me. > Albeit - wouldn't the > vector and/or GSI ones be re-usable for this purpose? (I > don't know enough about ARM to be certain.) Vector is an x86 thing, while GSI is an ACPI term. There is probably a PPI to GSI mapping on ARM ACPI systems, but I wouldn't want this HVM_PARAM to work only with ACPI: it should work with device tree systems too, where GSI has no meaning. > And then I'm now also wondering about the description of bits > 8 and 9 - event channels don't know of edge/level triggering > or high/low polarity, so it looks to me as if the comment is at > least misleading too. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.5.3 preparations
>>> On 01.03.16 at 16:44, wrote: > On Mon, 29 Feb 2016, Jan Beulich wrote: >> it just occurred to me that 4.5.2 has been a while back, and indeed >> 4.5.3 would be due later this week. This may be a little too eager, >> but I'd like to aim at getting this out at least some time next week. >> Besides what is in the tree already, I have three more commits I >> intend to backport: >> 0640ffb67f x86emul: fix rIP handling >> 1329105943 x86/hvm: print register state upon triple fault >> 81d3a0b26c x86emul: limit-check branch targets >> Please indicate any further commits you think need putting in >> before that stable release (Stefano, I'd in particular rely on you >> to indicate any possible ARM candidates). > > 93f67ce718a020686d98db7edd7e9298bd7b36a5 xen/arm: vgic-v2: Report the > correct GICC size to the guest > 70ed1226d2e27f43c6f7d3aa9d5f2a0e1b29347d xen/arm: vgic-v2: Implement > correctly ITARGETSR0 - ITARGETSR7 read-only Done. In the process of doing so I've got the impression that you actually handed my commit IDs from the 4.6 branch instead of master ones. Also the second one didn't apply without fuzz, so please double check. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
>>> On 04.03.16 at 13:09, wrote: > On Fri, 4 Mar 2016, Jan Beulich wrote: >> >>> On 04.03.16 at 07:15, wrote: >> > From: Shannon Zhao >> > >> > Add a new delivery type: >> > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI. >> > To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and >> > bit 9 stands the interrupt polarity is active low(1) or high(0). >> > >> > Cc: Jan Beulich >> > Signed-off-by: Shannon Zhao >> >> The set of Cc-s is too narrow - all REST maintainers should be copied. >> >> > --- a/xen/include/public/hvm/params.h >> > +++ b/xen/include/public/hvm/params.h >> > @@ -55,6 +55,16 @@ >> > * if this delivery method is available. >> > */ >> > >> > +#define HVM_PARAM_CALLBACK_TYPE_EVENT3 >> > +/* >> > + * val[55:16] need to be zero. >> > + * val[15:8] is flag of event-channel interrupt: >> > + * bit 8: interrupt is edge(1) or level(0) triggered >> > + * bit 9: interrupt is active low(1) or high(0) >> > + * val[7:0] is PPI number used by event-channel. >> > + * This is only used by ARM/ARM64. >> > + */ >> >> I think the name of the constant needs improvement. The low 8 >> bits make this extremely ARM specific, so perhaps >> HVM_PARAM_CALLBACK_TYPE_PPI? > > That would be OK for me. > > >> Albeit - wouldn't the >> vector and/or GSI ones be re-usable for this purpose? (I >> don't know enough about ARM to be certain.) > > Vector is an x86 thing, while GSI is an ACPI term. There is probably a > PPI to GSI mapping on ARM ACPI systems, but I wouldn't want this > HVM_PARAM to work only with ACPI: it should work with device tree > systems too, where GSI has no meaning. Okay. Then how about making _VECTOR x86-specific, and the new one ARM-specific (via #ifdef), at once allowing (if so wanted) both to share the same numeric value? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 01/17] Xen: ACPI: Hide UART used by Xen
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> Signed-off-by: Shannon Zhao
> ---
> CC: "Rafael J. Wysocki" (supporter:ACPI)
> CC: Len Brown (supporter:ACPI)
> CC: linux-a...@vger.kernel.org (open list:ACPI)
> ---
> drivers/acpi/scan.c | 68
> +
> 1 file changed, 68 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 407a376..31d794c 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
> DEFINE_MUTEX(acpi_device_lock);
> LIST_HEAD(acpi_wakeup_device_list);
> static DEFINE_MUTEX(acpi_hp_context_lock);
> +static u64 spcr_uart_addr;
>
> struct acpi_dep_data {
> struct list_head node;
> @@ -1453,6 +1454,47 @@ static int acpi_add_single_object(struct acpi_device
> **child,
> return 0;
> }
>
> +static acpi_status acpi_get_resource_fixed_memory32(struct acpi_resource
> *res,
> + void *context)
> +{
> + struct acpi_resource_fixed_memory32 *fixed_memory32;
> +
> + if (res->type != ACPI_RESOURCE_TYPE_FIXED_MEMORY32)
> + return AE_OK;
> +
> + fixed_memory32 = &res->data.fixed_memory32;
Should we call acpi_resource_to_address64 instead?
Aside from this the rest looks good.
> + if (!fixed_memory32)
> + return AE_OK;
> +
> + *((u32 *)context) = fixed_memory32->address;
> + return AE_CTRL_TERMINATE;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> + acpi_status status;
> + u32 addr = 0;
> +
> + /* Check if it should ignore the UART device */
> + if (spcr_uart_addr != 0) {
> + if (!acpi_has_method(handle, METHOD_NAME__CRS))
> + return false;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_get_resource_fixed_memory32,
> + &addr);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + if (addr == spcr_uart_addr) {
> + printk(KERN_INFO PREFIX "The UART device in SPCR table
> will be hidden\n");
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
> {
> @@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle,
> int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> + if (acpi_device_should_be_hidden(handle))
> + return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1919,6 +1964,8 @@ static int acpi_bus_scan_fixed(void)
> int __init acpi_scan_init(void)
> {
> int result;
> + acpi_status status;
> + struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1933,6 +1980,27 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> + /* If there is STAO table, check whether it needs to ignore the UART
> + * device in SPCR table.
> + */
> + status = acpi_get_table(ACPI_SIG_STAO, 0,
> + (struct acpi_table_header **)&stao_ptr);
> + if (ACPI_SUCCESS(status)) {
> + if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> + printk(KERN_INFO PREFIX "STAO Name List not yet
> supported.");
> +
> + if (stao_ptr->ignore_uart) {
> + struct acpi_table_spcr *spcr_ptr;
> +
> + status = acpi_get_table(ACPI_SIG_SPCR, 0,
> + (struct acpi_table_header **)&spcr_ptr);
> + if (ACPI_SUCCESS(status))
> + spcr_uart_addr = spcr_ptr->serial_port.address;
> + else
> + printk(KERN_WARNING PREFIX "STAO table present,
> but SPCR is missing\n");
> + }
> + }
> +
> mutex_lock(&acpi_scan_lock);
> /*
>* Enumerate devices in the ACPI namespace.
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/errno: Reduce complexity of inclusion
>>> On 03.03.16 at 15:14, wrote: > @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint > is already connected */ > XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */ > XEN_ERRNO(ETIMEDOUT, 110)/* Connection timed out */ > > -#undef XEN_ERRNO > #endif /* XEN_ERRNO */ > - > -#ifndef __XEN_PUBLIC_ERRNO_H__ > -#define __XEN_PUBLIC_ERRNO_H__ > - > /* ` } */ > > + > +/* > + * Clean up from a default include. Close the enum (for C) and remove the > + * default XEN_ERRNO from scope. > + */ > +#ifdef XEN_ERRNO_DEFAULT_INCLUDE > +#undef XEN_ERRNO_DEFAULT_INCLUDE > +#undef XEN_ERRNO > #ifndef __ASSEMBLY__ > }; > #endif > > -#endif /* __XEN_PUBLIC_ERRNO_H__ */ > +#endif /* XEN_ERRNO_DEFAULT_INCLUDE */ So far, upon reaching the end oft the file XEN_ERRNO is undefined, no matter whether it got defined here or prior to inclusion. I think this property should be retained, but moving the #undef to the very end. Please indicate if that's okay with you, as this doesn't really require another version to be sent. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
On Fri, 4 Mar 2016, Jan Beulich wrote: > >>> On 04.03.16 at 13:09, wrote: > > On Fri, 4 Mar 2016, Jan Beulich wrote: > >> >>> On 04.03.16 at 07:15, wrote: > >> > From: Shannon Zhao > >> > > >> > Add a new delivery type: > >> > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI. > >> > To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and > >> > bit 9 stands the interrupt polarity is active low(1) or high(0). > >> > > >> > Cc: Jan Beulich > >> > Signed-off-by: Shannon Zhao > >> > >> The set of Cc-s is too narrow - all REST maintainers should be copied. > >> > >> > --- a/xen/include/public/hvm/params.h > >> > +++ b/xen/include/public/hvm/params.h > >> > @@ -55,6 +55,16 @@ > >> > * if this delivery method is available. > >> > */ > >> > > >> > +#define HVM_PARAM_CALLBACK_TYPE_EVENT3 > >> > +/* > >> > + * val[55:16] need to be zero. > >> > + * val[15:8] is flag of event-channel interrupt: > >> > + * bit 8: interrupt is edge(1) or level(0) triggered > >> > + * bit 9: interrupt is active low(1) or high(0) > >> > + * val[7:0] is PPI number used by event-channel. > >> > + * This is only used by ARM/ARM64. > >> > + */ > >> > >> I think the name of the constant needs improvement. The low 8 > >> bits make this extremely ARM specific, so perhaps > >> HVM_PARAM_CALLBACK_TYPE_PPI? > > > > That would be OK for me. > > > > > >> Albeit - wouldn't the > >> vector and/or GSI ones be re-usable for this purpose? (I > >> don't know enough about ARM to be certain.) > > > > Vector is an x86 thing, while GSI is an ACPI term. There is probably a > > PPI to GSI mapping on ARM ACPI systems, but I wouldn't want this > > HVM_PARAM to work only with ACPI: it should work with device tree > > systems too, where GSI has no meaning. > > Okay. Then how about making _VECTOR x86-specific, and the > new one ARM-specific (via #ifdef), at once allowing (if so > wanted) both to share the same numeric value? Fine by me ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 16/17] FDT: Add a helper to get the subnode by given name
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Sometimes it needs to check if there is a subnode of given node in FDT
> by given name. Introduce this helper to get the subnode if it exists.
>
> CC: Rob Herring
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
> drivers/of/fdt.c | 13 +
> include/linux/of_fdt.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 655f79d..09001db 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -645,6 +645,19 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node,
> }
>
> /**
> + * of_get_flat_dt_subnode_by_name - get the subnode by given name
> + *
> + * @node: the parent node
> + * @uname: the name of subnode
> + * @return offset of the subnode, or -FDT_ERR_NOTFOUND if there is none
> + */
> +
> +int of_get_flat_dt_subnode_by_name(unsigned long node, const char *uname)
> +{
> + return fdt_subnode_offset(initial_boot_params, node, uname);
> +}
> +
> +/**
> * of_get_flat_dt_root - find the root node in the flat blob
> */
> unsigned long __init of_get_flat_dt_root(void)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index df9ef38..fc28162 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -52,6 +52,8 @@ extern char __dtb_end[];
> extern int of_scan_flat_dt(int (*it)(unsigned long node, const char *uname,
>int depth, void *data),
> void *data);
> +extern int of_get_flat_dt_subnode_by_name(unsigned long node,
> + const char *uname);
> extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
> int *size);
> extern int of_flat_dt_is_compatible(unsigned long node, const char *name);
> --
> 2.0.4
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/errno: Reduce complexity of inclusion
>>> On 04.03.16 at 13:24, wrote: On 03.03.16 at 15:14, wrote: >> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint >> is already > connected */ >> XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */ >> XEN_ERRNO(ETIMEDOUT,110)/* Connection timed out */ >> >> -#undef XEN_ERRNO >> #endif /* XEN_ERRNO */ >> - >> -#ifndef __XEN_PUBLIC_ERRNO_H__ >> -#define __XEN_PUBLIC_ERRNO_H__ >> - >> /* ` } */ >> >> + >> +/* >> + * Clean up from a default include. Close the enum (for C) and remove the >> + * default XEN_ERRNO from scope. >> + */ >> +#ifdef XEN_ERRNO_DEFAULT_INCLUDE >> +#undef XEN_ERRNO_DEFAULT_INCLUDE >> +#undef XEN_ERRNO >> #ifndef __ASSEMBLY__ >> }; >> #endif >> >> -#endif /* __XEN_PUBLIC_ERRNO_H__ */ >> +#endif /* XEN_ERRNO_DEFAULT_INCLUDE */ > > So far, upon reaching the end oft the file XEN_ERRNO is undefined, > no matter whether it got defined here or prior to inclusion. I think > this property should be retained, but moving the #undef to the > very end. Or rather not removing it from where it's now. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/errno: Reduce complexity of inclusion
On 04/03/16 12:28, Jan Beulich wrote: On 04.03.16 at 13:24, wrote: > On 03.03.16 at 15:14, wrote: >>> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint >>> is already >> connected */ >>> XEN_ERRNO(ENOTCONN,107)/* Transport endpoint is not connected >>> */ >>> XEN_ERRNO(ETIMEDOUT, 110)/* Connection timed out */ >>> >>> -#undef XEN_ERRNO >>> #endif /* XEN_ERRNO */ >>> - >>> -#ifndef __XEN_PUBLIC_ERRNO_H__ >>> -#define __XEN_PUBLIC_ERRNO_H__ >>> - >>> /* ` } */ >>> >>> + >>> +/* >>> + * Clean up from a default include. Close the enum (for C) and remove the >>> + * default XEN_ERRNO from scope. >>> + */ >>> +#ifdef XEN_ERRNO_DEFAULT_INCLUDE >>> +#undef XEN_ERRNO_DEFAULT_INCLUDE >>> +#undef XEN_ERRNO >>> #ifndef __ASSEMBLY__ >>> }; >>> #endif >>> >>> -#endif /* __XEN_PUBLIC_ERRNO_H__ */ >>> +#endif /* XEN_ERRNO_DEFAULT_INCLUDE */ >> So far, upon reaching the end oft the file XEN_ERRNO is undefined, >> no matter whether it got defined here or prior to inclusion. I think >> this property should be retained, but moving the #undef to the >> very end. > Or rather not removing it from where it's now. IMO, it is wrong to undef XEN_ERRNO if it was provided from external scope. The only users of this "custom" include in Xen itself, and shortly, hvmloader. I think it is fine as-is. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/errno: Reduce complexity of inclusion
>>> On 04.03.16 at 13:50, wrote: > On 04/03/16 12:28, Jan Beulich wrote: > On 04.03.16 at 13:24, wrote: >> On 03.03.16 at 15:14, wrote: @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN,106)/* Transport endpoint is already >>> connected */ XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */ XEN_ERRNO(ETIMEDOUT, 110)/* Connection timed out */ -#undef XEN_ERRNO #endif /* XEN_ERRNO */ - -#ifndef __XEN_PUBLIC_ERRNO_H__ -#define __XEN_PUBLIC_ERRNO_H__ - /* ` } */ + +/* + * Clean up from a default include. Close the enum (for C) and remove the + * default XEN_ERRNO from scope. + */ +#ifdef XEN_ERRNO_DEFAULT_INCLUDE +#undef XEN_ERRNO_DEFAULT_INCLUDE +#undef XEN_ERRNO #ifndef __ASSEMBLY__ }; #endif -#endif /* __XEN_PUBLIC_ERRNO_H__ */ +#endif /* XEN_ERRNO_DEFAULT_INCLUDE */ >>> So far, upon reaching the end oft the file XEN_ERRNO is undefined, >>> no matter whether it got defined here or prior to inclusion. I think >>> this property should be retained, but moving the #undef to the >>> very end. >> Or rather not removing it from where it's now. > > IMO, it is wrong to undef XEN_ERRNO if it was provided from external scope. Well, even if not written down, that's the intended behavior: The use case for the including file to further need that definition is rather hard to see, whereas use cases for the including file wanting to do multiple inclusion are quite easy to construct, and in that case the including file would needlessly be forced to repeatedly #undef the symbol. > The only users of this "custom" include in Xen itself, and shortly, > hvmloader. The only users you know of. I'm definitely having plans to make Linux use it too, to have a build time check that the errno values continue to be in sync. > I think it is fine as-is. I could use the same words, just for the unpatched file: I don't really agree with this part of your change. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Ping: [PATCH 0/4] ns16550: enable support for Pericom controllers
>>> On 23.02.16 at 12:22, wrote: > Patches 1 and 2 are meant to go in. Patch 3 is a prerequisite to patch > 4 and may go in as well, but patch 4 is RFC because with the Pericom > board I have MSI doesn't appear to function. Since it also does not > work in baremetal Linux when doing the trivial adjustments needed in > its driver, I suspect the feature doesn't work in general, which is > supported by the observation that the device continues to assert > INTx despite the MSI enable bit being set (causing unclaimed IRQs > until that IRQ gets shut off). While I got some responses back from > Pericom support, no actual statement of whether MSI is actually > known to work on their boards was ever made by them. I _think_ > patch 4 is correct (and hence could go in), but I have no way of > proving this by testing. > > 1: ns16550: store pointer to config parameters for PCI > 2: ns16550: enable Pericom controller support > 3: console: adjust IRQ initialization > 4: ns16550: enable use of PCI MSI > > Signed-off-by: Jan Beulich > > (Konrad, I'd appreciate if you could double check that I didn't > accidentally break the Oxford controller support.) > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-4.1 test] 85117: regressions - trouble: blocked/broken/fail/pass
flight 85117 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/85117/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 66399 test-armhf-armhf-xl-multivcpu 16 guest-start.2 fail in 82991 REGR. vs. 66399 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt 3 host-install(3) broken pass in 84995 test-armhf-armhf-xl-cubietruck 11 guest-start fail in 82991 pass in 85117 test-amd64-amd64-xl 17 guest-localmigrate/x10 fail in 84906 pass in 85117 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 84995 pass in 85117 test-armhf-armhf-xl-rtds 6 xen-boot fail in 84995 pass in 85117 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 82991 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 84906 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 84906 like 66399 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 66399 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399 test-armhf-armhf-xl-vhd 9 debian-di-installfail like 66399 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 test-armhf-armhf-libvirt 14 guest-saverestore fail in 82991 never pass test-armhf-armhf-libvirt 12 migrate-support-check fail in 82991 never pass test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 84906 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 84906 never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass version targeted for testing: linux83fdace666f72dbfc4a7681a04e3689b61dae3b9 baseline version: linux07cc49f66973f49a391c91bf4b158fa0f2562ca8 Last test of basis66399 2015-12-15 18:20:39 Z 79 days Failing since 78925 2016-01-24 13:50:39 Z 39 days 40 attempts Testing same since82845 2016-02-16 14:18:38 Z 1
[Xen-devel] [xen-unstable-smoke test] 85320: regressions - FAIL
flight 85320 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/85320/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 03720ea541382a3ca80eaaec2aa11932b03aacaf baseline version: xen 7ba900efe5f526c941b1ca055e5347947bb7eb4b Last test of basis85080 2016-03-02 16:00:54 Z1 days Testing same since85178 2016-03-03 09:20:13 Z1 days 13 attempts People who touched revisions under test: Andrew Cooper Aravind Gopalakrishnan Boris Ostrovsky Dario Faggioli Hanjun Guo Jan Beulich Juergen Gross Naresh Bhat Parth Dixit Shannon Zhao Shannon Zhao Stefano Stabellini Tomasz Nowicki jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 323 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [V3] x86/xsaves: calculate the xstate_comp_offsets base on xcomp_bv
>>> On 04.03.16 at 12:00, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -934,8 +934,14 @@ long arch_do_domctl(
> goto vcpuextstate_out;
> }
>
> -expand_xsave_states(v, xsave_area,
> -size - 2 * sizeof(uint64_t));
> +ret = expand_xsave_states(v, xsave_area,
> + size - 2 * sizeof(uint64_t));
> +if ( ret )
> +{
> +xfree(xsave_area);
> +vcpu_unpause(v);
> +goto vcpuextstate_out;
> +}
Well, while this is one way to deal with the problem, it's certainly
not the most desirable one: We should try to avoid runtime
allocations, failures of which then cause other things to fail (in
perhaps not very graceful ways). And doing so is pretty simple
here, and you even have two options: Either allocate a per-CPU
array, or - considering that XCNTXT_MASK has only a limited
number of bits set - even use an on-stack array of suitable
(compile time determined from XCNTXT_MASK) size. If you
want to save space, this could presumably even be uint16_t[],
in which case I think it would further be okay if all 63 possible
features were known (totaling to a variable size of 126 bytes).
This is even more so considering that you forgot to adjust
hvm.c in a similar manner.
> @@ -111,21 +111,27 @@ static int setup_xstate_features(bool_t bsp)
> for ( leaf = 2; leaf < xstate_features; leaf++ )
> {
> if ( bsp )
> +{
> cpuid_count(XSTATE_CPUID, leaf, &xstate_sizes[leaf],
> -&xstate_offsets[leaf], &tmp, &tmp);
> +&xstate_offsets[leaf], &ecx, &edx);
> +if ( ecx & XSTATE_ALIGN64 )
> +set_bit(leaf, &xstate_align);
__set_bit()
> @@ -134,22 +140,26 @@ static void __init setup_xstate_comp(void)
> * in the fixed offsets in the xsave area in either compacted form
> * or standard form.
> */
> -xstate_comp_offsets[0] = 0;
> xstate_comp_offsets[1] = XSAVE_SSE_OFFSET;
>
> xstate_comp_offsets[2] = FXSAVE_SIZE + XSAVE_HDR_SIZE;
>
> for ( i = 3; i < xstate_features; i++ )
> {
> -xstate_comp_offsets[i] = xstate_comp_offsets[i - 1] +
> - (((1ul << i) & xfeature_mask)
> - ? xstate_sizes[i - 1] : 0);
> -ASSERT(xstate_comp_offsets[i] + xstate_sizes[i] <= xsave_cntxt_size);
> +if ( (1ul << i) & xcomp_bv )
> +{
> +xstate_comp_offsets[i] = test_bit(i, &xstate_align) ?
> + ROUNDUP(xstate_comp_offsets[i - 1], 64)
> :
> + xstate_comp_offsets[i -1];
> +xstate_comp_offsets[i] += xstate_sizes[i - 1];
> +ASSERT(xstate_comp_offsets[i] + xstate_sizes[i] <=
> xsave_cntxt_size);
> +}
This now seems wrong for the case when there are discontiguous
bits in xcomp_bv, as you leave zeros in the array (which by itself
is fine, but confuses the subsequent iteration). I think you'd
benefit from having a local variable holding the offset you're
currently at:
offset = xstate_comp_offsets[2];
for ( i = 2; i < xstate_features; i++ )
{
if ( (1ul << i) & xcomp_bv )
{
if ( test_bit(i, &xstate_align) )
offset = ROUNDUP(offset, 64);
xstate_comp_offsets[i] = offset;
offset += xstate_sizes[i];
ASSERT(offset <= xsave_cntxt_size);
}
}
or something along those lines.
> static void *get_xsave_addr(struct xsave_struct *xsave,
> -unsigned int xfeature_idx)
> +unsigned int *xstate_comp_offsets,
const
> @@ -94,8 +96,8 @@ bool_t xsave_enabled(const struct vcpu *v);
> int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum,
> const struct xsave_hdr *);
> int __must_check handle_xsetbv(u32 index, u64 new_bv);
> -void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size);
> -void compress_xsave_states(struct vcpu *v, const void *src, unsigned int
> size);
> +int expand_xsave_states(struct vcpu *v, void *dest, unsigned int size);
> +int compress_xsave_states(struct vcpu *v, const void *src, unsigned int
> size);
While with the above I assume these are going to remain what
they have been, a general advice: If you convert a function
from having void return type to something else, and that
something else can indicate an error, use __must_check so the
compiler can tell you whether you've forgotten to update some
caller.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one
On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote: > On March 04, 2016 5:29pm, wrote: > > On March 04, 2016 7:59am, wrote: > > > > > Also I'd highlight the below modification: > > > -if ( !spin_trylock(&pcidevs_lock) ) > > > -return -ERESTART; > > > - > > > +pcidevs_lock(); > > > > > > IMO, it is right too. > > Well, I'll have to see where exactly this is (pulling such out of > > context is pretty > > unhelpful), but I suspect it can't be replaced like this. > > > Jan, I am looking forward to your review. > btw, It is in the assign_device(), in the > xen/drivers/passthrough/pci.c file. > Mmm... If multiple cpus calls assign_device(), and the calls race, the behavior between before and after the patch looks indeed different to me. In fact, in current code, the cpus that find the lock busy already, would quit the function immediately and a continuation is created. On the other hand, with the patch, they would spin and actually get the lock, one after the other (if there's more of them) at some point. Please, double check my reasoning, but I looks to me that it is indeed different what happens when the hypercall is restarted (i.e., in current code) and what happens if we just let others take the lock and execute the function (i.e., with the patch applied). I suggest you try to figure out whether that is actually the case. Once you've done, feel free to report here and ask for help for finding a solution, if you don't see one. > > > > but I'd add a mention of this in the changelog. > > > In git log? > > To be honest, changes like this would better not be buried in a big > > rework like > > the one here. Make it a prereq patch, where you then will kind of > > automatically > > describe why it's correct. (I agree current code is bogus, and > > we're not hitting > > the respective > > BUG_ON() in check_lock() only because spin_debug gets set to true > > only after > > most __init code has run.) > Agreed, I would make a prereq patch in v7. > Ok. In general, I agree with Jan. In this case, I suggested just mentioning in changelog as we curently basically have a bug, and I think it would be fine to have something like "Doing what we do also serves as a fix for a bug found in xxx yyy". But it's indeed Jan's call, and his solution is certainly cleaner. Not to mention that, in the case of assign_device(), fixing that would most likely require being done in a patch on its own anyway. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D 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] [V2] x86/xsaves: fix overwriting between non-lazy/lazy xsaves
>>> On 04.03.16 at 12:22, wrote: > The offset at which components xsaved by xsave[sc] are not fixed. > So when when a save with v->fpu_dirtied set is followed by one > with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data > written by the lazy one. > > The solution is when xsave[sc] is enabled and taking xcr0_accum into > consideration, if guest has ever used lazy states, vcpu_xsave_mask will > return XSTATE_ALL. Otherwise vcpu_xsave_mask will return XSTATE_NONLAZY. > This may cause overhead save on lazy states which will cause performance > impact. As xsavec support code will be cleaned up(reason is list below), > so the patch only take xsaves into consideration. > > After doing some performance test on xsavec and xsaveopt(suggested by jan), > the result show xsaveopt performs better than xsavec. So next step clean up > xsavec suppot code in xen and disable xsaves (xsaves should be used when > supervised state is introduced). I'd rather see this being right away except of just getting mentioned here; I don't expect this to be too difficult a change. > --- a/xen/arch/x86/i387.c > +++ b/xen/arch/x86/i387.c > @@ -118,7 +118,8 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu > *v) > if ( v->fpu_dirtied ) > return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY; > > -return v->arch.nonlazy_xstate_used ? XSTATE_NONLAZY : 0; > +return cpu_has_xsaves && (v->arch.xcr0_accum & XSTATE_LAZY & > ~XSTATE_FP_SSE) ? If (here or in the suggested future patch) such an expression is needed, I'd highly recommend accompanying it by a comment explaining what this is about (i.e. specifically why the low two bits can be ignored for the purpose here). In any event you will need to make the commit description (which currently just says "if guest has ever used lazy states") match this. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] XSA-155: _apparently_ missing blktap1 fix (up to 4.5)
On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote: > In the course of backporting other XSA fixes to very old trees I had > noticed that the XSA-155 had shrunk to just the change to > xen/include/public/io/ring.h at some point, which didn't seem right. > Clearly up to 4.5 the situation of blktap1 is the same as that of > blktap2, i.e. one would think it also needs to be fixed. However, in > the course of doing so I stumbled across the code blindly using > req->id as an array index (which similarly is the case for blktap2). > That alone would be another security issue, if only the first change Yes. We fixed that in blkback some time ago, but yes that code base has some quite errant bugs in it. Would love to say I can fix them, but the TODO list is getting a bit long. > really addressed one. But it didn't: The rings we're talking about > here are those interfacing with the kernel module, and it's only the > kernel module which interfaces with the guest ring. > > Bottom line: No fix is needed to blktap1, and the change to blktap2 > didn't really fix anything either. It merely made things slightly slower > due to the extra copy operation. (I haven't fully understood the > purpose of block-log.c yet, but I can't see how it would manage to > bypass the kernel module and interface directly with the frontend > in the guest, the more that tdlog_open() sets up its ring using > shm_open(), implying host local operation. Hence that part of the > change, which has no blktap1 equivalent, should not be needed > either.) > > Therefore, Ian, I'd like to request that the blktap2 change not be > backported to any of the stable trees - only the libvchan one > should make it there (and the prereq to the blktap2 one, adding > RING_COPY_REQUEST(), then isn't needed either). Since that > blktap2 change isn't entirely benign, I think we should even > consider reverting it from master. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 3/5] IOMMU: Make the pcidevs_lock a recursive one
>>> On 04.03.16 at 14:59, wrote: > On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote: >> On March 04, 2016 5:29pm, wrote: >> > To be honest, changes like this would better not be buried in a big >> > rework like >> > the one here. Make it a prereq patch, where you then will kind of >> > automatically >> > describe why it's correct. (I agree current code is bogus, and >> > we're not hitting >> > the respective >> > BUG_ON() in check_lock() only because spin_debug gets set to true >> > only after >> > most __init code has run.) >> Agreed, I would make a prereq patch in v7. >> > Ok. In general, I agree with Jan. > > In this case, I suggested just mentioning in changelog as we curently > basically have a bug, and I think it would be fine to have something > like "Doing what we do also serves as a fix for a bug found in xxx > yyy". > > But it's indeed Jan's call, and his solution is certainly cleaner. Well, one of the reasons to separate out bug fixes is to make them backportable. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable baseline-only test] 44216: regressions - trouble: blocked/broken/fail/pass
This run is configured for baseline tests only. flight 44216 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/44216/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm3 host-install(3) broken REGR. vs. 44208 test-amd64-i386-pair 4 host-install/dst_host(4) broken REGR. vs. 44208 test-armhf-armhf-xl-xsm 10 debian-fixup fail REGR. vs. 44208 Regressions which are regarded as allowable (not blocking): build-amd64-rumpuserxen 6 xen-buildfail like 44208 build-i386-rumpuserxen6 xen-buildfail like 44208 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeatfail like 44208 test-amd64-amd64-xl-xsm 19 guest-start/debian.repeatfail like 44208 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 44208 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44208 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 test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 12 saverestore-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 13 guest-saverestorefail never pass test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 3f19ca9ad0b66c57c91921dc8a695634eee0c679 baseline version: xen 986d9fc3bbf8a6d9d088ca22d1422bd5de249396 Last test of basis44208 2016-03-02 13:50:31 Z2 days Testing same since44216 2016-03-03 20:57:55 Z0 days1 attempts People who touched revisions under test: Boris Ostrovsky for SVM bits Doug Goldstein Feng Wu Haozhong Zhang Ian Campbell Ian Jackson Jan Beulich Kevin Tian Liang Li Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm
Re: [Xen-devel] XSA-155: _apparently_ missing blktap1 fix (up to 4.5)
>>> On 04.03.16 at 15:09, wrote: > On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote: >> In the course of backporting other XSA fixes to very old trees I had >> noticed that the XSA-155 had shrunk to just the change to >> xen/include/public/io/ring.h at some point, which didn't seem right. >> Clearly up to 4.5 the situation of blktap1 is the same as that of >> blktap2, i.e. one would think it also needs to be fixed. However, in >> the course of doing so I stumbled across the code blindly using >> req->id as an array index (which similarly is the case for blktap2). >> That alone would be another security issue, if only the first change > > Yes. We fixed that in blkback some time ago, but yes that code base > has some quite errant bugs in it. > > Would love to say I can fix them, but the TODO list is getting > a bit long. But my point was - there is (and was) nothing to fix there. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] arm/timer: fix panic when booting with DT
While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
refactors the functions preinit_xen_time and init_xen_time. But it
wrongly moves the platform_get_irq from init_xen_time to
preinit_dt_xen_time and this will cause booting failure.
So move platform_get_irq back to init_xen_time to fix it.
Signed-off-by: Shannon Zhao
---
v2: refactor the codes as a small function
---
xen/arch/arm/time.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index 5f8f974..7dae28b 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -119,7 +119,6 @@ static void __init preinit_dt_xen_time(void)
};
int res;
u32 rate;
-unsigned int i;
timer = dt_find_matching_node(NULL, timer_ids);
if ( !timer )
@@ -133,16 +132,6 @@ static void __init preinit_dt_xen_time(void)
cpu_khz = rate / 1000;
timer_dt_clock_frequency = rate;
}
-
-/* Retrieve all IRQs for the timer */
-for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
-{
-res = platform_get_irq(timer, i);
-
-if ( res < 0 )
-panic("Timer: Unable to retrieve IRQ %u from the device tree", i);
-timer_irq[i] = res;
-}
}
void __init preinit_xen_time(void)
@@ -165,9 +154,28 @@ void __init preinit_xen_time(void)
boot_count = READ_SYSREG64(CNTPCT_EL0);
}
+static void __init init_dt_xen_time(void)
+{
+int res;
+unsigned int i;
+
+/* Retrieve all IRQs for the timer */
+for ( i = TIMER_PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++ )
+{
+res = platform_get_irq(timer, i);
+
+if ( res < 0 )
+panic("Timer: Unable to retrieve IRQ %u from the device tree", i);
+timer_irq[i] = res;
+}
+}
+
/* Set up the timer on the boot CPU (late init function) */
int __init init_xen_time(void)
{
+if ( acpi_disabled )
+init_dt_xen_time();
+
/* Check that this CPU supports the Generic Timer interface */
if ( !cpu_has_gentimer )
panic("CPU does not support the Generic Timer v1 interface");
--
2.1.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.3-testing test] 85121: regressions - trouble: blocked/broken/fail/pass
flight 85121 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/85121/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004 build-armhf 3 host-install(3) broken REGR. vs. 83004 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 83004 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 83004 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 83004 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 83004 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 404e83e055cb419efccbcb0c5c89476307a9ae46 baseline version: xen ccc7adf9cff5d5f93720afcc1d0f7227d50feab2 Last test of basis83004 2016-02-18 14:47:44 Z 14 days Testing same since84923 2016-03-01 13:41:07 Z3 days3 attempts People who touched revisions under test: Ian Campbell Ian Jackson Wei Liu jobs: build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopsbroken build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl blocked test-amd64-i386-xl pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64fail test-amd64-i386-xl-qemut-debianhvm-amd64 fail test-amd64-amd64-xl-qemuu-debianhvm-amd64fail test-amd64-i386-xl-qemuu-debianhvm-amd64 fail test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail
