The new format specifier is '%pp', and prints a pci_sbdf_t using the
seg:bus:dev.func format. Replace all SBDFs printed using
'%04x:%02x:%02x.%u' to use the new format specifier.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Use base 8 to print the functi
flight 140501 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140501/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140491
Tests which
flight 140468 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140468/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 86c98d165a4b667fe15d1c139a5cb363cec17282
baseline version:
freebsd 41a4c010326
On 8/17/2019 7:04 AM, Andrew Cooper wrote:
>> Similarly, to what extent does the dom0 (or other such
>> privileged domain) utilize "foreign memory maps" to reach into another
>> guest's memory? I understand that this is necessary when creating a
>> guest, for live migration, and for QEMU to emulate
flight 140458 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 15 guest-saverestorefail REGR. vs. 140282
test-amd64-i386-x
flight 140494 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 140491
Tests which
flight 140451 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140451/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which are fail
Xen will only print a warning if there are memory unallocated when using
1:1 mapping (only used by dom0). This also includes the case where no
memory has been allocated.
It will bring to all sort of issues that can be hard to diagnostic for
users (the warning can be difficult to spot or disregard)
flight 140454 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 15 guest-start/debian.repeat fail REGR. vs.
139829
build-amd64-xsm
Hi Pawel,
On 8/21/19 9:19 AM, Pawel Wieczorkiewicz wrote:
Livepatch only tracks an entire payload applied/reverted state. But,
with an option to supply the apply_payload() and/or revert_payload()
functions as optional hooks, it becomes possible to intermix the
execution of the original apply_pay
flight 140491 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140491/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi,
On 8/21/19 11:20 AM, Andrew Cooper wrote:
On 21/08/2019 11:04, Pawel Wieczorkiewicz wrote:
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index dd8b47a1fa..18b9684aeb 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -55,7 +55,7 @@ static int
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ws16-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
> On 21. Aug 2019, at 20:49, Konrad Rzeszutek Wilk
> wrote:
>
>
>> +# Using xen-syms built in the previous step by build_full().
>> +SPECIAL_VARS=$(readelf -wi "$OUTPUT/xen-syms" |
>
> What version of readelf supports this? Asking as in the past there were some
> options with binutil
On 21. Aug 2019, at 20:31, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:
On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receiv
> On 21. Aug 2019, at 20:30, Konrad Rzeszutek Wilk
> wrote:
>
> On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
>> typedef enum livepatch_func_state {
>> LIVEPATCH_FUNC_NOT_APPLIED = 0,
>> LIVEPATCH_FUNC_APPLIED = 1
>> @@ -838,11 +850,12 @@ struct livepatch_func {
>> uint32_t ne
> On 21. Aug 2019, at 20:28, Konrad Rzeszutek Wilk
> wrote:
>
> On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
>> struct livepatch_func {
>> const char *name; /* Name of function to be patched. */
>> void *new_addr;
>> @@ -834,6 +839,10 @@ struct livepatch_func {
>> uint3
> On 21. Aug 2019, at 20:12, Konrad Rzeszutek Wilk
> wrote:
>
> On 8/14/19 4:39 AM, Pawel Wieczorkiewicz wrote:
>> #ifdef __XEN__
>> +typedef enum livepatch_func_state {
>> +LIVEPATCH_FUNC_NOT_APPLIED = 0,
>> +LIVEPATCH_FUNC_APPLIED = 1
>> +} livepatch_func_state_t;
>> +
>> struct live
On 21. Aug 2019, at 20:09, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:
On 8/14/19 4:38 AM, Pawel Wieczorkiewicz wrote:
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-
flight 140444 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140444/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR.
vs. 139698
Tests which
On 21. Aug 2019, at 20:10, Konrad Rzeszutek Wilk
mailto:konrad.w...@oracle.com>> wrote:
On 8/14/19 4:38 AM, Pawel Wieczorkiewicz wrote:
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receiv
+# Using xen-syms built in the previous step by build_full().
+SPECIAL_VARS=$(readelf -wi "$OUTPUT/xen-syms" |
What version of readelf supports this? Asking as in the past there were
some options with binutils that had conflicting options and we had to
add some custom hackery code to
On 8/15/19 12:29 PM, Andrew Cooper wrote:
On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote:
Thanks Julien. I will do that next time (unless you guys want me to
re-send all this ;-)).
BTW, I also pushed my changes onto the xenbits server:
http://xenbits.xenproject.org/gitweb/?p=people/wipawel/li
On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standar
On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
typedef enum livepatch_func_state {
LIVEPATCH_FUNC_NOT_APPLIED = 0,
LIVEPATCH_FUNC_APPLIED = 1
@@ -838,11 +850,12 @@ struct livepatch_func {
uint32_t new_size;
uint32_t old_size;
uint8_t version;/* MUST be LIV
On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
struct livepatch_func {
const char *name; /* Name of function to be patched. */
void *new_addr;
@@ -834,6 +839,10 @@ struct livepatch_func {
uint32_t old_size;
uint8_t version;/* MUST be LIVEPATCH_PAYLOAD_VERS
From: Oleksandr Tyshchenko
There is a strict requirement for the IOMMU which wants to share
the P2M table with the CPU. The maximum supported by the IOMMU
Stage-2 input size must be greater or equal to the P2M IPA size.
So, first initialize the IOMMU and gather the requirements and
then initiali
On 8/21/19 4:19 AM, Pawel Wieczorkiewicz wrote:
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
In order to prevent (up)loading any hotpatches built for diffe
On 8/14/19 4:39 AM, Pawel Wieczorkiewicz wrote:
#ifdef __XEN__
+typedef enum livepatch_func_state {
+LIVEPATCH_FUNC_NOT_APPLIED = 0,
+LIVEPATCH_FUNC_APPLIED = 1
+} livepatch_func_state_t;
+
struct livepatch_func {
const char *name; /* Name of function to be patched. */
flight 140483 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140483/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 8/14/19 4:38 AM, Pawel Wieczorkiewicz wrote:
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-byte alignment padding to reserve
place for future flags and options.
The new fields are
On 8/14/19 4:38 AM, Pawel Wieczorkiewicz wrote:
By default, in the quiescing zone, a hotpatch payload is applied with
apply_payload() and reverted with revert_payload() functions. Both of
the functions receive the payload struct pointer as a parameter. The
functions are also a place where standar
Hi Paul,
Thank you for the review,
On 20/08/2019 09:15, Paul Durrant wrote:
-Original Message-
From: Julien Grall
Sent: 19 August 2019 15:27
To: xen-devel@lists.xenproject.org
Cc: Julien Grall ; Stefano Stabellini
; Volodymyr
Babchuk ; Andrew Cooper
; George Dunlap
; Ian Jackson ; Ja
Hi,
On 20/08/2019 14:12, Andrew Cooper wrote:
On 19/08/2019 19:37, Julien Grall wrote:
Hi Andrew,
On 8/19/19 7:04 PM, Andrew Cooper wrote:
On 19/08/2019 19:01, Julien Grall wrote:
Commit b5e6e1ee8da "xen/console: Don't treat NUL character as the end
of the buffer" extended sercon_puts to tak
flight 140448 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140448/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9c90d39b600bd33c7e0600865e6d860d46ce95f3
baseline version:
ovmf 0970a80583a9a0595eb35
flight 140442 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
139876
test-amd64-amd6
On 21.08.19 18:47, Paul Durrant wrote:
Hi
You should also check whether the new requested alignment is compatible with
the existing block
alignment
I am wondering:
In case when we use only type-safe construction for the basic allocation
(xmalloc) and type-safe construction for the re-allo
From: David Woodhouse
Ditch the bootsym() access from C code for the variables populated by
16-bit boot code. As well as being cleaner this also paves the way for
not having the 16-bit boot code in low memory for no-real-mode or EFI
loader boots at all.
These variables are put into a separate .d
From: David Woodhouse
If the no-real-mode flag is set, don't go there at all. This is a prelude
to not even putting it there in the first place.
Signed-off-by: David Woodhouse
---
xen/arch/x86/boot/head.S | 10 ++
xen/arch/x86/boot/trampoline.S | 4
2 files changed, 10 inse
From: David Woodhouse
In preparation for splitting the boot and permanent trampolines from
each other. Some of these will change back, but most are boot so do the
plain search/replace that way first, then a subsequent patch will extract
the permanent trampoline code.
Signed-off-by: David Woodhou
From: David Woodhouse
Where booted from EFI or with no-real-mode, there is no need to stomp
on low memory with the 16-boot code. Instead, just go straight to
trampoline_protmode_entry() at its physical location within the Xen
image, having applied suitable relocations.
This means that the GDT ha
Some cleanups for the boot path, originally inspired by an attempt to
avoid scribbling on arbitrarily-chosen low memory.
In the no-real-mode case we don't need to bounce through low memory at
all; we can run the 32-bit trampoline in-place in the Xen image.
The variables containing information whi
From: David Woodhouse
As a first step toward using the low-memory trampoline only when necessary
for a legacy boot without no-real-mode, clean up the relocations into
three separate groups.
• bootsym() is now used only at boot time when no-real-mode isn't set.
• bootdatasym() is for variables
> -Original Message-
> From: Roger Pau Monne
> Sent: 21 August 2019 15:59
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
>
> Subject: [PATCH 4/7] ioreq: allow registering internal ioreq server handler
>
> Provide a
Hi Anthony,
On 08/13/19 13:30, Anthony PERARD wrote:
> This patch allows the ResetVector to be run indenpendently from build
> time addresses.
>
> The goal of the patch is to avoid having to create RAM just below 4G
> when creating a Xen PVH guest while being compatible with the way
> hvmloader c
> -Original Message-
> From: Roger Pau Monne
> Sent: 21 August 2019 15:59
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Paul Durrant
> ; Jan Beulich
> ; Andrew Cooper ; Wei Liu
>
> Subject: [PATCH 3/7] ioreq: allow dispatching ioreqs to internal servers
>
> Internal iore
> -Original Message-
> From: Roger Pau Monne
> Sent: 21 August 2019 15:59
> To: xen-devel@lists.xenproject.org
> Cc: Roger Pau Monne ; Jan Beulich ;
> Andrew Cooper
> ; Wei Liu ; Paul Durrant
>
> Subject: [PATCH 2/7] ioreq: add internal ioreq initialization support
>
> Add support for
On 08/15/19 13:03, Laszlo Ersek wrote:
> On 08/13/19 13:30, Anthony PERARD wrote:
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/ovmf.git
>> br.platform-xen-pvh-v5
>>
>> Changes in v5:
>> - patch 23 got a rework of the lapic range skipping
>> - sma
> -Original Message-
> From: Oleksandr
> Sent: 21 August 2019 15:36
> To: Paul Durrant ; xen-devel@lists.xenproject.org
> Cc: sstabell...@kernel.org; Wei Liu ; Konrad Rzeszutek Wilk
> ;
> George Dunlap ; Andrew Cooper
> ; Ian Jackson
> ; Tim (Xen.org) ; Oleksandr Tyshchenko
> ; julien.gr
> -Original Message-
> From: Anthony PERARD
> Sent: 21 August 2019 10:20
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; Stefano Stabellini
> ; Paul
> Durrant ; xen-devel@lists.xenproject.org
> Subject: [PATCH 2/2] xen-bus: Avoid rewriting identical values to xenstore
>
> When QEMU re
On 8/20/19 11:14 PM, Chaitanya Kulkarni wrote:
In the blk-zoned, bcache, f2fs, target-pscsi, xen and blktrace
implementation block device->hd_part->number of sectors field is
accessed directly without any appropriate locking or accessor function.
There is an existing accessor function present in
On 8/20/19 11:14 PM, Chaitanya Kulkarni wrote:
This patch introduces helper function to read the number of sectors
from struct block_device->bd_part member. For more details Please refer
to the comment in the include/linux/genhd.h for part_nr_sects_read().
Reviewed-by: Minwoo Im
Reviewed-by: Ma
Add support for internal ioreq servers to initialization and
deinitialization routines, prevent some functions from being executed
against internal ioreq servers and add guards to only allow internal
callers to modify internal ioreq servers. External callers (ie: from
hypercalls) are only allowed t
Provide a routine to register the handler for an internal ioreq
server. Note the handler can only be set once.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/ioreq.c| 32
xen/include/asm-x86/hvm/ioreq.h | 3 +++
2 files changed, 35 insertions(+)
di
...and switch vPCI to use this infrastructure for long running
physmap modification operations.
This allows to get rid of the vPCI specific modifications done to
handle_hvm_io_completion and allows generalizing the support for
long-running operations to other internal ioreq servers. Such support
i
Pick up on the infrastructure already added for vPCI and allow ioreq
to decode accesses to MMCFG regions registered for a domain. This
infrastructure is still only accessible from internal callers, so
MMCFG regions can only be registered from the internal domain builder
used by PVH dom0.
Note that
Such internal servers are implemented by a single function that handles
ioreqs inside the hypervisor.
The motivation behind this change is to switch vPCI to become an
internal ioreq server, so that accesses to the PCI config space can be
multiplexed between devices handled by vPCI and devices hand
Internal ioreq servers are plain function handlers implemented inside
of the hypervisor. Note that most fields used by current (external)
ioreq servers are not needed for internal ones, and hence have been
placed inside of a struct and packed in an union together with the
only internal specific fie
Switch vPCI to become an internal ioreq server, and hence drop all the
vPCI specific decoding and trapping to PCI IO ports and MMCFG regions.
This allows to unify the vPCI code with the ioreq infrastructure,
opening the door for domains having PCI accesses handled by vPCI and
other ioreq servers a
Internal ioreq servers are always processed first, and ioreqs are
dispatched by calling the handler function. If no internal servers have
registered for an ioreq it's then forwarded to external callers.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/ioreq.c | 19 ++-
1 file
Ian, Wei,
we got a report about a crash from libxl_domain_suspend like this, from 'virsh
migrate --live xen+ssh://host':
#1 helper_done (egc=0x7fc0284aa6c0, shs=0x7fc0180256c8) at
libxl_save_callout.c:371
helper_failed
helper_stop
libxl__save_helper_abort
#2 check_all_finished (egc=0x7fc0284
On 21.08.19 11:09, Paul Durrant wrote:
Hi, Paul
}
+void *_xrealloc(void *ptr, unsigned long size, unsigned long align)
+{
+unsigned long curr_size, tmp_size;
+void *p;
+
+if ( !size )
+{
+xfree(ptr);
+return ZERO_BLOCK_PTR;
+}
+
+if ( ptr == NULL || p
flight 140474 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140474/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Mon, 2019-08-12 at 11:10 +0200, Jan Beulich wrote:
> On 09.08.2019 17:01, David Woodhouse wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -735,7 +735,17 @@ trampoline_setup:
> > /* Switch to low-memory stack which lives at the end of trampoline
> > r
flight 140431 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140431/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-seattle broken in 140384
test-amd64-i386-xl7
flight 140428 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
test-amd64-i386-xl-
On Tue, Aug 20, 2019 at 04:12:41AM +0200, Marek Marczykowski-Górecki wrote:
> match_watch_by_token() when returns an error, sets also exception within
> python. This is generally the right thing to do, but when
> xspy_read_watch() handle EAGAIN error internally, the exception needs to
> be cleared.
On Wed, 2019-08-14 at 19:35 +0200, Dario Faggioli wrote:
> On Wed, 2019-08-14 at 09:27 -0700, Stefano Stabellini wrote:
> > On Wed, 14 Aug 2019, Dario Faggioli wrote:
> > > On Tue, 2019-08-13 at 14:14 -0700, Stefano Stabellini wrote:
> > > Now, while staring at the code of that loop, I've seen that
On 21/08/2019 11:04, Pawel Wieczorkiewicz wrote:
> diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
> index dd8b47a1fa..18b9684aeb 100644
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -55,7 +55,7 @@ static int elf_resolve_sections(struct livepatch_el
On 21/08/2019 10:13, Paul Durrant wrote:
>> -Original Message-
>> From: Roger Pau Monne
>> Sent: 21 August 2019 09:52
>> To: Paul Durrant
>> Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew
>> Cooper
>> ; Wei Liu
>> Subject: Re: [PATCH] viridian: make viridian_time_domain_freeze
This complements [1] commit for ARM and livepatch_elf files.
[1] 4470efeae4 livepatch: always print XENLOG_ERR information
Signed-off-by: Pawel Wieczorkiewicz
---
xen/arch/arm/arm32/livepatch.c | 28 +--
xen/arch/arm/arm64/livepatch.c | 28 +--
xen/common/livepatch_elf.c |
flight 140465 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/140465/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 77a994f3f8eb0d3cb0f2bf314b0ebf6a1d37f623
baseline version:
xen f7ef
> -Original Message-
> From: Anthony PERARD
> Sent: 21 August 2019 10:20
> To: qemu-de...@nongnu.org
> Cc: Anthony Perard ; qemu-sta...@nongnu.org;
> Stefano Stabellini
> ; Paul Durrant ;
> xen-devel@lists.xenproject.org
> Subject: [PATCH 1/2] xen-bus: Fix backend state transition on dev
When a frontend want to reset its state and the backend one, it start
with setting "Closing", then wait for the backend (QEMU) to do the same.
But when QEMU is setting "Closing" to its state, it trigger an event
(xenstore watch) that re-execute xen_device_backend_changed() and set
the backend stat
When QEMU receive a xenstore watch event suggesting that the "state" or
"online" status of the frontend or the backend changed, it record this
in its own state but it also re-write the value back into xenstore even
so there were no changed. This trigger an unnecessary xenstore watch
event which QEM
> -Original Message-
> From: Roger Pau Monne
> Sent: 21 August 2019 09:52
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Jan Beulich ; Andrew
> Cooper
> ; Wei Liu
> Subject: Re: [PATCH] viridian: make viridian_time_domain_freeze() safe to
> call...
>
> On Wed, Aug 21, 2019 a
On Wed, Aug 21, 2019 at 09:22:58AM +0100, Paul Durrant wrote:
> ...on a partially destroyed domain.
>
> viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
> (respectively) on the dynamically allocated per-domain and per-vcpu viridian
> areas [1], which are freed during domain_relin
...on a partially destroyed domain.
viridian_time_domain_freeze() and viridian_time_vcpu_freeze() rely
(respectively) on the dynamically allocated per-domain and per-vcpu viridian
areas [1], which are freed during domain_relinquish_resources().
Because arch_domain_pause() can call viridian_domain_
Include new sections containing optional apply and revert action
hooks.
The following new section names are supported:
- .livepatch.hooks.apply
- .livepatch.hooks.revert
Signed-off-by: Pawel Wieczorkiewicz
---
create-diff-object.c | 10 ++
1 file changed, 10 insertions(+)
diff --gi
Include new sections containing optional pre-, post- action hooks.
The following new section names are supported:
- .livepatch.hooks.preapply
- .livepatch.hooks.postapply
- .livepatch.hooks.prerevert
- .livepatch.hooks.postrevert
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Ross Lage
In the process of creating a final hotpatch module file make sure to
strip all transient symbols that have not been caught and removed by
create-diff-object processing. For now these are only the hooks
kpatch load/unload symbols.
For all new object files that are carried along for the final linkin
Strip all unneeded metadata symbols from generated hotpatch modules.
The metadata symbols are the symbols from metadata-like sections (e.g.
'.livepatch.funcs') or livepatch hooks symbols (defined by a set of
prefixes. E.g. 'livepatch_load_data_').
By default the create-diff-object does not create
In some build systems symlinks might be used for patch file names
to point from target directories to actual patches. Following those
symlinks breaks naming convention as the resulting built modules
would be named after the actual hardlink insteads of the symlink.
Livepatch-build obtains hotpatch
This function checks if given section has an included corresponding
RELA section and/or any of the symbols table symbols references the
section. Section associated symbols are ignored here as there is
always such a symbol for every section.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-I
When there is no changed function in the generated payload, do not
create an empty .livepatch.funcs section. Hypervisor code considers
such payloads as broken and rejects to load them.
Such payloads without any changed functions may appear when only
hooks are specified.
Signed-off-by: Pawel Wiecz
Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section has undefined group_size.
Allow to specify different .l
Extend livepatch_patch_func to support a new field: expect. This new
field describes the expected data, its length and whether expectation
is enabled. The expectation's data is of opaque padding size.
Bump the payload version for hotpatches built with expectations.
The expectations are supported s
Older versions of GCC did not split .rodata.str sections by function.
Because of that, the entire section was always included.
The livepatch-build-tools commit [1] fixed patch creation and kept
including all .rodata.str sections, in order to maintain existing
behavior for GCC 6.1+.
This means all .
With version 2 of a payload structure additional field is supported
to track whether given function has been applied or reverted.
There also comes additional 8-byte alignment padding to reserve
place for future flags and options.
The new fields are zero-out upon .livepatch.funcs section creation.
The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.
This is a livepatch backport of kpatch upstream commit [1]:
kpatch-build: detect special section group sizes 170449847136a48b19fc
Xen onl
This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.
With stacked hotpatch modules it is essential that each and every
hotpatch is verified against the hypervisor bu
This function determines, based on the given section name, if the
sections belongs to the special sections category.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: Norbert Manthey
Reviewed-by: Ross Lagerwall
---
create-diff-obje
The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation require
Detect standard (always to be included) sections via their section
header type. The standard sections: ".shstrtab", ".symtab", ".strtab"
are either of type SHT_SYMTAB or SHT_STRTAB.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Andra-Irina Paraschiv
Reviewed-by: Bjoern Doebel
Reviewed-by: No
Do not copy over the built_in.o and prelink.o object files when they
get rebuilt as they are used for transient linking by Xen's build
system.
Signed-off-by: Pawel Wieczorkiewicz
Reviewed-by: Martin Pohlack
Reviewed-by: Petre Eftime
Reviewed-by: Ross Lagerwall
---
livepatch-gcc | 2 ++
1 file
This series introduces new features to the livepatch functionality as
briefly discussed during Xen Developer Summit 2019: [a] and [b].
It also provides a few fixes and some small improvements.
IMPROVEMENTS:
1. Ignore build system object files: [2]
2. Allow using symlink names for hotpatch module
During verification check if all sections do not contain any entries
with undefined symbols (STN_UNDEF). This situation can happen when a
section is copied over from its original object to a patched object,
but various symbols related to the section are not copied along.
This scenario happens typic
Up to now the livepatch-build ignores newly created object files.
When patch applies new .c file and augments its Makefile to build it
the resulting object file is not taken into account for final linking
step.
Such newly created object files can be detected by comparing patched/
and original/ dir
Extend the livepatch list operation to fetch also payloads' metadata.
This is achieved by extending the sysctl list interface with 2 extra
guest handles:
* metadata - an array of arbitrary size strings
* metadata_len - an array of metadata strings' lengths (uin32_t each)
Payloads' metadata is
1 - 100 of 115 matches
Mail list logo
