Hi,
On 03/10/17 17:19, Andrew Cooper wrote:
On 03/10/17 17:03, Wei Liu wrote:
diff --git a/xen/common/ubsan/ubsan.c b/xen/common/ubsan/ubsan.c
new file mode 100644
index 0000000000..aa359e712c
--- /dev/null
+++ b/xen/common/ubsan/ubsan.c
@@ -0,0 +1,486 @@
+/*
+ * UBSAN error reporting functions
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Andrey Ryabinin <ryabinin....@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Adapt to Xen by:
+ * Andrew Cooper <andrew.coop...@citrix.com>
+ * Wei Liu <wei.l...@citrix.com>
+ */
+
+#include <xen/bitops.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/types.h>
+#include <xen/sched.h>
+#include <xen/spinlock.h>
+#include <xen/percpu.h>
+
+#define pr_err(...) printk(XENLOG_ERR __VA_ARGS__)
+#define dump_stack dump_execution_state
+#define __noreturn noreturn
+#define CONFIG_ARCH_SUPPORTS_INT128
+#define u64 long long unsigned int
+#define s64 long long int
These last three should be in asm-$ARCH/config.h or similar. I'm fairly
sure arm32 will struggle with INT128.
AFAICT, Linux doesn't enable this option for both arm64 and arm32.
Also, I think the current (re)engineering should stay. There is nothing
vcpu specific about the in_ubsan flag. (Especially, given your
tbutils.o observation above.)
As for commits introducing the code, I had a vague plan to introduce the
unmodified code from upstream Linux, then my forward ported patch (as
that isn't in Linux, even today), and then a change adding the Kconfig
option, and these defines, to get it to compile.
That would be handy to see the changes.
Given that this is clearly a debugging option, and its basically ready,
I wouldn't necessarily hold off from putting it into 4.10.
I thought about the same when I saw the patch. I guess we can get UBSAN
support for x86 into Xen 4.10. I don't think it will be possible for Arm
given the necessary rework in the memory layout (we need to expand the
region size for Xen mapping) and assembly.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
