[Xen-devel] [linux-3.14 baseline-only test] 67694: regressions - FAIL

This run is configured for baseline tests only. flight 67694 linux-3.14 real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67694/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 6 xen-boot

[Xen-devel] [xen-unstable baseline-only test] 67693: regressions - trouble: blocked/broken/fail/pass

This run is configured for baseline tests only. flight 67693 xen-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/67693/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-xsm 11 guest-start

[Xen-devel] Outreachy Winter Internship

Hello Sir,I am Kavya Sharma, an aspiring Outreachy intern.It would be my privilege to be an intern with xenproject.org this winter.I have read about Xen Hypervisor Userspace Tools and I am interested in your project 'golang bindings for libxl'. Sir,can you please guide me on this and also

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-09 11:14:50, Ian Jackson wrote: > Jan Beulich writes ("Re: [PATCH 1/3] x86: refactor psr implementation in > hypervisor."): > > On 09.09.16 at 10:09, wrote: > > > Sorry, I may misunderstand you. Maybe "check_exceed_cos_max" is a good > > > name? > > > >

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

On 16-09-09 02:32:25, Jan Beulich wrote: > >>> On 09.09.16 at 10:09, wrote: > > On 16-09-08 03:54:24, Jan Beulich wrote: > >> >>> On 08.09.16 at 09:28, wrote: > >> > On 16-09-07 03:01:34, Jan Beulich wrote: > >> >> >> >>> On 25.08.16 at 07:22,

Re: [Xen-devel] [PATCH V2] xen/arm: arm64: Update the Image header

Hi Julien, On Fri, Sep 09, 2016 at 02:19:33PM +0100, Julien Grall wrote: >Hello Peng, > >On 01/09/16 02:38, Peng Fan wrote: >>This patch is mainly modified from Linux kernel: >>[1] commit a2c1d73b94ed: arm64: Update the Image header >>[2] commit 6ad1fe5d9077: arm64: avoid R_AARCH64_ABS64

[Xen-devel] [PATCH v3 09/18] livepatch/arm/x86: Check payload for for unwelcomed symbols.

Certain platforms, such as ARM [32|64] add extra mapping symbols such as $x (for ARM64 instructions), or more interesting to this patch: $t (for Thumb instructions). These symbols are suppose to help the final linker to make any adjustments (such as add an veneer). But more importantly - we do not

[Xen-devel] [PATCH v3 15/18] bug/x86/arm: Align bug_frames sections.

Most of the WARN_ON or BUG_ON sections are properly aligned on x86. However on ARM and on x86 assembler the macros don't include any aligment information - hence they end up being the default byte granularity. On ARM32 it is paramount that the aligment is word-size (4) otherwise if one tries to

[Xen-devel] [PATCH v3 16/18] livepatch: ARM32 support.

The patch piggybacks on: livepatch: Initial ARM64 support, which brings up all of the neccessary livepatch infrastructure pieces in. This patch adds three major pieces: 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which means the adddendum had to be extracted from within the

[Xen-devel] [PATCH v3 17/18] livepatch, arm[32|64]: Share arch_livepatch_revert_jmp

It is exactly the same in both platforms. No functional change. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Julien Grall Cc: Stefano Stabellini v3: New submission. --- xen/arch/arm/arm32/livepatch.c | 19

[Xen-devel] [PATCH v3 11/18] livepatch: tests: Move the .name value to .rodata

Right now the contents of 'name' are all located in the .data section. We want them in the .rodata section so change the type to have const on them. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Andrew Cooper Cc: Jan Beulich

[Xen-devel] [PATCH v3 01/18] arm/x86: Add HAS_[ALTERNATIVE|EX_TABLE]

x86 implements all of them by default - and we just add two extra HAS_ variables to be declared in autoconf.h. ARM 64 only has alternative while ARM 32 has none of them. The ARM64 is going to be a bit funny as there is an ALTERNATIVE already and we end up selecting the HAS_ALTERNATIVE whenever

[Xen-devel] [PATCH v3 05/18] arm: poison initmem when it is freed.

The current byte sequence is '0xcc' which makes sense on x86, but on ARM it is: stclgt 12, cr12, [ip], {204} ; 0xcc Picking something more ARM applicable such as: efefefefsvc 0x00efefef Creates a nice crash if one executes that code: (XEN) CPU1: Unexpected Trap:

[Xen-devel] [PATCH v3 06/18] livepatch: Initial ARM64 support.

As compared to x86 the va of the hypervisor .text is locked down - we cannot modify the running pagetables to have the .ro flag unset. We borrow the same idea that alternative patching has - which is to vmap the entire .text region and use the alternative virtual address for patching. Since we

[Xen-devel] [PATCH v3 07/18] livepatch: ARM/x86: Check displacement of old_addr and new_addr

If the distance is too great we are in trouble - as our relocation distance can surely be clipped, or still have a valid width - but cause an overflow of distance. On various architectures the maximum displacement for a unconditional branch/jump varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while

[Xen-devel] [PATCH v3 18/18] livepatch: arm[32, 64], x86: NOP test-case

The test-case is quite simple - we NOP the 'xen_minor_version'. The amount of NOPs depends on the architecture. On x86 the function is 11 bytes long: 55 push %rbp <- NOP 48 89 e5mov%rsp,%rbp <- NOP b8 04 00 00 00 mov$0x4,%eax

[Xen-devel] [PATCH v3 04/18] arm/mm: Introduce modify_xen_mappings

Which is only used by Livepatch code. The purpose behind this call is to modify the page table entries flags. Specifically the .ro and .nx flags. The current mechanism puts cache attributes in the flags and the .ro and .nx are locked down and assumed to be .ro=0, nx=1. Livepatch needs .nx=0 and

[Xen-devel] [PATCH v3 10/18] livepatch: Move test-cases to their own sub-directory in test.

So they can be shared with ARM64 (but not yet, so they are only built on x86). No functional change. We also need to tweak the MAINTAINERS and .gitignore file. Also we need to update SUBDIRS to include the new 'test' directory so 'cscope' can show the example livepatches. Acked-by: Jan Beulich

[Xen-devel] [PATCH v3] Livepatch for ARM 64 and 32.

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last] - Addressed the two outstanding concerns: CPU bit feature to test alternative test-case, and errata #843419 on some Cortex-A53 - Dealt with comments from Jan, Julien and Andrew. - Fixed (offlist) with Julien ARM32 not

[Xen-devel] [PATCH v3 14/18] xen/arm32: Add an helper to invalidate all instruction caches

This is exactly like commit fb9d877a9c0f3d4d15db8f6e0c5506ea641862c6 "xen/arm64: Add an helper to invalidate all instruction caches" except it is on ARM32 side. When we are flushing the cache we are most likley also want to flush the branch predictor too. Hence we add this. Signed-off-by: Konrad

[Xen-devel] [PATCH v3 08/18] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

Those symbols are used to help final linkers to replace insn. The ARM ELF specification mandates that they are present to denote the start of certain CPU features. There are two variants of it - short and long format. Either way - we can ignore these symbols. Reviewed-by: Andrew Cooper

[Xen-devel] [PATCH v5 3/4] livepatch: NOP if func->new_addr is zero.

The NOP functionality will NOP any of the code at the 'old_addr' or at 'name' if the 'new_addr' is zero. The purpose of this is to NOP out calls, such as: e8 <4-bytes-offset> (5 byte insn), or on ARM a 4 byte insn for branching. We need the EIP of where we need to the NOP, and that can be

[Xen-devel] [PATCH v5] Livepatch fixes and general features for Xen 4.8.

Hey! Since v4: [https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02705.html] - Committed Acked/Reviewed patches. - Discarded couple of patches to address later. Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-08/msg01825.html] - Acked on reviews v2, v1: - Left

[Xen-devel] [PATCH v5 2/4] livepatch: Add limit of 2MB to payload .bss sections.

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793 "xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the size of the binary at 2MB. We follow that in capping the size of the .BSSes to be at maximum 2MB. Signed-off-by: Konrad Rzeszutek Wilk --- Cc:

[Xen-devel] [PATCH v5 4/4] livepach: Add .livepatch.hooks functions and test-case

From: Ross Lagerwall Add hook functions which run during patch apply and patch revert. Hook functions are used by livepatch payloads to manipulate data structures during patching, etc. One use case is the XSA91. As Martin mentions it: "If we have shadow variables, we

[Xen-devel] [linux-3.14 test] 100885: tolerable FAIL - PUSHED

flight 100885 linux-3.14 real [real] http://logs.test-lab.xenproject.org/osstest/logs/100885/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100784

[Xen-devel] [xen-unstable-coverity test] 100886: all pass - PUSHED

flight 100886 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/100886/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc baseline version: xen

[Xen-devel] [xen-unstable test] 100884: tolerable FAIL - PUSHED

flight 100884 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/100884/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100844