Hi Konrad,
On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:
On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
[...]
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 22806b6..fe83653 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -82,6 +82,6 @@ subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
.PHONY: tests
tests:
-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq ($(XEN_TARGET_ARCH),arm32)
$(MAKE) -f $(BASEDIR)/Rules.mk -C test livepatch
endif
diff --git a/xen/common/test/Makefile b/xen/common/test/Makefile
index 23dff1d..3eed6dd 100644
--- a/xen/common/test/Makefile
+++ b/xen/common/test/Makefile
@@ -1,5 +1,11 @@
include $(XEN_ROOT)/Config.mk
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+else
Is there any reason to fallback on arm64 flags by default? Would not it be
better to have an else if here?
+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
I presume you are referring to this comment. I am not sure how you would
identify whether the elf64-littleaarch64 is not part of the OBJCOPY?
Oh I guess you can: objcopy --info
Or are you saying just use 'arm64' instead of 'aarch64' ?
I was suggesting to do
ifeq ($(XEN_TARGET_ARCH),x86_64))
OBJCOPY_MAGIC := ...
endif
ifeq ($(XEN_TARGET_ARCH),arm64))
OBJCOPY_MAGIC := ...
endif
+endif
+
CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
@@ -54,7 +60,7 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
.PHONY: note.o
note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id
$(BASEDIR)/xen-syms $@.bin
- $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ $(OBJCOPY) $(OBJCOPY_MAGIC) \
--rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin
@@ -65,7 +71,7 @@ note.o:
.PHONY: hello_world_note.o
hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH)
$@.bin
- $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ $(OBJCOPY) $(OBJCOPY_MAGIC) \
--rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin
diff --git a/xen/common/test/xen_hello_world_func.c
b/xen/common/test/xen_hello_world_func.c
index 03d6b84..0e1a722 100644
--- a/xen/common/test/xen_hello_world_func.c
+++ b/xen/common/test/xen_hello_world_func.c
@@ -6,14 +6,17 @@
#include <xen/types.h>
#include <asm/alternative.h>
+#ifdef CONFIG_X86
#include <asm/nops.h>
#include <asm/uaccess.h>
static unsigned long *non_canonical_addr = (unsigned long
*)0xdead000000000000ULL;
+#endif
/* Our replacement function for xen_extra_version. */
const char *xen_hello_world(void)
{
+#ifdef CONFIG_X86
unsigned long tmp;
int rc;
@@ -24,7 +27,9 @@ const char *xen_hello_world(void)
*/
rc = __get_user(tmp, non_canonical_addr);
BUG_ON(rc != -EFAULT);
-
+#else
+ asm(ALTERNATIVE("nop", "nop", 1));
Why the hardcoded 1 here? I am wondering if we should introduce a new
capability "LIVEPATCH_TEST" which is enabled by default. So we can test that
the the alternative is working on all the platform. What do you think?
Sure, but I am not sure what number you would like? Perhaps 42 :-) ?
Unfortunately the number is an index in the bitmap, so we have to
allocate them contiguously.
Also, this made me realize that the current implementation of
apply_alternatives cannot work if we are patching outside the xen binary. :/
I need to have a think to see how we can handle any region.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
