Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Julien Grall <julien.grall@xxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel