Re: [Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

On Fri, Jul 22, 2016 at 02:24:44PM -0700, Luis R. Rodriguez wrote: > diff --git a/tools/objtool/special.c b/tools/objtool/special.c > index bff8abb3a4aa..f0ad369f994b 100644 > --- a/tools/objtool/special.c > +++ b/tools/objtool/special.c > @@ -26,6 +26,10 @@ > #include "special.h" > #include

Re: [Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

On Sat, Jul 23, 2016 at 12:26:54AM +0200, Luis R. Rodriguez wrote: > On Fri, Jul 22, 2016 at 04:49:45PM -0500, Josh Poimboeuf wrote: > > On Fri, Jul 22, 2016 at 02:24:44PM -0700, Luis R. Rodriguez wrote: > > > diff --git a/tools/objtool/special.c b/tools/objtool/special.c > > > index

Re: [Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

On Fri, Jul 22, 2016 at 04:49:45PM -0500, Josh Poimboeuf wrote: > On Fri, Jul 22, 2016 at 02:24:44PM -0700, Luis R. Rodriguez wrote: > > diff --git a/tools/objtool/special.c b/tools/objtool/special.c > > index bff8abb3a4aa..f0ad369f994b 100644 > > --- a/tools/objtool/special.c > > +++

Re: [Xen-devel] [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/22/2016 07:45 PM, Roger Pau Monné wrote: > On Fri, Jul 22, 2016 at 05:43:32PM +0800, Bob Liu wrote: >> >> On 07/22/2016 05:34 PM, Roger Pau Monné wrote: >>> On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote: On 07/22/2016 03:45 PM, Roger Pau Monné wrote: > On Thu, Jul

Re: [Xen-devel] [RFC v3 05/13] sections.h: add sections header to collect all section info

On Fri, Jul 22, 2016 at 10:37:16PM +0100, James Hogan wrote: > Hi Luis, > > On Friday 22 July 2016 14:24:39 Luis R. Rodriguez wrote: > > arch/alpha/include/asm/sections.h | 6 + > > arch/arm64/include/asm/sections.h | 6 + > > arch/avr32/include/asm/sections.h | 6 + > >

Re: [Xen-devel] [RFC v3 05/13] sections.h: add sections header to collect all section info

Hi Luis, On Friday 22 July 2016 14:24:39 Luis R. Rodriguez wrote: > arch/alpha/include/asm/sections.h | 6 + > arch/arm64/include/asm/sections.h | 6 + > arch/avr32/include/asm/sections.h | 6 + > arch/cris/include/asm/sections.h | 6 + >

Re: [Xen-devel] [RFC v3 02/13] dell-smo8800: include uaccess.h

On Friday 22 July 2016 23:24:36 Luis R. Rodriguez wrote: > sections.h is currently included and it provides dell-smo8800 > with what it needs, an upcoming change will decouple uaccess.h > from sections.h. This driver needs to explicitly require uaccess.h > before this change. > > v3: new to this

[Xen-devel] [RFC v3 04/13] sections.h: guard against asm and linker script

We'll later add some generic helpers for use in the linker scripts and some generic asm code for all architectures. To do that we'll first need to guard against linker script and asm code. On x86 uaccess.h has a struct which is used as part of a section, move that to sections.h as we otherwise

[Xen-devel] [RFC v3 03/13] scripts/module-common.lds: enable generation

scripts/module-common.lds is currently pretty static, in the future this may change and we will want access to kernel macros to help expands certain areas. To get access to use macros we need to generate module-common.lds from module-common.lds.S, for now though only enable the generation. We'll

[Xen-devel] [RFC v3 13/13] kprobes: port blacklist kprobes to linker table

kprobe makes use of two sections, the one dealing with the actual kprobes was recently ported using the standard section range API. The blacklist functionality of kprobes is still using a custom section and declaring its custom section using the linker script as follows: type Linux-section

[Xen-devel] [RFC v3 05/13] sections.h: add sections header to collect all section info

Linux makes extensive use of custom ELF header sections, documentation for these are well scatterred. Unify this documentation in a central place and provide helpers to build custom Linux sections. We are now generalizing sections.h in code to enable avoiding modifying the linker when we want to

[Xen-devel] [RFC v3 11/13] dynamic_debug: port to use linker tables

This removes the custom vmlinux.lds.h hacks and uses the generalized solution for .data (SECTION_DATA) entries. This is much more potential for further fine tuning here though in the future. For instance, linker tables enable an extra postfix for order level annotations, this could easily be used

[Xen-devel] [RFC v3 12/13] kprobes: port .kprobes.text to section range

kprobe makes use of two custom sections, each custom section is folded into one of the standard Linux sections types as follows, it currently relies on the linker script to fold the custom section onto the respective Linux section: type Linux-section custom section name begin

[Xen-devel] [RFC v3 02/13] dell-smo8800: include uaccess.h

sections.h is currently included and it provides dell-smo8800 with what it needs, an upcoming change will decouple uaccess.h from sections.h. This driver needs to explicitly require uaccess.h before this change. v3: new to this series -- needed due to collateral of the split of old linker

[Xen-devel] [RFC v3 06/13] ranges.h: add helpers to build and identify Linux section ranges

Section ranges are on one of the types of custom sections types used in Linux. This provides a series of helpers for defining them and using them. Most importantly this also enables us to avoid modifying the linker script when we add new section range. It turns out a lot of custom sections are

[Xen-devel] [RFC v3 00/13] linux: generalize sections, ranges and linker tables

was already dealt with through that tree. Thanks to hpa for tons of feedback. Should you need it, the code here is also available on my linux-next 20160722-linker-table-v3-try2 branch on kernel.org [2]. Lastly, ranges and table development go under copyleft-next, Rusty recently asked for code to go in prior

[Xen-devel] [RFC v3 08/13] firmware/Makefile: force recompilation if makefile changes

If you modify the target asm we currently do not force the recompilation of the firmware files. The target asm is in the firmware/Makefile, peg this file as a dependency to require re-compilation of firmware targets when the asm changes. v3: introduced in this series Signed-off-by: Luis R.

[Xen-devel] [RFC v3 07/13] tables.h: add linker table support

A linker table is a data structure that is stitched together from items in multiple object files. Linux has historically implicitly used linker tables for ages, however they were all built in an adhoc manner which requires linker script modifications, per architecture. This adds a general linker

[Xen-devel] [RFC v3 10/13] jump_label: port __jump_table to linker tables

Move the __jump_table from the a custom section solution to a generic solution, this avoiding extra vmlinux.lds.h customizations. This also demos the use of the .data (SECTION_DATA) linker table and of the shared asm call push_section_tbl(). Built-in kernel functionality was tested with

[Xen-devel] [RFC v3 09/13] firmware: port built-in section to linker table

This ports built-in firmware to use linker tables, this replaces the custom section solution with a generic solution. This also demos the use of the .rodata (SECTION_RO) linker tables. Tested with 0 built-in firmware, 1 and 2 built-in firmwares successfully. v3: o explicitly include tables.h as

[Xen-devel] [RFC v3 01/13] x86: remove LTO_REFERENCE_INITCALL()

The setup for LTO never made it upstream, and although this has some users, this is now really old stuff for a gcc 4.7 LTO problem. We know that at least LTO_REFERENCE_INITCALL() work around can be removed if LTO is not supported on v4.7 anymore. As per Andi the DISABLE_LTO and LTO_CFLAGS are

Re: [Xen-devel] [PATCH v3 1/4] tools: remove systemd xenstore socket definitions

On Fri, Jul 22, 2016 at 08:49:17PM +0200, Juergen Gross wrote: > On 22/07/16 18:31, Wei Liu wrote: > > Only skim-read this patch, will do proper review later. > > > > On Fri, Jul 22, 2016 at 05:09:28PM +0200, Juergen Gross wrote: > > [...] > >> CAMLprim value ocaml_launched_by_systemd(value

Re: [Xen-devel] [PATCH v3 1/4] tools: remove systemd xenstore socket definitions

On 22/07/16 18:31, Wei Liu wrote: > Only skim-read this patch, will do proper review later. > > On Fri, Jul 22, 2016 at 05:09:28PM +0200, Juergen Gross wrote: > [...] >> CAMLprim value ocaml_launched_by_systemd(value ignore) >> { >> -CAMLparam1(ignore); >> -CAMLlocal1(ret); >> +

Re: [Xen-devel] [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD

On Fri, Jul 22, 2016 at 01:45:05PM -0400, Boris Ostrovsky wrote: > On 07/22/2016 01:38 PM, Wei Liu wrote: > > On Fri, Jul 22, 2016 at 01:14:01PM -0400, Boris Ostrovsky wrote: > >> Current code incorrectly adds 1 to full register instead of > >> incrementing the field in bits 15:12. > >> > >>

Re: [Xen-devel] [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD

On 07/22/2016 01:38 PM, Wei Liu wrote: > On Fri, Jul 22, 2016 at 01:14:01PM -0400, Boris Ostrovsky wrote: >> Current code incorrectly adds 1 to full register instead of >> incrementing the field in bits 15:12. >> >> Signed-off-by: Boris Ostrovsky > Acked-by: Wei Liu

Re: [Xen-devel] [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD

On Fri, Jul 22, 2016 at 01:14:01PM -0400, Boris Ostrovsky wrote: > Current code incorrectly adds 1 to full register instead of > incrementing the field in bits 15:12. > > Signed-off-by: Boris Ostrovsky Acked-by: Wei Liu I trust your expertise

[Xen-devel] [PATCH] tools/libxc: Properly increment ApicIdCoreSize field on AMD

Current code incorrectly adds 1 to full register instead of incrementing the field in bits 15:12. Signed-off-by: Boris Ostrovsky --- tools/libxc/xc_cpuid_x86.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_cpuid_x86.c

Re: [Xen-devel] [PATCH v3 1/4] tools: remove systemd xenstore socket definitions

Only skim-read this patch, will do proper review later. On Fri, Jul 22, 2016 at 05:09:28PM +0200, Juergen Gross wrote: [...] > CAMLprim value ocaml_launched_by_systemd(value ignore) > { > - CAMLparam1(ignore); > - CAMLlocal1(ret); > + CAMLparam1(ignore); > + CAMLlocal1(ret);

[Xen-devel] Infrastructure Maintenance Window: July 25, 2016 from 8:00 - 10:00 UTC

Hi everyone, just a quick note that we will perform the following maintenance activities on Monady July 25, from 8:00 - 10:00 UTC. The following work will be performed: - OS Upgrade of bugs.xenproject.org to Debian Jessie (this will take 1-2 hours) Best Regards Lars

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 4:00 PM, Razvan Cojocaru wrote: On 07/22/2016 03:32 PM, Corneliu ZUZU wrote: Look @ hvm_do_resume(): 1. If you, as a toolstack user, get at sane step no. 6: "Uninitialize everything (no events are possible here because of steps 4-5)." 2. But just before you do that, a

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: Introduce alternative runtime patching

On 22/07/16 16:38, Konrad Rzeszutek Wilk wrote: + +origptr = ALT_ORIG_PTR(alt); +writeptr = origptr - (u32 *)_start + writemap; How about just using writeptr += ? I am not sure about your suggestion here. Regardless the Linux code, the origptr will not follow a pattern at

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: Introduce alternative runtime patching

> >>+ > >>+origptr = ALT_ORIG_PTR(alt); > >>+writeptr = origptr - (u32 *)_start + writemap; > > > >How about just using writeptr += ? > > I am not sure about your suggestion here. Regardless the Linux code, the > origptr will not follow a pattern at each iteration. So we have to

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: cpufeature: Provide an helper to check if a capability is supported

On Fri, Jul 22, 2016 at 04:31:13PM +0100, Julien Grall wrote: > Hi Konrad, > > On 22/07/16 15:18, Konrad Rzeszutek Wilk wrote: > >On Wed, Jul 20, 2016 at 04:25:55PM +0100, Julien Grall wrote: > >>diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c > >>index 7a1b56b..088625b 100644

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: cpufeature: Provide an helper to check if a capability is supported

Hi Konrad, On 22/07/16 15:18, Konrad Rzeszutek Wilk wrote: On Wed, Jul 20, 2016 at 04:25:55PM +0100, Julien Grall wrote: diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c index 7a1b56b..088625b 100644 --- a/xen/arch/arm/cpufeature.c +++ b/xen/arch/arm/cpufeature.c @@ -24,6

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: Introduce alternative runtime patching

On 22/07/16 15:15, Konrad Rzeszutek Wilk wrote: diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c new file mode 100644 index 000..d00f98e --- /dev/null +++ b/xen/arch/arm/alternative.c Hey! Hi Konrad, I've some comments, most of them are light. What I am concerned

[Xen-devel] [PATCH v3 4/4] tools: make xenstore domain easy configurable

Add configuration entries to sysconfig.xencommons for selection of the xenstore type (domain or daemon) and start the selected xenstore service via a script called from sysvinit or systemd. Signed-off-by: Juergen Gross --- V3: - remove check for running xenstore domain, as this

[Xen-devel] [PATCH v3 1/4] tools: remove systemd xenstore socket definitions

On a system with systemd the xenstore sockets are created via systemd. Remove the related configuration files in order to be able to decide at runtime whether the sockets should be created or not. This will enable Xen to start xenstore either via a daemon or via a stub domain. As the xenstore

[Xen-devel] [PATCH v3 3/4] tools: use pidfile for test if xenstored is running

Instead of trying to read xenstore via xenstore-read use the pidfile of xenstored for the test whether xenstored is running. This prepares support of xenstore domain, as trying to read xenstore will block for ever in case xenstore domain is started after trying to read. Signed-off-by: Juergen

[Xen-devel] [PATCH v3 0/4] tools: make xenstore domain/daemon configurable

Add a configuration option to /etc/sysconfig/xencommons to let the user configure whether he wants to start xenstore service as a daemon or as a stubdom. Changes in V3: - patch 1: re-add sd_notify() call - split up former patch 2 into 3 patches as requested by Ian Jackson - patch 4 (was 2):

[Xen-devel] [PATCH v3 2/4] tools: split out xenstored starting form xencommons

In order to prepare starting a xenstore domain split out the starting of the xenstore daemon from the xencommons script into a dedicated launch-xenstore script. Correct one error: don't remove old tdb files in background, as this could lead to very subtle races. A rerun of autogen.sh is

Re: [Xen-devel] "X86_PV_VCPU_MSRS record truncated" during domain restore

The patches (that are attached to "[PATCH RFC 0/4] Fix issues with zero-length records in migration v2") work! I patched locally qubes-builder to import your patches and recreate rpm files. These patches also work on Xen 4.6.1. Best regards, Massimo On 07/21/2016 10:53 AM, Andrew Cooper

Re: [Xen-devel] [PATCH 5/9] xen/arm: Provide macros to help creating workaround helpers

On Wed, Jul 20, 2016 at 8:43 AM, Julien Grall wrote: > Hi Konrad, > >>> For instance, the line bellow will create a workaround helper for >>> erratum #424242 which is enabled when the capability >>> ARM64_WORKAROUND_424242 is set and only available for ARM64: 42, eh? >>>

Re: [Xen-devel] [PATCH v5 0/7] xen/arm: Introduce alternative runtime patching for ARM64

On Wed, Jul 20, 2016 at 04:25:53PM +0100, Julien Grall wrote: > Hello, > > Some of the processor errata will require to modify code sequence. As those > modifications may impact the performance, they should only be enabled on > affected cores. Furthermore, Xen may also want to take advantage of >

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

Sure, I will continue to send revisions until it is approved upstream. On Jul 22, 2016 5:24 PM, "Quan Xu" wrote: > Anthony, thanks for your explaination. > IMO, patch 1 and patch 2 need your detailed review.. IMO the reset > patches are good in general.. > Emil, if patch 1

Re: [Xen-devel] [PATCH v5 4/7] xen/arm: Document the errata implemented in Xen

On Wed, Jul 20, 2016 at 04:25:57PM +0100, Julien Grall wrote: > The new document will help to keep track of each erratum Xen is able to > handle. > > The text is based on the Linux doc in Documents/arm64/silicon-errata.txt. > > Also list the current errata that Xen is aware of. > >

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

Anthony, thanks for your explaination.IMO, patch 1  and patch 2 need your detailed review.. IMO the reset patches are good in general..Emil, if patch 1 / patch 2 are reviewed from anthony, could you send out v10? :) i know it's not an easy task, thanks in advence!! Quan On Mon, 18 Jul 2016 

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: Detect silicon revision and set cap bits accordingly

On Wed, Jul 20, 2016 at 04:25:56PM +0100, Julien Grall wrote: > After each CPU has been started, we iterate through a list of CPU > errata to detect CPUs which need from hypervisor code patches. > > For each bug there is a function which check if that a particular CPU is s/check/checks/ >

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: Introduce alternative runtime patching

> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c > new file mode 100644 > index 000..d00f98e > --- /dev/null > +++ b/xen/arch/arm/alternative.c Hey! I've some comments, most of them are light. What I am concerned most is the difference between comments in the header vs

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: cpufeature: Provide an helper to check if a capability is supported

On Wed, Jul 20, 2016 at 04:25:55PM +0100, Julien Grall wrote: > The CPU capabilities will be set depending on the value found in the CPU > registers. This patch provides a generic to go through a set of capabilities > and find which one should be enabled. > > The parameter "info" is used to

Re: [Xen-devel] [PATCH 01/19] xen: Create a new file xen_pvdev.c

    sorry for the bad format from web email, and later review (neo training in new company)..    patch 6 -- patch 12, rename * patch,  are good to me.  Quan   --From:Emil Condrea Time:2016 Jul 19 (Tue)

[Xen-devel] [qemu-mainline baseline-only test] 66672: regressions - FAIL

This run is configured for baseline tests only. flight 66672 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66672/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 5 xen-build

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On 22/07/16 12:05, Sergej Proskurin wrote: On 07/22/2016 12:38 PM, Julien Grall wrote: On 22/07/16 11:39, Sergej Proskurin wrote: On 07/22/2016 12:26 PM, Julien Grall wrote: On 22/07/16 11:16, Sergej Proskurin wrote: Hi Julien, Hello, On 07/22/2016 11:18 AM, Julien Grall wrote:

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 07/22/2016 03:32 PM, Corneliu ZUZU wrote: >>> Look @ hvm_do_resume(): >>> >>> 1. If you, as a toolstack user, get at sane step no. 6: "Uninitialize >>> everything (no events are possible here because of steps 4-5)." >>> 2. But just before you do that, a hvm_do_resume() happens on an >>>

Re: [Xen-devel] [PATCH] xen: credit2: don't let b_avgload go negative.

On Fri, Jul 22, 2016 at 01:34:27PM +0100, George Dunlap wrote: > On 22/07/16 13:04, Dario Faggioli wrote: > > The ASSERT() made effective by b5b5876619bd8ec2e > > ("xen: credit2: fix two s_time_t handling issues > > in load balancing") triggers for b_avgload (spotted > > by OSSTest). > > > >

Re: [Xen-devel] [PATCH] xen: credit2: don't let b_avgload go negative.

On 22/07/16 13:04, Dario Faggioli wrote: > The ASSERT() made effective by b5b5876619bd8ec2e > ("xen: credit2: fix two s_time_t handling issues > in load balancing") triggers for b_avgload (spotted > by OSSTest). > > b_avgload is where we store the prediction of how > the load of a runqueue will

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 3:10 PM, Razvan Cojocaru wrote: On 07/22/2016 02:39 PM, Corneliu ZUZU wrote: On 7/22/2016 1:29 PM, Razvan Cojocaru wrote: On 07/22/2016 01:17 PM, Corneliu ZUZU wrote: On 7/22/2016 12:55 PM, Razvan Cojocaru wrote: On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: Hi, I've been

Re: [Xen-devel] [xen-unstable test] 97737: regressions - FAIL

On Fri, 2016-07-22 at 11:49 +0100, Wei Liu wrote: > On Fri, Jul 22, 2016 at 03:27:30AM +, osstest service owner > wrote: > > > > flight 97737 xen-unstable real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/97737/ > > > > Regressions :-( > > > > Tests which did not succeed and

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 07/22/2016 02:39 PM, Corneliu ZUZU wrote: > On 7/22/2016 1:29 PM, Razvan Cojocaru wrote: >> On 07/22/2016 01:17 PM, Corneliu ZUZU wrote: >>> On 7/22/2016 12:55 PM, Razvan Cojocaru wrote: On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: > Hi, > > I've been inspecting vm-event code

[Xen-devel] [PATCH] xen: credit2: don't let b_avgload go negative.

The ASSERT() made effective by b5b5876619bd8ec2e ("xen: credit2: fix two s_time_t handling issues in load balancing") triggers for b_avgload (spotted by OSSTest). b_avgload is where we store the prediction of how the load of a runqueue will look like in the medium to long term, because of a vcpu

[Xen-devel] [distros-debian-jessie test] 66673: tolerable FAIL

flight 66673 distros-debian-jessie real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/66673/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): build-amd64 5 xen-buildfail blocked in 66571 build-i386

Re: [Xen-devel] [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Fri, Jul 22, 2016 at 05:43:32PM +0800, Bob Liu wrote: > > On 07/22/2016 05:34 PM, Roger Pau Monné wrote: > > On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote: > >> > >> On 07/22/2016 03:45 PM, Roger Pau Monné wrote: > >>> On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote: > >

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 2:13 PM, Andrew Cooper wrote: On 22/07/16 11:31, Corneliu ZUZU wrote: On 7/22/2016 12:51 PM, Andrew Cooper wrote: On 22/07/16 10:27, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 1:29 PM, Razvan Cojocaru wrote: On 07/22/2016 01:17 PM, Corneliu ZUZU wrote: On 7/22/2016 12:55 PM, Razvan Cojocaru wrote: On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done.

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On 07/22/2016 12:57 PM, Julien Grall wrote: > > > On 22/07/16 11:46, Sergej Proskurin wrote: >> >> >> On 07/22/2016 12:34 PM, Julien Grall wrote: >>> >>> >>> On 22/07/16 11:25, Sergej Proskurin wrote: Hi Julien, On 07/22/2016 11:30 AM, Julien Grall wrote: > > > On

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 22/07/16 11:31, Corneliu ZUZU wrote: On 7/22/2016 12:51 PM, Andrew Cooper wrote: On 22/07/16 10:27, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I understood correctly, domain pausing is done

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On 07/22/2016 12:38 PM, Julien Grall wrote: > > > On 22/07/16 11:39, Sergej Proskurin wrote: >> >> >> On 07/22/2016 12:26 PM, Julien Grall wrote: >>> >>> >>> On 22/07/16 11:16, Sergej Proskurin wrote: Hi Julien, >>> >>> Hello, >>> On 07/22/2016 11:18 AM, Julien Grall wrote: >

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On 22/07/16 11:46, Sergej Proskurin wrote: On 07/22/2016 12:34 PM, Julien Grall wrote: On 22/07/16 11:25, Sergej Proskurin wrote: Hi Julien, On 07/22/2016 11:30 AM, Julien Grall wrote: On 22/07/16 09:54, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 07/20/2016 06:11 PM,

Re: [Xen-devel] [xen-unstable test] 97737: regressions - FAIL

On Fri, Jul 22, 2016 at 03:27:30AM +, osstest service owner wrote: > flight 97737 xen-unstable real [real] > http://logs.test-lab.xenproject.org/osstest/logs/97737/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On 07/22/2016 12:34 PM, Julien Grall wrote: > > > On 22/07/16 11:25, Sergej Proskurin wrote: >> Hi Julien, >> >> On 07/22/2016 11:30 AM, Julien Grall wrote: >>> >>> >>> On 22/07/16 09:54, Sergej Proskurin wrote: Hi Julien, >>> >>> Hello Sergej, >>> On 07/20/2016 06:11 PM, Julien

Re: [Xen-devel] OVMF very slow on AMD

On Mon, 2016-07-18 at 16:09 +0100, Anthony PERARD wrote: >  > $ dwdiff procinfo_guest_ovmf_kvm procinfo_guest_ovmf_xen > processor : 0 > vendor_id : AuthenticAMD > cpu family: [-6-] {+21+} > model : [-6-] {+1+} > model name: [-QEMU Virtual CPU version 2.5+-] {+AMD >

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On 22/07/16 11:39, Sergej Proskurin wrote: On 07/22/2016 12:26 PM, Julien Grall wrote: On 22/07/16 11:16, Sergej Proskurin wrote: Hi Julien, Hello, On 07/22/2016 11:18 AM, Julien Grall wrote: On 22/07/16 09:32, Sergej Proskurin wrote: Hi Julien, Hello Sergej, -int

Re: [Xen-devel] [PATCH v2 1/1] ratelimit: Implement rate limit for credit2 scheduler Rate limit assures that a vcpu will execute for a minimum amount of time before being put at the back of a queue or

On Mon, 2016-07-18 at 13:22 +0100, Anshul Makkar wrote: > Hey, Anshul. Thanks, and sorry for the delay in reviewing. This version is an improvement, but it looks to me that you've missed a few of the review comments to v1. > It introduces a minimum amount of latency > "introduces

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On 07/22/2016 12:26 PM, Julien Grall wrote: > > > On 22/07/16 11:16, Sergej Proskurin wrote: >> Hi Julien, > > Hello, > >> On 07/22/2016 11:18 AM, Julien Grall wrote: >>> >>> >>> On 22/07/16 09:32, Sergej Proskurin wrote: Hi Julien, >>> >>> Hello Sergej, >>> > -int

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On 22/07/16 11:25, Sergej Proskurin wrote: Hi Julien, On 07/22/2016 11:30 AM, Julien Grall wrote: On 22/07/16 09:54, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 07/20/2016 06:11 PM, Julien Grall wrote: The function flush_tlb_domain is not used outside of the file where it has

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 12:51 PM, Andrew Cooper wrote: On 22/07/16 10:27, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I understood correctly, domain pausing is done solely to force all the vCPUs of that domain

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 07/22/2016 01:17 PM, Corneliu ZUZU wrote: > On 7/22/2016 12:55 PM, Razvan Cojocaru wrote: >> On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: >>> Hi, >>> >>> I've been inspecting vm-event code parts to try and understand when and >>> why domain pausing/locking is done. If I understood correctly,

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

On 22/07/16 11:16, Sergej Proskurin wrote: Hi Julien, Hello, On 07/22/2016 11:18 AM, Julien Grall wrote: On 22/07/16 09:32, Sergej Proskurin wrote: Hi Julien, Hello Sergej, -int p2m_alloc_table(struct domain *d) +static int p2m_alloc_table(struct domain *d) While moving parts of

Re: [Xen-devel] Kernel panic on Xen virtualisation in Debian

On 22.07.2016 11:03, Ingo Jürgensmann wrote: In the meanwhile, I activated IPv6 again on Tuesday evening and today the server crashed again some minutes ago. Here's the output from netconsole: ... and the second subsequent crash: Jul 22 11:15:04 31.172.31.251 [ 2774.896036] BUG: unable to

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

Hi Julien, On 07/22/2016 11:30 AM, Julien Grall wrote: > > > On 22/07/16 09:54, Sergej Proskurin wrote: >> Hi Julien, > > Hello Sergej, > >> On 07/20/2016 06:11 PM, Julien Grall wrote: >>> The function flush_tlb_domain is not used outside of the file where it >>> has been declared. >>> >> >>

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 7/22/2016 12:55 PM, Razvan Cojocaru wrote: On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I understood correctly, domain pausing is done solely to force all the vCPUs of that

Re: [Xen-devel] [XTF PATCH v2 4/4] xtf-runner: regularise runner exit code

On 22/07/16 10:58, Wei Liu wrote: Updated this patch Thanks. Pylint warned of an unnecessary semicolon from "res_idx = all_results.index(res);" which I dropped. Whole series Reviewed and committed. ~Andrew ___ Xen-devel mailing list

Re: [Xen-devel] [PATCH 15/22] xen/arm: Don't call p2m_alloc_table from arch_domain_create

Hi Julien, On 07/22/2016 11:18 AM, Julien Grall wrote: > > > On 22/07/16 09:32, Sergej Proskurin wrote: >> Hi Julien, > > Hello Sergej, > >>> -int p2m_alloc_table(struct domain *d) >>> +static int p2m_alloc_table(struct domain *d) >> >> While moving parts of the altp2m code out of

Re: [Xen-devel] [XTF PATCH v2 4/4] xtf-runner: regularise runner exit code

Updated this patch ---8<--- From ef1f9ddfa797bb4095d48b90efc3c92a0a8fd1b6 Mon Sep 17 00:00:00 2001 From: Wei Liu Date: Mon, 13 Jun 2016 15:06:48 +0100 Subject: [XTF PATCH] xtf-runner: regularise runner exit code Cc: andrew.coop...@citrix.com The script now returns the most

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 07/22/2016 12:27 PM, Corneliu ZUZU wrote: > Hi, > > I've been inspecting vm-event code parts to try and understand when and > why domain pausing/locking is done. If I understood correctly, domain > pausing is done solely to force all the vCPUs of that domain to see a > configuration update and

Re: [Xen-devel] [XTF PATCH v2 4/4] xtf-runner: regularise runner exit code

On Fri, Jul 22, 2016 at 10:49:18AM +0100, Andrew Cooper wrote: > On 22/07/16 10:43, Wei Liu wrote: > > >The script now returns the most severe result. Document the exit code in > >help string. > > > >Signed-off-by: Wei Liu > >--- > > xtf-runner | 22 ++ >

Re: [Xen-devel] Locking on vm-event operations (monitor)

On 22/07/16 10:27, Corneliu ZUZU wrote: Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I understood correctly, domain pausing is done solely to force all the vCPUs of that domain to see a configuration update and act upon

Re: [Xen-devel] [XTF PATCH v2 4/4] xtf-runner: regularise runner exit code

On 22/07/16 10:43, Wei Liu wrote: The script now returns the most severe result. Document the exit code in help string. Signed-off-by: Wei Liu --- xtf-runner | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/xtf-runner

[Xen-devel] [XTF PATCH v2 2/4] xtf-runner: sync all test results

Signed-off-by: Wei Liu --- xtf-runner | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/xtf-runner b/xtf-runner index 50a5e96..c938f28 100755 --- a/xtf-runner +++ b/xtf-runner @@ -17,6 +17,9 @@ try: except ImportError: import simplejson as json

Re: [Xen-devel] [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On 07/22/2016 05:34 PM, Roger Pau Monné wrote: > On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote: >> >> On 07/22/2016 03:45 PM, Roger Pau Monné wrote: >>> On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote: On 07/21/2016 04:57 PM, Roger Pau Monné wrote: >> ..[snip].. >>

[Xen-devel] [XTF PATCH v2 1/4] gitignore: ignore vim swp file

Signed-off-by: Wei Liu --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 01243f0..56e1884 100644 --- a/.gitignore +++ b/.gitignore @@ -3,6 +3,7 @@ *.d *.pyc *.pyo +*.swp /arch/x86/*.lds /cscope.* /dist/ -- 2.1.4

[Xen-devel] [XTF PATCH v2 3/4] xtf-runner: provide a set of exit codes for different results

Signed-off-by: Wei Liu --- xtf-runner | 10 ++ 1 file changed, 10 insertions(+) diff --git a/xtf-runner b/xtf-runner index c938f28..1c96750 100755 --- a/xtf-runner +++ b/xtf-runner @@ -21,6 +21,16 @@ except ImportError: # Note that warning is not a result on its

[Xen-devel] [XTF PATCH v2 0/4] Runner exit code clean up

Wei Liu (4): gitignore: ignore vim swp file xtf-runner: sync all test results xtf-runner: provide a set of exit codes for different results xtf-runner: regularise runner exit code .gitignore | 1 + xtf-runner | 37 - 2 files changed, 33 insertions(+),

[Xen-devel] [XTF PATCH v2 4/4] xtf-runner: regularise runner exit code

The script now returns the most severe result. Document the exit code in help string. Signed-off-by: Wei Liu --- xtf-runner | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/xtf-runner b/xtf-runner index 1c96750..15b98c6 100755 ---

Re: [Xen-devel] [PATCH XTF 3/3] xtf-runner: regularise runner exit code

On 22/07/16 10:29, Wei Liu wrote: On Thu, Jul 21, 2016 at 08:04:59PM +0100, Andrew Cooper wrote: On 21/07/2016 16:44, Wei Liu wrote: Report the first "ERROR" and "FAILURE" if found, otherwise report "SKIP" if found. Eventually if everything is ok the exit code will be 0. See runner code for

Re: [Xen-devel] [PATCH 3/3] xen-blkfront: dynamic configuration of per-vbd resources

On Fri, Jul 22, 2016 at 04:17:48PM +0800, Bob Liu wrote: > > On 07/22/2016 03:45 PM, Roger Pau Monné wrote: > > On Thu, Jul 21, 2016 at 06:08:05PM +0800, Bob Liu wrote: > >> > >> On 07/21/2016 04:57 PM, Roger Pau Monné wrote: > ..[snip].. > + > +static ssize_t

Re: [Xen-devel] [PATCH 20/22] xen/arm: Don't export flush_tlb_domain

On 22/07/16 09:54, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 07/20/2016 06:11 PM, Julien Grall wrote: The function flush_tlb_domain is not used outside of the file where it has been declared. As for patch #15, the same applies here too: For altp2m,

Re: [Xen-devel] [PATCH XTF 3/3] xtf-runner: regularise runner exit code

On Thu, Jul 21, 2016 at 08:04:59PM +0100, Andrew Cooper wrote: > On 21/07/2016 16:44, Wei Liu wrote: > > Report the first "ERROR" and "FAILURE" if found, otherwise report "SKIP" > > if found. Eventually if everything is ok the exit code will be 0. > > > > See runner code for numeric exit code

Re: [Xen-devel] [PATCH 19/22] xen/arm: p2m: Inline p2m_load_VTTBR into p2m_restore_state

On 22/07/16 09:07, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 07/20/2016 06:11 PM, Julien Grall wrote: p2m_restore_state is the last caller of p2m_load_VTTBR and already check if the vCPU does not belong to the idle domain. Note that it is likely possible to remove some isb in

[Xen-devel] Locking on vm-event operations (monitor)

Hi, I've been inspecting vm-event code parts to try and understand when and why domain pausing/locking is done. If I understood correctly, domain pausing is done solely to force all the vCPUs of that domain to see a configuration update and act upon it (e.g. in the case of a

Re: [Xen-devel] [PATCH 16/22] xen/arm: p2m: Move the vttbr field from arch_domain to p2m_domain

On 22/07/16 08:46, Sergej Proskurin wrote: Hi Julien, Hello Sergej, On 07/20/2016 06:10 PM, Julien Grall wrote: The field vttbr holds the base address of the translation table for guest. Its value will depends on how the p2m has been initialized and will only be used by the code code. So

  1   2   >