Re: [Xen-devel] [PATCH v2 for-next 2/9] gcov: rename folder and header to coverage
On Thu, Nov 09, 2017 at 11:13:42AM +, Roger Pau Monne wrote: > Preparatory change before adding llvm profiling support. > No functional change. > > Signed-off-by: Roger Pau Monné > --- > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk Reviewed-by: Konrad Rzeszutek Wilk ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-next 3/9] gcov: rename sysctl and functions
On Thu, Nov 09, 2017 at 11:13:43AM +, Roger Pau Monne wrote: > Change gcov to cov (for internal interfaces) or coverage (for the > public ones). > > Signed-off-by: Roger Pau Monné > --- > Cc: Ian Jackson > Cc: Wei Liu > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk Reviewed-by: Konrad Rzeszutek Wilk ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for-next 5/9] coverage: introduce generic file
On Thu, Nov 09, 2017 at 11:13:45AM +, Roger Pau Monne wrote:
> It will contain the generic implementation of sysctl_cov_op, which
> will be shared between all the coverage implementations.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> ---
> Changes since v1:
> - Use private coverage.h header.
> - Sort alphabetically the obj-y list.
> ---
> xen/common/coverage/Makefile | 2 +-
> xen/common/coverage/coverage.c | 73
> ++
> xen/common/coverage/coverage.h | 1 +
> xen/common/coverage/gcov.c | 39 +-
> 4 files changed, 76 insertions(+), 39 deletions(-)
> create mode 100644 xen/common/coverage/coverage.c
>
> diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
> index a7a48494ca..5387bc6429 100644
> --- a/xen/common/coverage/Makefile
> +++ b/xen/common/coverage/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += gcov_base.o gcov.o
> +obj-y += coverage.o gcov_base.o gcov.o
> obj-y += $(call cc-ifversion,lt,0x040700, \
> gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \
> gcc_4_7.o, $(call cc-ifversion,lt,0x05, \
> diff --git a/xen/common/coverage/coverage.c b/xen/common/coverage/coverage.c
> new file mode 100644
> index 00..bd90f28663
> --- /dev/null
> +++ b/xen/common/coverage/coverage.c
> @@ -0,0 +1,73 @@
> +/*
> + * Generic functionality for coverage analysis.
> + *
> + * Copyright (C) 2017 Citrix Systems R&D
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see
> <http://www.gnu.org/licenses/>.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "coverage.h"
> +
> +int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
> +{
> +int ret;
> +
> +switch ( op->cmd )
> +{
> +case XEN_SYSCTL_COVERAGE_get_size:
> +op->size = cov_ops.get_size();
> +ret = 0;
> +break;
> +
> +case XEN_SYSCTL_COVERAGE_read:
> +{
> +XEN_GUEST_HANDLE_PARAM(char) buf;
> +uint32_t size = op->size;
> +
> +buf = guest_handle_cast(op->buffer, char);
> +
> +ret = cov_ops.dump(buf, &size);
> +op->size = size;
> +
> +break;
> +}
> +
> +case XEN_SYSCTL_COVERAGE_reset:
> +cov_ops.reset_counters();
> +ret = 0;
> +break;
> +
> +default:
> +ret = -EOPNOTSUPP;
> +break;
> +}
> +
> +return ret;
> +}
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/common/coverage/coverage.h b/xen/common/coverage/coverage.h
> index 4613d5e6c1..003bb76950 100644
> --- a/xen/common/coverage/coverage.h
> +++ b/xen/common/coverage/coverage.h
> @@ -8,5 +8,6 @@ struct cov_sysctl_ops {
> void (*reset_counters)(void);
> int (*dump)(XEN_GUEST_HANDLE_PARAM(char), uint32_t *);
> };
> +extern const struct cov_sysctl_ops cov_ops;
>
> #endif
> diff --git a/xen/common/coverage/gcov.c b/xen/common/coverage/gcov.c
> index 8627ef3355..3cc98728bf 100644
> --- a/xen/common/coverage/gcov.c
> +++ b/xen/common/coverage/gcov.c
> @@ -210,49 +210,12 @@ static int gcov_dump_all(XEN_GUEST_HANDLE_PARAM(char)
> buffer,
> return ret;
> }
>
> -static const struct cov_sysctl_ops cov_ops = {
> +const struct cov_sysctl_ops cov_ops = {
> .get_size = gcov_get_size,
> .reset_counters = gcov_reset_all_counters,
> .dump = gcov_dump_all,
> };
>
> -int sysctl_cov_op(struct xen_sysctl_coverage_op *op)
> -{
> -int ret;
> -
> -switch ( op->cmd )
> -{
> -case XEN_SYSCTL_COVERAGE_get_size:
> -op->size = cov_ops.get_size();
> -ret = 0;
> -br
Re: [Xen-devel] [PATCH v2 for-next 6/9] kconfig/gcov: rename to coverage
On Thu, Nov 09, 2017 at 11:13:46AM +, Roger Pau Monne wrote: > So it can be used by both gcc and clang. Just add the Kconfig option > and modify the makefiles so the llvm coverage specific code can be > added in a follow up patch. > > Signed-off-by: Roger Pau Monné > --- > Cc: Andrew Cooper > Cc: George Dunlap > Cc: Ian Jackson > Cc: Jan Beulich > Cc: Konrad Rzeszutek Wilk > Cc: Stefano Stabellini > Cc: Tim Deegan > Cc: Wei Liu > --- > Changes since v1: > - Use a choice in kconfig to select code coverage technology. > - Compile coverage.c regardless of selected code coverage technology. > - Introduce an unimplemented sysctl_cov_op function if >CONFIG_COVERAGE is not set. > --- > docs/misc/coverage.markdown | 2 +- > xen/Kconfig.debug| 7 +++ > xen/Rules.mk | 6 +- > xen/common/Makefile | 2 +- > xen/common/coverage/Makefile | 5 - > xen/common/sysctl.c | 2 -- > xen/include/xen/coverage.h | 7 ++- > 7 files changed, 20 insertions(+), 11 deletions(-) > > diff --git a/docs/misc/coverage.markdown b/docs/misc/coverage.markdown > index b47aba2648..430cd27b2f 100644 > --- a/docs/misc/coverage.markdown > +++ b/docs/misc/coverage.markdown > @@ -10,7 +10,7 @@ down your hypervisor. > > ## Enable coverage > > -Test coverage support can be turned on compiling Xen with the `CONFIG_GCOV` > +Test coverage support can be turned on compiling Xen with the > `CONFIG_COVERAGE` > option set to `y`. > > Change your `.config` or run `make -C xen menuconfig`. > diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug > index 7bb0465b5d..153d68fed3 100644 > --- a/xen/Kconfig.debug > +++ b/xen/Kconfig.debug > @@ -28,12 +28,11 @@ config FRAME_POINTER > maybe slower, but it gives very useful debugging information > in case of any Xen bugs. > > -config GCOV > - bool "Gcov Support" > +config COVERAGE > + bool "Code coverage support" > depends on !LIVEPATCH > - select SUPPRESS_DUPLICATE_SYMBOL_WARNINGS Any particular reason this was removed? Or is the idea that the coverage technology should have this select? > ---help--- > - Enable gcov (a test coverage program in GCC) support. > + Enable code coverage support. > > If unsure, say N here. > > diff --git a/xen/Rules.mk b/xen/Rules.mk > index 2659f8a4d1..d1b72e24ab 100644 > --- a/xen/Rules.mk > +++ b/xen/Rules.mk > @@ -115,9 +115,13 @@ subdir-all := $(subdir-y) $(subdir-n) > > $(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS += > -DINIT_SECTIONS_ONLY > > -ifeq ($(CONFIG_GCOV),y) > +ifeq ($(CONFIG_COVERAGE),y) > +ifeq ($(clang),y) > +$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS > += -fprofile-instr-generate -fcoverage-mapping > +else > $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS > += -fprofile-arcs -ftest-coverage > endif > +endif > > ifeq ($(CONFIG_UBSAN),y) > $(filter-out %.init.o $(noubsan-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS > += -fsanitize=undefined > diff --git a/xen/common/Makefile b/xen/common/Makefile > index ad181636f6..3a349f478b 100644 > --- a/xen/common/Makefile > +++ b/xen/common/Makefile > @@ -74,7 +74,7 @@ tmem-y := tmem.o tmem_xen.o tmem_control.o > tmem-$(CONFIG_COMPAT) += compat/tmem_xen.o > obj-$(CONFIG_TMEM) += $(tmem-y) > > -subdir-$(CONFIG_GCOV) += coverage > +subdir-$(CONFIG_COVERAGE) += coverage > subdir-$(CONFIG_UBSAN) += ubsan > > subdir-y += libelf > diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile > index 5387bc6429..1039a160c4 100644 > --- a/xen/common/coverage/Makefile > +++ b/xen/common/coverage/Makefile > @@ -1,6 +1,9 @@ > -obj-y += coverage.o gcov_base.o gcov.o > +obj-y += coverage.o > +ifneq ($(clang),y) > +obj-y += gcov_base.o gcov.o > obj-y += $(call cc-ifversion,lt,0x040700, \ > gcc_3_4.o, $(call cc-ifversion,lt,0x040900, \ > gcc_4_7.o, $(call cc-ifversion,lt,0x05, \ > gcc_4_9.o, $(call cc-ifversion,lt,0x07, \ > gcc_5.o, gcc_7.o > +endif > diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c > index f2ae6295ff..8e83c33a16 100644 > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -396,12 +396,10 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > u_sysctl) > } > break; > > -#ifdef CONFIG_GCOV > case XEN_SYSCTL_coverage_op: > ret = sysctl_cov_op(&op->u.coverage_op); > copyback = 1; > break; > -#endif > > #ifdef CONFIG_HAS
Re: [Xen-devel] [PATCH v2 for-next 4/9] gcov: introduce hooks for the sysctl
On Thu, Nov 09, 2017 at 11:13:44AM +, Roger Pau Monne wrote:
> So that other implementations of the sysctl can be added.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> ---
> Changes since v1:
> - Constify cov_ops.
> - Introduce a local coverage.h provate header and place the
>definition of cov_sysctl_ops there.
> ---
> xen/common/coverage/coverage.h | 12
> xen/common/coverage/gcov.c | 13 ++---
> 2 files changed, 22 insertions(+), 3 deletions(-)
> create mode 100644 xen/common/coverage/coverage.h
>
> diff --git a/xen/common/coverage/coverage.h b/xen/common/coverage/coverage.h
> new file mode 100644
> index 00..4613d5e6c1
> --- /dev/null
> +++ b/xen/common/coverage/coverage.h
> @@ -0,0 +1,12 @@
> +#ifndef _XEN_COV_PRIV_H
> +#define _XEN_COV_PRIV_H
> +
> +#include
> +
> +struct cov_sysctl_ops {
> +uint32_t (*get_size)(void);
> +void (*reset_counters)(void);
> +int (*dump)(XEN_GUEST_HANDLE_PARAM(char), uint32_t *);
> +};
> +
> +#endif
Perhaps add the editor configuration block?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] HiKey 960 (ARM 64) rcu_preempt detected stalls
.snip.. > [0.00] Booting Linux on physical CPU 0x0 > > [0.00] Linux version 4.13.0-linaro-hikey960+ (mc@xenpro3) (gcc > version 7.1.1 20170510 (Linaro GCC 7.1-2017.05)) #1 SMP PREEMPT Wed Sep 13 > 10:16:12 EDT 2017 What branch is this? And what git repo ? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/2] x86/svm: Add virtual GIF feature definition
On Thu, Nov 16, 2017 at 11:19:38AM -0600, Brian Woods wrote:
> Add support for enabling the virtual GIF feature.
>
> Signed-off-by: Brian Woods
> ---
> xen/include/asm-x86/hvm/svm/svm.h | 2 ++
> xen/include/asm-x86/hvm/svm/vmcb.h | 6 --
> 2 files changed, 6 insertions(+), 2 deletions(-)
The patch says 'v2', but I don't see anything having changed here.
Usually one adds comments in here (right after ---) with something
to the effect of:
v1: New version
v2: Nothing new.
Or if something did change (like in second patch), you say exactly what changed.
Thanks!
>
> diff --git a/xen/include/asm-x86/hvm/svm/svm.h
> b/xen/include/asm-x86/hvm/svm/svm.h
> index 0956f860ef..ec1eda6a3e 100644
> --- a/xen/include/asm-x86/hvm/svm/svm.h
> +++ b/xen/include/asm-x86/hvm/svm/svm.h
> @@ -64,6 +64,7 @@ extern u32 svm_feature_flags;
> #define SVM_FEATURE_FLUSHBYASID6 /* TLB flush by ASID support */
> #define SVM_FEATURE_DECODEASSISTS 7 /* Decode assists support */
> #define SVM_FEATURE_PAUSEFILTER 10 /* Pause intercept filter support */
> +#define SVM_FEATURE_VGIF 16 /* Virtual GIF */
>
> #define cpu_has_svm_feature(f) test_bit(f, &svm_feature_flags)
> #define cpu_has_svm_npt cpu_has_svm_feature(SVM_FEATURE_NPT)
> @@ -72,6 +73,7 @@ extern u32 svm_feature_flags;
> #define cpu_has_svm_nrips cpu_has_svm_feature(SVM_FEATURE_NRIPS)
> #define cpu_has_svm_cleanbits cpu_has_svm_feature(SVM_FEATURE_VMCBCLEAN)
> #define cpu_has_svm_decodecpu_has_svm_feature(SVM_FEATURE_DECODEASSISTS)
> +#define cpu_has_svm_vgif cpu_has_svm_feature(SVM_FEATURE_VGIF)
> #define cpu_has_pause_filter cpu_has_svm_feature(SVM_FEATURE_PAUSEFILTER)
> #define cpu_has_tsc_ratio cpu_has_svm_feature(SVM_FEATURE_TSCRATEMSR)
>
> diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h
> b/xen/include/asm-x86/hvm/svm/vmcb.h
> index 01ce20b0bd..595cfcf57b 100644
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -325,12 +325,14 @@ typedef union
> {
> u64 tpr: 8;
> u64 irq: 1;
> -u64 rsvd0:7;
> +u64 vgif: 1;
> +u64 rsvd0:6;
> u64 prio: 4;
> u64 ign_tpr: 1;
> u64 rsvd1:3;
> u64 intr_masking: 1;
> -u64 rsvd2:7;
> +u64 vgif_enable: 1;
> +u64 rsvd2:6;
> u64 vector: 8;
> u64 rsvd3: 24;
> } fields;
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/16] SUPPORT.md: Add Security-releated features
On Mon, Nov 13, 2017 at 03:41:22PM +, George Dunlap wrote: > With the exception of driver domains, which depend on PCI passthrough, > and will be introduced later. > > Signed-off-by: George Dunlap > --- > CC: Ian Jackson > CC: Wei Liu > CC: Andrew Cooper > CC: Jan Beulich > CC: Stefano Stabellini > CC: Konrad Wilk Reviewed-by: Konrad Rzeszutek Wilk [the livepatching part] > CC: Tim Deegan > CC: Tamas K Lengyel > CC: Rich Persaud > --- > SUPPORT.md | 34 ++ > 1 file changed, 34 insertions(+) > > diff --git a/SUPPORT.md b/SUPPORT.md > index 722a29fec5..0f7426593e 100644 > --- a/SUPPORT.md > +++ b/SUPPORT.md > @@ -421,6 +421,40 @@ there is currently no xl support. > > Status: Supported > > +## Security > + > +### Device Model Stub Domains > + > +Status: Supported > + > +### KCONFIG Expert > + > +Status: Experimental > + > +### Live Patching > + > +Status, x86: Supported > +Status, ARM: Experimental > + > +Compile time disabled for ARM > + > +### Virtual Machine Introspection > + > +Status, x86: Supported, not security supported > + > +### XSM & FLASK > + > +Status: Experimental > + > +Compile time disabled > + > +### FLASK default policy > + > +Status: Experimental > + > +The default policy includes FLASK labels and roles for a "typical" Xen-based > system > +with dom0, driver domains, stub domains, domUs, and so on. > + > ## Virtual Hardware, Hypervisor > > ### x86/Nested PV > -- > 2.15.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v3 0/6] x86/idle: add halt poll support
On Mon, Nov 13, 2017 at 06:05:59PM +0800, Quan Xu wrote: > From: Yang Zhang > > Some latency-intensive workload have seen obviously performance > drop when running inside VM. The main reason is that the overhead > is amplified when running inside VM. The most cost I have seen is > inside idle path. Meaning an VMEXIT b/c it is an 'halt' operation ? And then going back in guest (VMRESUME) takes time. And hence your latency gets all whacked b/c of this? So if I understand - you want to use your _full_ timeslice (of the guest) without ever (or as much as possible) to go in the hypervisor? Which means in effect you don't care about power-saving or CPUfreq savings, you just want to eat the full CPU for snack? > > This patch introduces a new mechanism to poll for a while before > entering idle state. If schedule is needed during poll, then we > don't need to goes through the heavy overhead path. Schedule of what? The guest or the host? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2 v2] xen: Fix 16550 UART console for HP Moonshot (Aarch64) platform
On Thu, Nov 09, 2017 at 03:49:24PM +0530, Bhupinder Thakur wrote:
> The console was not working on HP Moonshot (HPE Proliant Aarch64) because
> the UART registers were accessed as 8-bit aligned addresses. However,
> registers are 32-bit aligned for HP Moonshot.
>
> Since ACPI/SPCR table does not specify the register shift to be applied
> to the
> register offset, this patch implements an erratum to correctly set the
> register
> shift for HP Moonshot.
>
> Similar erratum was implemented in linux:
>
> commit 79a648328d2a604524a30523ca763fbeca0f70e3
> Author: Loc Ho
> Date: Mon Jul 3 14:33:09 2017 -0700
>
> ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
>
> APM X-Gene verion 1 and 2 have an 8250 UART with its register
> aligned to 32-bit. In addition, the latest released BIOS
> encodes the access field as 8-bit access instead 32-bit access.
> This causes no console with ACPI boot as the console
> will not match X-Gene UART port due to the lack of mmio32
> option.
>
> Signed-off-by: Loc Ho
> Acked-by: Greg Kroah-Hartman
> Signed-off-by: Rafael J. Wysocki
Any particular reason you offset this whole commit description by four spaces?
>
> Signed-off-by: Bhupinder Thakur
> ---
> CC: Andrew Cooper
> CC: George Dunlap
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
> CC: Julien Grall
>
> xen/drivers/char/ns16550.c | 42 --
> 1 file changed, 40 insertions(+), 2 deletions(-)
This is v2 posting, but I don't see what changed.
Usually you do something like this:
v1: New posting
v2: Nothing changed from v1.
or
v1: New posting
v2: Added more folks on CC
Added consts in XYZ..
>
> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index cf42fce..bb01c46 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -1517,6 +1517,33 @@ static int ns16550_init_dt(struct ns16550 *uart,
>
> #ifdef CONFIG_ACPI
> #include
> +/*
> + * APM X-Gene v1 and v2 UART hardware is an 16550 like device but has its
> + * register aligned to 32-bit. In addition, the BIOS also encoded the
> + * access width to be 8 bits. This function detects this errata condition.
> + */
> +static bool xgene_8250_erratum_present(struct acpi_table_spcr *tb)
> +{
> +bool xgene_8250 = false;
> +
> +if ( tb->interface_type != ACPI_DBG2_16550_COMPATIBLE )
> +return false;
> +
> +if ( memcmp(tb->header.oem_id, "APMC0D", ACPI_OEM_ID_SIZE) &&
> + memcmp(tb->header.oem_id, "HPE ", ACPI_OEM_ID_SIZE) )
> +return false;
> +
> +if ( !memcmp(tb->header.oem_table_id, "XGENESPC",
> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 0 )
> +xgene_8250 = true;
Why not just 'return true' ?
> +
> +if ( !memcmp(tb->header.oem_table_id, "ProLiant",
> + ACPI_OEM_TABLE_ID_SIZE) && tb->header.oem_revision == 1 )
> +xgene_8250 = true;
And return true here too?
> +
> +return xgene_8250;
And then this is just 'return false' and you don't have xgen_8250 on the stack?
> +}
> +
> static int ns16550_init_acpi(struct ns16550 *uart,
> const void *data)
> {
> @@ -1539,9 +1566,20 @@ static int ns16550_init_acpi(struct ns16550 *uart,
> uart->io_base = spcr->serial_port.address;
> uart->irq = spcr->interrupt;
> uart->reg_width = spcr->serial_port.bit_width / 8;
> -uart->reg_shift = 0;
> -uart->io_size = UART_MAX_REG << uart->reg_shift;
>
> +if ( xgene_8250_erratum_present(spcr) )
> +{
> +/*
> + * for xgene v1 and v2 the registers are 32-bit and so a
s/for/For/
> + * register shift of 2 has to be applied to get the
> + * correct register offset.
> + */
> +uart->reg_shift = 2;
> +}
> +else
> +uart->reg_shift = 0;
> +
> +uart->io_size = UART_MAX_REG << uart->reg_shift;
> irq_set_type(spcr->interrupt, spcr->interrupt_type);
>
> return 0;
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen PVH support in grub2
On Tue, Nov 07, 2017 at 11:10:29AM -0500, Boris Ostrovsky wrote: > On 11/07/2017 02:42 AM, Juergen Gross wrote: > > On 06/11/17 17:42, Boris Ostrovsky wrote: > >> On 11/06/2017 10:05 AM, Juergen Gross wrote: > >>> On 06/11/17 15:51, Boris Ostrovsky wrote: > On 11/06/2017 02:16 AM, Juergen Gross wrote: > > On 03/11/17 20:00, Boris Ostrovsky wrote: > >> On 11/03/2017 02:40 PM, Juergen Gross wrote: > >>> On 03/11/17 19:35, Boris Ostrovsky wrote: > On 11/03/2017 02:23 PM, Juergen Gross wrote: > > On 03/11/17 19:19, Boris Ostrovsky wrote: > >> On 11/03/2017 02:05 PM, Juergen Gross wrote: > >>> So again the question: how to tell whether we are PVH or HVM in > >>> init_hypervisor_platform()? ACPi tables are scanned way later... > >> Can we make grub/OVMF append a boot option? > >> > >> Or set setup_header.hardware_subarch to something? We already have > >> X86_SUBARCH_XEN but it is only used by PV. Or we might be able to > >> use > >> hardware_subarch_data (will need to get a buy-in from x86 > >> maintainers, I > >> think). > > But wouldn't this break the idea to reuse the native boot paths in > > grub/OVMF without further modifications? > WDYM? We will have to have some sort of a plugin in either one to > build > the zeropage anyway. So we'd set hardware_subarch there, in addition > to > other things like setting memory and such. > >>> But isn't the zeropage already being built? I admit that setting > >>> subarch > >>> isn't a big deal, but using another entry with a passed-through pvh > >>> start struct isn't either... > >> I don't follow, sorry. My understanding is that zeropage will be built > >> by PVH-enlightened grub so part of this process would be setting the > >> subarch bit. > > My reasoning was based on Roger's remark: > > > > "OTOH if Linux is capable of booting from the native entry point inside > > of a PVH container, we would only have to port OVMF and grub in order > > to work inside of a PVH container, leaving the rest of the logic > > untouched." > Right, and in my mind porting OVMF/grub includes creating proper > zeropage. > >>> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run > >>> in PVH environment without touching the parts setting up anything for > >>> the new kernel. > >> Someone needs to do what xen_prepare_pvh() does. > > As the loader is filling in the memory map information > > That's the thing that I thought may need to be done by us (setting > commandline too) . But I haven't looked at Xen support in grub so maybe > it's already there. > > > the only thing > > remaining would be setting xen_pvh. And this could be delayed as my test > > have shown, so we only need to detect the PVH case from inside the > > kernel. One possibility would be the flags in the ACPI FADT table as > > Roger mentioned, another idea would be a flag in zeropage set by the > > loader. > > > >> And, for 64-bit, we also may need to build early pagetables since > >> startup_64() (unlike startup_32()) expects paging to be on. (I don't > >> know whether this is already part of standard FW codepath) > > This would be done the same way as for a native kernel. > > This is done by Linux trampoline code. AFAIK grub loads kernel in realmode. Adding in Maran who is looking at re-using PVH for qemu launching the kernels. > > > -boris > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Unable to create guest PV domain on OMAP5432
On Wed, Nov 08, 2017 at 10:47:20AM +0530, Jayadev Kumaran wrote: > Hello all, > > I'm trying to implement Xen hypervisor support on OMAP5432.I have followed > the steps as in > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM > for the initial setup. I'm able to see the domain 0 successfully up. > > > > > > > > *root@omap5-evm:~# /etc/init.d/xencommons startStarting > /usr/local/sbin/xenstored...Setting domain 0 name, domid and JSON > config...Done setting up Dom0Starting xenconsoled...Starting QEMU as disk > backend for dom0* > > > > *root@omap5-evm:~# xl listNameID > Mem VCPUs State Time(s)Domain-0 > 0 512 2 r- 11.5* What does 'xl info' say? B/c: .. > Expanding d4 grant table from 0 to 1 frames(XEN) memory.c:238:d0v0 Could > not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error: .. looks like it could not allocate memory? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features
On Thu, Nov 02, 2017 at 08:59:20AM +0800, Zhong Yang wrote:
> On Wed, Nov 01, 2017 at 03:29:16PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Fri, Oct 27, 2017 at 10:18:04PM +0800, Yang Zhong wrote:
> > > Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> > > VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> > > need expose to guest.wq
> >
> > s/wq//
>
> Hello Konrad,
>
> Thanks for reviewing my patch, i will remove this .wq in next
> version,thanks!
Heh. I also did an review and it looked OK to me. You can also
add Reviewed-by: Konrad Rzeszutek Wilk
>
> Regards,
>
> Yang
>
> > >
> > > The bit definition:
> > > CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> > > CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> > > CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> > > CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
> > > CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512VNNI
> > > CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
> > >
> > > The release document ref below link:
> > > https://software.intel.com/sites/default/files/managed/c5/15/\
> > > architecture-instruction-set-extensions-programming-reference.pdf
> >
> > Ah! Thank you!
> > >
> > > Signed-off-by: Yang Zhong
> > > ---
> > > docs/man/xl.cfg.pod.5.in| 3 ++-
> > > tools/libxl/libxl_cpuid.c | 6 ++
> > > tools/misc/xen-cpuid.c | 13 +++--
> > > xen/include/public/arch-x86/cpufeatureset.h | 6 ++
> > > xen/tools/gen-cpuid.py | 3 ++-
> > > 5 files changed, 23 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> > > index b7b91d8..d056768 100644
> > > --- a/docs/man/xl.cfg.pod.5.in
> > > +++ b/docs/man/xl.cfg.pod.5.in
> > > @@ -1731,7 +1731,8 @@ perfctr_core perfctr_nb pge pku popcnt pse pse36
> > > psn rdrand rdseed rdtscp rtm
> > > sha skinit smap smep smx ss sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2
> > > sse4a
> > > ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
> > > svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline
> > > tsc_adjust
> > > -umip vme vmx wdt x2apic xop xsave xtpr
> > > +umip vme vmx wdt x2apic xop xsave xtpr avx512_vbmi2 gfni vaes vpclmulqdq
> > > +avx512_vnni avx512_bitalg
> > >
> > >
> > > The xend syntax is a list of values in the form of
> > > diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
> > > index e692b61..614991f 100644
> > > --- a/tools/libxl/libxl_cpuid.c
> > > +++ b/tools/libxl/libxl_cpuid.c
> > > @@ -199,6 +199,12 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
> > > *cpuid, const char* str)
> > > {"umip", 0x0007, 0, CPUID_REG_ECX, 2, 1},
> > > {"pku", 0x0007, 0, CPUID_REG_ECX, 3, 1},
> > > {"ospke",0x0007, 0, CPUID_REG_ECX, 4, 1},
> > > +{"avx512_vbmi2", 0x0007, 0, CPUID_REG_ECX, 6, 1},
> > > +{"gfni", 0x0007, 0, CPUID_REG_ECX, 8, 1},
> > > +{"vaes", 0x0007, 0, CPUID_REG_ECX, 9, 1},
> > > +{"vpclmulqdq", 0x0007, 0, CPUID_REG_ECX, 10, 1},
> > > +{"avx512_vnni", 0x0007, 0, CPUID_REG_ECX, 11, 1},
> > > +{"avx512_bitalg",0x0007, 0, CPUID_REG_ECX, 12, 1},
> > >
> > > {"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2, 1},
> > > {"avx512-4fmaps",0x0007, 0, CPUID_REG_EDX, 3, 1},
> > > diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> > > index 106be0f..985deea 100644
> > > --- a/tools/misc/xen-cpuid.c
> > > +++ b/tools/misc/xen-cpuid.c
> > > @@ -120,12 +120,13 @@ static const char *str_Da1[32] =
> > >
> > > static const char *str_7c0[32] =
> > > {
> > > -[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> > > -[ 2] = "REZ", [ 3] = "pku",
> > > -[ 4] = "ospke",
> > > -
> > > -[5 ... 13] = "REZ",
> > > -
> > > +[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> > > +[ 2] = "REZ", [ 3] = &quo
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On Thu, Nov 02, 2017 at 10:46:20AM +, George Dunlap wrote: > On 11/01/2017 05:10 PM, Konrad Rzeszutek Wilk wrote: > > On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote: > >> On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk > >> wrote: > >>>> +### Soft-reset for PV guests > >>> > >>> s/PV/HVM/ > >> > >> Is it? I thought this was for RHEL 5 PV guests to be able to do crash > >> kernels. > >> > >>>> +### Transcendent Memory > >>>> + > >>>> +Status: Experimental > >>>> + > >>>> +[XXX Add description] > >>> > >>> Guests with tmem drivers autoballoon memory out allowing a fluid > >>> and dynamic memory allocation - in effect memory overcommit without > >>> the need to swap. Only works with Linux guests (as it requires > >>> OS drivers). > >> > >> But autoballooning doesn't require any support in Xen, right? I > >> thought the TMEM support in Xen was more about the trancendent memory > >> backends. > > > > frontends you mean? That is Linux guests when compiled with XEN_TMEM will > > balloon down (using the self-shrinker) to using the normal balloon code > > (XENMEM_decrease_reservation, XENMEM_populate_physmap) to make the > > guest smaller. Then the Linux code starts hitting the case where it starts > > swapping memory out - and that is where the tmem comes in and the > > pages are swapped out to the hypervisor. > > Right -- so TMEM itself actually consists of this ephemeral and > non-ephemeral memory pools. Autoballooning is just a trick to get Linux > to put the least-used pages into one of the pools. > > How about this: > > --- > Transcendent Memory (tmem) allows the creation of hypervisor memory > pools which guests can use to store memory rather than caching in its > own memory or swapping to disk. Having these in the hypervisor can > allow more efficient aggregate use of memory across VMs. > --- Perfect! > > -George ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/cpuid: Enable new SSE/AVX/AVX512 cpu features
On Fri, Oct 27, 2017 at 10:18:04PM +0800, Yang Zhong wrote:
> Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> need expose to guest.wq
s/wq//
>
> The bit definition:
> CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
> CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
> CPUID.(EAX=7,ECX=0):ECX[bit 10] VPCLMULQDQ
> CPUID.(EAX=7,ECX=0):ECX[bit 11] AVX512VNNI
> CPUID.(EAX=7,ECX=0):ECX[bit 12] AVX512_BITALG
>
> The release document ref below link:
> https://software.intel.com/sites/default/files/managed/c5/15/\
> architecture-instruction-set-extensions-programming-reference.pdf
Ah! Thank you!
>
> Signed-off-by: Yang Zhong
> ---
> docs/man/xl.cfg.pod.5.in| 3 ++-
> tools/libxl/libxl_cpuid.c | 6 ++
> tools/misc/xen-cpuid.c | 13 +++--
> xen/include/public/arch-x86/cpufeatureset.h | 6 ++
> xen/tools/gen-cpuid.py | 3 ++-
> 5 files changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index b7b91d8..d056768 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1731,7 +1731,8 @@ perfctr_core perfctr_nb pge pku popcnt pse pse36 psn
> rdrand rdseed rdtscp rtm
> sha skinit smap smep smx ss sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2 sse4a
> ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate
> svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust
> -umip vme vmx wdt x2apic xop xsave xtpr
> +umip vme vmx wdt x2apic xop xsave xtpr avx512_vbmi2 gfni vaes vpclmulqdq
> +avx512_vnni avx512_bitalg
>
>
> The xend syntax is a list of values in the form of
> diff --git a/tools/libxl/libxl_cpuid.c b/tools/libxl/libxl_cpuid.c
> index e692b61..614991f 100644
> --- a/tools/libxl/libxl_cpuid.c
> +++ b/tools/libxl/libxl_cpuid.c
> @@ -199,6 +199,12 @@ int libxl_cpuid_parse_config(libxl_cpuid_policy_list
> *cpuid, const char* str)
> {"umip", 0x0007, 0, CPUID_REG_ECX, 2, 1},
> {"pku", 0x0007, 0, CPUID_REG_ECX, 3, 1},
> {"ospke",0x0007, 0, CPUID_REG_ECX, 4, 1},
> +{"avx512_vbmi2", 0x0007, 0, CPUID_REG_ECX, 6, 1},
> +{"gfni", 0x0007, 0, CPUID_REG_ECX, 8, 1},
> +{"vaes", 0x0007, 0, CPUID_REG_ECX, 9, 1},
> +{"vpclmulqdq", 0x0007, 0, CPUID_REG_ECX, 10, 1},
> +{"avx512_vnni", 0x0007, 0, CPUID_REG_ECX, 11, 1},
> +{"avx512_bitalg",0x0007, 0, CPUID_REG_ECX, 12, 1},
>
> {"avx512-4vnniw",0x0007, 0, CPUID_REG_EDX, 2, 1},
> {"avx512-4fmaps",0x0007, 0, CPUID_REG_EDX, 3, 1},
> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> index 106be0f..985deea 100644
> --- a/tools/misc/xen-cpuid.c
> +++ b/tools/misc/xen-cpuid.c
> @@ -120,12 +120,13 @@ static const char *str_Da1[32] =
>
> static const char *str_7c0[32] =
> {
> -[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> -[ 2] = "REZ", [ 3] = "pku",
> -[ 4] = "ospke",
> -
> -[5 ... 13] = "REZ",
> -
> +[ 0] = "prechwt1", [ 1] = "avx512vbmi",
> +[ 2] = "REZ", [ 3] = "pku",
> +[ 4] = "ospke",[ 5] = "REZ",
> +[ 6] = "avx512_vbmi2", [ 7] = "REZ",
> +[ 8] = "gfni", [ 9] = "vaes",
> +[10] = "vpclmulqdq", [11] = "avx512_vnni",
> +[12] = "avx512_bitalg",[13] = "REZ",
> [14] = "avx512_vpopcntdq",
>
> [15 ... 31] = "REZ",
> diff --git a/xen/include/public/arch-x86/cpufeatureset.h
> b/xen/include/public/arch-x86/cpufeatureset.h
> index 0ee3ea3..bb24b79 100644
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A AVX-512
> Vector Byte Manipulation Ins
> XEN_CPUFEATURE(UMIP, 6*32+ 2) /*S User Mode Instruction Prevention
> */
> XEN_CPUFEATURE(PKU, 6*32+ 3) /*H Protection Keys for Userspace */
> XEN_CPUFEATURE(OSPKE, 6*32+ 4) /*! OS Protection Keys Enable */
> +XEN_CPUFEATURE(AVX512_VBMI2, 6*32+ 6) /*A addition AVX-512 VBMI
> Instructions */
> +XEN_CPUFEATURE(GFNI, 6*32+ 8) /*A Galois Field New Instructions */
> +XEN_CPUFEATURE(VAES, 6*32+ 9) /*A Vector AES instructions */
> +XEN_CPUFEATURE(VPCLMULQDQ,6*32+ 10) /*A vector PCLMULQDQ instructions */
> +XEN_CPUFEATURE(AVX512_VNNI, 6*32+ 11) /*A Vector Neural Network
> Instructions */
> +XEN_CPUFEATURE(AVX512_BITALG, 6*32+ 12) /*A support for VPOPCNT[B,W] and
> VPSHUFBITQMB*/
> XEN_CPUFEATURE(AVX512_VPOPCNTDQ, 6*32+14) /*A POPCNT for vectors of DW/QW */
> XEN_CPUFEATURE(RDPID, 6*32+22) /*A RDPID instruction */
>
> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
> index 9ec4486..be8df48 100755
> --- a/xen/tools/gen
Re: [Xen-devel] [PATCH v3 for-next 3/4] xen/tmem: Convert the file common/tmem_xen.c to use typesafe MFN
On Wed, Nov 01, 2017 at 02:03:15PM +, Julien Grall wrote:
> The file common/tmem_xen.c is now converted to use typesafe. This is
> requiring to override the macro page_to_mfn to make it work with mfn_t.
>
> Note that all variables converted to mfn_t havem there initial value,
> when set, switch from 0 to INVALID_MFN. This is fine because the initial
> values was always overriden before used.
>
> Also add a couple of missing newlines suggested by Andrew in the code.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andrew Cooper
>
> ---
>
> Cc: Konrad Rzeszutek Wilk
Acked-by: Konrad Rzeszutek Wilk
But could you confirm that you did compile this on x86 and with CONFIG_TMEM=y
in the .config?
Thanks!
>
> Changes in v2:
> - Add missing newlines
> - Add Andrew's reviewed-by
> ---
> xen/common/tmem_xen.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
> index 20f74b268f..bd52e44faf 100644
> --- a/xen/common/tmem_xen.c
> +++ b/xen/common/tmem_xen.c
> @@ -14,6 +14,10 @@
> #include
> #include
>
> +/* Override macros from asm/page.h to make them work with mfn_t */
> +#undef page_to_mfn
> +#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
> +
> bool __read_mostly opt_tmem;
> boolean_param("tmem", opt_tmem);
>
> @@ -31,7 +35,7 @@ static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);
> static DEFINE_PER_CPU_READ_MOSTLY(void *, scratch_page);
>
> #if defined(CONFIG_ARM)
> -static inline void *cli_get_page(xen_pfn_t cmfn, unsigned long *pcli_mfn,
> +static inline void *cli_get_page(xen_pfn_t cmfn, mfn_t *pcli_mfn,
> struct page_info **pcli_pfp, bool cli_write)
> {
> ASSERT_UNREACHABLE();
> @@ -39,14 +43,14 @@ static inline void *cli_get_page(xen_pfn_t cmfn, unsigned
> long *pcli_mfn,
> }
>
> static inline void cli_put_page(void *cli_va, struct page_info *cli_pfp,
> -unsigned long cli_mfn, bool mark_dirty)
> +mfn_t cli_mfn, bool mark_dirty)
> {
> ASSERT_UNREACHABLE();
> }
> #else
> #include
>
> -static inline void *cli_get_page(xen_pfn_t cmfn, unsigned long *pcli_mfn,
> +static inline void *cli_get_page(xen_pfn_t cmfn, mfn_t *pcli_mfn,
> struct page_info **pcli_pfp, bool cli_write)
> {
> p2m_type_t t;
> @@ -68,16 +72,17 @@ static inline void *cli_get_page(xen_pfn_t cmfn, unsigned
> long *pcli_mfn,
>
> *pcli_mfn = page_to_mfn(page);
> *pcli_pfp = page;
> -return map_domain_page(_mfn(*pcli_mfn));
> +
> +return map_domain_page(*pcli_mfn);
> }
>
> static inline void cli_put_page(void *cli_va, struct page_info *cli_pfp,
> -unsigned long cli_mfn, bool mark_dirty)
> +mfn_t cli_mfn, bool mark_dirty)
> {
> if ( mark_dirty )
> {
> put_page_and_type(cli_pfp);
> -paging_mark_dirty(current->domain, _mfn(cli_mfn));
> +paging_mark_dirty(current->domain, cli_mfn);
> }
> else
> put_page(cli_pfp);
> @@ -88,14 +93,14 @@ static inline void cli_put_page(void *cli_va, struct
> page_info *cli_pfp,
> int tmem_copy_from_client(struct page_info *pfp,
> xen_pfn_t cmfn, tmem_cli_va_param_t clibuf)
> {
> -unsigned long tmem_mfn, cli_mfn = 0;
> +mfn_t tmem_mfn, cli_mfn = INVALID_MFN;
> char *tmem_va, *cli_va = NULL;
> struct page_info *cli_pfp = NULL;
> int rc = 1;
>
> ASSERT(pfp != NULL);
> tmem_mfn = page_to_mfn(pfp);
> -tmem_va = map_domain_page(_mfn(tmem_mfn));
> +tmem_va = map_domain_page(tmem_mfn);
> if ( guest_handle_is_null(clibuf) )
> {
> cli_va = cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
> @@ -125,7 +130,7 @@ int tmem_compress_from_client(xen_pfn_t cmfn,
> unsigned char *wmem = this_cpu(workmem);
> char *scratch = this_cpu(scratch_page);
> struct page_info *cli_pfp = NULL;
> -unsigned long cli_mfn = 0;
> +mfn_t cli_mfn = INVALID_MFN;
> void *cli_va = NULL;
>
> if ( dmem == NULL || wmem == NULL )
> @@ -152,7 +157,7 @@ int tmem_compress_from_client(xen_pfn_t cmfn,
> int tmem_copy_to_client(xen_pfn_t cmfn, struct page_info *pfp,
> tmem_cli_va_param_t clibuf)
> {
> -unsigned long tmem_mfn, cli_mfn = 0;
> +mfn_t tmem_mfn, cli_mfn = INVALID_MFN;
> char *tmem_va, *cli_va = NULL;
> struct page_info *cli_pfp = NULL;
> int rc = 1;
> @@ -165,7 +170,8 @@ int tmem_c
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
On Tue, Oct 24, 2017 at 04:22:38PM +0100, George Dunlap wrote: > On Fri, Sep 15, 2017 at 3:51 PM, Konrad Rzeszutek Wilk > wrote: > >> +### Soft-reset for PV guests > > > > s/PV/HVM/ > > Is it? I thought this was for RHEL 5 PV guests to be able to do crash > kernels. > > >> +### Transcendent Memory > >> + > >> +Status: Experimental > >> + > >> +[XXX Add description] > > > > Guests with tmem drivers autoballoon memory out allowing a fluid > > and dynamic memory allocation - in effect memory overcommit without > > the need to swap. Only works with Linux guests (as it requires > > OS drivers). > > But autoballooning doesn't require any support in Xen, right? I > thought the TMEM support in Xen was more about the trancendent memory > backends. frontends you mean? That is Linux guests when compiled with XEN_TMEM will balloon down (using the self-shrinker) to using the normal balloon code (XENMEM_decrease_reservation, XENMEM_populate_physmap) to make the guest smaller. Then the Linux code starts hitting the case where it starts swapping memory out - and that is where the tmem comes in and the pages are swapped out to the hypervisor. There is also the secondary cache (cleancache) which just puts pages in the hypervisor temporary cache, kind of like an L3. For that you don't need ballooning. > > > ..snip.. > >> +### Live Patching > >> + > >> +Status, x86: Supported > >> +Status, ARM: Experimental > >> + > >> +Compile time disabled > > > > for ARM. > > > > As the patch will do: > > > > config LIVEPATCH > > - bool "Live patching support (TECH PREVIEW)" > > - default n > > + bool "Live patching support" > > + default X86 > > depends on HAS_BUILD_ID = "y" > > ---help--- > > Allows a running Xen hypervisor to be dynamically patched using > > Ack > > -George > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] linux-arm-xen branch, commit access, etc.
On Fri, Oct 20, 2017 at 03:34:40PM +0100, Ian Jackson wrote: > Currently we are running our ARM tests in osstest off a branch in > Stefano's personal Linux tree. This is a bit unsatisfactory. > > We would like to switch to a branch that Julien can push to too, and > that is in a more official place. > > There are two options: > > 1. Create an ARM-specific Xen tree. Currently we don't have many > ARM-specific trees but I don't see a problem with this. So > we could create > /arm/linux.git > on xenbits. > > 2. Use a branch name within /linux-pvops.git, the main Linux > tree on xenbits. This would mean making Julien a committer. 3. Use upstream released kernels. Follow them when they are released. > > What do people think would be best ? > > Also, separately, surely Julien should be listed in MAINTAINERS for > the Xen ARM stuff in upstream Linux ? He doesn't seem to be at least > in the version I have lying about here... > > Thanks, > Ian. > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 00/16] Enable Memory Bandwidth Allocation in Xen
On Mon, Oct 16, 2017 at 11:04:05AM +0800, Yi Sun wrote: > Hi, all, > > We plan to bring a new PSR (Platform Shared Resource) feature called > Intel Memory Bandwidth Allocation (MBA) to Xen. > > Besides the MBA enabling, we change some interfaces to make them more > general but not only for CAT. > > Any comments are welcome! > > You can find this series at: > https://github.com/yisun-git/xen_mba mba_v8 > > This version bases on below pre-fix patch which has been merged into staging > branch: > "x86: psr: support co-exist features' values setting" > https://lists.xen.org/archives/html/xen-devel/2017-10/msg00866.html > > CC: Jan Beulich > CC: Andrew Cooper > CC: Wei Liu > CC: Ian Jackson > CC: Daniel De Graaf > CC: Roger Pau Monné > CC: Konrad Rzeszutek Wilk > CC: Chao Peng > CC: Julien Grall > > --- > Acked and Reviewed list before V8: > > a - Acked-by > r - Reviewed-by > > r patch 1 - docs: create Memory Bandwidth Allocation (MBA) feature > document > ar patch 2 - Rename PSR sysctl/domctl interfaces and xsm policy to make > them be general > ar patch 3 - x86: rename 'cbm_type' to 'psr_type' to make it general > ar patch 4 - x86: a few optimizations to psr codes > r patch 5 - x86: implement data structure and CPU init flow for MBA > ar patch 6 - x86: implement get hw info flow for MBA > ar patch 7 - x86: implement get value interface for MBA So 8 is missing and Ack/Review-edyb? > ar patch 9 - tools: create general interfaces to support psr allocation > features > ar patch 10 - tools: implement the new libxc get hw info interface > ar patch 11 - tools: implement the new libxl get hw info interface > ar patch 12 - tools: implement the new xl get hw info interface > ar patch 13 - tools: rename 'xc_psr_cat_type' to 'xc_psr_type' > ar patch 14 - tools: implement new generic get value interface and MBA get > value command > ar patch 15 - tools: implement new generic set value interface and MBA set > value command > ar patch 16 - docs: add MBA description in docs Also I tried to merge this on 'staging' and had a bit of issues. By any chance do you have an up-to-date branc? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [dpdk-dev] Can xenvirt pmd work in xen guest (aka DomU) without xen-vhost in Dom0 ?
On Mon, Oct 09, 2017 at 12:13:47AM +0800, Tan, Jianfeng wrote: > Hi, > > > On 10/8/2017 12:54 PM, Bill Bonaparte wrote: > > Thanks Jianfeng for taking time to reply. > > > > please allow me to briefly explain why I want to run dpdk on xen. > > our system is based on dpdk, which means we use dpdk as packet > > receive/transmit engine, > > and with integrated dpdk virtio/vmxnet3 driver, our system can run on > > KVM/VMware platform . > > this year, we have plan to run our system on AWS cloud, but I found that > > AWS > > uses xen as its virtualization platform, and the bus-info of nic is > > vif-x (x could be 0,1,2...), > > the driver used in kernel is vif. this should be para-virtualized nic > > used on xen. > > My guess is exactly as you describe. In AWS, we lack of a PMD for xen > netfront (vif) nic. And even we got such a PMD, we still need a PMD for xen > netback. Both are missing. > > > > > I don't know which dpdk drvier can manage this pv nic. then I see > > xenvirt, I think this driver can > > did this job, like virtio can manage virtio nic which is used on kvm. > > unfortunately, after some study work, I run testpmd successfully on xen, > > but no packets received. > > > > with the informain got from you, I know It's need to run vhost_xen at > > dom0 so that xenvirt at domU can work. > > but for my case, I have no change to run vhost_xen at dom0, because I > > only can operate my own domU. > > > > for this case, If I want to run system which is based on dpdk at domU, > > what should I do? > > appreciate any idea or suggestion from you. > > What kind of performance are you seeking? Only accelerating the frontend by > a new PMD, i.e. netfront, we can bypass the VM kernel (). But without > accelerating the backend, it only brings limited improvement. > > Not sure if anyone from Amazon or Oracle can comment? Joao has been working on updates in the Xen PV network driver such that there is a higher acceleration (aka recycle grants). See in xen.git tree: commit 30655e2bf0ce8ee50e61728e2558e0363f4af1c9 Author: Joao Martins Date: Tue Oct 3 18:46:08 2017 +0100 public/io/netif.h: add gref mapping control messages This combined with the drivers that Broadcom wrote (I think that is the name of the company that posted them a year or so ago), should provide awesome performance. > > Thanks, > Jianfeng ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] libxl: Change the type of console_mfn to xen_pfn_t
On Tue, Oct 17, 2017 at 10:16:30PM +0530, Bhupinder Thakur wrote:
One also explains the rationale in the commit. Perhaps also
include 'Reported-by' ..
> Signed-off-by: Bhupinder Thakur
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Stefano Stabellini
> CC: Julien Grall
>
> tools/libxl/libxl_console.c | 2 +-
> tools/libxl/libxl_dom.c | 2 +-
> tools/libxl/libxl_internal.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 6bfc0e5..f2ca689 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t
> domid,
> flexarray_append(ro_front, "port");
> flexarray_append(ro_front, GCSPRINTF("%"PRIu32,
> state->console_port));
> flexarray_append(ro_front, "ring-ref");
> -flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
> +flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn,
> state->console_mfn));
> } else {
> flexarray_append(front, "state");
> flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index ef834e6..a58e74f 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -869,7 +869,7 @@ out:
> static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
> libxl_domain_build_info *info,
> int store_evtchn, unsigned long *store_mfn,
> -int console_evtchn, unsigned long
> *console_mfn,
> +int console_evtchn, xen_pfn_t *console_mfn,
> domid_t store_domid, domid_t console_domid)
> {
> struct hvm_info_table *va_hvm;
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 45e6df6..f52aeb3 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -1128,7 +1128,7 @@ typedef struct {
>
> uint32_t console_port;
> uint32_t console_domid;
> -unsigned long console_mfn;
> +xen_pfn_t console_mfn;
> char *console_tty;
>
> char *saved_state;
> --
> 2.7.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/public: Correct the definition of GNTTAB_CACHE_SOURCE_GREF
On Tue, Oct 17, 2017 at 03:11:51PM +0100, Andrew Cooper wrote:
> Discovered when running the XSA-232 PoC on a UBSAN-enabled hypervisor.
>
> (d79) XSA-232 PoC
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in grant_table.c:3217:25
> (XEN) left shift of 1 by 31 places cannot be represented in type 'int'
> (XEN) [ Xen-4.10.0-rc x86_64 debug=y Tainted:H ]
>
> Update all of the GNTTAB_CACHE_* constants to be unsigned integers.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Tim Deegan
> CC: Wei Liu
> CC: Julien Grall
>
> This is a trivial bugfix, and is low risk for 4.10
> ---
> xen/include/public/grant_table.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/xen/include/public/grant_table.h
> b/xen/include/public/grant_table.h
> index 018036e..180d62c 100644
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -589,9 +589,9 @@ struct gnttab_cache_flush {
> } a;
> uint16_t offset; /* offset from start of grant */
> uint16_t length; /* size within the grant */
> -#define GNTTAB_CACHE_CLEAN (1<<0)
> -#define GNTTAB_CACHE_INVAL (1<<1)
> -#define GNTTAB_CACHE_SOURCE_GREF(1<<31)
> +#define GNTTAB_CACHE_CLEAN (1u<<0)
> +#define GNTTAB_CACHE_INVAL (1u<<1)
> +#define GNTTAB_CACHE_SOURCE_GREF(1u<<31)
> uint32_t op;
> };
> typedef struct gnttab_cache_flush gnttab_cache_flush_t;
> --
> 2.1.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On Sun, Oct 15, 2017 at 03:31:15AM +0300, Michael S. Tsirkin wrote: > On Fri, Oct 13, 2017 at 03:46:39PM -0700, Stefano Stabellini wrote: > > On Fri, 13 Oct 2017, Jan Beulich wrote: > > > >>> On 13.10.17 at 13:13, wrote: > > > > To Jan, Andrew, Stefano and Anthony, > > > > > > > > what do you think about allowing QEMU to build the entire guest ACPI > > > > and letting SeaBIOS to load it? ACPI builder code in hvmloader is > > > > still there and just bypassed in this case. > > > > > > Well, if that can be made work in a non-quirky way and without > > > loss of functionality, I'd probably be fine. I do think, however, > > > that there's a reason this is being handled in hvmloader right now. > > > > And not to discourage you, just as a clarification, you'll also need to > > consider backward compatibility: unless the tables are identical, I > > imagine we'll have to keep using the old tables for already installed > > virtual machines. > > Maybe you can handle this using machine type versioning. And the type could be v2 if nvdimm was provided (which is something that the toolstack would figure out). The toolstack could also have a seperate 'v2' config flag if somebody wanted to play with this _outside_ of having NVDIMM in the guest? > Installed guests would use the old type. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On Thu, Oct 12, 2017 at 08:45:44PM +0800, Haozhong Zhang wrote: > On 10/10/17 12:05 -0400, Konrad Rzeszutek Wilk wrote: > > On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote: > > > On 09/11/17 11:52 -0700, Stefano Stabellini wrote: > > > > CC'ing xen-devel, and the Xen tools and x86 maintainers. > > > > > > > > On Mon, 11 Sep 2017, Igor Mammedov wrote: > > > > > On Mon, 11 Sep 2017 12:41:47 +0800 > > > > > Haozhong Zhang wrote: > > > > > > > > > > > This is the QEMU part patches that works with the associated Xen > > > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on > > > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate > > > > > > guest address space for vNVDIMM devices. > > > > > > > > > > > > All patches can be found at > > > > > > Xen: https://github.com/hzzhan9/xen.git nvdimm-rfc-v3 > > > > > > QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3 > > > > > > > > > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing > > > > > > label data, as the Xen side support for labels is not implemented > > > > > > yet. > > > > > > > > > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a > > > > > > hotplug > > > > > > memory region for Xen guest, in order to make the existing nvdimm > > > > > > device plugging path work on Xen. > > > > > > > > > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU > > > > > > is > > > > > > used as the Xen device model. > > > > > > > > > > I've skimmed over patch-set and can't say that I'm happy with > > > > > number of xen_enabled() invariants it introduced as well as > > > > > with partial blobs it creates. > > > > > > > > I have not read the series (Haozhong, please CC me, Anthony and > > > > xen-devel to the whole series next time), but yes, indeed. Let's not add > > > > more xen_enabled() if possible. > > > > > > > > Haozhong, was there a design document thread on xen-devel about this? If > > > > so, did it reach a conclusion? Was the design accepted? If so, please > > > > add a link to the design doc in the introductory email, so that > > > > everybody can read it and be on the same page. > > > > > > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed > > > the guest ACPI. > > > > > > [1] > > > https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html > > > > Igor, did you have a chance to read it? > > > > .. see below > > > > > > > > > > > > > > > > I'd like to reduce above and a way to do this might be making xen > > > > > 1. use fw_cfg > > > > > 2. fetch QEMU build acpi tables from fw_cfg > > > > > 3. extract nvdim tables (which is trivial) and use them > > > > > > > > > > looking at xen_load_linux(), it seems possible to use fw_cfg. > > > > > > > > > > So what's stopping xen from using it elsewhere?, > > > > > instead of adding more xen specific code to do 'the same' > > > > > job and not reusing/sharing common code with tcg/kvm. > > > > > > > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines > > > > rely on a firmware-like application called "hvmloader" that runs in > > > > guest context and generates the ACPI tables. I have no opinions on > > > > hvmloader and I'll let the Xen maintainers talk about it. However, keep > > > > in mind that with an HVM guest some devices are emulated by Xen and/or > > > > by other device emulators that can run alongside QEMU. QEMU doesn't have > > > > a full few of the system. > > > > > > > > Here the question is: does it have to be QEMU the one to generate the > > > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader > > > > like the rest, instead of introducing this split-brain design about > > > > ACPI. We need to see a design doc to fully understand this. > > > > > &
Re: [Xen-devel] [PATCH v10 04/11] public: xen.h: add definitions for UUID handling
On Wed, Oct 11, 2017 at 02:57:59PM +0300, Volodymyr Babchuk wrote:
> Added type xen_uuid_t. This type represents UUID as an array of 16
> bytes in big endian format.
>
> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
>
> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
>
> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}
>
> NB: We define a new structure here rather than re-using EFI_GUID.
> EFI_GUID uses a Microsoft-style encoding which, among other things,
> mixes little-endian and big-endian. The structure defined in this
> patch, unlike EFI_GUID, is compatible with the Linux kernel and libuuid.
>
> Signed-off-by: Volodymyr Babchuk
Acked-by: Konrad Rzeszutek Wilk
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest
On Tue, Sep 12, 2017 at 11:15:09AM +0800, Haozhong Zhang wrote: > On 09/11/17 11:52 -0700, Stefano Stabellini wrote: > > CC'ing xen-devel, and the Xen tools and x86 maintainers. > > > > On Mon, 11 Sep 2017, Igor Mammedov wrote: > > > On Mon, 11 Sep 2017 12:41:47 +0800 > > > Haozhong Zhang wrote: > > > > > > > This is the QEMU part patches that works with the associated Xen > > > > patches to enable vNVDIMM support for Xen HVM domains. Xen relies on > > > > QEMU to build guest NFIT and NVDIMM namespace devices, and allocate > > > > guest address space for vNVDIMM devices. > > > > > > > > All patches can be found at > > > > Xen: https://github.com/hzzhan9/xen.git nvdimm-rfc-v3 > > > > QEMU: https://github.com/hzzhan9/qemu.git xen-nvdimm-rfc-v3 > > > > > > > > Patch 1 is to avoid dereferencing the NULL pointer to non-existing > > > > label data, as the Xen side support for labels is not implemented yet. > > > > > > > > Patch 2 & 3 add a memory backend dedicated for Xen usage and a hotplug > > > > memory region for Xen guest, in order to make the existing nvdimm > > > > device plugging path work on Xen. > > > > > > > > Patch 4 - 10 build and cooy NFIT from QEMU to Xen guest, when QEMU is > > > > used as the Xen device model. > > > > > > I've skimmed over patch-set and can't say that I'm happy with > > > number of xen_enabled() invariants it introduced as well as > > > with partial blobs it creates. > > > > I have not read the series (Haozhong, please CC me, Anthony and > > xen-devel to the whole series next time), but yes, indeed. Let's not add > > more xen_enabled() if possible. > > > > Haozhong, was there a design document thread on xen-devel about this? If > > so, did it reach a conclusion? Was the design accepted? If so, please > > add a link to the design doc in the introductory email, so that > > everybody can read it and be on the same page. > > Yes, there is a design [1] discussed and reviewed. Section 4.3 discussed > the guest ACPI. > > [1] https://lists.xenproject.org/archives/html/xen-devel/2016-07/msg01921.html Igor, did you have a chance to read it? .. see below > > > > > > > > I'd like to reduce above and a way to do this might be making xen > > > 1. use fw_cfg > > > 2. fetch QEMU build acpi tables from fw_cfg > > > 3. extract nvdim tables (which is trivial) and use them > > > > > > looking at xen_load_linux(), it seems possible to use fw_cfg. > > > > > > So what's stopping xen from using it elsewhere?, > > > instead of adding more xen specific code to do 'the same' > > > job and not reusing/sharing common code with tcg/kvm. > > > > So far, ACPI tables have not been generated by QEMU. Xen HVM machines > > rely on a firmware-like application called "hvmloader" that runs in > > guest context and generates the ACPI tables. I have no opinions on > > hvmloader and I'll let the Xen maintainers talk about it. However, keep > > in mind that with an HVM guest some devices are emulated by Xen and/or > > by other device emulators that can run alongside QEMU. QEMU doesn't have > > a full few of the system. > > > > Here the question is: does it have to be QEMU the one to generate the > > ACPI blobs for the nvdimm? It would be nicer if it was up to hvmloader > > like the rest, instead of introducing this split-brain design about > > ACPI. We need to see a design doc to fully understand this. > > > > hvmloader runs in the guest and is responsible to build/load guest > ACPI. However, it's not capable to build AML at runtime (for the lack > of AML builder). If any guest ACPI object is needed (e.g. by guest > DSDT), it has to be generated from ASL by iasl at Xen compile time and > then be loaded by hvmloader at runtime. > > Xen includes an OperationRegion "BIOS" in the static generated guest > DSDT, whose address is hardcoded and which contains a list of values > filled by hvmloader at runtime. Other ACPI objects can refer to those > values (e.g., the number of vCPUs). But it's not enough for generating > guest NVDIMM ACPI objects at compile time and then being customized > and loaded by hvmload, because its structure (i.e., the number of > namespace devices) cannot be decided util the guest config is known. > > Alternatively, we may introduce an AML builder in hvmloader and build > all guest ACPI completely in hvmloader. Looking at the similar > implementation in QEMU, it would not be small, compared to the current > size of hvmloader. Besides, I'm still going to let QEMU handle guest > NVDIMM _DSM and _FIT calls, which is another reason I use QEMU to > build NVDIMM ACPI. > > > If the design doc thread led into thinking that it has to be QEMU to > > generate them, then would it make the code nicer if we used fw_cfg to > > get the (full or partial) tables from QEMU, as Igor suggested? > > I'll have a look at the code (which I didn't notice) pointed by Igor. And there is a spec too! https://github.com/qemu/qemu/blob/master/docs/specs/fw_cfg.txt Igor, did you have in mind to use
Re: [Xen-devel] [PATCH] Remove redundant code in branch MAP_PIRQ_TYPE_MSI
On Mon, Oct 09, 2017 at 02:15:48PM +0800, Joe Jin wrote: > Looks good for me. > > Reviewed-by: Joe Jin Ah, indeed. Reviewed-by: Konrad Rzeszutek Wilk Also CC-ing Jan and Andrew. P.S. Could you change the title to have 'x86/physdev:' as part of the name please? > > On 10/09/2017 02:00 PM, Zhenzhong Duan wrote: > > Same code is already in allocate_and_map_msi_pirq() > > > > Signed-off-by: Zhenzhong Duan > > --- > > xen/arch/x86/physdev.c |2 -- > > 1 files changed, 0 insertions(+), 2 deletions(-) > > > > diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c > > index 0eb4097..aa02d18 100644 > > --- a/xen/arch/x86/physdev.c > > +++ b/xen/arch/x86/physdev.c > > @@ -122,8 +122,6 @@ int physdev_map_pirq(domid_t domid, int type, int > > *index, int *pirq_p, > > break; > > > > case MAP_PIRQ_TYPE_MSI: > > -if ( !msi->table_base ) > > -msi->entry_nr = 1; > > /* fallthrough */ > > case MAP_PIRQ_TYPE_MULTI_MSI: > > ret = allocate_and_map_msi_pirq(d, *index, pirq_p, type, msi); > > > > > -- > Oracle <http://www.oracle.com> > Joe Jin | Software Development Director | +8610.6106.5624 > ORACLE | Linux and Virtualization > No. 24 Zhongguancun Software Park, Haidian District | 100193 Beijing > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [refpolicy SELinux PATCH] Updates to SELinux refpolicies to make xenconsoled work. (v1)]
Re-sending as the first didn't hit the refpolicy mailing list. Date: Mon, 9 Oct 2017 11:53:45 -0400 From: Konrad Rzeszutek Wilk To: refpol...@oss.tresys.com Cc: xen-de...@lists.xenproject.org Subject: [refpolicy SELinux PATCH] Updates to SELinux refpolicies to make xenconsoled work. (v1) Hey! Since Xen 4.6 the xenstored prefers to use /dev/xen/xenbus instead of /proc/xen/xenbus. That wasn't in the original email that Anthony had sent: "[refpolicy] [SELINUX POLICY PATCH] Update for Xen 4.7" http://oss.tresys.com/pipermail/refpolicy/2017-August/009784.html But nonetheless it is needed to make xenconsoled work on Fedora installs. Additionally we also add the 'map' functionality to make the xenconsoled /xenconsole work together. For more details, please see: https://bugzilla.redhat.com/show_bug.cgi?id=1484908 Please merge at your convience. Konrad Rzeszutek Wilk (2): kernel/xen: Update for Xen 4.6 kernel/xen: Add map permission to the dev_rw_xen policy/modules/kernel/devices.fc | 1 + policy/modules/kernel/devices.if | 1 + 2 files changed, 2 insertions(+) - End forwarded message - ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [refpolicy SELinux PATCH 2/2] kernel/xen: Add map permission to the dev_rw_xen
From: Konrad Rzeszutek Wilk
type=AVC msg=audit(1504637347.487:280): avc: denied { map } for pid=857
comm="xenconsoled" path="/dev/xen/privcmd" dev="devtmpfs" ino=16289
scontext=system_u:system_r:xenconsoled_t:s0
Without this we can't use xenconsole (client) to
talk to xenconsoled (server).
Signed-off-by: Konrad Rzeszutek Wilk
---
policy/modules/kernel/devices.if | 1 +
1 file changed, 1 insertion(+)
diff --git a/policy/modules/kernel/devices.if b/policy/modules/kernel/devices.if
index 4c47709ff..c9071df8f 100644
--- a/policy/modules/kernel/devices.if
+++ b/policy/modules/kernel/devices.if
@@ -4984,6 +4984,7 @@ interface(`dev_rw_xen',`
')
rw_chr_files_pattern($1, device_t, xen_device_t)
+ allow $1 xen_device_t:chr_file map;
')
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [refpolicy SELinux PATCH 1/2] kernel/xen: Update for Xen 4.6
From: Konrad Rzeszutek Wilk libxenstored since git commit 9c89dc95201ffed5fead17b35754bf9440fdbdc0 prefers to use "/dev/xen/xenbus" over the "/proc/xen/xenbus". Signed-off-by: Konrad Rzeszutek Wilk --- policy/modules/kernel/devices.fc | 1 + 1 file changed, 1 insertion(+) diff --git a/policy/modules/kernel/devices.fc b/policy/modules/kernel/devices.fc index f4093434b..e206720be 100644 --- a/policy/modules/kernel/devices.fc +++ b/policy/modules/kernel/devices.fc @@ -183,6 +183,7 @@ ifdef(`distro_suse', ` /dev/xen/gntdev-c gen_context(system_u:object_r:xen_device_t,s0) /dev/xen/gntalloc -c gen_context(system_u:object_r:xen_device_t,s0) /dev/xen/privcmd -c gen_context(system_u:object_r:xen_device_t,s0) +/dev/xen/xenbus-c gen_context(system_u:object_r:xen_device_t,s0) ifdef(`distro_debian',` # this is a static /dev dir "backup mount" -- 2.13.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [refpolicy SELinux PATCH] Updates to SELinux refpolicies to make xenconsoled work. (v1)
Hey! Since Xen 4.6 the xenstored prefers to use /dev/xen/xenbus instead of /proc/xen/xenbus. That wasn't in the original email that Anthony had sent: "[refpolicy] [SELINUX POLICY PATCH] Update for Xen 4.7" http://oss.tresys.com/pipermail/refpolicy/2017-August/009784.html But nonetheless it is needed to make xenconsoled work on Fedora installs. Additionally we also add the 'map' functionality to make the xenconsoled /xenconsole work together. For more details, please see: https://bugzilla.redhat.com/show_bug.cgi?id=1484908 Please merge at your convience. Konrad Rzeszutek Wilk (2): kernel/xen: Update for Xen 4.6 kernel/xen: Add map permission to the dev_rw_xen policy/modules/kernel/devices.fc | 1 + policy/modules/kernel/devices.if | 1 + 2 files changed, 2 insertions(+) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.
On Thu, Oct 05, 2017 at 04:28:46PM +0200, Dario Faggioli wrote:
> Replace, in the 'M:' fields of the components I co-maintain
> ('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
> email, to which I don't have access any longer, with my
> personal email.
>
> Signed-off-by: Dario Faggioli
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Jan Beulich
> Cc: Konrad Rzeszutek Wilk
Acked-by: Konrad Rzeszutek Wilk
> Cc: Stefano Stabellini
> Cc: Tim Deegan
> Cc: Wei Liu
> Cc: Juergen Gross
> Cc: Meng Xu
> ---
> MAINTAINERS |6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 12dbad130c..4d7092324a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>
> CPU POOLS
> M: Juergen Gross
> -M: Dario Faggioli
> +M: Dario Faggioli
> S: Supported
> F: xen/common/cpupool.c
>
> @@ -335,14 +335,14 @@ F: tools/hotplug/Linux/remus-netbuf-setup
> F: tools/hotplug/Linux/block-drbd-probe
>
> RTDS SCHEDULER
> -M: Dario Faggioli
> +M: Dario Faggioli
> M: Meng Xu
> S: Supported
> F: xen/common/sched_rt.c
>
> SCHEDULING
> M: George Dunlap
> -M: Dario Faggioli
> +M: Dario Faggioli
> S: Supported
> F: xen/common/sched*
>
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 01/11] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.
On Thu, Oct 05, 2017 at 02:47:30PM +0100, Ross Lagerwall wrote: > On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote: > > If the livepatch has only .rodata sections then it is OK to also > > apply/revert/apply the livepatch without having to worry about the > > unforseen consequences. > > > > See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c > > "livepatch: Disallow applying after an revert" for details. > > > > Signed-off-by: Konrad Rzeszutek Wilk > > --- > > Cc: Ross Lagerwall > > > > The patch looks OK, but what is the use case for a live patch with only > .rodata? A NOP one. This hasn't been an issue in the past, but further patches change the .livepatch_funcs from RW to RO (to be in line with what livepatch-build-tools.git do) - and then the xen_nop testcase does not work anymore. > > Regards, > -- > Ross Lagerwall > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] 4.9.52: INFO: task XXX blocked for more than 300 seconds.
On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote: > Hello, > Adding Ankur to this as I think he saw something similar. But in the meantime - do you see this with the latest version of Linux? > with linux-4.9.52 running on Debian-Wheezy with Xen-4.1 I observed > several stuck processes: Here is one (truncated) dump of the Linux > kernel messages: > > > [] ? __schedule+0x23d/0x6d0 > > [] ? bit_wait_timeout+0x90/0x90 > > [] ? schedule+0x32/0x80 > > [] ? schedule_timeout+0x1ec/0x360 > > [] ? __blk_mq_run_hw_queue+0x327/0x3e0* see below > > [] ? xen_clocksource_get_cycles+0x11/0x20 > > [] ? bit_wait_timeout+0x90/0x90 > > [] ? io_schedule_timeout+0xb4/0x130 > > [] ? prepare_to_wait+0x57/0x80 > > [] ? bit_wait_io+0x17/0x60 > > [] ? __wait_on_bit+0x5c/0x90 > > [] ? bit_wait_timeout+0x90/0x90 > > [] ? out_of_line_wait_on_bit+0x7e/0xa0 > > [] ? autoremove_wake_function+0x40/0x40 > > [] ? jbd2_journal_commit_transaction+0xd48/0x17e0 [jbd2] > > [] ? __switch_to+0x2c9/0x720 > > [] ? try_to_del_timer_sync+0x4d/0x80 > > [] ? kjournald2+0xdd/0x280 [jbd2] > > [] ? wake_up_atomic_t+0x30/0x30 > > [] ? commit_timeout+0x10/0x10 [jbd2] > > [] ? kthread+0xf0/0x110 > > [] ? __switch_to+0x2c9/0x720 > > [] ? kthread_park+0x60/0x60 > > [] ? ret_from_fork+0x25/0x30 > > NMI backtrace for cpu 2 > > CPU: 2 PID: 35 Comm: khungtaskd Not tainted 4.9.0-ucs105-amd64 #1 Debian > > 4.9.30-2A~4.2.0.201709271649 > > 81331935 0002 > > 81335e60 0002 8104cb70 8801f0c90e80 > > 81335f6a 8801f0c90e80 003fffbc 81128048 > > Call Trace: > > [] ? dump_stack+0x5c/0x77 > > [] ? nmi_cpu_backtrace+0x90/0xa0 > > [] ? irq_force_complete_move+0x140/0x140 > > [] ? nmi_trigger_cpumask_backtrace+0xfa/0x130 > > [] ? watchdog+0x2b8/0x330 > > [] ? reset_hung_task_detector+0x10/0x10 > > [] ? kthread+0xf0/0x110 > > [] ? __switch_to+0x2c9/0x720 > > [] ? kthread_park+0x60/0x60 > > [] ? ret_from_fork+0x25/0x30 > > Sending NMI from CPU 2 to CPUs 0-1,3: > > NMI backtrace for cpu 1 > > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0-ucs105-amd64 #1 Debian > > 4.9.30-2A~4.2.0.201709271649 > > task: 8801f4a02ec0 task.stack: c90040ca4000 > > RIP: e030:[] [] > > xen_hypercall_sched_op+0xa/0x20 > > RSP: e02b:c90040ca7ed0 EFLAGS: 0246 > > RAX: RBX: 8801f4a02ec0 RCX: 810013aa > > RDX: 81c4ba70 RSI: RDI: 0001 > > RBP: 0001 R08: R09: > > R10: 7ff0 R11: 0246 R12: > > R13: R14: 8801f4a02ec0 R15: 8801f4a02ec0 > > FS: 7f23ac595700() GS:8801f5a8() knlGS: > > CS: e033 DS: 002b ES: 002b CR0: 80050033 > > CR2: 7f52537d6d46 CR3: 0001bba23000 CR4: 2660 > > Stack: > > 8801bb832201 0001 8101b55c 81611ec8 > > 8801f4a02ec0 0001 810bc280 8801f4a02ec0 > > 8801f4a02ec0 c0a995961d41240f addce6dcadd009c9 > > Call Trace: > > [] ? xen_safe_halt+0xc/0x20 > > [] ? default_idle+0x18/0xd0 > > [] ? cpu_startup_entry+0x1f0/0x260 > > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc > > cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 > > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > > NMI backtrace for cpu 3 > > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.0-ucs105-amd64 #1 Debian > > 4.9.30-2A~4.2.0.201709271649 > > task: 8801f4a24f00 task.stack: c90040cb4000 > > RIP: e030:[] [] > > xen_hypercall_sched_op+0xa/0x20 > > RSP: e02b:c90040cb7ed0 EFLAGS: 0246 > > RAX: RBX: 8801f4a24f00 RCX: 810013aa > > RDX: 81c4ba70 RSI: RDI: 0001 > > RBP: 0003 R08: R09: > > R10: 7ff0 R11: 0246 R12: > > R13: R14: 8801f4a24f00 R15: 8801f4a24f00 > > FS: 7f1a2af19700() GS:8801f5b8() knlGS: > > CS: e033 DS: 002b ES: 002b CR0: 80050033 > > CR2: 7f4a5416b000 CR3: 0001d83ec000 CR4: 2660 > > Stack: > > 0001 0001 8101b55c 81611ec8 > > 8801f4a24f00 0003 810bc280 8801f4a24f00 > > 8801f4a24f00 77816deb133b9979 addce6dcadd009c9 > > Call Trace: > > [] ? xen_safe_halt+0xc/0x20 > > [] ? default_idle+0x18/0xd0 > > [] ? cpu_startup_entry+0x1f0/0x260 > > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc > > cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 > > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc > > NMI backtrace for cpu 0 > > CPU: 0 PID: 0 Comm: swapper/0 Not ta
Re: [Xen-devel] [PATCH v7 04/11] public: xen.h: add definitions for UUID handling
On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote:
> Added type xen_uuid_t. This type represents UUID as an array of 16
> bytes in big endian format.
>
> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
>
> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
> 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
>
> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
> {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
> 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}
>
> NB: This is compatible with Linux kernel and with libuuid, but it is not
> compatible with Microsoft, as they use mixed-endian encoding (some
> components are little-endian, some are big-endian).
Oh boy. What a mess.
Do we care about Microsoft for this or is this more for information
purpose?
>
> Signed-off-by: Volodymyr Babchuk
> ---
>
> * Fixed example for XEN_DEFINE_UUID() usage. Was
> XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, 0xaabbccddeeff)
>
> * Added comment to xen.h
>
> * Used
> #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> instead of
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
>
> * Used generic macro XEN_DEFINE_UUID_
>
> ---
> xen/include/public/xen.h | 33 +
> 1 file changed, 33 insertions(+)
>
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 2ac6b1e..1a6255f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
> __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
> __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
>
> +typedef struct
> +{
> +uint8_t a[16];
> +} xen_uuid_t;
> +
> +/*
> + * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
> + * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
> + * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
> + * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
> + * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
> + *
> + * NB: This is compatible with Linux kernel and with libuuid, but it is not
> + * compatible with Microsoft, as they use mixed-endian encoding (some
> + * components are little-endian, some are big-endian).
> + */
> +#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)\
> +{{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF, \
> + ((a) >> 8) & 0xFF, ((a) >> 0) & 0xFF, \
> + ((b) >> 8) & 0xFF, ((b) >> 0) & 0xFF, \
> + ((c) >> 8) & 0xFF, ((c) >> 0) & 0xFF, \
> + ((d) >> 8) & 0xFF, ((d) >> 0) & 0xFF, \
> +e1, e2, e3, e4, e5, e6}}
> +
> +/* Compound literals are supported in C99 and later. */
> +#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
> +(xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
> +#else
> +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
> +XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
> +#endif /* defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L */
> +
> #endif /* !__ASSEMBLY__ */
>
> /* Default definitions for macros used by domctl/sysctl. */
> --
> 2.7.4
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xen/ubsan: Introduce and use CONFIG_UBSAN
> +config UBSAN > + bool "Undefined behaviour sanitizer" > + depends on X86 > + ---help--- > + Enable undefined behaviour sanitizer. > + > + If unsure, say N here. Could you perhaps expand it a bit? How does it sanitize it? With soap :-)? And what 'undefinded behaviour's are we talking about? opcodes? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] xen/tmem: Drop unnecessary noinline attribute
On Tue, Oct 03, 2017 at 07:07:50PM +0100, Andrew Cooper wrote:
> tmem_mempool_page_get() is only referenced by address, so isn't eligable for
> inlining in the first place.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Konrad Rzeszutek Wilk
Reviewed-by: Konrad Rzeszutek Wilk
>
> Not related to the rest of the series, but I stumbled across it while
> resolving another noinline issue.
> ---
> xen/common/tmem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> index c955cf7..324f42a 100644
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -200,7 +200,7 @@ static void tmem_free_page(struct tmem_pool *pool, struct
> page_info *pfp)
> atomic_dec_and_assert(global_page_count);
> }
>
> -static noinline void *tmem_mempool_page_get(unsigned long size)
> +static void *tmem_mempool_page_get(unsigned long size)
> {
> struct page_info *pi;
>
> --
> 2.1.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore
I get this when compiling under ARM32 (Ubuntu 15.04,
gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
libxl_console.c: In function ‘libxl__device_vuart_add’:
libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long
unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
^
;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 9/9] xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one
On Mon, Oct 02, 2017 at 06:31:50PM +0100, Julien Grall wrote:
> This will help to consolidate the page-table code and avoid different
> path depending on the action to perform.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andre Przywara
> Reviewed-by: Stefano Stabellini
>
> ---
>
Reviewed-by: Konrad Rzeszutek Wilk
> Cc: Ross Lagerwall
>
> arch_livepatch_secure is now the same as on x86. It might be
> possible to combine both, but I left that alone for now.
>
> Changes in v3:
> - Add Stefano's reviewed-by
>
> Changes in v2:
> - Add Andre's reviewed-by
> ---
> xen/arch/arm/livepatch.c | 6 +++---
> xen/arch/arm/mm.c | 5 ++---
> xen/include/asm-arm/page.h | 11 ---
> 3 files changed, 5 insertions(+), 17 deletions(-)
>
> diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
> index 3e53524365..279d52cc6c 100644
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -146,15 +146,15 @@ int arch_livepatch_secure(const void *va, unsigned int
> pages, enum va_type type)
> switch ( type )
> {
> case LIVEPATCH_VA_RX:
> -flags = PTE_RO; /* R set, NX clear */
> +flags = PAGE_HYPERVISOR_RX;
> break;
>
> case LIVEPATCH_VA_RW:
> -flags = PTE_NX; /* R clear, NX set */
> +flags = PAGE_HYPERVISOR_RW;
> break;
>
> case LIVEPATCH_VA_RO:
> -flags = PTE_NX | PTE_RO; /* R set, NX set */
> +flags = PAGE_HYPERVISOR_RO;
> break;
>
> default:
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 57afedf0be..705bdd9cce 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -1041,8 +1041,8 @@ static int create_xen_entries(enum xenmap_operation op,
> else
> {
> pte = *entry;
> -pte.pt.ro = PTE_RO_MASK(flags);
> -pte.pt.xn = PTE_NX_MASK(flags);
> +pte.pt.ro = PAGE_RO_MASK(flags);
> +pte.pt.xn = PAGE_XN_MASK(flags);
> if ( !pte.pt.ro && !pte.pt.xn )
> {
> printk("%s: Incorrect combination for addr=%lx\n",
> @@ -1085,7 +1085,6 @@ int destroy_xen_mappings(unsigned long v, unsigned long
> e)
>
> int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
> {
> -ASSERT((flags & (PTE_NX | PTE_RO)) == flags);
> return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
>flags);
> }
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index e2b3e402d0..e4be83a7bc 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -96,17 +96,6 @@
> #define PAGE_HYPERVISOR_WC (_PAGE_DEVICE|MT_NORMAL_NC)
>
> /*
> - * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to
> be
> - * used with modify_xen_mappings.
> - */
> -#define _PTE_NX_BIT 0U
> -#define _PTE_RO_BIT 1U
> -#define PTE_NX (1U << _PTE_NX_BIT)
> -#define PTE_RO (1U << _PTE_RO_BIT)
> -#define PTE_NX_MASK(x) (((x) >> _PTE_NX_BIT) & 0x1U)
> -#define PTE_RO_MASK(x) (((x) >> _PTE_RO_BIT) & 0x1U)
> -
> -/*
> * Stage 2 Memory Type.
> *
> * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 1/1] public/io/netif.h: add gref mapping control messages
On Wed, Sep 20, 2017 at 08:23:20AM +, Paul Durrant wrote: > > -Original Message- > > From: Joao Martins [mailto:joao.m.mart...@oracle.com] > > Sent: 19 September 2017 20:08 > > To: Xen-devel > > Cc: Wei Liu ; Paul Durrant ; > > Konrad Rzeszutek Wilk ; Joao Martins > > > > Subject: [PATCH v4 1/1] public/io/netif.h: add gref mapping control messages > > > > Adds 3 messages to allow guest to let backend keep grants mapped, > > such that 1) guests allowing fast recycling of pages can avoid doing > > grant ops for those cases, or otherwise 2) preferring copies over > > grants and 3) always using a fixed set of pages for network I/O. > > > > The three control ring messages added are: > > - Add grefs to be mapped by backend > > - Remove grefs mappings (If they are not in use) > > - Get maximum amount of grefs kept mapped. > > > > Signed-off-by: Joao Martins > > I think the text is clear enough now. Now for the netfront/netback patches :-) > > Reviewed-by: Paul Durrant Reviewed-by: Konrad Rzeszutek Wilk Joao, would you be OK reposting this along with an patch that drops the pandoc document in docs/misc? Feel free to add my Reviewed-by as I see that you already removed the mention of 'RFC' from it. Thank you. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/1] netif: staging grants for I/O requests
> Joao Martins (1): > public/io/netif.h: add gref mapping control messages > > xen/include/public/io/netif.h | 115 > ++ > 1 file changed, 115 insertions(+) > --- Could you include the following pandoc document in docs/misc? And change only one thing: > % Staging grants for network I/O requests > % Joao Martins <> > % Revision 3 > > \clearpage > > > Architecture(s): Any > > > # Background and Motivation > > At the Xen hackaton '16 networking session, we spoke about having a > permanently > mapped region to describe header/linear region of packet buffers. This > document > outlines the proposal covering motivation of this and applicability for other > use-cases alongside the necessary changes. This proposal is an RFC and also s/is an RFC and also/ And with that Reviewed-by: Konrad Rzeszutek Wilk ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] (Offlist)Re: ARM64 HiKey 960 Xen BUG at page_alloc.c:738
On Fri, Sep 29, 2017 at 10:57:11AM -0400, John P. McDermott (USN Civilian) wrote: > Xen Developers, > > Trying to run Xen ARM64 on HiKey 960. Following the guidance on the wiki, > building on Ubuntu 17, everything works as expected until Xen boots. The > interesting tail of the serial console output is (Offlist) Can you make sure that CONFIG_SCRUB_DEBUG is not set. > (XEN) > (XEN) Panic on CPU 0: > (XEN) Xen BUG at page_alloc.c:738 > (XEN) > (XEN) > (XEN) Reboot in five seconds... > > > I would be pleased to supply any further information that might help. > > Sincerely, > > John > > > > > > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Formal vote on Unicore Proposal (deadline Frid, Oct 6th)
On Fri, Sep 29, 2017 at 12:07:47PM +, Lars Kurth wrote: > Dear committers, > > in accordance with https://www.xenproject.org/governance.html, I need the > leadership teams of the two mature projects – the Hypervisor and the XAPI > project – to vote on this proposal. > > The Advisory Board is endorsing the proposal and there seems to be wide > consensus amongst community members. > > The specific voting rules in this case are outlined in section > https://www.xenproject.org/governance.html#project-decisions > > People allowed to vote on behalf of the Hypervisor project are: > Julien Grall, Andy Cooper, George Dunlap, Ian Jackson, Jan Beulich, Konrad R > Wilk, Stefano Stabellini, Tim Deegan, Wei Liu +1 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] GRUB2 missing multiboot2 patches?Re: Only 1 CPU was detected
On Fri, Sep 29, 2017 at 11:49:39AM +0100, Michael Young wrote: > > > On Thu, 28 Sep 2017, Hongjiang Zhang wrote: > > > > -Original Message- > > > From: Stefan Bader [mailto:stefan.ba...@canonical.com] > > > Sent: Friday, September 29, 2017 4:49 AM > > > To: Konrad Rzeszutek Wilk ; Hongjiang Zhang > > > > > > Cc: Juergen Gross ; xen-de...@lists.xenproject.org > > > Subject: Re: GRUB2 missing multiboot2 patches?Re: [Xen-devel] Only 1 CPU > > > was detected > > > > > > On 28.09.2017 16:03, Konrad Rzeszutek Wilk wrote: > > > > On Thu, Sep 28, 2017 at 02:45:38PM +, Hongjiang Zhang wrote: > > > > > > > (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found > > > > > > > [20070126] > > > > > > > > > > > > Uuh, that is rather bad, I guess. > > > > > > > > I am going to assume this is due to not having: > > > > > > > > b4d709b6e Use grub-file to figure out whether multiboot2 should be > > > > used for Xen.gz a8e0f1adf Fix util/grub.d/20_linux_xen.in: Add > > > > xen_boot command support for aarch64 > > > > > > > > In the grub that he is using (Ubuntu?) > > > > > > > > In other words he is using 'multiboot' instead of 'multiboot2' > > > > > > > If this is Ubuntu, my expectation is that this would require Xen 4.9 > > > (which is > > > part of 17.10 but not yet released) and work on grub2 (which I will very > > > unlikely have the time for). Debian has not yet moved to Xen 4.9, so I > > > would > > > doubt that it would work there either. > > > > > If Xen 4.9 does not work either, shall I try CentOS 7.13 instead? Or which > > Linux distribution is recommended? > > I think Fedora 27 (currently in beta) is almost there (for x86_64 anyway). > It does have xen 4.9, but some manual steps are needed to get grub2 working > using multiboot2. These are > > * edit the grub.cfg file to use multiboot2 and module2 rather than multiboot > and module It won't generate the stanza. > * install the grub2-efi-x64-modules package and copy multiboot2.mod and > relocator.mod from /usr/lib/grub/x86_64-efi to > /boot/efi/EFI/fedora/x86_64-efi/ (which you probably need to create) > * add insmod multiboot2 to the relevant section in the grub.cfg file with > the other insmod lines. > > Also watch out for useless sections in the grub.cfg file for a xen config > file rather than for xen itself. Sadly not there as the ARM changes broke x86, see: https://bugzilla.redhat.com/show_bug.cgi?id=1486002 > > I recently got xen working doing the above including running a domU guest, > but gdm didn't start and I haven't had a chance to work out if that is > related or not. > > Michael Young ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] GRUB2 missing multiboot2 patches?Re: Only 1 CPU was detected
On Thu, Sep 28, 2017 at 02:45:38PM +, Hongjiang Zhang wrote: > >> (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found > >> [20070126] > > > >Uuh, that is rather bad, I guess. I am going to assume this is due to not having: b4d709b6e Use grub-file to figure out whether multiboot2 should be used for Xen.gz a8e0f1adf Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64 In the grub that he is using (Ubuntu?) In other words he is using 'multiboot' instead of 'multiboot2' ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] Tips on how to debug EFI code (iPXE) from within KVM after ipxe.efi has crashed with #GP?
Hey,
I am hitting an interesting issue with the latest versions of iPXE,
edk2, and GRUB wherein I am trying to boot GRUB (via iPXE), and then
load Xen, I get this:
!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID -
ExceptionData -
RIP - BEC2949C, CS - 0038, RFLAGS - 00210216
RAX - , RCX - BFA2DC18, RDX -
RBX - BFA2DC60, RSP - BFEDDFD8, RBP - 0008
RSI - , RDI - 0001
R8 - 0001, R9 - 0030, R10 - 0009E000
R11 - BFF1A000, R12 - BFEF7260, R13 - BFA2DC18
R14 - BF40BD18, R15 - BEB4E8A4
DS - 0030, ES - 0030, FS - 0030
GS - 0030, SS - 0030
CR0 - 80010033, CR2 - , CR3 - BFE7D000
CR4 - 0668, CR8 -
DR0 - , DR1 - , DR2 -
DR3 - , DR6 - 0FF0, DR7 - 0400
GDTR - BFE6B698 0047, LDTR -
IDTR - BF620018 0FFF, TR -
FXSAVE_STATE - BFEDDC30
Find image 808610ed.efidrv (ImageBase=BEC27000,
EntryPoint=BEC2E089)
And now I am trying to figure out how to troubleshoot this.
(and yes I am thinking it was related to the Tivoli work-around, but
disabling that didn't help).
I was somehow hoping I could use 'crash' tool and run it with with the guest
memory and the iPXE code:
#crash ipxe/src/bin/ipxe.lkrn.tmp ./guest-memory
..
WARNING: machine type mismatch:
crash utility: X86_64
ipxe/src/bin/ipxe.lkrn.tmp: X86
crash: ipxe/src/bin/ipxe.lkrn.tmp: not a supported file format
..
So how do folks troubleshoot things like this?
A bit background information:
- The /guest-memory I got by having an -qmp argument and telneting in
it and doing:
{"execute":"dump-guest-memory","arguments":{"paging":
false,"protocol":"file:/guest-memory"}}
- The 80810ed.efidrv is built using:
(cd ipxe/src;make bin-x86_64-efi/808610d3.efi CONFIG=qemu
DEBUG=iscsi:4,scsi:4 EMBED=/ipxe.config -j8)
if [ $? -ne 0 ]; then exit 1; fi
(cd ipxe/src;EfiRom -f 0x8086 -i 0x1528 --pci23 -ec
bin-x86_64-efi/808610d3.efidrv -o ../../808610d3.rom)
if [ $? -ne 0 ]; then exit 1; fi
The ipxe script is simple:
!ipxe
dhcp && echo * DHCP worked || goto dhcp_retry
echo * IP address: ${net0/ip} ; echo * Subnet mask: ${net0/netmask}
ifstat
set url http://10.0.1.2/
echo ${url}
imgfetch ${url}/grub.efi
imgstat
boot grub.efi
- And grub.efi was created with this:
GRUB_MODULES="boot chain configfile echo efinet eval ext2 fat font
gettext gfxterm gzio help linux loadenv lsefi normal part_gpt par
t_msdos read regexp search search_fs_file search_fs_uuid search_label
terminal terminfo test tftp time multiboot multiboot2 net slee
p efifwsetup lsefisystab lspci lsefi lsacpi lsefimmap acpi fat eval
elf file linux linux16 pcidump http serial efi_gop"
grub-install/usr/bin/grub-mkimage \
--config ${GRUB_CFG} \
--directory=`pwd`/grub-install/usr/lib64/grub/x86_64-efi \
--output=grub.efi \
--format=x86_64-efi \
--prefix "(http)/" \
$GRUB_MODULES
# more grub.config
set timeout=5
net_bootp
net_ls_addr
net_ls_cards
net_ls_routes
lspci
set net_default_server=10.0.1.2
serial --speed=115200 --unit=0 --word=8
terminal_output serial console
terminal_input serial console
multiboot2 (http,10.0.1.2)/xen.gz dom0_mem=max:1G loglvl=all
guest_loglvl=all console=com1 com1=115200,8n1
module2 (http,10.0.1.2)/vmlinuz console=hvc0 debug initcall_debug
module2 (http,10.0.1.2)/initrd.img
boot
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM Hikey 960 - Missing Image Files for Xen
On Thu, Sep 28, 2017 at 08:29:27AM -0400, John P. McDermott (USN Civilian) wrote: > Xen Developers, > > The guidance for running Xen on a HiKey 960 identifies files that should be > flashed onto the board, as part of the process for installing Xen. > > https://wiki.xen.org/wiki/HiKey960 > > All but 2 of the files are available from 96 Boards or can be created by > following the guidance. The 2 I have not been able to find are > > cache.img > userdata.img > > I have found all sorts of guidance and source code that copies these files, > assuming they exist. I have nothing on how these 2 files are generated or > where copies might be found. Does anyone know how to get them or if they are > even needed for Xen on the HiKey 960? They are not needed. > > Sincerely, > > John > ___ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes
On Wed, Sep 27, 2017 at 02:46:23PM +0100, Joao Martins wrote: > This file defines an ABI shared between guest and hypervisor(s) > (KVM, Xen) and as such there should be an correspondent entry in > MAINTAINERS file. Notice that there's already a text notice at the > top of the header file, hence this commit simply enforces it more > explicitly and have both peers noticed when such changes happen. > > Signed-off-by: Joao Martins > Acked-by: Juergen Gross Reviewed-by: Konrad Rzeszutek Wilk > --- > In the end, I choose the originally posted because this is so far the > only ABI shared between Xen/KVM. Therefore whenever we have more things > shared it would deserve its own place in MAINTAINERS file. If the > thinking is wrong, I can switch to the alternative with a > "PARAVIRT ABIS" section. > > Changes since v1: > * Add Juergen Gross Acked-by. > --- > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 6671f375f7fc..a4834c3c377a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7603,6 +7603,7 @@ S: Supported > F: arch/x86/kvm/ > F: arch/x86/include/uapi/asm/kvm* > F: arch/x86/include/asm/kvm* > +F: arch/x86/include/asm/pvclock-abi.h > F: arch/x86/kernel/kvm.c > F: arch/x86/kernel/kvmclock.c > > @@ -14718,6 +14719,7 @@ F:arch/x86/xen/ > F: drivers/*/xen-*front.c > F: drivers/xen/ > F: arch/x86/include/asm/xen/ > +F: arch/x86/include/asm/pvclock-abi.h > F: include/xen/ > F: include/uapi/xen/ > F: Documentation/ABI/stable/sysfs-hypervisor-xen > -- > 2.11.0 > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy
On Fri, Sep 22, 2017 at 09:35:40AM +0200, Sander Eikelenboom wrote: > On 22/09/17 04:09, Christopher Clark wrote: > > On Thu, Sep 21, 2017 at 1:27 PM, Sander Eikelenboom > > wrote: > >> > >> On Thu, September 21, 2017, 10:39:52 AM, Roger Pau Monné wrote: > >> > >>> On Wed, Sep 20, 2017 at 03:50:35PM -0400, Jérôme Oufella wrote: > > I'm using PCI pass-through to map a PCIe (intel i210) controller into > a HVM domain. The system uses xen-pciback to hide the appropriate PCI > device from Dom0. > > When creating the HVM domain after an hypervisor cold boot, the HVM > domain can access and use the PCIe controller without problem. > > However, if the HVM domain is destroyed then restarted, it won't be > able to use the pass-through PCI device anymore. The PCI device is > seen and can be mapped, however, the interrupts will not be passed to > the HVM domain anymore (this is visible under a Linux guest as > /proc/interrupts counters remain 0). The behavior on a Windows10 guest > is the same. > > A few interesting hints I noticed: > > - On Dom0, 'lspci -vv' on that PCIe device between the "working" and > the "muted interrupts" states, I noted a difference between the > MSI-X caps: > > - Capabilities: [70] MSI-X: Enable- Count=5 Masked- <-- IRQs will work > if domain started > + Capabilities: [70] MSI-X: Enable- Count=5 Masked+ <-- IRQs won't work > if domain started > ^^^ > >> > >>> IMHO it seems that either your device is not able to perform a reset > >>> successfully, or Linux is not correctly performing such reset. I don't > >>> think there's a lot that can be done from the Xen side. > >> > >> Unfortunately for a lot of pci-devices a simple reset as performed by > >> default isn't enough, > >> but also almost none support a real pci FLR. > >> > >> In the distant past Konrad has made a patchset that implemented a bus > >> reset and > >> reseting config space. (It piggy backed on already existing libxl > >> mechanism of > >> trying to call on a syfs "do_flr" attribute which triggers pciback to > >> perform > >> the busreset and rewrite of config space for the device. > >> > >> I use that patchset ever since for my pci-passtrough needs and it works > >> pretty > >> well. I can shutdown an restart VM's with pci devices passed trhough (also > >> AMD > >> Radeon graphic cards). > > > > Just to confirm the utility of that piece of work: OpenXT also uses an > > extended version of that same patch to perform device reset for > > passthrough. > > > > I've attached a copy of that OpenXT patch to this message and it can > > also be obtained from our git repository: > > https://github.com/OpenXT/xenclient-oe/blob/f8d3b282a87231d9ae717b13d506e8e7e28c78c4/recipes-kernel/linux/4.9/patches/thorough-reset-interface-to-pciback-s-sysfs.patch > > This version creates a sysfs node named "reset_device" and the OpenXT > > libxl toolstack is patched to use that node instead of "do_flr". > > Nice to hear there are more users of this patch. On #xen on IRC there were > from time to time > also users who tried pci-passtrough and ran into this issue (and probably > abandonning the idea > since having to restart your host before being able to use your pass > throughed device again > defies much of the use case). > > > Konrad's original work encountered pushback on upstream acceptance at > > the time it was developed. I'm not sure I've found where that > > discussion ended. Is there any prospect of a more comprehensive reset > > mechanism being accepted into xen-pciback, or elsewhere in the kernel? > > Yeah it was nacked by David Vrabel and the discussion somewhat bleeded to > death. > >From what i remember the main issue was with the naming, since it doesn't do > >a FLR, > the sysfs hook shouldn't be called "do_flr". > > Some other perhaps minor issues i can think of are: > - No way to excempt pci-devices from this new way of resetting them. > Perhaps there could be pci devices/topologies were this way of > resetting causes more problems than it solves and could cause a > regression. Unfortunately auto detecting what works doesn't seem to > be possible. On the other hand (though only with my n=10) i haven't > encountered > such a device yet. > > - The communication path between libxl and the kernel via sysfs. > I think the preference was for a: > a) having it use a more common used Xen communication channel or > b) having it all self-contained in pci-back. (from my memory and the openxt > patch description > there could be some locking issue when trying to implement it this way, > but the vfio guys had that solved for there reset implementation if i > from one of the comments in there source code (patches by Alex Williamson > if i remember correctly). > > - Not an issue back then when the patch was made, bu
Re: [Xen-devel] Xen Porting Inquiry
On Fri, Sep 22, 2017 at 09:31:26AM -0700, t...@hughes.net wrote: > Hello, > > Who can I contact at Xen to obtain an estimate of the effort required to port > Xen to IBM's OpenPOWER 9 CPU? I would recommend you speak to IBM as they would be most qualified to answer that question. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM64:Porting xen to new hardware
On Fri, Sep 22, 2017 at 03:30:57PM +0530, bharat gohil wrote:
> Hello Wilk,
>
> I had try 'console=hvc0' but no success.
>
> @Oleksandr: At this moment it is difficult to share any file of guest.
> It would be helpful if anyone provide me general technique to debug dom0
> bringup issue.
You can also hit 'Ctrl-a' three times and then 'd' which would give you
the stack trace and EIP of dom0. That should help in figuirng where your
dom0 is stuck.
>
> Thanks,
> Bharat
>
> On Mon, Sep 18, 2017 at 8:16 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
>
> > On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> > > Hi Bharat
> > >
> > > On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil wrote:
> > > > Hello Olensandr,
> > > >
> > > > I able to boot xen and trying to boot dom0 but there are no console
> > log for
> > > > dom0.
> > > >
> > > > following log for xen and it stuck booting dom0.
> > > >
> > > > (XEN) I/O virtualisation disabled
> > > > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > > > (XEN) alternatives: Patching with alt table 400d2e08 ->
> > > > 400d32dc
> > > > (XEN) *** LOADING DOMAIN 0 ***
> > > > (XEN) Loading kernel from boot module @ 40148158
> > > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > > > (XEN) BANK[0] 0x004800-0x005000 (128MB)
> > > > (XEN) Grant table range: 0x00bfe0-0x00bfe65000
> > > > (XEN) Loading zImage from 40148158 to
> > > > 4808-4948
> > > > (XEN) Allocating PPI 16 for event channel interrupt
> > > > (XEN) Loading dom0 DTB to 0x4fe0-0x4fe0f31e
> > > > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > > > (XEN) ..done.
> > > > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > > > (XEN) Std. Loglevel: All
> > > > (XEN) Guest Loglevel: All
> > > > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> > input to
> > > > Xen)
> > > > (XEN) Freed 272kB init memory.
> > > >
> > > > I have done all the xen configuration in linux kernel 4.9. This kernel
> > > > booting fine without xen.
> > > >
> > > > following are the DTB changes,
> > > >
> > > > chosen {
> > > > #address-cells = <1>;
> > > > #size-cells = <1>;
> > > > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > > > stdout-path = "serial0";
> > > > module: module@0 {
> > > > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > > > reg = <0x40148158 0x140>;
> > > > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
> >
> > It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> >
> > > > ignore_loglevel rw root=/dev/mmcblk0p7";
> > > > };
> > > >
> > > > };
> > > >
> > > > Can you tell me how to debug dom0 booting or anything which i can
> > check?
> > >
> > > Don't now much about "debug dom0 booting", I leave it for competent
> > people.
> > >
> > > Looks weird, even with earlyprintk no logs.
> > > Do you have DEBUG_LL and all related options enabled in your dom0 kernel
> > config?
> > >
> > > 1. Check that following options are enabled in your kernel config file:
> > >
> > > CONFIG_HVC_XEN=y
> > > CONFIG_HVC_XEN_FRONTEND=y
> > >
> > > 2. Check that dom0 kernel doesn't disable clock for console.
> > >
> > > BTW, could you post full Xen log, kernel config and device-tree you are
> > using?
> > > If you have some changes on top of Xen, post them too.
> > > These may help people to identify what is wrong.
> > >
> > > >
> > > >
> > > > Thanks,
> > > > Bharat
> > > >
> > > > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko <
> > olekst...@gmail.com>
> > > > wrote:
> > > >>
> > > >> Hi Bharat
> > > >>
> > > >>
[Xen-devel] [PATCH v4 02/11] livepatch: Tighten alignment checks.
The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.
We on loading did not take this in-to account so this patch adds
a check on the ELF file as it is being parsed.
Reviewed-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
v1: Initial patch
v2: Drop the check when loading it in memory
Add check for alignment being anything but power of two (ignoring 0, and 1)
Change dprintk to include hex values and print addr not size.
v3: Change the two checks to be per Jan's recommendations.
v4: Add Jan's Reviewed-by.
Swap the two conditionals around.
---
xen/common/livepatch_elf.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index b69e2718dd..dd8b47a1fa 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,19 @@ static int elf_resolve_sections(struct livepatch_elf *elf,
const void *data)
delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past
end");
return -EINVAL;
}
+else if ( sec[i].sec->sh_addralign & (sec[i].sec->sh_addralign - 1) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] alignment
(%#"PRIxElfAddr") is not supported\n",
+elf->name, i, sec[i].sec->sh_addralign);
+return -EOPNOTSUPP;
+}
+else if ( sec[i].sec->sh_addralign &&
+ sec[i].sec->sh_addr % sec[i].sec->sh_addralign )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] addr
(%#"PRIxElfAddr") is not aligned properly (%#"PRIxElfAddr")\n",
+elf->name, i, sec[i].sec->sh_addr,
sec[i].sec->sh_addralign);
+return -EINVAL;
+}
else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
sec[i].sec->sh_type == SHT_NOBITS &&
sec[i].sec->sh_size > LIVEPATCH_MAX_SIZE )
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 07/11] livepatch/x86/arm[32, 64]: Force .livepatch.depends section to be uint32_t aligned.
By default when using objcopy we lose the alignment when we copy it from
xen-syms -
with the result that alignment (on ARM32 for example) can be 1:
[Nr] Name TypeAddr OffSize ES Flg Lk Inf Al
..
[ 6] .livepatch.depend PROGBITS 93 24 00 A 0 0 1
That, combined with wacky offset means it will be loaded in
memory with the wrong alignment:
(XEN) livepatch.c:425: livepatch: xen_bye_world: Loaded .livepatch.depends at
000a08043
And later we crash as the .livepatch.depends is not aligned to four bytes, while
the xen_build_id_check expects the code to be four byte aligned and we
get an hypervisor crash (on ARM32):
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN) [ Xen-4.10Hello World arm32 debug=y Not tainted ]
(XEN) CPU:0
(XEN) PC: 002400a0 xen_build_id_check+0x8/0xe8
..snip..
(XEN) Xen call trace:
(XEN)[<002400a0>] xen_build_id_check+0x8/0xe8 (PC)
(XEN)[<0021a9c0>] livepatch_op+0x768/0x1610 (LR)
(XEN)[<0023bbe4>] do_sysctl+0x9c8/0xa9c
(XEN)[<002673c4>] do_trap_guest_sync+0x11e0/0x177c
(XEN)[<0026b6a0>] entry.o#return_from_trap+0/0x4
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
This fix forces all the test-cases to be built with a
.livepatch.depends structure containing the build-id extracted from
the hypervisor (except the xen_bye_world test-case).
We use the 'mkhex' tool instead of 'xxd' as the end result is an 'unsigned'
instead of 'char' type array - which naturally forces the alignment to be of
four.
Also the 'mkhex' tools allows us to pass the section name as parameter.
The end result is much better alignment:
[ 7] .livepatch.depend PROGBITS 94 24 00 A 0 0 4
Note that thanks to 'unsigned int .. __note_depends' the symbol becomes
global:
$ readelf --symbols *.livepatch | grep depen
23: 36 OBJECT GLOBAL HIDDEN 6 note_depends
49: 36 OBJECT GLOBAL HIDDEN17 note_depends
16: 36 OBJECT GLOBAL HIDDEN 3 note_depends
21: 36 OBJECT GLOBAL HIDDEN 6 note_depends
See patch titled: "livepatch/arm/x86: Rename note_depends symbol from
test-cases."
which fixes this.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
v2: First posting.
v3: - Used mkhex from tools/misc instead of tools/firmware/hvmloader/
- Include the XEN crash
---
docs/misc/livepatch.markdown | 2 ++
xen/test/livepatch/Makefile| 56 +++---
xen/test/livepatch/xen_bye_world.c | 1 +
xen/test/livepatch/xen_hello_world.c | 1 +
xen/test/livepatch/xen_nop.c | 1 +
xen/test/livepatch/xen_replace_world.c | 1 +
6 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 59f89aa292..091029781e 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -430,6 +430,8 @@ checksum, MD5 checksum or any unique value.
The size of these structures varies with the --build-id linker option.
+On ARM32 this section must by four-byte aligned.
+
## Hypercalls
We will employ the sub operations of the system management hypercall (sysctl).
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 6831383db1..d23833e36f 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,15 +1,7 @@
include $(XEN_ROOT)/Config.mk
-ifeq ($(XEN_TARGET_ARCH),x86_64)
-OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
-endif
-ifeq ($(XEN_TARGET_ARCH),arm64)
-OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
-endif
-ifeq ($(XEN_TARGET_ARCH),arm32)
-OBJCOPY_MAGIC := -I binary -O elf32-littlearm -B arm
-endif
-
+NOTE_SYMBOL = "note_depends"
+NOTE_DEPENDS = "const __section(\".livepatch.depends\") $(NOTE_SYMBOL)"
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}')
@@ -38,7 +30,7 @@ uninstall:
.PHONY: clean
clean::
- rm -f *.o .*.o.d *.livepatch config.h
+ rm -f *.o .*.o.d *.livepatch config.h livepatch_depends.h
hello_world_livepatch_depends.h *.bin
#
# To compute these values we need the binary files: xen-syms
@@ -56,10 +48,10 @@ config.h: xen_hello_world_func.o
echo "#define MINOR_VERSION_ADDR $(MINOR_VERSION_ADDR)"; \
echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
-xen_hello_world.o: config.h
+xen_hello_world.o: config.h livepatch_depends.h
.PHONY: $(LIVEPATCH)
-$(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
+$(LIVEP
[Xen-devel] [PATCH v4 11/11] livepatch: Declare live patching as a supported feature
From: Ross Lagerwall See docs/features/livepatch.pandoc for the details. Reviewed-by: Jan Beulich Signed-off-by: Ross Lagerwall Signed-off-by: Konrad Rzeszutek Wilk -- v2: - Moved it into a feature document. - Clarified a few bits and pieces based on feedback. v3: - default X86 - added Jan's Reviewed-by - Added tech preview for ARM. - Cut down the 3) paragraph per George's input --- docs/features/livepatch.pandoc | 106 + xen/common/Kconfig | 4 +- 2 files changed, 108 insertions(+), 2 deletions(-) create mode 100644 docs/features/livepatch.pandoc diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc new file mode 100644 index 00..17f1cd0d05 --- /dev/null +++ b/docs/features/livepatch.pandoc @@ -0,0 +1,106 @@ +% Live Patching +% Revision 1 + +\clearpage + +# Basics + + + Status: **Supported** + + Architecture: x86 + + Status: **Tech Preview/Experimental** + + Architecture: ARM + + Component: Hypervisor, toolstack + + + +# Details + +Xen Live Patching has been available as tech preview feature since Xen +4.7 and has now had a couple of releases to stabilize. Xen Live patching +has been used by multiple vendors to fix several real-world security +issues without any severe bugs encountered. Additionally, there are now +tests in OSSTest that test live patching to ensure that no regressions +are introduced. + +Based on the amount of testing and usage it has had, we are ready to +declare live patching as a 'Supported' feature on x86. + +Live patching is slightly peculiar when it comes to support because it +allows the host administrator to break their system rather easily +depending on the content of the live patch. Because of this, it is +worth detailing the scope of security support: + +1) Unprivileged access to live patching operations: + Live patching operations should only be accessible to privileged + guests and it shall be treated as a security issue if this is not + the case. + +2) Bugs in the patch-application code such that vulnerabilities exist + after application: + If a correct live patch is loaded but it is not applied correctly + such that it might result in an insecure system (e.g. not all + functions are patched), it shall be treated as a security issue. + +3) Bugs in livepatch-build-tools creating an incorrect live patch that + results in an insecure host: + If livepatch-build-tools creates an incorrect live patch that + results in an insecure host, this shall not be considered a security + issue. A live patch should be checked to verify that it is valid + before loading. + +4) Loading an incorrect live patch that results in an insecure host or + host crash: + If a live patch (whether created using livepatch-build-tools or some + alternative) is loaded and it results in an insecure host or host + crash due to the content of the live patch being incorrect or the + issue being inappropriate to live patch, this is not considered as a + security issue. + +5) Bugs in the live patch parsing code (the ELF loader): + Bugs in the live patch parsing code such as out-of-bounds reads + caused by invalid ELF files are not considered to be security issues + because the it can only be triggered by a privileged domain. + +6) Bugs which allow a guest to prevent the application of a livepatch: + A guest should not be able to prevent the application of a live + patch. If an unprivileged guest can somehow prevent the application + of a live patch despite pausing it (xl pause ...), it shall be + treated as a security issue. + +Note: It is expected that live patches are tested in a test environment +before being used in production to avoid unexpected issues. In +particular, to avoid the issues described by (3), (4), & (5). + +There are also some generic security questions which are worth asking: + +1) Is guest->host privilege escalation possible? + +The new live patching sysctl subops are only accessible to privileged +domains and this is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce a guest->host +privilege escalation. + +2) Is guest user->guest kernel escalation possible? + +No, although an incorrect live patch can introduce a guest user->guest +kernel privilege escalation. + +3) Is there any information leakage? + +The new live patching sysctl subops are only accessible to privileged +domains so it is not possible for an unprivileged guest to access the +list of loaded live patches. This is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce an +information leakage. + +4) Can a Denial-of-Service be triggered? + +There are no known ways that an unprivileged guest can prevent a
[Xen-devel] [PATCH v4 10/11] livepatch/arm[32, 64]: Modify .livepatch.funcs section to be RW when patching
This was found when porting livepatch-build-tools to ARM64/32
When livepatch-build-tools are built (and test-case thanks to:
livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
the .livepatch.funcs are in read-only section.
However the hypervisor uses the 'opaque' for its own purpose, that
is stashing the original code. But the .livepatch_funcs section is
in the RO vmap area so on ARM[32,64] we get a fault (as the
secure_payload changes the VA to RO).
On x86 the same protection is in place. In 'arch_livepatch_quiesce'
we disable WP to allow changes to read-only pages (and in arch_livepatch_revive
we re-enable the WP protection).
On ARM[32,64] we do not have the luxury of a global register that can
be changed after boot. In lieu of that we modify the VA of where
the .livepatch.funcs is to RW. After we are done with patching
we change it back to RO.
To do this we need to stash during livepatching the va of the page
in which the .livepatch.func resides, and the number of pages said
section uses (or 1 at min).
Equipped with that we can patch livepatch functions which have
.livepatch_funcs in rodata section.
An alternative is to add the 'W' flag during loading of the
.livepatch_funcs which would result the section being in writeable
region from the gecko.
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
v4: First posting
---
xen/arch/arm/livepatch.c| 45 ++---
xen/arch/x86/livepatch.c| 2 +-
xen/common/livepatch.c | 9 +++--
xen/include/asm-arm/livepatch.h | 13
xen/include/xen/livepatch.h | 2 +-
5 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 76723f1f1a..f23df8597d 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,13 +18,15 @@
#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
void *vmap_of_xen_text;
+struct livepatch_va livepatch_stash;
-int arch_livepatch_quiesce(void)
+int arch_livepatch_quiesce(struct livepatch_func *func, size_t nfuncs)
{
mfn_t text_mfn;
unsigned int text_order;
+int rc = 0;
-if ( vmap_of_xen_text )
+if ( vmap_of_xen_text || livepatch_stash.va )
return -EINVAL;
text_mfn = virt_to_mfn(_start);
@@ -43,7 +46,29 @@ int arch_livepatch_quiesce(void)
return -ENOMEM;
}
-return 0;
+if ( nfuncs )
+{
+unsigned long va = (unsigned long)func;
+unsigned int offs = va & (PAGE_SIZE - 1);
+unsigned int pages = PFN_UP(offs + nfuncs * sizeof(*func));
+
+va &= PAGE_MASK;
+
+rc = modify_xen_mappings(va, va + (pages * PAGE_SIZE), PTE_NX);
+if ( rc )
+{
+printk(XENLOG_ERR LIVEPATCH "Failed to modify 0x%lx to RW\n", va);
+vunmap(vmap_of_xen_text);
+vmap_of_xen_text = NULL;
+}
+else
+{
+livepatch_stash.va = va;
+livepatch_stash.pages = pages;
+}
+}
+
+return rc;
}
void arch_livepatch_revive(void)
@@ -58,6 +83,20 @@ void arch_livepatch_revive(void)
vunmap(vmap_of_xen_text);
vmap_of_xen_text = NULL;
+
+if ( livepatch_stash.va )
+{
+unsigned long va = livepatch_stash.va;
+
+int rc = modify_xen_mappings(va, va + (livepatch_stash.pages *
PAGE_SIZE),
+ PTE_NX | PTE_RO);
+if ( rc )
+printk(XENLOG_ERR LIVEPATCH "Failed to modify %lx to RO!\n", va);
+
+livepatch_stash.va = 0;
+livepatch_stash.pages = 0;
+
+}
}
int arch_livepatch_verify_func(const struct livepatch_func *func)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 48d20fdacd..f5865370d5 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -14,7 +14,7 @@
#include
#include
-int arch_livepatch_quiesce(void)
+int arch_livepatch_quiesce(struct livepatch_func *func, size_t nfuncs)
{
/* Disable WP to allow changes to read-only pages. */
write_cr0(read_cr0() & ~X86_CR0_WP);
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index f736c3a7ea..af8998ec8d 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -56,6 +56,7 @@ struct payload {
int32_t rc; /* 0 or -XEN_EXX. */
bool reverted; /* Whether it was reverted. */
bool safe_to_reapply;/* Can apply safely after revert. */
+bool funcs_ro; /* Are livepatch.funcs in .rodata
section. */
struct list_head list; /* Linked to 'payload_list'. */
const void *text_addr; /* Virtual address of .text. */
size_t text_size;/* .. and its
[Xen-devel] [PATCH v4 06/11] mkhex: Move it to tools/misc
It makes more sense to put a tool to be used by other subsystems
to be in 'tools/misc' along 'mkrpm','mkdeb', etc.
The patch titled "xen/livepatch/x86/arm32: Force .livepatch.depends
section to be uint32_t aligned" uses mkhex.
Suggested-by: Julien Grall
Signed-off-by: Konrad Rzeszutek Wilk
---
CC: Ian Jackson
CC: Wei Liu
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Jan Beulich
Cc: Andrew Cooper
v4: First posting.
---
tools/firmware/hvmloader/Makefile| 8
tools/{firmware/hvmloader => misc}/mkhex | 0
2 files changed, 4 insertions(+), 4 deletions(-)
rename tools/{firmware/hvmloader => misc}/mkhex (100%)
diff --git a/tools/firmware/hvmloader/Makefile
b/tools/firmware/hvmloader/Makefile
index 7c4c0ce535..a5b4c32c1a 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -91,23 +91,23 @@ roms.inc: $(ROMS)
ifneq ($(ROMBIOS_ROM),)
echo "#ifdef ROM_INCLUDE_ROMBIOS" >> $@.new
- sh ./mkhex rombios $(ROMBIOS_ROM) >> $@.new
+ sh ../../misc/mkhex rombios $(ROMBIOS_ROM) >> $@.new
echo "#endif" >> $@.new
endif
ifneq ($(STDVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
- sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
+ sh ../../misc/mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new
echo "#endif" >> $@.new
endif
ifneq ($(CIRRUSVGA_ROM),)
echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new
- sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
+ sh ../../misc/mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new
echo "#endif" >> $@.new
endif
ifneq ($(ETHERBOOT_ROMS),)
echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new
- sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
+ sh ../../misc/mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new
echo "#endif" >> $@.new
endif
diff --git a/tools/firmware/hvmloader/mkhex b/tools/misc/mkhex
similarity index 100%
rename from tools/firmware/hvmloader/mkhex
rename to tools/misc/mkhex
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 01/11] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.
If the livepatch has only .rodata sections then it is OK to also apply/revert/apply the livepatch without having to worry about the unforseen consequences. See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c "livepatch: Disallow applying after an revert" for details. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Ross Lagerwall v3: First posting. --- xen/common/livepatch.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c index 66167a5573..b0dcd415ba 100644 --- a/xen/common/livepatch.c +++ b/xen/common/livepatch.c @@ -417,9 +417,12 @@ static int move_payload(struct payload *payload, struct livepatch_elf *elf) } } -/* Only one RW section with non-zero size: .livepatch.funcs */ -if ( rw_buf_cnt == 1 && - !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC) ) +/* + * Only one RW section with non-zero size: .livepatch.funcs, + * or only RO sections. + */ +if ( !rw_buf_cnt || (rw_buf_cnt == 1 && + !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC)) ) payload->safe_to_reapply = true; out: xfree(offset); -- 2.13.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 05/11] alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections.
This is very similar to 137c59b9ff3f7a214f03b52d9c00a0a02374af1f "bug/x86/arm: Align bug_frames sections." On ARM and on x86 the C and assembler macros don't include any alignment information - hence they end up being the default byte granularity. On ARM32 it is paramount that the alignment is word-size (4) otherwise if one tries to use (uint32_t*) access (such as livepatch ELF relocations) we get a Data Abort. Specifically this issue was observed on ARM32 with a cross compiler for the livepatches. Mainly the livepatches .data section size was not padded to the section alignment: ARM32 native: Contents of section .rodata: 68695f66 756e6300 63686563 6b5f666e hi_func.check_fn 0010 6300 78656e5f 65787472 615f7665 c...xen_extra_ve 0020 7273696f 6e00rsion... ARM32 cross compiler: Contents of section .rodata: 68695f66 756e6300 63686563 6b5f666e hi_func.check_fn 0010 6300 78656e5f 65787472 615f7665 c...xen_extra_ve 0020 7273696f 6e00rsion. And when we loaded it the next section would be put right behind it: native: (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000 (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024 (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 00a0404c cross compiler: (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .text at 00a02000 (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .rodata at 00a04024 (XEN) livepatch.c:413: livepatch: xen_hello_world: Loaded .altinstructions at 00a0404a (See 4a vs 4c) native readelf: [ 4] .rodata PROGBITS 000164 28 00 A 0 0 4 [ 5] .altinstructions PROGBITS 00018c 0c 00 A 0 0 1 cross compiler readelf --sections: [ 4] .rodata PROGBITS 000164 26 00 A 0 0 4 [ 5] .altinstructions PROGBITS 00018a 0c 00 A 0 0 1 And as can be seen the .altinstructions have alignment of 1 which from 'man elf' is: "Values of zero and one mean no alignment is required." which means we can ignore it. Enforcing .altinstructions (and also .altinstr_replacement for completness on ARM) to have the proper alignment across all architectures and in both C and x86 makes them all the same. On x86 the bloat-o-meter detects that with this change the file shrinks: add/remove: 1/0 grow/shrink: 0/2 up/down: 156/-367 (-211) function old new delta get_page_from_gfn - 156+156 do_mmu_update 45784569 -9 do_mmuext_op56045246-358 Total: Before=3170439, After=3170228, chg -0.01% But as found adding even "#Hi!\n" will casue this optimization, so the bloat-o-meter value here is useless. While on ARM 32/64: add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0) function old new delta Total: Before=822563, After=822563, chg +0.00% Also since the macros have the alignment coded in them there is no need to do that for the xen.lds.S anymore. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Ross Lagerwall Cc: Stefano Stabellini Cc: Julien Grall Cc: Jan Beulich Cc: Andrew Cooper v2: - First posting. v3: - Figured out the x86 bloat-o-meter results. - Removed the .ALIGN from xen.lds.S - Removed the .p2align on .altinstr_replacement per Jan's request. - Put most of the commit description for the original issue v4: - Added one .ALIGN back on xen.lds.S (arm) - Changed the .ALIGN(8) to ALIGN(4) on xen.lds.S (x86) - Moved p2align inside of the macros (ALTINSTR_ENTRY and altinstruction_entry) --- xen/arch/arm/xen.lds.S| 1 - xen/arch/x86/xen.lds.S| 2 +- xen/include/asm-arm/alternative.h | 4 xen/include/asm-x86/alternative.h | 2 ++ 4 files changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S index c9b9546435..84ee475405 100644 --- a/xen/arch/arm/xen.lds.S +++ b/xen/arch/arm/xen.lds.S @@ -159,7 +159,6 @@ SECTIONS __alt_instructions = .; *(.altinstructions) __alt_instructions_end = .; - . = ALIGN(4); *(.altinstr_replacement) #endif diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S index d5e8821d41..b03cca011b 100644 --- a/xen/arch/x86/xen.lds.S +++ b/xen/arch/x86/xen.lds.S @@ -202,7 +202,7 @@ SECTIONS * "Alternative instructions for different CPU types or capabilities" * Think locking instructions on spinlocks. */ - . = ALIGN(8); + . = ALIGN(4); __alt_instructions = .; *(.altinstructions) __alt_instructions_end = .; diff --git a/xen/include/asm-arm/alternative.h b/xen/include/asm-arm/alternative.h index 6cc9d0dc5f..5e0d2b39a5 1006
[Xen-devel] [PATCH v4 09/11] livepatch/tests: Make sure all .livepatch.funcs sections are read-only
Instead of being writable (.data). This mimics the behavior of what livepatch-build-tools do. Other approaches such as 'struct const livepatch_funcs' still result in the WA section attributes. Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Ross Lagerwall v2: First posting. v3: Don't do multiple objcopy invocations. --- xen/test/livepatch/Makefile | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile index b48669cc13..9e45a81452 100644 --- a/xen/test/livepatch/Makefile +++ b/xen/test/livepatch/Makefile @@ -53,7 +53,8 @@ xen_hello_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH) $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^ - $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) \ + --set-section-flags .livepatch.funcs=alloc,readonly $@ # # This target is only accessible if CONFIG_LIVEPATCH is defined, which @@ -89,21 +90,24 @@ xen_bye_world.o: config.h hello_world_livepatch_depends.h .PHONY: $(LIVEPATCH_BYE) $(LIVEPATCH_BYE): xen_bye_world_func.o xen_bye_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_BYE) $^ - $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) \ + --set-section-flags .livepatch.funcs=alloc,readonly $@ xen_replace_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_REPLACE) $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^ - $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) \ + --set-section-flags .livepatch.funcs=alloc,readonly $@ xen_nop.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_NOP) $(LIVEPATCH_NOP): xen_nop.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^ - $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) \ + --set-section-flags .livepatch.funcs=alloc,readonly $@ .PHONY: livepatch livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP) -- 2.13.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4] Livepatching patch set for 4.10
Hey,
As I was trying to port livepatch-build-tools.git to work under ARM32 and ARM64
(still ongoing, if somebody wants to help/take over would appreciate it)
I found some inconsistencies compared to the x86 and test-cases:
- The .livepatch.funcs in the test-cases are in RW section but the
livepatch-build-tools
puts them in the RO sections. That works on x86 as arch_livepatch_quiesce
turns of WP globally during the livepatching.
But not on ARM.. and to make it work there I ended up using
modify_xen_mappings
- Cross compiling ARM32 introduces subtle alignment issues. Mainly
both .altinstructions and .livepatch.depends end up with the
wrong alingment and the hypervisor blows up. Both fixes are
in the patchset.
I am also including in this patchset:
- Declare the livepatch supported on x86 (but not ARM). I will
shortly check it in if nobody screams.
I am NOT including in this patchset:
- The local/global symbol patchset functionality. I am still
working on Jan's feedback to use STV_INTERNAL.
Lastly, I tested this on ARM32 (Cubietruck), ARM64 (HiKey960) and
on x86.
Patches are in
git://xenbits.xen.org/people/konradwilk/xen.git staging-for-4.10.v4
Konrad Rzeszutek Wilk (10):
livepatch: Expand check for safe_for_reapply if livepatch has only
.rodata.
livepatch: Tighten alignment checks.
livepatch: Include sizes when an mismatch occurs
livepatch/arm[32,64]: Don't load and crash on livepatches loaded with
wrong text alignment.
alternative/x86/arm32: Align altinstructions (and altinstr_replacement)
sections.
mkhex: Move it to tools/misc
livepatch/x86/arm[32,64]: Force .livepatch.depends section to be uint32_t
aligned.
livepatch/arm/x86: Rename note_depends symbol from test-cases.
livepatch/tests: Make sure all .livepatch.funcs sections are read-only
livepatch/arm[32,64]: Modify .livepatch.funcs section to be RW when
patching
Ross Lagerwall (1):
livepatch: Declare live patching as a supported feature
docs/features/livepatch.pandoc | 106 +++
docs/misc/livepatch.markdown | 4 ++
tools/firmware/hvmloader/Makefile| 8 +--
tools/{firmware/hvmloader => misc}/mkhex | 0
xen/arch/arm/arm32/livepatch.c | 13 +++-
xen/arch/arm/kernel.c| 2 +-
xen/arch/arm/livepatch.c | 54 +++-
xen/arch/arm/mm.c| 28
xen/arch/arm/platforms/vexpress.c| 2 +-
xen/arch/arm/xen.lds.S | 1 -
xen/arch/x86/livepatch.c | 8 ++-
xen/arch/x86/xen.lds.S | 2 +-
xen/common/Kconfig | 4 +-
xen/common/livepatch.c | 71 -
xen/common/livepatch_elf.c | 13
xen/drivers/video/arm_hdlcd.c| 2 +-
xen/include/asm-arm/alternative.h| 4 ++
xen/include/asm-arm/livepatch.h | 13
xen/include/asm-arm/page.h | 51 ---
xen/include/asm-x86/alternative.h| 2 +
xen/include/xen/elfstructs.h | 2 +
xen/include/xen/livepatch.h | 3 +-
xen/test/livepatch/Makefile | 64 ++-
xen/test/livepatch/xen_bye_world.c | 1 +
xen/test/livepatch/xen_hello_world.c | 1 +
xen/test/livepatch/xen_nop.c | 1 +
xen/test/livepatch/xen_replace_world.c | 1 +
27 files changed, 347 insertions(+), 114 deletions(-)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 08/11] livepatch/arm/x86: Rename note_depends symbol from test-cases.
This surfaced due to "xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned." which switched to a different way of including the build-id. Each livepatch ends with a global: 30: 1 OBJECT GLOBAL HIDDEN 7 note_depends which will cause collision when loading. One attempted solution was to add in the Makefile stanza: @sed -i '/unsigned/static unsinged/' $@ But that resulted in the note_depends being omitted from the livepatch (as it was static and not used) which meant we would not have an .livepatch_depends section which we require. One solution is to remove the symbol via the --strip-symbols after generating the livepatch. However that fails as note_depends is in use by .rel.debug_info: Relocation section '.rel.debug_info' at offset 0x151c contains 113 entries: Offset InfoTypeSym.Value Sym. Name .. 0625 1e02 R_ARM_ABS32 note_depends And the solution to that is to also slap on --strip-debug which removes various .debug* sections (which livepatch ignores anyhow): .debug_aranges, .debug_info, .debug_abbrev, .debug_line, .debug_frame, .debug_str, and their .rel.* sections. And that will remove that. Alternatively we could also use --localize-symbol so that note_depends is not globally visible. But that won't help as hypervisor treats both local and global symbols as global when resolving them. This patch decides to pick an easier path, just rename the symbol by prefixing it with the name of the livepatch: $ nm *.livepatch | grep depend R xen_bye_world.livepatch_note_depends R xen_hello_world.livepatch_note_depends R xen_local_symbols.livepatch_note_depends R xen_nop.livepatch_note_depends R xen_replace_world.livepatch_note_depends Signed-off-by: Konrad Rzeszutek Wilk --- Cc: Ross Lagerwall v3: First posting. v4: Instead of stripping the symbol (and also using --strip-debug), just rename the symbol. --- xen/test/livepatch/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile index d23833e36f..b48669cc13 100644 --- a/xen/test/livepatch/Makefile +++ b/xen/test/livepatch/Makefile @@ -53,6 +53,7 @@ xen_hello_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH) $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ # # This target is only accessible if CONFIG_LIVEPATCH is defined, which @@ -88,18 +89,21 @@ xen_bye_world.o: config.h hello_world_livepatch_depends.h .PHONY: $(LIVEPATCH_BYE) $(LIVEPATCH_BYE): xen_bye_world_func.o xen_bye_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_BYE) $^ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ xen_replace_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_REPLACE) $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ xen_nop.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_NOP) $(LIVEPATCH_NOP): xen_nop.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^ + $(OBJCOPY) --redefine-sym $(NOTE_SYMBOL)=$@_$(NOTE_SYMBOL) $@ .PHONY: livepatch livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP) -- 2.13.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 03/11] livepatch: Include sizes when an mismatch occurs
If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.
Also make it more natural by having "Multiples" in the warning.
Also fix one case where we would fail if the size of the .ex_table
was being zero - but that is OK.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
v1: First posting.
v2: - Changed to 'Multiple' per Jan's recommendation.
- Folded the checks in 'check_size' function and removed all the other
parts of code that checked for this.
v3: - Drop bool zero_ok
- Return bool instead of int (and invert the return condition)
- Change name of the function to be more clear
---
xen/common/livepatch.c | 46 +---
xen/include/xen/elfstructs.h | 2 ++
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index b0dcd415ba..b9376c94e9 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -460,6 +460,22 @@ static int secure_payload(struct payload *payload, struct
livepatch_elf *elf)
return rc;
}
+static bool section_ok(const struct livepatch_elf *elf,
+ const struct livepatch_elf_sec *sec, size_t sz)
+{
+if ( !elf || !sec )
+return false;
+
+if ( sec->sec->sh_size % sz )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size %"PRIuElfWord" of %s
(must be multiple of %zu)\n",
+elf->name, sec->sec->sh_size, sec->name, sz);
+return false;
+}
+
+return true;
+}
+
static int check_special_sections(const struct livepatch_elf *elf)
{
unsigned int i;
@@ -509,12 +525,8 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC);
ASSERT(sec);
-if ( sec->sec->sh_size % sizeof(*payload->funcs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of
"ELF_LIVEPATCH_FUNC"!\n",
-elf->name);
+if ( !section_ok(elf, sec, sizeof(*payload->funcs)) )
return -EINVAL;
-}
payload->funcs = sec->load_addr;
payload->nfuncs = sec->sec->sh_size / sizeof(*payload->funcs);
@@ -556,7 +568,7 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
if ( sec )
{
-if ( sec->sec->sh_size % sizeof(*payload->load_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->load_funcs)) )
return -EINVAL;
payload->load_funcs = sec->load_addr;
@@ -566,7 +578,7 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.unload");
if ( sec )
{
-if ( sec->sec->sh_size % sizeof(*payload->unload_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->unload_funcs)) )
return -EINVAL;
payload->unload_funcs = sec->load_addr;
@@ -637,12 +649,8 @@ static int prepare_payload(struct payload *payload,
if ( !sec )
continue;
-if ( sec->sec->sh_size % sizeof(*region->frame[i].bugs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of
.bug_frames.%u!\n",
-elf->name, i);
+if ( !section_ok(elf, sec, sizeof(*region->frame[i].bugs)) )
return -EINVAL;
-}
region->frame[i].bugs = sec->load_addr;
region->frame[i].n_bugs = sec->sec->sh_size /
@@ -655,12 +663,8 @@ static int prepare_payload(struct payload *payload,
#ifdef CONFIG_HAS_ALTERNATIVE
struct alt_instr *a, *start, *end;
-if ( sec->sec->sh_size % sizeof(*a) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Size of .alt_instr is not
multiple of %zu!\n",
-elf->name, sizeof(*a));
+if ( !section_ok(elf, sec, sizeof(*a)) )
return -EINVAL;
-}
start = sec->load_addr;
end = sec->load_addr + sec->sec->sh_size;
@@ -692,14 +696,8 @@ static int prepare_payload(struct payload *payload,
#ifdef CONFIG_HAS_EX_TABLE
struct exception_table_entry *s, *e;
-if ( !sec->sec->sh_size ||
- (sec->sec->sh_size % sizeof(*region->ex)) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of .ex_table
(exp:%lu vs %lu)!\n",
-elf->name, sizeof(*region->ex),
-sec->sec->sh_size);
+if ( !section_ok(elf, sec, sizeof(*region->ex)) )
return -EINVAL;
-}
s = sec->load_addr;
e = sec->load_addr + sec->
[Xen-devel] [PATCH v4 04/11] livepatch/arm[32, 64]: Don't load and crash on livepatches loaded with wrong text alignment.
The ARM 32&64 ELF specification says "sections containing ARM
code must be at least 32-bit aligned." This patch adds the
check for that. We also make sure that this check is done
when doing relocations for the types that are considered
ARM code. However we don't have to check for all as we only
implement a small subset of them - as such we only check for
data types that are implemented - and if the type is anything else
and not aligned to 32-bit, then we error out.
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Ross Lagerwall
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
v1: First posting.
v2: Redo the commit to include the commits which fix the alignment issues.
Also mention the need in the docs
v3: Change the docs to explicitly mention text code section alignment
requirements.
Invert arch_livepatch_verify_alignment return value (true for alignment is
ok).
Drop the alignment check in check_special_sections.
Make the alignment check in check_section only for executable sections.
Rewrote the commit message as it is not applicable to v2 of the patch
anymore.
v4: Also do the check on ARM64
Put () around the section check
Use vaddr_t instead of uint32_t as that won't work on ARM64.
---
docs/misc/livepatch.markdown | 2 ++
xen/arch/arm/arm32/livepatch.c | 13 +++--
xen/arch/arm/livepatch.c | 9 +
xen/arch/x86/livepatch.c | 6 ++
xen/common/livepatch.c | 7 +++
xen/include/xen/livepatch.h| 1 +
6 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b850cb..59f89aa292 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -279,6 +279,8 @@ It may also have some architecture-specific sections. For
example:
* Exception tables.
* Relocations for each of these sections.
+Note that on ARM 32 & 64 the sections containing code MUST be four byte
aligned.
+
The Xen Live Patch core code loads the payload as a standard ELF binary,
relocates it
and handles the architecture-specifc sections as needed. This process is much
like what the Linux kernel module loader does.
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 41378a54ae..4fcbb59be5 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -233,7 +233,7 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
uint32_t val;
void *dest;
unsigned char type;
-s32 addend;
+s32 addend = 0;
if ( use_rela )
{
@@ -251,7 +251,6 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
symndx = ELF32_R_SYM(r->r_info);
type = ELF32_R_TYPE(r->r_info);
dest = base->load_addr + r->r_offset; /* P */
-addend = get_addend(type, dest);
}
if ( symndx == STN_UNDEF )
@@ -272,6 +271,16 @@ int arch_livepatch_perform(struct livepatch_elf *elf,
elf->name, symndx);
return -EINVAL;
}
+else if ( (type != R_ARM_ABS32 && type != R_ARM_REL32) /* Only check
code. */ &&
+ ((uint32_t)dest % sizeof(uint32_t)) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: dest=%p (%s) is not aligned
properly!\n",
+elf->name, dest, base->name);
+return -EINVAL;
+}
+
+if ( !use_rela )
+addend = get_addend(type, dest);
val = elf->sym[symndx].sym->st_value; /* S */
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3e53524365..76723f1f1a 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -135,6 +135,15 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf
*elf,
return true;
}
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+if ( (sec->sec->sh_flags & SHF_EXECINSTR) &&
+ ((vaddr_t)sec->load_addr % sizeof(uint32_t)) )
+return false;
+
+return true;
+};
+
int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type
type)
{
unsigned long start = (unsigned long)va;
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 406eb910cc..48d20fdacd 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -148,6 +148,12 @@ bool arch_livepatch_symbol_deny(const struct livepatch_elf
*elf,
return false;
}
+bool arch_livepatch_verify_alignment(const struct livepatch_elf_sec *sec)
+{
+/* Unaligned access on x86 is fine. */
+return true;
+}
+
int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff
Re: [Xen-devel] [PATCH v3 06/17] xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned.
On Wed, Sep 20, 2017 at 03:01:57PM +0100, Wei Liu wrote: > On Tue, Sep 19, 2017 at 12:05:16PM +0100, Julien Grall wrote: > > Hi Konrad, > > > > On 19/09/17 01:32, Konrad Rzeszutek Wilk wrote: > > > > > +.PHONY: livepatch_depends.h > > > > > +livepatch_depends.h: note.bin > > > > > + $(shell (../../../tools/firmware/hvmloader/mkhex > > > > > $(NOTE_DEPENDS) $^ > $@)) > > > > > > > > It looks quite odd to use a file in firmware/hvmloader for livepatch. > > > > Would > > > > it be possible to move mkhex to a generic place? > > > > > > Like so? > > > > It is what I had in mind. I CCed Ian and Wei to get feedback from them. > > > > Just move it to a directory called tools/scripts? I spoke to Wei and Ian on IRC and they are OK with it being in tools/misc - especially as 'mkrpm','mkdeb' are all in there. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.
On Tue, Sep 19, 2017 at 09:04:44AM -0600, Jan Beulich wrote: > >>> On 18.09.17 at 21:37, wrote: > > On Tue, Sep 12, 2017 at 02:57:04AM -0600, Jan Beulich wrote: > >> >>> On 12.09.17 at 02:22, wrote: > >> > If I compile the test-case under ARM32 it works OK (as the > >> > .livepatch.depends ends up being aligned to four bytes). > >> > >> So why is that? What entity is creating this section (or the > >> directive(s) to create it)? > > > > gcc > > > > Looking at the xen_bye_world.o produced by cross-compiler: > > > > xen_bye_world.o: file format elf32-littlearm > > > > Contents of section .rodata: > > 78656e5f 65787472 615f7665 7273696f xen_extra_versio > > 0010 6e00 n. > > > > And native: > > > > xen_bye_world.o: file format elf32-littlearm > > > > Contents of section .rodata: > > 78656e5f 65787472 615f7665 7273696f xen_extra_versio > > 0010 6e00 n... > > This may rather be a gas than a gcc behavioral difference. What's > the alignment of .rodata in both cases? Cross: * on the livepatch: ..snip.. [ 4] .rodata PROGBITS 74 12 00 A 0 0 4 [ 5] .rodata.str1.4PROGBITS 88 0b 01 AMS 0 0 4 [ 6] .livepatch.depend PROGBITS 93 24 00 A 0 0 1 * on the .o file: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al .. snip.. [ 1] .text PROGBITS 34 00 00 AX 0 0 1 [ 2] .data PROGBITS 34 00 00 WA 0 0 1 [ 3] .bss NOBITS 34 00 00 WA 0 0 1 [ 4] .rodata PROGBITS 34 14 00 A 0 0 4 [ 5] .livepatch.funcs PROGBITS 48 34 00 WA 0 0 4 Native: * on the livepatch: ..snip.. [ 4] .rodata PROGBITS 74 14 00 A 0 0 4 [ 5] .rodata.str1.4PROGBITS 88 0c 01 AMS 0 0 4 [ 6] .livepatch.depend PROGBITS 94 24 00 A 0 0 1 * on the .o file: ..snip.. [ 1] .text PROGBITS 34 00 00 AX 0 0 1 [ 2] .data PROGBITS 34 00 00 WA 0 0 1 [ 3] .bss NOBITS 34 00 00 WA 0 0 1 [ 4] .rodata PROGBITS 34 12 00 A 0 0 4 [ 5] .livepatch.funcs PROGBITS 48 34 00 WA 0 0 4 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Ping: [PATCH 2/2] public/sysctl: drop unnecessary typedefs and handles
On September 19, 2017 11:31:40 AM EDT, Jan Beulich wrote:
>>>> On 12.09.17 at 17:10, wrote:
>> --- a/xen/common/livepatch.c
>> +++ b/xen/common/livepatch.c
>> @@ -104,7 +104,7 @@ static struct livepatch_work livepatch_w
>> */
>> static DEFINE_PER_CPU(bool_t, work_to_do);
>>
>> -static int get_name(const xen_livepatch_name_t *name, char *n)
>> +static int get_name(const struct xen_livepatch_name *name, char *n)
>> {
>> if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
>> return -EINVAL;
>> @@ -121,7 +121,7 @@ static int get_name(const xen_livepatch_
>> return 0;
>> }
>>
>> -static int verify_payload(const xen_sysctl_livepatch_upload_t
>*upload, char *n)
>> +static int verify_payload(const struct xen_sysctl_livepatch_upload
>*upload, char *n)
>> {
>> if ( get_name(&upload->name, n) )
>> return -EINVAL;
>> @@ -897,7 +897,7 @@ static int load_payload_data(struct payl
>> return rc;
>> }
>>
>> -static int livepatch_upload(xen_sysctl_livepatch_upload_t *upload)
>> +static int livepatch_upload(struct xen_sysctl_livepatch_upload
>*upload)
>> {
>> struct payload *data, *found;
>> char n[XEN_LIVEPATCH_NAME_SIZE];
>> @@ -954,7 +954,7 @@ static int livepatch_upload(xen_sysctl_l
>> return rc;
>> }
>>
>> -static int livepatch_get(xen_sysctl_livepatch_get_t *get)
>> +static int livepatch_get(struct xen_sysctl_livepatch_get *get)
>> {
>> struct payload *data;
>> int rc;
>> @@ -985,9 +985,9 @@ static int livepatch_get(xen_sysctl_live
>> return 0;
>> }
>>
>> -static int livepatch_list(xen_sysctl_livepatch_list_t *list)
>> +static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>> {
>> -xen_livepatch_status_t status;
>> +struct xen_livepatch_status status;
>> struct payload *data;
>> unsigned int idx = 0, i = 0;
>> int rc = 0;
>> @@ -1451,7 +1451,7 @@ static int build_id_dep(struct payload *
>> return 0;
>> }
>>
>> -static int livepatch_action(xen_sysctl_livepatch_action_t *action)
>> +static int livepatch_action(struct xen_sysctl_livepatch_action
>*action)
>> {
>> struct payload *data;
>> char n[XEN_LIVEPATCH_NAME_SIZE];
>> @@ -1560,7 +1560,7 @@ static int livepatch_action(xen_sysctl_l
>> return rc;
>> }
>>
>> -int livepatch_op(xen_sysctl_livepatch_op_t *livepatch)
>> +int livepatch_op(struct xen_sysctl_livepatch_op *livepatch)
>> {
>> int rc;
>>
>
>Konrad, Ross?
Reviewed-by: Konrad Rzeszutek Wilk
>
>> --- a/xen/common/sched_arinc653.c
>> +++ b/xen/common/sched_arinc653.c
>> @@ -694,7 +694,7 @@ static int
>> a653sched_adjust_global(const struct scheduler *ops,
>> struct xen_sysctl_scheduler_op *sc)
>> {
>> -xen_sysctl_arinc653_schedule_t local_sched;
>> +struct xen_sysctl_arinc653_schedule local_sched;
>> int rc = -EINVAL;
>>
>> switch ( sc->cmd )
>
>Robert, Josh?
>
>> --- a/xen/common/trace.c
>> +++ b/xen/common/trace.c
>> @@ -367,9 +367,9 @@ void __init init_trace_bufs(void)
>>
>> /**
>> * tb_control - sysctl operations on trace buffers.
>> - * @tbc: a pointer to a xen_sysctl_tbuf_op_t to be filled out
>> + * @tbc: a pointer to a struct xen_sysctl_tbuf_op to be filled out
>> */
>> -int tb_control(xen_sysctl_tbuf_op_t *tbc)
>> +int tb_control(struct xen_sysctl_tbuf_op *tbc)
>> {
>> static DEFINE_SPINLOCK(lock);
>> int rc = 0;
>
>George?
>
>Jan
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.
On Tue, Sep 12, 2017 at 02:57:04AM -0600, Jan Beulich wrote: > >>> On 12.09.17 at 02:22, wrote: > > On Mon, Sep 11, 2017 at 03:01:15AM -0600, Jan Beulich wrote: > >> Hmm, as long as the relocation isn't required to be against aligned > >> fields only (mandated by the processor ABI) I think the code doing > >> the relocations would instead need to split the access, rather than > >> calling the section misaligned or increasing alignment beyond what > >> the ELF section headers say. > > > > Maybe the serial log would explain this better: > > > > xend_config_format : 4 > > Executing: '(set -e;cd /root/test/livepatch;xen-livepatch load > > xen_bye_world.livepatch)' ..(XEN) livepatch.c:413: livepatch: > > xen_bye_world: Loaded .note.gnu.build-id at 00a08000 > > (XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .text at 00a06000 > > (XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .rodata at 00a08024 > > (XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .rodata.str1.4 at > > 00a08038 > > (XEN) livepatch.c:413: livepatch: xen_bye_world: Loaded .livepatch.depends > > at 00a08043 > >[...] > > Keep in mind that this only happens if I cross-compile ARM32 under x86. > > That would suggest a build environment / build tools issue then: > Cross builds aren't supposed to produce binaries different from > native builds. Hm, the gcc parameters on both native and cross compiler have same args: konrad@osstest:/srv/cubietruck/source$ diff native.invocation /tmp/cross.invocation 1c1 < gcc -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -nostdinc -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe -g -D__XEN__ -include /source/xen.orig.git/xen/include/xen/config.h '-D__OBJECT_FILE__="xen_bye_world.o"' -Wa,--strip-local-absolute -fno-omit-frame-pointer -MMD -MF ./.xen_bye_world.o.d -msoft-float -mcpu=cortex-a15 -I/source/xen.orig.git/xen/include -fno-stack-protector -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -Wno-unused-local-typedefs -c xen_bye_world.c -o xen_bye_world.o --- > arm-linux-gnu-gcc -marm -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall > -Wstrict-prototypes -Wdeclaration-after-statement > -Wno-unused-but-set-variable -Wno-unused-local-typedefs -O1 -nostdinc > -fno-builtin -fno-common -Werror -Wredundant-decls -Wno-pointer-arith -pipe > -g -D__XEN__ -include /home/konrad/A20/xen.git/xen/include/xen/config.h > '-D__OBJECT_FILE__="xen_bye_world.o"' -Wa,--strip-local-absolute > -fno-omit-frame-pointer -MMD -MF ./.xen_bye_world.o.d -msoft-float > -mcpu=cortex-a15 -I/home/konrad/A20/xen.git/xen/include -fno-stack-protector > -fno-exceptions -Wnested-externs -DGCC_HAS_VISIBILITY_ATTRIBUTE -marm > -DBUILD_ID -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes > -Wdeclaration-after-statement -Wno-unused-but-set-variable > -Wno-unused-local-typedefs -c xen_bye_world.c -o xen_bye_world.o > > > If I compile the test-case under ARM32 it works OK (as the > > .livepatch.depends ends up being aligned to four bytes). > > So why is that? What entity is creating this section (or the > directive(s) to create it)? gcc Looking at the xen_bye_world.o produced by cross-compiler: xen_bye_world.o: file format elf32-littlearm Contents of section .rodata: 78656e5f 65787472 615f7665 7273696f xen_extra_versio 0010 6e00 n. And native: xen_bye_world.o: file format elf32-littlearm Contents of section .rodata: 78656e5f 65787472 615f7665 7273696f xen_extra_versio 0010 6e00 n... (The cross compiler is 7.0.1, while native is 4.9.2). ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/27 v9] xen/arm: vpl011: Define common ring buffer helper functions in console.h
On Mon, Sep 18, 2017 at 04:01:45PM +0530, Bhupinder Thakur wrote:
> DEFINE_XEN_FLEX_RING(xencons) defines common helper functions such as
> xencons_queued() to tell the current size of the ring buffer,
> xencons_mask() to mask off the index, which are useful helper functions.
> pl011 emulation code will use these helper functions.
>
> io/console.h includes io/ring.h which defines DEFINE_XEN_FLEX_RING.
>
> In console/daemon/io.c, string.h had to be included before io/console.h
> because ring.h uses string functions.
>
> Signed-off-by: Bhupinder Thakur
> Reviewed-by: Stefano Stabellini
> Acked-by: Wei Liu
Acked-by: Konrad Rzeszutek Wilk
> ---
> CC: Ian Jackson
> CC: Wei Liu
> CC: Konrad Rzeszutek Wilk
> CC: Stefano Stabellini
> CC: Julien Grall
>
> Changes since v4:
> - Split this change in a separate patch.
>
> tools/console/daemon/io.c | 2 +-
> xen/include/public/io/console.h | 4
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> tools/console/daemon/io.c | 2 +-
> xen/include/public/io/console.h | 4
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index 7e474bb..e8033d2 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -21,6 +21,7 @@
>
> #include "utils.h"
> #include "io.h"
> +#include
> #include
> #include
> #include
> @@ -29,7 +30,6 @@
>
> #include
> #include
> -#include
> #include
> #include
> #include
> diff --git a/xen/include/public/io/console.h b/xen/include/public/io/console.h
> index e2cd97f..5e45e1c 100644
> --- a/xen/include/public/io/console.h
> +++ b/xen/include/public/io/console.h
> @@ -27,6 +27,8 @@
> #ifndef __XEN_PUBLIC_IO_CONSOLE_H__
> #define __XEN_PUBLIC_IO_CONSOLE_H__
>
> +#include "ring.h"
> +
> typedef uint32_t XENCONS_RING_IDX;
>
> #define MASK_XENCONS_IDX(idx, ring) ((idx) & (sizeof(ring)-1))
> @@ -38,6 +40,8 @@ struct xencons_interface {
> XENCONS_RING_IDX out_cons, out_prod;
> };
>
> +DEFINE_XEN_FLEX_RING(xencons);
> +
> #endif /* __XEN_PUBLIC_IO_CONSOLE_H__ */
>
> /*
> --
> 2.7.4
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] Feature control on PV devices
On Thu, Sep 14, 2017 at 05:08:18PM +0100, Joao Martins wrote: > [ Realized that I didn't CC the maintainers, > so doing that now, +Linux folks +PV interfaces czar > Sorry for the noise! ] > > On 09/08/2017 09:49 AM, Joao Martins wrote: > > [Forgot two important details regarding Xenbus states] > > On 09/07/2017 05:53 PM, Joao Martins wrote: > >> Hey! > >> > >> We wanted to brought up this small proposal regarding the lack of > >> parameterization on PV devices on Xen. > >> > >> Currently users don't have a way for enforce and control what > >> features/queues/etc the backend provides. So far there's only global > >> parameters > >> on backends, and specs do not mention anything in this regard. How would this scale with say FreeBSD backends? And I am assuming you are also thinking about device driver backends - where you can't easily get access to the backend and change the SysFS parameters (if they have it all)? > >> > >> The most obvious example is netback/blkback max_queues module parameter > >> where it > >> sets the limit the maximum queues for all devices which is not that > >> flexible. > >> Other examples include controlling offloads visible by the NIC (e.g. > >> disabling > >> checksum offload, disabling scather-gather), others more about I/O path > >> (e.g. > >> disable blkif indirect descriptors, limit number of pages for the ring), > >> or less > >> grant usage by minimizing number of queues/descriptors. > >> > >> Of course there could be more examples, as this seems to be ortoghonal to > >> the > >> kinds of PV backends we have. And seems like all features appear to be > >> published > >> on the same xenbus state? > >> > >> The idea to address this would be very simple: > >> > >> - Toolstack when initializing device paths, writes additional entries in > >> the > >> form of 'request-' = . These entries are only > >> visible by the backend and toolstack; > >> > > And after that we switch the device state to XenbusStateInitialising as > > usual. > > > >> > >> - Backend reads this entries and uses as the value of > >> , which will then be visible on the frontend. > >> > > And after that we switch state to XenbusStateInitWait as usual. No changes > > are > > involved in xenbus state changes other than reading what the toolstack had > > written in "request-*" and seed accordingly. Backends without support would > > simply ignore these new entries. > > > >> [ Removal of the 'request-*' xenstore entries could represent a feedback > >> look > >> that the backend indeed read and used the value. Or else it could simply > >> be > >> ignored. ] > >> > >> And that's it. > >> > >> In pratice user would do: E.g. > >> > >> domain.cfg: > >> ... > >> name = "guest" > >> kernel = "bzImage" > >> vif = ["bridge=br0,queues=2"] > >> disk = [ > >> "format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2,queues=1,max-ring-page-order=0" > >> ] > >> ... > >> > >> Toolstack writes: > >> > >> /local/domain/0/backend/vif/8/0/request-multi-queue-max-queues = 2 > >> /local/domain/0/backend/vbd/8/51713/request-multi-queue-max-queues = 2 > >> /local/domain/0/backend/vbd/8/51713/request-max-ring-page-order = 0 > > > > /local/domain/0/backend/vbd/8/51713/state = 1 (XenbusStateInitialising) > > > >> > >> Backends reads and seeds with (and assuming it passes backend validation > >> ofc): > >> > >> /local/domain/0/backend/vif/8/0/multi-queue-max-queues = 2 > >> /local/domain/0/backend/vbd/8/51713/multi-queue-max-queues = 2 > >> /local/domain/0/backend/vbd/8/51713/max-ring-page-order = 0 > >> > > /local/domain/0/backend/vbd/8/51713/state = 2 (XenbusStateInitWait) > > > >> The XL configuration entry for controlling these tunable are just examples > >> it's > >> not clear the general preference for this. An alternative could be: > >> > >> vif = ["bridge=br0,features=queues:2\\;max-ring-page-order:0"] > >> > >> Which lets us have more generic feature control, without sticking to > >> particular > >> features names. > >> > >> Naturally libvirt could be a consumer of this (as it already has the > >> 'queues' > >> and host 'tso4', 'tso6', etc in their XML schemas) > >> > >> Thoughts? Do folks think the correct way of handling this? > >> > >> Cheers, > >> Joao > >> > >> [0] https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L2102 > >> ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 09/17] livepatch/arm[32, 64]: Modify livepatch_funcs
On Thu, Sep 14, 2017 at 02:20:42PM +0100, Julien Grall wrote:
> Hi Konrad,
>
> On 12/09/17 01:37, Konrad Rzeszutek Wilk wrote:
> > This was found when porting livepatch-build-tools to ARM64/32.
> >
> > When livepatch-build-tools are built (and test-case thanks to:
> > livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
> > the .livepatch.funcs are in read-only section.
> >
> > However the hypervisor uses the 'opaque' for its own purpose, that
> > is stashing the original code. But the .livepatch_funcs section is
> > in the RO vmap area so on ARM[32,64] we get a fault.
>
> This is because the payload is secure at loading and therefore before it get
> applied, right?
Yes.
>
> I was wondering if we could either defer the call to secure_payload or make
> the region temporarily writeable?
This patch creates a temporary writeable virtual address space.
But the idea of making the region temporarily writeable is also possible.
Is there a specific register I can use for this?
>
> >
> > On x86 the same protection is in place. In 'arch_livepatch_quiesce'
> > we disable WP to allow changes to read-only pages (and in arch_live_resume
>
> I can't find any function call arch_live_resume in Xen code. Do you mean
> arch_livepatch_revive?
Yes, let me update that.
>
> > we enable the WP protection).
> >
> > On ARM[32,64] we do not have the luxury of a global register that can
> > be changed after boot. In lieu of that we use the vmap to create
> > a temporary virtual address in which we can use instead.
> >
> > To do this we need to stash during livepatch: vmap of the hypervisor
> > code, vmap of the .livepatch_funcs (vmap comes in page aligned virtual
> > addresses), offset in the vmap (in case it is not nicely aligned), and
> > the original first livepatch_funcs to figure out the index.
> >
> > Equipped with that we can patch livepatch functions which have
> > .livepatch_funcs in rodata section.
> >
> > An alternative is to add the 'W' flag during loading of the
> > .livepatch_funcs which would result the section being in writeable
> > region from the gecko. >
> > Note that this vmap solution could be extended to x86 as well.
And also this, as there is more to it (As Andrew pointed out).
> >
> > Signed-off-by: Konrad Rzeszutek Wilk
> > ---
> > xen/arch/arm/arm32/livepatch.c | 11 ++---
> > xen/arch/arm/arm64/livepatch.c | 11 ++---
> > xen/arch/arm/livepatch.c| 52
> > -
> > xen/arch/x86/livepatch.c| 2 +-
> > xen/common/livepatch.c | 5 ++--
> > xen/include/asm-arm/livepatch.h | 13 ---
> > xen/include/xen/livepatch.h | 2 +-
> > 7 files changed, 71 insertions(+), 25 deletions(-)
> >
> > diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
> > index 10887ace81..d793ebcaad 100644
> > --- a/xen/arch/arm/arm32/livepatch.c
> > +++ b/xen/arch/arm/arm32/livepatch.c
> > @@ -16,18 +16,23 @@ void arch_livepatch_apply(struct livepatch_func *func)
> > uint32_t insn;
> > uint32_t *new_ptr;
> > unsigned int i, len;
> > +struct livepatch_func *f;
> > BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
> > BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
> > -ASSERT(vmap_of_xen_text);
> > +ASSERT(livepatch_vmap.text);
> > len = livepatch_insn_len(func);
> > if ( !len )
> > return;
> > +/* Index in the vmap region. */
> > +i = livepatch_vmap.va - func;
> > +f = (struct livepatch_func *)(livepatch_vmap.funcs +
> > livepatch_vmap.offset) + i;
> > +
> > /* Save old ones. */
> > -memcpy(func->opaque, func->old_addr, len);
> > +memcpy(f->opaque, func->old_addr, len);
> > if ( func->new_addr )
> > {
> > @@ -56,7 +61,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
> > else
> > insn = 0xe1a0; /* mov r0, r0 */
> > -new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
> > +new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
> > len = len / sizeof(uint32_t);
> > /* PATCH! */
> > diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
> > index 2728e2a125..662bedabc3 100644
> > --- a/xen/arch/arm/arm64/livepatch.c
> > +++ b/xen/arch/arm/arm64/livepatch.c
> > @@ -20,18 +20,23 @@ void arch_l
Re: [Xen-devel] [PATCH v3 08/17] livepatch/tests: Make sure all .livepatch.funcs sections are read-only
On Tue, Sep 12, 2017 at 08:49:55AM -0600, Jan Beulich wrote: > >>> On 12.09.17 at 02:37, wrote: > > --- a/xen/test/livepatch/Makefile > > +++ b/xen/test/livepatch/Makefile > > @@ -54,6 +54,7 @@ xen_hello_world.o: config.h livepatch_depends.h > > $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o > > $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^ > > $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@ > > + $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@ > > Why multiple objcopy invocations? I honestly have no idea. I converted it over to be \ and then have --set-section-flags on the same column as --strip-debug. > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 06/17] xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned.
> > +.PHONY: livepatch_depends.h > > +livepatch_depends.h: note.bin > > + $(shell (../../../tools/firmware/hvmloader/mkhex $(NOTE_DEPENDS) $^ > > > $@)) > > It looks quite odd to use a file in firmware/hvmloader for livepatch. Would > it be possible to move mkhex to a generic place? Like so? diff --git a/tools/firmware/hvmloader/Makefile b/tools/firmware/hvmloader/Makefile index 7c4c0ce535..a5b4c32c1a 100644 --- a/tools/firmware/hvmloader/Makefile +++ b/tools/firmware/hvmloader/Makefile @@ -91,23 +91,23 @@ roms.inc: $(ROMS) ifneq ($(ROMBIOS_ROM),) echo "#ifdef ROM_INCLUDE_ROMBIOS" >> $@.new - sh ./mkhex rombios $(ROMBIOS_ROM) >> $@.new + sh ../../misc/mkhex rombios $(ROMBIOS_ROM) >> $@.new echo "#endif" >> $@.new endif ifneq ($(STDVGA_ROM),) echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new - sh ./mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new + sh ../../misc/mkhex vgabios_stdvga $(STDVGA_ROM) >> $@.new echo "#endif" >> $@.new endif ifneq ($(CIRRUSVGA_ROM),) echo "#ifdef ROM_INCLUDE_VGABIOS" >> $@.new - sh ./mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new + sh ../../misc/mkhex vgabios_cirrusvga $(CIRRUSVGA_ROM) >> $@.new echo "#endif" >> $@.new endif ifneq ($(ETHERBOOT_ROMS),) echo "#ifdef ROM_INCLUDE_ETHERBOOT" >> $@.new - sh ./mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new + sh ../../misc/mkhex etherboot $(ETHERBOOT_ROMS) >> $@.new echo "#endif" >> $@.new endif diff --git a/tools/firmware/hvmloader/mkhex b/tools/misc/mkhex similarity index 100% rename from tools/firmware/hvmloader/mkhex rename to tools/misc/mkhex diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile index 8ac9f5e426..f0365305ba 100644 --- a/xen/test/livepatch/Makefile +++ b/xen/test/livepatch/Makefile @@ -73,7 +73,7 @@ note.bin: .PHONY: livepatch_depends.h livepatch_depends.h: note.bin - $(shell (../../../tools/firmware/hvmloader/mkhex $(NOTE_DEPENDS) $^ > $@)) + $(shell (../../../tools/misc/mkhex $(NOTE_DEPENDS) $^ > $@)) # # Extract the build-id of the xen_hello_world.livepatch @@ -85,7 +85,7 @@ hello_world_note.bin: $(LIVEPATCH) .PHONY: hello_world_livepatch_depends.h hello_world_livepatch_depends.h: hello_world_note.bin - $(shell (../../../tools/firmware/hvmloader/mkhex $(NOTE_DEPENDS) $^ > $@)) + $(shell (../../../tools/misc/mkhex $(NOTE_DEPENDS) $^ > $@)) xen_bye_world.o: config.h hello_world_livepatch_depends.h ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] ARM64:Porting xen to new hardware
On Fri, Sep 08, 2017 at 10:19:55PM +0300, Oleksandr Tyshchenko wrote:
> Hi Bharat
>
> On Thu, Sep 7, 2017 at 4:30 PM, bharat gohil wrote:
> > Hello Olensandr,
> >
> > I able to boot xen and trying to boot dom0 but there are no console log for
> > dom0.
> >
> > following log for xen and it stuck booting dom0.
> >
> > (XEN) I/O virtualisation disabled
> > (XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
> > (XEN) alternatives: Patching with alt table 400d2e08 ->
> > 400d32dc
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Loading kernel from boot module @ 40148158
> > (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> > (XEN) BANK[0] 0x004800-0x005000 (128MB)
> > (XEN) Grant table range: 0x00bfe0-0x00bfe65000
> > (XEN) Loading zImage from 40148158 to
> > 4808-4948
> > (XEN) Allocating PPI 16 for event channel interrupt
> > (XEN) Loading dom0 DTB to 0x4fe0-0x4fe0f31e
> > (XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
> > (XEN) ..done.
> > (XEN) Initial low memory virq threshold set at 0x4000 pages.
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to
> > Xen)
> > (XEN) Freed 272kB init memory.
> >
> > I have done all the xen configuration in linux kernel 4.9. This kernel
> > booting fine without xen.
> >
> > following are the DTB changes,
> >
> > chosen {
> > #address-cells = <1>;
> > #size-cells = <1>;
> > bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
> > stdout-path = "serial0";
> > module: module@0 {
> > compatible = "xen,linux-zimage", "xen,multiboot-module";
> > reg = <0x40148158 0x140>;
> > bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
It should be just 'console=hvc0', not 'console=hvc0,921600n8'
> > ignore_loglevel rw root=/dev/mmcblk0p7";
> > };
> >
> > };
> >
> > Can you tell me how to debug dom0 booting or anything which i can check?
>
> Don't now much about "debug dom0 booting", I leave it for competent people.
>
> Looks weird, even with earlyprintk no logs.
> Do you have DEBUG_LL and all related options enabled in your dom0 kernel
> config?
>
> 1. Check that following options are enabled in your kernel config file:
>
> CONFIG_HVC_XEN=y
> CONFIG_HVC_XEN_FRONTEND=y
>
> 2. Check that dom0 kernel doesn't disable clock for console.
>
> BTW, could you post full Xen log, kernel config and device-tree you are using?
> If you have some changes on top of Xen, post them too.
> These may help people to identify what is wrong.
>
> >
> >
> > Thanks,
> > Bharat
> >
> > On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko
> > wrote:
> >>
> >> Hi Bharat
> >>
> >> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil wrote:
> >> > Hello Oleksandr,
> >> >
> >> > Thank you very much.It resolved my issue.
> >> Sounds great!
> >>
> >> >
> >> > Thanks,
> >> > Bharat
> >> >
> >> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko
> >> >
> >> > wrote:
> >> >>
> >> >> Hi Bharat
> >> >>
> >> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil
> >> >> wrote:
> >> >> > Hello Oleksandr,
> >> >> >
> >> >> > I have corrected GIC settings but no success.Following line
> >> >> > disappear
> >> >> > from
> >> >> > log.
> >> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> >> >> >>> 0x2000
> >> >> >
> >> >> > Is anything else which can I try.
> >> >> >
> >> >> > I don’t know much about xen internal for ARM architecture. As you
> >> >> > mentioned,
> >> >> >>>Wrong GIC settings might lead to that IPIs won't work as expected.
> >> >> >>> And
> >> >> >>>boot CPU will get stuck waiting for another CPU.
> >> >> >
> >> >> > Can you explain it with some boot sequence and relation with IPI?
> >> >>
> >> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> >> >> smp_call_function (one CPU didn't receive interrupt from another one).
> >> >> Next patch helped us to fix this issue:
> >> >> https://patchwork.kernel.org/patch/9163065/
> >> >>
> >> >> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
> >> >> Can you take a look at the patch, maybe it is your case too.
> >> >>
> >> >> >
> >> >> > Thanks,
> >> >> > Bharat
> >> >> >
> >> >> >
> >> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> >> >> >
> >> >> > wrote:
> >> >> >>
> >> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil
> >> >> >> wrote:
> >> >> >> > Hello Oleksandr,
> >> >> >> Hi Bharat
> >> >> >>
> >> >> >> >
> >> >> >> > I had removed A72 cluster and tried to boot only two A35 but I got
> >> >> >> > same
> >> >> >> > error.
> >> >> >> >
> >> >> >> > Is anything added or missing in A35 compare to A53?
> >> >> >> Unfortunately, I don't know.
> >> >> >>
> >> >> >> BTW, did you check your GIC settings in the device-tree?
> >> >> >>
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> > B
Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738
.snip.. > (XEN) Loading dom0 DTB to 0x17e0-0x17e08265 > (XEN) init_domheap_pages: 0xb87b1->0xb87bc > (XEN) init_heap_pages: 0xb87b1 -> 0xb87bc > (XEN) init_domheap_pages: 0xb88f1->0xb98ae > (XEN) init_heap_pages: 0xb88f1 -> 0xb98ae <- so the memory is from here > > (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs I expanded this a bit to include: (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) NODE0 start=0x0 pages=579306, max_page=0xc (XEN) NODE0: #0 #1 #2 #3 #4 #5 #6 #7 (total=8) (XEN) NODE0 start=0x0, per_cpu=72413, rem=2, end=0x8d6ea that is the end of memory, but 0xb98ae > 0x8d6ae. end = min(node_start_pfn(i) + node_spanned_pages(i), max_page); 0 0x8D6EA0xc Oh: /* XXX: implement NUMA support */ #define node_spanned_pages(nid) (total_pages) ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738
On Thu, Sep 14, 2017 at 05:39:23PM -0400, Boris Ostrovsky wrote:
> On 09/14/2017 05:26 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, Sep 13, 2017 at 02:49:41PM -0400, Boris Ostrovsky wrote:
> >> On 09/13/2017 02:25 PM, Julien Grall wrote:
> >>> Hi,
> >>>
> >>> On 09/13/2017 07:05 PM, Boris Ostrovsky wrote:
> >>>> On 09/13/2017 11:32 AM, Konrad Rzeszutek Wilk wrote:
> >>>> Well, that's not a fix. This eliminates the case that something in
> >>>> ARM-specific code (which I haven't tested) accidentally clears
> >>>> _PGC_need_scrub.
> >>>>
> >>>> OK, I think I know what the problem is. You are using
> >>>> CONFIG_SEPARATE_XENHEAP, are you?
> >>> It seems the bug appear on Arm64, so CONFIG_SEPARATE_XENHEAP is not set.
> >>>
> >>> Note that Arm32 is using separate heap.
> >>
> >> For separate heap we will need
> >>
> >>
> >> diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
> >> index b5243fc..9f62ea2 100644
> >> --- a/xen/common/page_alloc.c
> >> +++ b/xen/common/page_alloc.c
> >> @@ -2059,7 +2059,7 @@ void free_xenheap_pages(void *v, unsigned int order)
> >>
> >> memguard_guard_range(v, 1 << (order + PAGE_SHIFT));
> >>
> >> -free_heap_pages(virt_to_page(v), order, false);
> >> +free_heap_pages(virt_to_page(v), order, scrub_debug);
> >> }
> >>
> >> #else
> >>
> >>
> >> If that doesn't help then there are two cases where free_heap_pages is
> >> called with 'false' --- one in alloc_domheap_pages() and the other in
> >> online_page().
> >>
> >> Setting one and then the other would further narrow it down.
> > It went further. See the serial log:
>
> Hmm. As Julien said, this is ARM64 so this patch should not have any effect.
>
> Have you tried flipping false to true in the two alloc_domheap_pages()
> invocations that I mentioned?
Yeah, it didn't help. But I decided during a certain call to debug this.
@@ -1705,6 +1711,7 @@ static void init_heap_pages(
{
unsigned long i;
+printk("%s: 0x%lx -> 0x%lx %s\n", __func__, page_to_mfn(pg),
page_to_mfn(pg) + nr_pages, scrub_debug ? "scrub" : "");
for ( i = 0; i < nr_pages; i++ )
{
unsigned int nid = phys_to_nid(page_to_maddr(pg+i));
@@ -1000,7 +1001,12 @@ if ( memflags & MEMF_debug ) {
spin_unlock(&heap_lock);
}
else if ( !(memflags & MEMF_no_scrub) )
+{
+
+ printk("%s:%d %d scrub mfn=0%lx\n", __func__, __LINE__, i,
page_to_mfn(&pg[i]));
+
check_one_page(&pg[i]);
+ }
}
if ( dirty_cnt )
@@ -1836,6 +1843,7 @@ static void __init smp_scrub_heap_pages(void *data)
else
end = start + chunk_size;
+printk("CPU%d: MFN=0x%lx -> 0x%lx\n", cpu, start, end);
for ( mfn = start; mfn < end; mfn++ )
{
pg = mfn_to_page(mfn);
Shows:
(XEN) Loading dom0 DTB to 0x17e0-0x17e08265
(XEN) init_domheap_pages: 0xb87b1->0xb87bc
(XEN) init_heap_pages: 0xb87b1 -> 0xb87bc
(XEN) init_domheap_pages: 0xb88f1->0xb98ae
(XEN) init_heap_pages: 0xb88f1 -> 0xb98ae <- so the memory is from here
(XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
(XEN) CPU0: MFN=0x0 -> 0x8000
(XEN) CPU6: MFN=0x6a12e -> 0x7212e
(XEN) CPU5: MFN=0x58651 -> 0x60651
(XEN) CPU2: MFN=0x235ba -> 0x2b5ba
(XEN) CPU1: MFN=0x11add -> 0x19add
(XEN) CPU3: MFN=0x35097 -> 0x3d097
(XEN) CPU4: MFN=0x46b74 -> 0x4eb74
(XEN) CPU7: MFN=0x7bc0b -> 0x83c0b
(XEN) .(XEN) CPU6: MFN=0x7212e -> 0x7a12e
(XEN) CPU5: MFN=0x60651 -> 0x68651
(XEN) CPU4: MFN=0x4eb74 -> 0x56b74
(XEN) CPU1: MFN=0x19add -> 0x21add
CPU0: MFN=0x8000 -> 0x1
(XEN) CPU7: MFN=0x83c0b -> 0x8bc0b
(XEN) CPU2: MFN=0x2b5ba -> 0x335ba
(XEN) CPU3: MFN=0x3d097 -> 0x45097
(XEN) .(XEN) CPU1: MFN=0x21add -> 0x235ba
(XEN) CPU2: MFN=0x335ba -> 0x35097
CPU0: MFN=0x1 -> 0x11add
(XEN) CPU3: MFN=0x45097 -> 0x46b74
(XEN) CPU6: MFN=0x7a12e -> 0x7bc0b
(XEN) CPU4: MFN=0x56b74 -> 0x58651
(XEN) CPU5: MFN=0x68651 -> 0x6a12e
(XEN) CPU7: MFN=0x8bc0b -> 0x8d6ea
(XEN) .done.
..snip..
(XEN) alloc_heap_pages:1006 0 scrub mfn=0b98ab
(XEN) Xen BUG at page_alloc.c:738
So in other words, it looks like scrub_heap_pages is somehow not
including this MFN.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] hvmloader: Use MB(x) and GB(x) macros
On Fri, Sep 15, 2017 at 05:57:50PM +0100, Wei Liu wrote: > On Fri, Sep 15, 2017 at 12:55:51PM -0400, Konrad Rzeszutek Wilk wrote: > > instead of hardcoding values. We also drop the uint64_t > > cast as the macro uses ULL to produce the proper width > > types. > > > > Acked-by: Jan Beulich > > Signed-off-by: Konrad Rzeszutek Wilk > > You've got Jan's ack so you can commit it right away. :-) True, but that was a year ago. It may have expired. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] mm: Scrub pages returned back to heap if MEMF_no_scrub is set
On Fri, Sep 15, 2017 at 12:47:29PM -0400, Boris Ostrovsky wrote:
> On 09/15/2017 12:05 PM, Jan Beulich wrote:
> On 15.09.17 at 16:04, wrote:
> >> Set free_heap_pages()'s need_scrub to true if alloc_domheap_pages()
> >> returns pages back to heap as result of assign_pages() error when those
> >> pages were requested with MEMF_no_scrub flag.
> >>
> >> We need to do this because there is a possibility that
> >> alloc_heap_pages() might clear buddy's PGC_need_scrubs flag without
> >> actually clearing the page.
> >>
> >> Signed-off-by: Boris Ostrovsky
> >> ---
> >> We are declaring a likely clean (or almost clean) chunk to be dirty. Since
> >> this only happend on assign_pages() error I figured it would be acceptable.
> > I think that's fine, but let's wait a little to see whether others
> > have differing opinions.
> >
> >> --- a/xen/common/page_alloc.c
> >> +++ b/xen/common/page_alloc.c
> >> @@ -2227,7 +2227,7 @@ struct page_info *alloc_domheap_pages(
> >> if ( d && !(memflags & MEMF_no_owner) &&
> >> assign_pages(d, pg, order, memflags) )
> >> {
> >> -free_heap_pages(pg, order, false);
> >> +free_heap_pages(pg, order, !!(memflags & MEMF_no_scrub));
> > No need for the !! (easily fixed while committing).
>
> Sure.
>
> > With that
> > Reviewed-by: Jan Beulich
> >
> > I take it this isn't related to the issue on ARM64 that Konrad has
> > found?
>
>
> It's related in the sense that I noticed this while looking at Konrad's
> problem. Whether or not it also fixes his issue --- I don't know. If it
> does then I think it will indicate that something else is going on there
> since this would mean he is hitting assign_pages() error.
Sadly no. Let me update the other email.
>
>
> -boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] python: Add binding for xs_fileno()
On Fri, Sep 15, 2017 at 05:35:34PM +0100, Euan Harris wrote:
> xs_fileno() returns a file descriptor which receives events when Xenstore
> watches fire. Exposing this in the Python bindings is a prerequisite
> for writing event-driven clients in Python.
>
> Signed-off-by: Euan Harris
Reviewed-by: Konrad Rzeszutek Wilk
> ---
> tools/python/xen/lowlevel/xs/xs.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/tools/python/xen/lowlevel/xs/xs.c
> b/tools/python/xen/lowlevel/xs/xs.c
> index aba5a20..9f1b916 100644
> --- a/tools/python/xen/lowlevel/xs/xs.c
> +++ b/tools/python/xen/lowlevel/xs/xs.c
> @@ -453,6 +453,25 @@ static PyObject *xspy_watch(XsHandle *self, PyObject
> *args)
> }
>
>
> +#define xspy_fileno_doc "\n" \
> + "Return the FD to poll for notifications when watches fire.\n" \
> + "Returns: [int] file descriptor.\n"\
> + "\n"
> +
> +static PyObject *xspy_fileno(XsHandle *self)
> +{
> +struct xs_handle *xh = xshandle(self);
> +int fd;
> +
> +if (!xh)
> +return NULL;
> +
> +fd = xs_fileno(xh);
> +
> +return PyInt_FromLong(fd);
> +}
> +
> +
> #define xspy_read_watch_doc "\n" \
> "Read a watch notification.\n" \
> "\n"\
> @@ -887,6 +906,7 @@ static PyMethodDef xshandle_methods[] = {
> XSPY_METH(release_domain,METH_VARARGS),
> XSPY_METH(close, METH_NOARGS),
> XSPY_METH(get_domain_path, METH_VARARGS),
> +XSPY_METH(fileno,METH_NOARGS),
> { NULL /* Sentinel. */ },
> };
>
> --
> 1.8.3.1
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] Left over patches from long-time ago.
Hey, I was cleaning my mailbox and noticed that I still hadn't this done. This one was from 2016 and it looks like I just never sent it out (even thought I did the fix the next day). I never got to fix the other patch: https://lists.xen.org/archives/html/xen-devel/2016-09/msg03191.html Anyhow, sending the first out and will commit it next week if nobody complains. The last reply was from Jan: 57ecd46b027800113...@prv-mh.provo.novell.com https://lists.xen.org/archives/html/xen-devel/2016-09/msg03228.html Thanks! tools/firmware/hvmloader/e820.c | 6 +++--- tools/firmware/hvmloader/pci.c| 8 tools/firmware/hvmloader/smbios.c | 5 ++--- tools/firmware/hvmloader/util.h | 3 +++ 4 files changed, 12 insertions(+), 10 deletions(-) Konrad Rzeszutek Wilk (1): hvmloader: Use MB(x) and GB(x) macros ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] hvmloader: Use MB(x) and GB(x) macros
instead of hardcoding values. We also drop the uint64_t
cast as the macro uses ULL to produce the proper width
types.
Acked-by: Jan Beulich
Signed-off-by: Konrad Rzeszutek Wilk
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Ian Jackson
Cc: Wei Liu
v2: New submission
v3: Don't use leading underscores in macro.
- Drop the uint64_t cast
- Added Jan's Ack.
---
tools/firmware/hvmloader/e820.c | 6 +++---
tools/firmware/hvmloader/pci.c| 8
tools/firmware/hvmloader/smbios.c | 5 ++---
tools/firmware/hvmloader/util.h | 3 +++
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/tools/firmware/hvmloader/e820.c b/tools/firmware/hvmloader/e820.c
index 5541b18705..4d1c955a02 100644
--- a/tools/firmware/hvmloader/e820.c
+++ b/tools/firmware/hvmloader/e820.c
@@ -82,7 +82,7 @@ void adjust_memory_map(void)
/* Modify the existing highmem region if it exists. */
if ( memory_map.map[i].type == E820_RAM &&
- high_mem_end && map_start == ((uint64_t)1 << 32) )
+ high_mem_end && map_start == GB(4) )
{
if ( high_mem_end != map_end )
memory_map.map[i].size = high_mem_end - map_start;
@@ -94,7 +94,7 @@ void adjust_memory_map(void)
/* If there was no highmem region, just create one. */
if ( high_mem_end )
{
-memory_map.map[i].addr = ((uint64_t)1 << 32);
+memory_map.map[i].addr = GB(4);
memory_map.map[i].size =
((uint64_t)hvm_info->high_mem_pgend << PAGE_SHIFT) -
memory_map.map[i].addr;
@@ -234,7 +234,7 @@ int build_e820_table(struct e820entry *e820,
}
/* Low RAM goes here. Reserve space for special pages. */
-BUG_ON(low_mem_end < (2u << 20));
+BUG_ON(low_mem_end < MB(2));
/*
* Construct E820 table according to recorded memory map.
diff --git a/tools/firmware/hvmloader/pci.c b/tools/firmware/hvmloader/pci.c
index 9543e5aaf2..0b708bf578 100644
--- a/tools/firmware/hvmloader/pci.c
+++ b/tools/firmware/hvmloader/pci.c
@@ -59,7 +59,7 @@ static int find_next_rmrr(uint32_t base)
{
unsigned int i;
int next_rmrr = -1;
-uint64_t end, min_end = 1ULL << 32;
+uint64_t end, min_end = GB(4);
for ( i = 0; i < memory_map.nr_map ; i++ )
{
@@ -297,7 +297,7 @@ void pci_setup(void)
if ( mmio_hole_size )
{
-uint64_t max_ram_below_4g = (1ULL << 32) - mmio_hole_size;
+uint64_t max_ram_below_4g = GB(4) - mmio_hole_size;
if ( max_ram_below_4g > HVM_BELOW_4G_MMIO_START )
{
@@ -385,13 +385,13 @@ void pci_setup(void)
adjust_memory_map();
high_mem_resource.base = ((uint64_t)hvm_info->high_mem_pgend) <<
PAGE_SHIFT;
-if ( high_mem_resource.base < 1ull << 32 )
+if ( high_mem_resource.base < GB(4) )
{
if ( hvm_info->high_mem_pgend != 0 )
printf("WARNING: hvm_info->high_mem_pgend %x"
" does not point into high memory!",
hvm_info->high_mem_pgend);
-high_mem_resource.base = 1ull << 32;
+high_mem_resource.base = GB(4);
}
printf("%sRAM in high memory; setting high_mem resource base to
"PRIllx"\n",
hvm_info->high_mem_pgend?"":"No ",
diff --git a/tools/firmware/hvmloader/smbios.c
b/tools/firmware/hvmloader/smbios.c
index bdd96b2f7a..40d8399be1 100644
--- a/tools/firmware/hvmloader/smbios.c
+++ b/tools/firmware/hvmloader/smbios.c
@@ -239,15 +239,14 @@ get_memsize(void)
sz = (uint64_t)hvm_info->low_mem_pgend << PAGE_SHIFT;
if ( hvm_info->high_mem_pgend )
-sz += (((uint64_t)hvm_info->high_mem_pgend << PAGE_SHIFT)
- - (1ull << 32));
+sz += (((uint64_t)hvm_info->high_mem_pgend << PAGE_SHIFT) - GB(4));
/*
* Round up to the nearest MB. The user specifies domU pseudo-physical
* memory in megabytes, so not doing this could easily lead to reporting
* one less MB than the user specified.
*/
-return (sz + (1ul << 20) - 1) >> 20;
+return (sz + MB(1) - 1) >> 20;
}
void
diff --git a/tools/firmware/hvmloader/util.h b/tools/firmware/hvmloader/util.h
index 2ef854eb8f..7bca6418d2 100644
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -48,6 +48,9 @@ void __bug(char *file, int line) __attribute__((noreturn));
#define max_t(type,x,y) \
({ type __x = (x); type __y = (y); __x > __y ? __x: __y; })
+#define MB(mb) (mb##ULL << 20)
+#define GB(gb) (gb##ULL << 30)
+
static inline int test_bit(unsigned int b, const void *p)
{
return !!(((const uint8_t *)p)[b>>3] & (1u<<(b&7)));
--
2.13.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md
> +### Soft-reset for PV guests s/PV/HVM/ > + > +Status: Supported > + > +Soft-reset allows a new kernel to start 'from scratch' with a fresh VM > state, > +but with all the memory from the previous state of the VM intact. > +This is primarily designed to allow "crash kernels", > +which can do core dumps of memory to help with debugging in the event of a > crash. > + > +### xentrace > + > +Status, x86: Supported > + > +Tool to capture Xen trace buffer data > + > +### gcov > + > +Status: Supported, Not security supported > + > +Export hypervisor coverage data suitable for analysis by gcov or lcov. > + > +## Memory Management > + > +### Memory Ballooning > + > +Status: Supported > + > +### Memory Sharing > + > +Status, x86 HVM: Tech Preview > +Status, ARM: Tech Preview > + > +Allow sharing of identical pages between guests > + > +### Memory Paging > + > +Status, x86 HVM: Experimenal > + > +Allow pages belonging to guests to be paged to disk > + > +### Transcendent Memory > + > +Status: Experimental > + > +[XXX Add description] Guests with tmem drivers autoballoon memory out allowing a fluid and dynamic memory allocation - in effect memory overcommit without the need to swap. Only works with Linux guests (as it requires OS drivers). ..snip.. > +### Live Patching > + > +Status, x86: Supported > +Status, ARM: Experimental > + > +Compile time disabled for ARM. As the patch will do: config LIVEPATCH - bool "Live patching support (TECH PREVIEW)" - default n + bool "Live patching support" + default X86 depends on HAS_BUILD_ID = "y" ---help--- Allows a running Xen hypervisor to be dynamically patched using ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738
On Wed, Sep 13, 2017 at 02:49:41PM -0400, Boris Ostrovsky wrote: > On 09/13/2017 02:25 PM, Julien Grall wrote: > > Hi, > > > > On 09/13/2017 07:05 PM, Boris Ostrovsky wrote: > >> On 09/13/2017 11:32 AM, Konrad Rzeszutek Wilk wrote: > >> Well, that's not a fix. This eliminates the case that something in > >> ARM-specific code (which I haven't tested) accidentally clears > >> _PGC_need_scrub. > >> > >> OK, I think I know what the problem is. You are using > >> CONFIG_SEPARATE_XENHEAP, are you? > > > > It seems the bug appear on Arm64, so CONFIG_SEPARATE_XENHEAP is not set. > > > > Note that Arm32 is using separate heap. > > > For separate heap we will need > > > diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c > index b5243fc..9f62ea2 100644 > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -2059,7 +2059,7 @@ void free_xenheap_pages(void *v, unsigned int order) > > memguard_guard_range(v, 1 << (order + PAGE_SHIFT)); > > -free_heap_pages(virt_to_page(v), order, false); > +free_heap_pages(virt_to_page(v), order, scrub_debug); > } > > #else > > > If that doesn't help then there are two cases where free_heap_pages is > called with 'false' --- one in alloc_domheap_pages() and the other in > online_page(). > > Setting one and then the other would further narrow it down. It went further. See the serial log: root@linaro-developer:~# xl info host : linaro-developer release: 4.12.0-linaro-hikey960+ version: #3 SMP PREEMPT Mon Jul 17 13:26:13 EDT 2017 machine: aarch64 nr_cpus: 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz: 1 hw_caps: ::::::: virt_caps : total_memory : 2262 free_memory: 712 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 10 xen_extra : -unstable xen_version: 4.10-unstable xen_caps : xen-3.0-aarch64 xen-3.0-armv7l xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x20 xen_changeset : Mon Jun 19 17:11:06 2017 -0400 git:b819b1ec24-dirty xen_commandline: loglvl=all console=dtuart dtuart=/soc/serial@fff32000 efi=no-rs dom0_mem=1500M cc_compiler: gcc (Debian 6.3.0-18) 6.3.0 20170516 cc_compile_by : root cc_compile_domain : cc_compile_date: Wed Sep 13 20:42:42 UTC 2017 build_id : 48fbef3c27a9d845faba3aea7e7d24063997815c xend_config_format : 4 root@linaro-developer:~# cd /home/xen.git root@linaro-developer:/home/xen.git# git diff . [1mdiff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c[m[m [1mindex b5243fca3c..9f62ea257d 100644[m[m [1m--- a/xen/common/page_alloc.c[m[m [1m+++ b/xen/common/page_alloc.c[m[m [36m@@ -2059,7 +2059,7 @@[m [mvoid free_xenheap_pages(void *v, unsigned int order)[m[m [m[m memguard_guard_range(v, 1 << (order + PAGE_SHIFT));[m[m [m[m [31m-free_heap_pages(virt_to_page(v), order, false);[m[m [32m+[m[32mfree_heap_pages(virt_to_page(v), order, scrub_debug);[m[m }[m[m [m[m #else[m[m [Kroot@linaro-developer:/home/xen.git# /r[Kcd /root root@linaro-developer:~# ./livepatch_test.pl Have 37 test-cases Executing: '(set -e;cd /root/test/livepatch;xen-livepatch list)' .. ID | status + Executing: '(set -e;cd /root/test/livepatch;xen-livepatch list)' .. ID | status + Executing: '(set -e;cd /root/test/livepatch;xl info)' ..host : linaro-developer release: 4.12.0-linaro-hikey960+ version: #3 SMP PREEMPT Mon Jul 17 13:26:13 EDT 2017 machine: aarch64 nr_cpus: 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 1 threads_per_core : 1 cpu_mhz: 1 hw_caps: ::::::: virt_caps : total_memory : 2262 free_memory: 712 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 10 xen_extra : -unstable xen_version: 4.10-unstable xen_ca
Re: [Xen-devel] GRUB documentation updated
On Thu, Sep 07, 2017 at 09:12:33PM +0200, Daniel Kiper wrote: > Hey, > > Some people asked me about Multiboot2 Specification and other GRUB doc stuff. > So, I have put latest things at > https://www.gnu.org/software/grub/grub-documentation.html Yeey! Thank you for doing that! > > I hope that helps. If you have any questions please drop me a line. > > Thanks, > > Daniel > > ___ > Grub-devel mailing list > grub-de...@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md
On Thu, Sep 07, 2017 at 05:50:13AM -0600, Jan Beulich wrote: > >>> On 07.09.17 at 13:31, wrote: > > On 08/31/2017 01:46 PM, Jan Beulich wrote: > > On 31.08.17 at 12:27, wrote: > >>> +### Live Patching > >>> + > >>> +Status: Supported, x86 only > >>> + > >>> +Compile time disabled > >> > >> Bu we're settled to change that, aren't we? It was even meant to be > >> so in 4.9, but then didn't make it. > > > > Change the compile time disabling? I don't really know. :-) > > Yeah, well, that series is taking awfully long to become ready to go > in. Konrad? Just posted it: https://lists.xen.org/archives/html/xen-devel/2017-09/msg01156.html ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.
On Wed, Sep 13, 2017 at 02:51:41AM -0600, Jan Beulich wrote: > >>> On 13.09.17 at 01:46, wrote: > > On Tue, Sep 12, 2017 at 08:48:33AM -0600, Jan Beulich wrote: > >> >>> On 12.09.17 at 02:37, wrote: > >> > This surfaced due to "xen/livepatch/x86/arm32: Force > >> > .livepatch.depends section to be uint32_t aligned." which switched > >> > to a different way of including the build-id. > >> > > >> > Each livepatch ends with a global: > >> > > >> > 30: 1 OBJECT GLOBAL HIDDEN 7 note_depends > >> > > >> > which will cause collision when loading. > >> > > >> > One attempted solution was to add in the Makefile stanza: > >> > @sed -i '/unsigned/static unsinged/' $@ > >> > > >> > But that resulted in the note_depends being omitted from the livepatch > >> > (as it was static and not used) which meant we would not have an > >> > .livepatch_depends section which we require. > >> > >> Did you consider using objcopy's --localize-symbol instead? > > > > Yes, so that note_depends is not globally visible. But that won't help > > as hypervisor treats both local and global symbols as global when resolving > > them. > > > > That is each of the livepatch has the node_depends in it, and we can't > > load xen_hello_world, followed by xen_replace_world test-case (so > > stacking them on top of each other) - as both have the same local > > symbol. > > Oh, right. Then perhaps stripping the symbol is as good or as bad as > deriving the symbol name from e.g. the patch name, or putting some > randomized tag on it. Yes, and I had in mind changing the name of it (to prefix it with the livepatch name) using --redefine-sym. But then figured it may be just easier to ditch the symbol altogether. Let me try it out - I do wonder if that would remove the need for stripping the debug symbols or if that would still trip the issue I keep on having - which is that the debug section would reference the original symbol. > > > (This is fixed in "livepatch: Add local and global symbol resolution." > > on which you said: > > > > > All the 'GLOBAL' have to be unique per livepatch. But the > > > 'LOCAL' can all be the same which means the semantic of 'static' > > > on functions and data variables is the right one. > > > > I think this is wrong: Afaict your change results in main image and > > patch local symbols to now be treated differently. While this may > > indeed help patches which are meant to replace others, it is going > > to get in the way if a patch wants to reference a local symbol > > already altered (or newly introduced) by a prior one. > > > > (https://www.mail-archive.com/xen-devel@lists.xen.org/msg111710.html) > > Right, this is a basically unresolvable ambiguity, I'm afraid. We'd > need a 3rd class of symbols. It may be worth considering to (ab)use > e.g. STV_INTERNAL for this purpose. Oh. Let me look at that. Thank you! > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC XEN PATCH v3 12/39] tools/xen-ndctl: add NVDIMM management util 'xen-ndctl'
On Mon, Sep 11, 2017 at 09:35:08AM -0700, Dan Williams wrote: > On Sun, Sep 10, 2017 at 10:39 PM, Haozhong Zhang > wrote: > > On 09/10/17 22:10 -0700, Dan Williams wrote: > >> On Sun, Sep 10, 2017 at 9:37 PM, Haozhong Zhang > >> wrote: > >> > The kernel NVDIMM driver and the traditional NVDIMM management > >> > utilities in Dom0 does not work now. 'xen-ndctl' is added as an > >> > alternatively, which manages NVDIMM via Xen hypercalls. > >> > > >> > Signed-off-by: Haozhong Zhang > >> > --- > >> > Cc: Ian Jackson > >> > Cc: Wei Liu > >> > --- > >> > .gitignore | 1 + > >> > tools/misc/Makefile| 4 ++ > >> > tools/misc/xen-ndctl.c | 172 > >> > + > >> > 3 files changed, 177 insertions(+) > >> > create mode 100644 tools/misc/xen-ndctl.c > >> > >> What about my offer to move this functionality into the upstream ndctl > >> utility [1]? I think it is thoroughly confusing that you are reusing > >> the name 'ndctl' and avoiding integration with the upstream ndctl > >> utility. > >> > >> [1]: https://patchwork.kernel.org/patch/9632865/ > > > > I'm not object to integrate it with ndctl. > > > > My only concern is that the integration will introduces two types of > > user interface. The upstream ndctl works with the kernel driver and > > provides easily used *names* (e.g., namespace0.0, region0, nmem0, > > etc.) for user input. However, this version patchset hides NFIT from > > Dom0 (to simplify the first implementation), so the kernel driver does > > not work in Dom0, neither does ndctl. Instead, xen-ndctl has to use > > *the physical address* for users to specify their interested NVDIMM > > region, which is different from upstream ndctl. > > Ok, I think this means that xen-ndctl should be renamed (xen-nvdimm?) > so that the distinction between the 2 tools is clear. I think it makes much more sense to integrate this in the upstream version of ndctl. As surely in the future the ndctl will need to work with other OSes too? Such as FreeBSD? ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738
On Tue, Sep 12, 2017 at 09:19:23PM -0400, Boris Ostrovsky wrote:
>
>
> On 09/12/2017 08:01 PM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Sep 11, 2017 at 08:45:02PM -0400, Boris Ostrovsky wrote:
> > >
> > >
> > > On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote:
> > > > Hey,
> > > >
> > > > I've only been able to reproduce this on ARM64 (trying right now ARM32
> > > > as well), and not on x86.
> > > >
> > > > If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
> > > > enable it and try to load a livepatch it blows up in page_alloc.c:738
> > > >
> > > > This is with origin/staging (d0291f3391)
> > >
> > > Can you still reproduce this if you revert 307c3be?
> >
> > Sadly yes - it still crashes. I didn't capture the serial output.
> >
> > I honestly think the issue is that on ARM64 the "sleep" loop does not
> > wake up as often as on x86 (CC-ing Dariof who I believe observed this
> > with Credit2 and the wakeup.. something) - maybe he remembers the
> > details. Anyhow my theory is that the pages are not scrubbed at all
> > when they go in the idle loop as once it goes to sleep - it stays there.
>
>
> There is no (well, should not be) any timing dependencies in how/whether
> pages are scrubbed. If a page doesn't get scrubbed because someone didn't
> wake up then it should be scrubbed in alloc_heap_pages(). So in this case
> the page is thought to be clean (_PGC_need_scrub is not set), but it is not.
>
> Have you tried running a guest (or two), rebooting in a loop?
No. I just cold-booted it and tried to livepatch.
>
> Another thing to try is to set need_scrub to true in free_heap_pages().
Magic!
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index dbad1e1ca0..9303eb4517 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1308,6 +1308,7 @@ static void free_heap_pages(
ASSERT(node >= 0);
spin_lock(&heap_lock);
+need_scrub = true;
for ( i = 0; i < (1 << order); i++ )
{
Fixes it ! :-)
>
> -boris
>
>
> >
> > Ah, see commit 05c52278a7c92bc753d9fe32017e4961012b9f23
> >
> > Maybe this is related?
> > >
> > >
> > > -boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 14/17] livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn
On Tue, Sep 12, 2017 at 08:54:34AM -0600, Jan Beulich wrote:
> >>> On 12.09.17 at 02:37, wrote:
> > With this change we can use _do_page_walk() to implement
> > arch_livepatch_lookup_mfn() which can be used to find out
> > vmap virtual addresses (as under x86 virt_to_mfn won't work
> > for vmap, but it does for arm!).
>
> How about using domain_page_map_to_mfn() instead?
It is very colorfull:
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 667573c..f90d4c8 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -17,11 +18,18 @@
mfn_t arch_livepatch_lookup_mfn(unsigned long addr)
{
unsigned long cr3 = read_cr3() >> PAGE_SHIFT;
+mfn_t r, r2;
+uint64_t mfn;
if ( !mfn_valid(_mfn(cr3)) )
return INVALID_MFN;
-return _do_page_walk(cr3, addr);
+r = _do_page_walk(cr3, addr);
+mfn = domain_page_map_to_mfn((void *)addr);
+r2 = _mfn(mfn);
+WARN_ON( !mfn_eq(r, r2) );
+
+return r;
}
void arch_livepatch_revive(void)
..
(XEN) livepatch.c:1450: livepatch: xen_hello_world: CPU1 - IPIing the other 3
CPUs
Applying xen_hello_world... (XEN) livepatch: xen_hello_world: Applying 1
functions
(XEN) Assertion 'va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END' failed at
domain_page.c:349
(XEN) [ Xen-4.10-unstable x86_64 debug=y Tainted: C ]
(XEN) CPU:1
(XEN) RIP:e008:[] domain_page_map_to_mfn+0x98/0xc8
(XEN) RFLAGS: 00010012 CONTEXT: hypervisor
(XEN) rax: 00d04020 rbx: 0009e400 rcx:
(XEN) rdx: 00108020 rsi: 9e677000 rdi: 82d08020
(XEN) rbp: 84842789fe18 rsp: 84842789fe18 r8: 8484278d83c0
(XEN) r9: 0004 r10: 0001 r11: 0001
(XEN) r12: 82d08020 r13: 84843e220ab0 r14: 0009b3af6068
(XEN) r15: cr0: 8005003b cr4: 000426e0
(XEN) cr3: 9e677000 cr2: 8800078d4328
(XEN) ds: 002b es: 002b fs: gs: ss: e010 cs: e008
(XEN) Xen code around (domain_page_map_to_mfn+0x98/0xc8):
(XEN) 48 3d ff ff ff 1f 76 04 <0f> 0b eb fe 48 c1 e7 10 48 c1 ef 1c 48 b8 00 00
(XEN) Xen stack trace from rsp=84842789fe18:
(XEN)84842789fe38 82d080286d05 0001 82d08060b180
(XEN)84842789fe88 82d08021b8b6 84842789fe58 82d0802395a5
(XEN)000d 84843e220bf0 84843e220ab0 84843e220bf0
(XEN)84843e220ab0 0009b3af6068 84842789feb8 82d08021bc38
(XEN)0001 0001 84843e220ab0 84843e220ab0
(XEN)84842789ff08 82d08021befa 84842789fed8 0246
(XEN) 84809e9a5000 0001 84809e6de000
(XEN)84842788c000 84842789fd78 82d08027d4e4
(XEN)8800394b6000 8800394b6002
(XEN)c95f3e60 0001 0246
(XEN) 9b810048 810013aa
(XEN)0001 deadbeefdeadf00d deadbeefdeadf00d 0100
(XEN)810013aa e033 0246 c95f3e48
(XEN)e02b 42f0e7438e1e7fc8 06c64a65b2da83f9 6ddeafb16f2755f2
(XEN)97e5fcb4dae8d065 ea89d67a0001 84809e9a5000 01b3b6129680
(XEN)000426e0
(XEN) Xen call trace:
(XEN)[] domain_page_map_to_mfn+0x98/0xc8
(XEN)[] arch_livepatch_lookup_mfn+0x46/0x61
(XEN)[] livepatch.c#livepatch_quiesce+0x45/0x1e4
(XEN)[] livepatch.c#apply_payload+0x3f/0x109
(XEN)[] check_for_livepatch_work+0x1f8/0x395
(XEN)[] domain.c#continue_idle_domain+0x1b/0x22
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 1:
(XEN) Assertion 'va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END' failed at
domain_page.c:349
(XEN)
(XEN)
(XEN) Reboot in five seconds...
Which is due to:
287 start = (void *)xen_virt_end;
288 end = (void *)(XEN_VIRT_END - NR_CPUS * PAGE_SIZE);
289
290 BUG_ON(end <= start);
291
292 vm_init_type(VMAP_XEN, start, end);
If I modify it a bit:
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 3432a854dd..a95e95b372 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -344,6 +344,11 @@ unsigned long domain_page_map_to_mfn(const void *ptr)
pl1e = virt_to_xen_l1e(va);
BUG_ON(!pl1e);
}
+else if ( va >= xen_virt_end && va < (XEN_VIRT_END - NR_CPUS * PAGE_SIZE) )
+{
+pl1e = virt_to_xen_l1e(va);
+BUG_ON(!pl1e);
+}
else
{
ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);
And then some extra debug:
(XEN) ptr=0x82004000d000, DIRECTMAP_VIRT_START=0x8480,
VMAP_VIRT_S
Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738
On Mon, Sep 11, 2017 at 08:45:02PM -0400, Boris Ostrovsky wrote: > > > On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote: > > Hey, > > > > I've only been able to reproduce this on ARM64 (trying right now ARM32 > > as well), and not on x86. > > > > If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if > > enable it and try to load a livepatch it blows up in page_alloc.c:738 > > > > This is with origin/staging (d0291f3391) > > Can you still reproduce this if you revert 307c3be? Sadly yes - it still crashes. I didn't capture the serial output. I honestly think the issue is that on ARM64 the "sleep" loop does not wake up as often as on x86 (CC-ing Dariof who I believe observed this with Credit2 and the wakeup.. something) - maybe he remembers the details. Anyhow my theory is that the pages are not scrubbed at all when they go in the idle loop as once it goes to sleep - it stays there. Ah, see commit 05c52278a7c92bc753d9fe32017e4961012b9f23 Maybe this is related? > > > -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.
On Tue, Sep 12, 2017 at 08:48:33AM -0600, Jan Beulich wrote: > >>> On 12.09.17 at 02:37, wrote: > > This surfaced due to "xen/livepatch/x86/arm32: Force > > .livepatch.depends section to be uint32_t aligned." which switched > > to a different way of including the build-id. > > > > Each livepatch ends with a global: > > > > 30: 1 OBJECT GLOBAL HIDDEN 7 note_depends > > > > which will cause collision when loading. > > > > One attempted solution was to add in the Makefile stanza: > > @sed -i '/unsigned/static unsinged/' $@ > > > > But that resulted in the note_depends being omitted from the livepatch > > (as it was static and not used) which meant we would not have an > > .livepatch_depends section which we require. > > Did you consider using objcopy's --localize-symbol instead? Yes, so that note_depends is not globally visible. But that won't help as hypervisor treats both local and global symbols as global when resolving them. That is each of the livepatch has the node_depends in it, and we can't load xen_hello_world, followed by xen_replace_world test-case (so stacking them on top of each other) - as both have the same local symbol. (This is fixed in "livepatch: Add local and global symbol resolution." on which you said: > All the 'GLOBAL' have to be unique per livepatch. But the > 'LOCAL' can all be the same which means the semantic of 'static' > on functions and data variables is the right one. I think this is wrong: Afaict your change results in main image and patch local symbols to now be treated differently. While this may indeed help patches which are meant to replace others, it is going to get in the way if a patch wants to reference a local symbol already altered (or newly introduced) by a prior one. (https://www.mail-archive.com/xen-devel@lists.xen.org/msg111710.html) > > Jan > ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 10/17] livepatch: Declare live patching as a supported feature
From: Ross Lagerwall See docs/features/livepatch.pandoc for the details. Reviewed-by: Jan Beulich Signed-off-by: Ross Lagerwall Signed-off-by: Konrad Rzeszutek Wilk -- v2: - Moved it into a feature document. - Clarified a few bits and pieces based on feedback. v3: - default X86 - added Jan's Reviewed-by - Added tech preview for ARM. - Cut down the 3) paragraph per George's input --- docs/features/livepatch.pandoc | 106 + xen/common/Kconfig | 4 +- 2 files changed, 108 insertions(+), 2 deletions(-) create mode 100644 docs/features/livepatch.pandoc diff --git a/docs/features/livepatch.pandoc b/docs/features/livepatch.pandoc new file mode 100644 index 00..17f1cd0d05 --- /dev/null +++ b/docs/features/livepatch.pandoc @@ -0,0 +1,106 @@ +% Live Patching +% Revision 1 + +\clearpage + +# Basics + + + Status: **Supported** + + Architecture: x86 + + Status: **Tech Preview/Experimental** + + Architecture: ARM + + Component: Hypervisor, toolstack + + + +# Details + +Xen Live Patching has been available as tech preview feature since Xen +4.7 and has now had a couple of releases to stabilize. Xen Live patching +has been used by multiple vendors to fix several real-world security +issues without any severe bugs encountered. Additionally, there are now +tests in OSSTest that test live patching to ensure that no regressions +are introduced. + +Based on the amount of testing and usage it has had, we are ready to +declare live patching as a 'Supported' feature on x86. + +Live patching is slightly peculiar when it comes to support because it +allows the host administrator to break their system rather easily +depending on the content of the live patch. Because of this, it is +worth detailing the scope of security support: + +1) Unprivileged access to live patching operations: + Live patching operations should only be accessible to privileged + guests and it shall be treated as a security issue if this is not + the case. + +2) Bugs in the patch-application code such that vulnerabilities exist + after application: + If a correct live patch is loaded but it is not applied correctly + such that it might result in an insecure system (e.g. not all + functions are patched), it shall be treated as a security issue. + +3) Bugs in livepatch-build-tools creating an incorrect live patch that + results in an insecure host: + If livepatch-build-tools creates an incorrect live patch that + results in an insecure host, this shall not be considered a security + issue. A live patch should be checked to verify that it is valid + before loading. + +4) Loading an incorrect live patch that results in an insecure host or + host crash: + If a live patch (whether created using livepatch-build-tools or some + alternative) is loaded and it results in an insecure host or host + crash due to the content of the live patch being incorrect or the + issue being inappropriate to live patch, this is not considered as a + security issue. + +5) Bugs in the live patch parsing code (the ELF loader): + Bugs in the live patch parsing code such as out-of-bounds reads + caused by invalid ELF files are not considered to be security issues + because the it can only be triggered by a privileged domain. + +6) Bugs which allow a guest to prevent the application of a livepatch: + A guest should not be able to prevent the application of a live + patch. If an unprivileged guest can somehow prevent the application + of a live patch despite pausing it (xl pause ...), it shall be + treated as a security issue. + +Note: It is expected that live patches are tested in a test environment +before being used in production to avoid unexpected issues. In +particular, to avoid the issues described by (3), (4), & (5). + +There are also some generic security questions which are worth asking: + +1) Is guest->host privilege escalation possible? + +The new live patching sysctl subops are only accessible to privileged +domains and this is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce a guest->host +privilege escalation. + +2) Is guest user->guest kernel escalation possible? + +No, although an incorrect live patch can introduce a guest user->guest +kernel privilege escalation. + +3) Is there any information leakage? + +The new live patching sysctl subops are only accessible to privileged +domains so it is not possible for an unprivileged guest to access the +list of loaded live patches. This is tested by OSSTest with an XTF test. +There is a caveat -- an incorrect live patch can introduce an +information leakage. + +4) Can a Denial-of-Service be triggered? + +There are no known ways that an unprivileged guest can prevent a
[Xen-devel] [PATCH v3 17/17] livepatch: Add xen_local_symbols test-case
To exercise the local/global visibility.
With "livepatch: Add local and global symbol resolution."
we can load both xen_hello_world and xen_local_symbols
without having to worry about:
-bash-4.1# xen-livepatch load xen_hello_world.livepatch
Uploading xen_hello_world.livepatch... completed
Applying xen_hello_world... completed
-bash-4.1# xen-livepatch list
ID | status
+
xen_hello_world | APPLIED
-bash-4.1# xen-livepatch upload xen_local_symbols xen_local_symbols.livepatch
Uploading xen_local_symbols.livepatch... failed
(XEN) livepatch.c:819: livepatch: xen_local_symbols: duplicate new symbol:
revert_hook
In fact you will see:
livepatch: xen_hello_world: new local symbol revert_hook
livepatch: xen_hello_world: new local symbol apply_hook
livepatch: xen_hello_world: new local symbol check_fnc
livepatch: xen_hello_world: new local symbol hello_world_patch_this_fnc
...
livepatch: xen_local_symbols: new local symbol revert_hook
livepatch: xen_local_symbols: new local symbol apply_hook
livepatch: xen_local_symbols: new local symbol hello_world_patch_this_fnc
..
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: First edition
v2: Build with mkhex version of build-id from hypervisor.
---
xen/test/livepatch/Makefile| 12 +++-
xen/test/livepatch/xen_local_symbols.c | 53 ++
2 files changed, 64 insertions(+), 1 deletion(-)
create mode 100644 xen/test/livepatch/xen_local_symbols.c
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 6e5b9a3a75..f88c8f9c80 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -11,11 +11,13 @@ LIVEPATCH := xen_hello_world.livepatch
LIVEPATCH_BYE := xen_bye_world.livepatch
LIVEPATCH_REPLACE := xen_replace_world.livepatch
LIVEPATCH_NOP := xen_nop.livepatch
+LIVEPATCH_LOCAL := xen_local_symbols.livepatch
LIVEPATCHES += $(LIVEPATCH)
LIVEPATCHES += $(LIVEPATCH_BYE)
LIVEPATCHES += $(LIVEPATCH_REPLACE)
LIVEPATCHES += $(LIVEPATCH_NOP)
+LIVEPATCHES += $(LIVEPATCH_LOCAL)
LIVEPATCH_DEBUG_DIR ?= $(DEBUG_DIR)/xen-livepatch
@@ -109,5 +111,13 @@ $(LIVEPATCH_NOP): xen_nop.o
$(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
$(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
+xen_local_symbols.o: config.h livepatch_depends.h
+
+.PHONY: $(LIVEPATCH_LOCAL)
+$(LIVEPATCH_LOCAL): xen_hello_world_func.o xen_local_symbols.o
+ $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_LOCAL) $^
+ $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
+ $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@
+
.PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
$(LIVEPATCH_LOCAL)
diff --git a/xen/test/livepatch/xen_local_symbols.c
b/xen/test/livepatch/xen_local_symbols.c
new file mode 100644
index 00..448c489818
--- /dev/null
+++ b/xen/test/livepatch/xen_local_symbols.c
@@ -0,0 +1,53 @@
+/*
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include "config.h"
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "livepatch_depends.h"
+
+/* Same name as in xen_hello_world */
+static const char hello_world_patch_this_fnc[] = "xen_extra_version";
+extern const char *xen_hello_world(void);
+
+/*
+ * The hooks are static here (LOCAL) and also in xen_hello_world.c
+ * and their name is exactly the same.
+ */
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook unloaded.\n");
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+struct livepatch_func __section(".livepatch.funcs")
livepatch_xen_local_symbols = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.name = hello_world_patch_this_fnc,
+.new_addr = xen_hello_world,
+.old_addr = xen_extra_version,
+.new_size = NEW_CODE_SZ,
+.old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 02/17] livepatch: Tighten alignment checks.
The ELF specification mentions nothing about the sh_size being
modulo the sh_addralign. Only that sh_addr MUST be aligned on
sh_addralign if sh_addralign is not zero or one.
We on loading did not take this in-to account so this patch adds
a check on the ELF file as it is being parsed.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial patch
v2: Drop the check when loading it in memory
Add check for alignment being anything but power of two (ignoring 0, and 1)
Change dprintk to include hex values and print addr not size.
v3: Change the two checks to be per Jan's recommendations.
---
xen/common/livepatch_elf.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index b69e2718dd..7839913ff5 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,19 @@ static int elf_resolve_sections(struct livepatch_elf *elf,
const void *data)
delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past
end");
return -EINVAL;
}
+else if ( sec[i].sec->sh_addralign &&
+ sec[i].sec->sh_addr % sec[i].sec->sh_addralign )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] addr
(%#"PRIxElfAddr") is not aligned properly (%#"PRIxElfAddr")\n",
+elf->name, i, sec[i].sec->sh_addr,
sec[i].sec->sh_addralign);
+return -EINVAL;
+}
+else if ( sec[i].sec->sh_addralign & (sec[i].sec->sh_addralign - 1) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Section [%u] alignment
(%#"PRIxElfAddr") is not supported\n",
+elf->name, i, sec[i].sec->sh_addralign);
+return -EOPNOTSUPP;
+}
else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
sec[i].sec->sh_type == SHT_NOBITS &&
sec[i].sec->sh_size > LIVEPATCH_MAX_SIZE )
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.
This surfaced due to "xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned." which switched to a different way of including the build-id. Each livepatch ends with a global: 30: 1 OBJECT GLOBAL HIDDEN 7 note_depends which will cause collision when loading. One attempted solution was to add in the Makefile stanza: @sed -i '/unsigned/static unsinged/' $@ But that resulted in the note_depends being omitted from the livepatch (as it was static and not used) which meant we would not have an .livepatch_depends section which we require. The solution to this is to remove the symbol via the --strip-symbols after generating the livepatch. However that fails as note_depends is in use by .rel.debug_info: Relocation section '.rel.debug_info' at offset 0x151c contains 113 entries: Offset InfoTypeSym.Value Sym. Name .. 0625 1e02 R_ARM_ABS32 note_depends And the solution to that is to also slap on --strip-debug which removes various .debug* sections (which livepatch ignores anyhow): .debug_aranges, .debug_info, .debug_abbrev, .debug_line, .debug_frame, .debug_str, and their .rel.* sections. And that will remove that. Alternatively we could also use --localize-symbol so that note_depends is not globally visible. But that won't help as hypervisor treats both local and global symbols as global when resolving them. (This is fixed in "livepatch: Add local and global symbol resolution." but that patch is stuck in limbo). Signed-off-by: Konrad Rzeszutek Wilk --- v3: First version --- xen/test/livepatch/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile index 89ad89dfd5..9e73861732 100644 --- a/xen/test/livepatch/Makefile +++ b/xen/test/livepatch/Makefile @@ -53,6 +53,7 @@ xen_hello_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH) $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^ + $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@ # # This target is only accessible if CONFIG_LIVEPATCH is defined, which @@ -88,18 +89,21 @@ xen_bye_world.o: config.h hello_world_livepatch_depends.h .PHONY: $(LIVEPATCH_BYE) $(LIVEPATCH_BYE): xen_bye_world_func.o xen_bye_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_BYE) $^ + $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@ xen_replace_world.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_REPLACE) $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^ + $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@ xen_nop.o: config.h livepatch_depends.h .PHONY: $(LIVEPATCH_NOP) $(LIVEPATCH_NOP): xen_nop.o $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^ + $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@ .PHONY: livepatch livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP) -- 2.13.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3] Livepatching patch set for 4.10
Hey, As I was trying to port livepatch-build-tools.git to work under ARM32 and ARM64 (still ongoing, if somebody wants to help/take over would appreciate it) I found some inconsistencies compared to the x86 and test-cases: - The .livepatch.funcs in the test-cases are in RW section but the livepatch-build-tools puts them in the RO sections. That works on x86 as arch_livepatch_quiesce turns of WP globally during the livepatching. But not on ARM.. and to make it work there I ended up using the vmap functionality. Which then I made common on x86 as well (so no more CR4 mucking). This meant however meant mucking with x86 code page walker to have a do_page_walk functionality. - Cross compiling ARM32 introduces subtle alignment issues. Mainly both .altinstructions and .livepatch.depends end up with the wrong alingment and the hypervisor blows up. Both fixes are in the patchset. I am also including in this patchset: - Declare the livepatch supported on x86 (but not ARM). It has latest feedback from Andrew and George (I hope!) - Post the local/global symbol patchset functionality. Only Jan had commented and I would appreciate other folks feedback - perhaps folks have better ideas on this? Lastly, I tested this on ARM32 (Cubietruck), ARM64 (HiKey960) and on x86. All looked good until I enabled CONFIG_DEBUG_SCRUB - which is reported in: https://lists.xen.org/archives/html/xen-devel/2017-09/msg01147.html Patches are in git://xenbits.xen.org/people/konradwilk/xen.git staging-for-4.10.v3 docs/features/livepatch.pandoc | 106 docs/misc/livepatch.markdown | 4 + xen/arch/arm/arm32/livepatch.c | 33 - xen/arch/arm/arm64/livepatch.c | 17 ++- xen/arch/arm/livepatch.c | 49 +--- xen/arch/arm/xen.lds.S | 2 - xen/arch/x86/livepatch.c | 36 -- xen/arch/x86/x86_64/mm.c | 33 +++-- xen/arch/x86/xen.lds.S | 1 - xen/common/Kconfig | 4 +- xen/common/livepatch.c | 219 + xen/common/livepatch_elf.c | 13 ++ xen/include/asm-arm/alternative.h | 4 + xen/include/asm-arm/livepatch.h| 6 - xen/include/asm-x86/alternative.h | 1 + xen/include/asm-x86/mm.h | 1 + xen/include/xen/elfstructs.h | 2 + xen/include/xen/livepatch.h| 23 +++- xen/include/xen/livepatch_elf.h| 7 ++ xen/test/livepatch/Makefile| 76 +++- xen/test/livepatch/xen_bye_world.c | 1 + xen/test/livepatch/xen_hello_world.c | 1 + xen/test/livepatch/xen_local_symbols.c | 53 xen/test/livepatch/xen_nop.c | 1 + xen/test/livepatch/xen_replace_world.c | 1 + 25 files changed, 521 insertions(+), 173 deletions(-) Konrad Rzeszutek Wilk (16): livepatch: Expand check for safe_for_reapply if livepatch has only .rodata. livepatch: Tighten alignment checks. livepatch: Include sizes when an mismatch occurs xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong text alignment. alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections. xen/livepatch/x86/arm32: Force .livepatch.depends section to be uint32_t aligned. livepatch/arm/x86: Strip note_depends symbol from test-cases. livepatch/tests: Make sure all .livepatch.funcs sections are read-only livepatch/arm[32,64]: Modify livepatch_funcs livepatch/x86/arm[32,64]: Use common vmap code for applying. livepatch/x86/arm[32,64]: Unify arch_livepatch_revert livepatch: Expand spin_debug_disable in [apply|revert]_payload livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn livepatch/x86/arm: Utilize the arch_livepatch_lookup_mfn livepatch: Add local and global symbol resolution. livepatch: Add xen_local_symbols test-case Ross Lagerwall (1): livepatch: Declare live patching as a supported feature ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 03/17] livepatch: Include sizes when an mismatch occurs
If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.
Also make it more natural by having "Multiples" in the warning.
Also fix one case where we would fail if the size of the .ex_table
was being zero - but that is OK.
Signed-off-by: Konrad Rzeszutek Wilk
---
v1: Initial version
v2: - Changed to 'Multiple' per Jan's recommendation.
- Folded the checks in 'check_size' function and removed all the other
parts of code that checked for this.
v3: - Drop bool zero_ok
- Return bool instead of int (and invert the return condition)
- Change name of the function to be more clear
---
xen/common/livepatch.c | 46 +---
xen/include/xen/elfstructs.h | 2 ++
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index a1f54c42d3..c6ee95fbcf 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -460,6 +460,22 @@ static int secure_payload(struct payload *payload, struct
livepatch_elf *elf)
return rc;
}
+static bool section_ok(const struct livepatch_elf *elf,
+ const struct livepatch_elf_sec *sec, size_t sz)
+{
+if ( !elf || !sec )
+return false;
+
+if ( sec->sec->sh_size % sz )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size %"PRIuElfWord" of %s
(must be multiple of %zu)\n",
+elf->name, sec->sec->sh_size, sec->name, sz);
+return false;
+}
+
+return true;
+}
+
static int check_special_sections(const struct livepatch_elf *elf)
{
unsigned int i;
@@ -509,12 +525,8 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_FUNC);
ASSERT(sec);
-if ( sec->sec->sh_size % sizeof(*payload->funcs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of
"ELF_LIVEPATCH_FUNC"!\n",
-elf->name);
+if ( !section_ok(elf, sec, sizeof(*payload->funcs)) )
return -EINVAL;
-}
payload->funcs = sec->load_addr;
payload->nfuncs = sec->sec->sh_size / sizeof(*payload->funcs);
@@ -556,7 +568,7 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
if ( sec )
{
-if ( sec->sec->sh_size % sizeof(*payload->load_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->load_funcs)) )
return -EINVAL;
payload->load_funcs = sec->load_addr;
@@ -566,7 +578,7 @@ static int prepare_payload(struct payload *payload,
sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.unload");
if ( sec )
{
-if ( sec->sec->sh_size % sizeof(*payload->unload_funcs) )
+if ( !section_ok(elf, sec, sizeof(*payload->unload_funcs)) )
return -EINVAL;
payload->unload_funcs = sec->load_addr;
@@ -637,12 +649,8 @@ static int prepare_payload(struct payload *payload,
if ( !sec )
continue;
-if ( sec->sec->sh_size % sizeof(*region->frame[i].bugs) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of
.bug_frames.%u!\n",
-elf->name, i);
+if ( !section_ok(elf, sec, sizeof(*region->frame[i].bugs)) )
return -EINVAL;
-}
region->frame[i].bugs = sec->load_addr;
region->frame[i].n_bugs = sec->sec->sh_size /
@@ -655,12 +663,8 @@ static int prepare_payload(struct payload *payload,
#ifdef CONFIG_HAS_ALTERNATIVE
struct alt_instr *a, *start, *end;
-if ( sec->sec->sh_size % sizeof(*a) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Size of .alt_instr is not
multiple of %zu!\n",
-elf->name, sizeof(*a));
+if ( !section_ok(elf, sec, sizeof(*a)) )
return -EINVAL;
-}
start = sec->load_addr;
end = sec->load_addr + sec->sec->sh_size;
@@ -692,14 +696,8 @@ static int prepare_payload(struct payload *payload,
#ifdef CONFIG_HAS_EX_TABLE
struct exception_table_entry *s, *e;
-if ( !sec->sec->sh_size ||
- (sec->sec->sh_size % sizeof(*region->ex)) )
-{
-dprintk(XENLOG_ERR, LIVEPATCH "%s: Wrong size of .ex_table
(exp:%lu vs %lu)!\n",
-elf->name, sizeof(*region->ex),
-sec->sec->sh_size);
+if ( !section_ok(elf, sec, sizeof(*region->ex)) )
return -EINVAL;
-}
s = sec->load_addr;
e = sec->load_addr + sec->sec->s
[Xen-devel] [PATCH v3 09/17] livepatch/arm[32, 64]: Modify livepatch_funcs
This was found when porting livepatch-build-tools to ARM64/32.
When livepatch-build-tools are built (and test-case thanks to:
livepatch/tests: Make sure all .livepatch.funcs sections are read-only)
the .livepatch.funcs are in read-only section.
However the hypervisor uses the 'opaque' for its own purpose, that
is stashing the original code. But the .livepatch_funcs section is
in the RO vmap area so on ARM[32,64] we get a fault.
On x86 the same protection is in place. In 'arch_livepatch_quiesce'
we disable WP to allow changes to read-only pages (and in arch_live_resume
we enable the WP protection).
On ARM[32,64] we do not have the luxury of a global register that can
be changed after boot. In lieu of that we use the vmap to create
a temporary virtual address in which we can use instead.
To do this we need to stash during livepatch: vmap of the hypervisor
code, vmap of the .livepatch_funcs (vmap comes in page aligned virtual
addresses), offset in the vmap (in case it is not nicely aligned), and
the original first livepatch_funcs to figure out the index.
Equipped with that we can patch livepatch functions which have
.livepatch_funcs in rodata section.
An alternative is to add the 'W' flag during loading of the
.livepatch_funcs which would result the section being in writeable
region from the gecko.
Note that this vmap solution could be extended to x86 as well.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/arch/arm/arm32/livepatch.c | 11 ++---
xen/arch/arm/arm64/livepatch.c | 11 ++---
xen/arch/arm/livepatch.c| 52 -
xen/arch/x86/livepatch.c| 2 +-
xen/common/livepatch.c | 5 ++--
xen/include/asm-arm/livepatch.h | 13 ---
xen/include/xen/livepatch.h | 2 +-
7 files changed, 71 insertions(+), 25 deletions(-)
diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 10887ace81..d793ebcaad 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -16,18 +16,23 @@ void arch_livepatch_apply(struct livepatch_func *func)
uint32_t insn;
uint32_t *new_ptr;
unsigned int i, len;
+struct livepatch_func *f;
BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
-ASSERT(vmap_of_xen_text);
+ASSERT(livepatch_vmap.text);
len = livepatch_insn_len(func);
if ( !len )
return;
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs +
livepatch_vmap.offset) + i;
+
/* Save old ones. */
-memcpy(func->opaque, func->old_addr, len);
+memcpy(f->opaque, func->old_addr, len);
if ( func->new_addr )
{
@@ -56,7 +61,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
else
insn = 0xe1a0; /* mov r0, r0 */
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
len = len / sizeof(uint32_t);
/* PATCH! */
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 2728e2a125..662bedabc3 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -20,18 +20,23 @@ void arch_livepatch_apply(struct livepatch_func *func)
uint32_t insn;
uint32_t *new_ptr;
unsigned int i, len;
+struct livepatch_func *f;
BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
-ASSERT(vmap_of_xen_text);
+ASSERT(livepatch_vmap.text);
len = livepatch_insn_len(func);
if ( !len )
return;
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs +
livepatch_vmap.offset) + i;
+
/* Save old ones. */
-memcpy(func->opaque, func->old_addr, len);
+memcpy(f->opaque, func->old_addr, len);
if ( func->new_addr )
insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
@@ -43,7 +48,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
/* Verified in livepatch_verify_distance. */
ASSERT(insn != AARCH64_BREAK_FAULT);
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
len = len / sizeof(uint32_t);
/* PATCH! */
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3e53524365..2f9ae8e61e 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
@@ -16,14 +17,18 @@
#undef virt_to_mfn
#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
-void *vmap_of_xen_text;
+struct livepatch_vmap_stash livepatch_vmap;
-int arch_livepatch_quie
[Xen-devel] [PATCH v3 13/17] livepatch: Expand spin_debug_disable in [apply|revert]_payload
Under ARM64 the vmap calls were all done with IRQs disabled which
didn't trip the spinlock debug check (as seen on x86):
livepatch.c:1330: livepatch: xen_hello_world: timeout is 3000ns
livepatch.c:1437: livepatch: xen_hello_world: CPU3 - IPIing the other 3 CPUs
Applying xen_hello_world... (XEN) livepatch: xen_hello_world: Applying 1
functions
Xen BUG at spinlock.c:47
..snip..
[] spinlock.c#check_lock+0x3e/0x44
[] _spin_lock+0x11/0x4a
[] __vmap+0x78/0x381
[] livepatch.c#livepatch_quiesce+0xc4/0x1bf
[] livepatch.c#apply_payload+0x3a/0x102
[] check_for_livepatch_work+0x1f3/0x390
[] domain.c#continue_idle_domain+0x1b/0x22
But are definitly the case on x86 - so we expand the scope
of the spin_debug_disable.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/common/livepatch.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 93083cda1a..2f5ee1ae75 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1154,22 +1154,22 @@ static int apply_payload(struct payload *data)
printk(XENLOG_INFO LIVEPATCH "%s: Applying %u functions\n",
data->name, data->nfuncs);
+/*
+ * Since we are running with IRQs disabled and the hooks may call common
+ * code - which expects certain spinlocks to run with IRQs enabled - we
+ * temporarily disable the spin locks IRQ state checks.
+ */
+spin_debug_disable();
rc = livepatch_quiesce(data->funcs, data->nfuncs);
if ( rc )
{
+spin_debug_enable();
printk(XENLOG_ERR LIVEPATCH "%s: unable to quiesce!\n", data->name);
return rc;
}
-/*
- * Since we are running with IRQs disabled and the hooks may call common
- * code - which expects certain spinlocks to run with IRQs enabled - we
- * temporarily disable the spin locks IRQ state checks.
- */
-spin_debug_disable();
for ( i = 0; i < data->n_load_funcs; i++ )
data->load_funcs[i]();
-spin_debug_enable();
ASSERT(!local_irq_is_enabled());
@@ -1177,6 +1177,7 @@ static int apply_payload(struct payload *data)
arch_livepatch_apply(&data->funcs[i]);
livepatch_revive();
+spin_debug_enable();
/*
* We need RCU variant (which has barriers) in case we crash here.
@@ -1195,9 +1196,16 @@ static int revert_payload(struct payload *data)
printk(XENLOG_INFO LIVEPATCH "%s: Reverting\n", data->name);
+/*
+ * Since we are running with IRQs disabled and the hooks may call common
+ * code - which expects certain spinlocks to run with IRQs enabled - we
+ * temporarily disable the spin locks IRQ state checks.
+ */
+spin_debug_disable();
rc = livepatch_quiesce(data->funcs, data->nfuncs);
if ( rc )
{
+spin_debug_enable();
printk(XENLOG_ERR LIVEPATCH "%s: unable to quiesce!\n", data->name);
return rc;
}
@@ -1205,19 +1213,13 @@ static int revert_payload(struct payload *data)
for ( i = 0; i < data->nfuncs; i++ )
livepatch_revert(&data->funcs[i]);
-/*
- * Since we are running with IRQs disabled and the hooks may call common
- * code - which expects certain spinlocks to run with IRQs enabled - we
- * temporarily disable the spin locks IRQ state checks.
- */
-spin_debug_disable();
for ( i = 0; i < data->n_unload_funcs; i++ )
data->unload_funcs[i]();
-spin_debug_enable();
ASSERT(!local_irq_is_enabled());
livepatch_revive();
+spin_debug_enable();
/*
* We need RCU variant (which has barriers) in case we crash here.
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 11/17] livepatch/x86/arm[32, 64]: Use common vmap code for applying.
Patch titled "livepatch/arm[32,64]: Modify livepatch_funcs" added
the infrastructure on ARM [32,64] to use vmap as way to
map read-only regions. On x86 we use a global register.
But there is nothing wrong with using on x86 the same method
as on ARM[32,64] - which is exactly what this patch does.
As result the common code for setting up vmap is now
done in livepatch_quiesce and there is no arch specific
arch_livepatch_quiesce anymore.
The same treatment is applied to arch_livepatch_revive albeit
we still need arch specific code for ARM (to clear the i-cache).
Interestingly the arch_livepatch_revert looks almost the same
on x86 and ARM. See 'livepatch/x86/arm[32,64]: Unify arch_livepatch_revert'
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/arch/arm/livepatch.c| 64
xen/arch/x86/livepatch.c| 32 +---
xen/common/livepatch.c | 81 +++--
xen/include/asm-arm/livepatch.h | 13 ---
xen/include/xen/livepatch.h | 13 +++
5 files changed, 108 insertions(+), 95 deletions(-)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 2f9ae8e61e..2debb5368c 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -17,57 +17,6 @@
#undef virt_to_mfn
#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
-struct livepatch_vmap_stash livepatch_vmap;
-
-int arch_livepatch_quiesce(struct livepatch_func *funcs, unsigned int nfuncs)
-{
-mfn_t text_mfn, rodata_mfn;
-void *vmap_addr;
-unsigned int text_order;
-unsigned long va = (unsigned long)(funcs);
-unsigned int offs = va & (PAGE_SIZE - 1);
-unsigned int size = PFN_UP(offs + nfuncs * sizeof(*funcs));
-
-if ( livepatch_vmap.text || livepatch_vmap.funcs )
-return -EINVAL;
-
-text_mfn = virt_to_mfn(_start);
-text_order = get_order_from_bytes(_end - _start);
-
-/*
- * The text section is read-only. So re-map Xen to be able to patch
- * the code.
- */
-vmap_addr = __vmap(&text_mfn, 1U << text_order, 1, 1, PAGE_HYPERVISOR,
- VMAP_DEFAULT);
-
-if ( !vmap_addr )
-{
-printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of hypervisor!
(order=%u)\n",
- text_order);
-return -ENOMEM;
-}
-
-livepatch_vmap.text = vmap_addr;
-livepatch_vmap.offset = offs;
-
-rodata_mfn = virt_to_mfn(va & PAGE_MASK);
-vmap_addr = __vmap(&rodata_mfn, size, 1, 1, PAGE_HYPERVISOR,
VMAP_DEFAULT);
-if ( !vmap_addr )
-{
-printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of livepatch_funcs!
(mfn=%"PRI_mfn", size=%u)\n",
- mfn_x(rodata_mfn), size);
-vunmap(livepatch_vmap.text);
-livepatch_vmap.text = NULL;
-return -ENOMEM;
-}
-
-livepatch_vmap.funcs = vmap_addr;
-livepatch_vmap.va = funcs;
-
-return 0;
-}
-
void arch_livepatch_revive(void)
{
/*
@@ -75,19 +24,6 @@ void arch_livepatch_revive(void)
* arch_livepatch_[apply|revert].
*/
invalidate_icache();
-
-if ( livepatch_vmap.text )
-vunmap(livepatch_vmap.text);
-
-livepatch_vmap.text = NULL;
-
-if ( livepatch_vmap.funcs )
-vunmap(livepatch_vmap.funcs);
-
-livepatch_vmap.funcs = NULL;
-
-livepatch_vmap.va = NULL;
-livepatch_vmap.offset = 0;
}
int arch_livepatch_verify_func(const struct livepatch_func *func)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 8522fcbd36..5273f5a176 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -14,18 +14,9 @@
#include
#include
-int arch_livepatch_quiesce(struct livepatch_func *func, unsigned int nfuncs)
-{
-/* Disable WP to allow changes to read-only pages. */
-write_cr0(read_cr0() & ~X86_CR0_WP);
-
-return 0;
-}
-
void arch_livepatch_revive(void)
{
-/* Reinstate WP. */
-write_cr0(read_cr0() | X86_CR0_WP);
+/* Nothing to do. */
}
int arch_livepatch_verify_func(const struct livepatch_func *func)
@@ -54,14 +45,21 @@ void noinline arch_livepatch_apply(struct livepatch_func
*func)
{
uint8_t *old_ptr;
uint8_t insn[sizeof(func->opaque)];
-unsigned int len;
+unsigned int i, len;
+struct livepatch_func *f;
-old_ptr = func->old_addr;
+/* Recompute using the vmap. */
+old_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
len = livepatch_insn_len(func);
if ( !len )
return;
-memcpy(func->opaque, old_ptr, len);
+/* Index in the vmap region. */
+i = livepatch_vmap.va - func;
+f = (struct livepatch_func *)(livepatch_vmap.funcs +
livepatch_vmap.offset) + i;
+
+memcpy(f->opaque, old_ptr, len);
+
if ( func->new_addr )
{
int32_t val;
@@ -85,7 +83,13 @@ void noinline arch_livepatch_apply(struct livepatch_func
*func)
*/
void noinline arch_l
[Xen-devel] [PATCH v3 12/17] livepatch/x86/arm[32, 64]: Unify arch_livepatch_revert
The arch_livepatch_revert is very similar between the platforms.
Lets unify it as much as possible.
Signed-off-by: Konrad Rzeszutek Wilk
---
xen/arch/arm/livepatch.c| 10 +-
xen/arch/x86/livepatch.c| 10 ++
xen/common/livepatch.c | 14 +-
xen/include/xen/livepatch.h | 3 +--
4 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 2debb5368c..e1d5d58f97 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -39,16 +39,8 @@ int arch_livepatch_verify_func(const struct livepatch_func
*func)
return 0;
}
-void arch_livepatch_revert(const struct livepatch_func *func)
+void arch_livepatch_revert(uint32_t *new_ptr, unsigned int len)
{
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
-
clean_and_invalidate_dcache_va_range(new_ptr, len);
}
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 5273f5a176..12287d445f 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -81,15 +81,9 @@ void noinline arch_livepatch_apply(struct livepatch_func
*func)
* "noinline" to cause control flow change and thus invalidate I$ and
* cause refetch after modification.
*/
-void noinline arch_livepatch_revert(const struct livepatch_func *func)
+void noinline arch_livepatch_revert(uint32_t *new_ptr, unsigned int len)
{
-uint32_t *new_ptr;
-unsigned int len;
-
-new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
-
-len = livepatch_insn_len(func);
-memcpy(new_ptr, func->opaque, len);
+/* Nothing to do. */
}
/*
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index eb7d4098fd..93083cda1a 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1128,6 +1128,18 @@ static void livepatch_revive(void)
livepatch_vmap.offset = 0;
}
+static void livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int len;
+
+new_ptr = func->old_addr - (void *)_start + livepatch_vmap.text;
+
+len = livepatch_insn_len(func);
+memcpy(new_ptr, func->opaque, len);
+
+arch_livepatch_revert(new_ptr, len);
+}
/*
* The following functions get the CPUs into an appropriate state and
* apply (or revert) each of the payload's functions. This is needed
@@ -1191,7 +1203,7 @@ static int revert_payload(struct payload *data)
}
for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_revert(&data->funcs[i]);
+livepatch_revert(&data->funcs[i]);
/*
* Since we are running with IRQs disabled and the hooks may call common
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 1659ffcdf0..065c1a323a 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -117,11 +117,10 @@ extern struct livepatch_vmap_stash livepatch_vmap;
* These functions are called around the critical region patching live code,
* for an architecture to take make appropratie global state adjustments.
*/
-int arch_livepatch_quiesce(struct livepatch_func *func, unsigned int nfuncs);
void arch_livepatch_revive(void);
void arch_livepatch_apply(struct livepatch_func *func);
-void arch_livepatch_revert(const struct livepatch_func *func);
+void arch_livepatch_revert(uint32_t *new_ptr, unsigned int len);
void arch_livepatch_post_action(void);
void arch_livepatch_mask(void);
--
2.13.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
