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
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
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
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?
> >
> >
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,
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
28 matches
Mail list logo