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

Reply via email to