[Xen-devel] [PATCH] Livepatch: Support local/global symbols.

Heya, Please see the following two patches: [PATCH v1 1/3] livepatch: Add local and global symbol resolution. [PATCH v1 2/3] livepatch: Add xen_local_symbols test-case which depend on "xen/test/Makefile: Fix clean target, broken by pattern rule" to install properly. There is also an OSSTEST

[Xen-devel] [PATCH v1 2/3] 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

[Xen-devel] [PATCH v1 OSSTEST 3/3] ts-livepatch: Expand testcase to include global/local symbols

testing. The test is to verify that the local symbols of payloads are ignored during loading. See Xen's patch "livepatch: Add local and global symbol resolution." Signed-off-by: Konrad Rzeszutek Wilk --- ts-livepatch-run | 26 -- 1 file changed,

[Xen-devel] [PATCH v1 1/3] livepatch: Add local and global symbol resolution.

This way we can load livepatches with symbol names that are the same as long as they are local ('static'). The use case here is to replace an existing livepatch with a newer one - and one which has the same local symbols. Without this patch we get: livepatch.c:819: livepatch: xen_local_symbols:

[Xen-devel] [xen-4.9-testing test] 110568: regressions - FAIL

flight 110568 xen-4.9-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/110568/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 110550

[Xen-devel] stub domain crash related to bind_interdomain

I have gotten messages like this sporadically in the qemu-dm log for stub domains, both at domain start and domain reboot: evtchn_open() -> 7 ERROR: bind_interdomain failed with rc=-22xenevtchn_bind_interdomain(121, 0) = -22 bind interdomain ioctl error 22 Unable to find x86 CPU definition

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

On 19/06/2017 19:30, Konrad Rzeszutek Wilk wrote: > On Wed, Jun 14, 2017 at 12:49:21PM -0600, Jan Beulich wrote: > Andrew Cooper 06/14/17 8:34 PM >>> >>> Well - I've got a livepatch with such a relocation. It is probably a >>> livepatch build tools issue, but the

Re: [Xen-devel] [PATCH v12 01/34] ARM: vGIC: avoid rank lock when reading priority

On Mon, 19 Jun 2017, Julien Grall wrote: > Hi, > > On 14/06/17 18:55, Julien Grall wrote: > > Hi Andre, > > > > On 06/14/2017 05:51 PM, Andre Przywara wrote: > > > When reading the priority value of a virtual interrupt, we were taking > > > the respective rank lock so far. > > > However for

Re: [Xen-devel] [PATCH 1/2] arm: smccc: handle SMCs/HVCs according to SMCCC

Hello Julien, Thank you for review. It is my first time, when I'm submitting patch to XEN, so I have some questions. On 15.06.17 13:48, Julien Grall wrote: On 14/06/17 15:10, Volodymyr Babchuk wrote: SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs. SMCCC states that

[Xen-devel] [linux-next test] 110564: regressions - FAIL

flight 110564 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/110564/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-pair 20 guest-start/debian fail REGR. vs. 110547

Re: [Xen-devel] [PATCH for-4.9] xen/test/Makefile: Fix clean target, broken by pattern rule

On Mon, Jun 19, 2017 at 03:23:26PM +0100, Ian Jackson wrote: > In "xen/test/livepatch: Regularise Makefiles" we reworked > xen/test/Makefile to use a pattern rule. However, there are two > problems with this. Both are related to the way that xen/Rules.mk is > implicitly part of this Makefile

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hi Stefano, On 19 June 2017 at 10:54, Stefano Stabellini wrote: >> But given the conversation so far, it seems likely that that is mainly >> due to the fact that context switching on ARM has not been optimized. > > True. However, Volodymyr took the time to demonstrate

Re: [Xen-devel] [PATCH 2/2] xen/livepatch: Don't crash on encountering STN_UNDEF relocations

On Wed, Jun 14, 2017 at 12:49:21PM -0600, Jan Beulich wrote: > >>> Andrew Cooper 06/14/17 8:34 PM >>> > >Well - I've got a livepatch with such a relocation. It is probably a > >livepatch build tools issue, but the question is whether Xen should ever > >accept such a

Re: [Xen-devel] Notes on stubdoms and latency on ARM

Hi George, On 19 June 2017 at 02:37, George Dunlap wrote: > There is no way out: if the stubdom needs events, then we'll have to > expose and context switch the vGIC. If it doesn't, then we can skip the > vGIC. However, we would have a similar problem with

Re: [Xen-devel] [PATCH 1/2] xen/livepatch: Clean up arch relocation handling

On Wed, Jun 14, 2017 at 07:28:39PM +0100, Andrew Cooper wrote: > On 14/06/17 15:02, Jan Beulich wrote: > On 14.06.17 at 15:44, wrote: > >> On Tue, Jun 13, 2017 at 09:51:35PM +0100, Andrew Cooper wrote: > >>> --- a/xen/arch/arm/arm32/livepatch.c > >>> +++

Re: [Xen-devel] Notes on stubdoms and latency on ARM

On Mon, 19 Jun 2017, George Dunlap wrote: > On 17/06/17 01:14, Volodymyr Babchuk wrote: > > Hello George, > > > > On 31 May 2017 at 20:02, George Dunlap wrote: > There is no way out: if the stubdom needs events, then we'll have to > expose and context switch

Re: [Xen-devel] ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)

On Mon, Jun 19, 2017 at 07:22:39PM +0200, Geert Uytterhoeven wrote: > Hi Al, > > On Mon, Jun 19, 2017 at 5:08 PM, Al Viro wrote: > > Fixed in vfs.git#ufs-fixes; see commit > > 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1 > > there. Not sure if it's worth splitting... > >

Re: [Xen-devel] ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)

Hi Al, On Mon, Jun 19, 2017 at 5:08 PM, Al Viro wrote: > Fixed in vfs.git#ufs-fixes; see commit > 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1 > there. Not sure if it's worth splitting... I can confirm that commit fixes the build for m68k. Let's hope it fixes the build

[Xen-devel] [xen-unstable-smoke test] 110573: tolerable trouble: broken/pass - PUSHED

flight 110573 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110573/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

Re: [Xen-devel] [PATCH v2 09/20] rbtree: adjust root color in rb_insert_color() only when necessary

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > --- a/xen/common/rbtree.c > +++ b/xen/common/rbtree.c > @@ -90,8 +90,23 @@ void rb_insert_color(struct rb_node *node, struct > rb_root *root) >  { >  struct rb_node *parent, *gparent; >   > -while ((parent = rb_parent(node)) &&

Re: [Xen-devel] [PATCH v2 08/20] rbtree: break out of rb_insert_color loop after tree rotation

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > It is a well known property of rbtrees that insertion never requires > more > than two tree rotations.  In our implementation, after one loop > iteration > identified one or two necessary tree rotations, we would iterate and > look > for

Re: [Xen-devel] [PATCH v2 08/16] xen/arm: livepatch: Redefine virt_to_mfn to support typesafe

On Mon, Jun 19, 2017 at 05:57:45PM +0100, Julien Grall wrote: > The file xen/arch/arm/livepatch.c is using typesafe MFN in most of > the place. The only caller to virt_to_mfn is using with _mfn(...). > > To avoid extra _mfn(...), re-define virt_to_mfn within > xen/arch/arm/livepatch.c to handle

Re: [Xen-devel] [PATCH v2 07/20] rbtree: move some implementation details from rbtree.h to rbtree.c

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > --- a/xen/include/xen/rbtree.h > +++ b/xen/include/xen/rbtree.h > @@ -21,9 +21,7 @@ >   >  struct rb_node >  { > The Linux commit converts this into: struct rb_node { and.. > -unsigned long  rb_parent_color; > -#define RB_RED  0 >

Re: [Xen-devel] [PATCH v4 4/4] x86/vioapic: bind interrupts to PVH Dom0

On Wed, Jun 07, 2017 at 07:20:38AM -0600, Jan Beulich wrote: > >>> On 01.06.17 at 13:49, wrote: > > --- a/xen/arch/x86/hvm/vioapic.c > > +++ b/xen/arch/x86/hvm/vioapic.c > > @@ -158,6 +158,52 @@ static int vioapic_read( > > return X86EMUL_OKAY; > > } > > > > +static

Re: [Xen-devel] [PATCH v2 06/20] rbtree: empty nodes have no color

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > Empty nodes have no color.  We can make use of this property to > simplify > the code emitted by the RB_EMPTY_NODE and RB_CLEAR_NODE > macros.  Also, > we can get rid of the rb_init_node function which had been introduced > by > commit

Re: [Xen-devel] [PATCH 02/14 v4] xen/arm: vpl011: Define generic vreg_reg* access functions in vreg.h

Hi, On 19/06/17 17:53, Bhupinder Thakur wrote: > Hi Andre, > > On 19 June 2017 at 15:03, Andre Przywara wrote: >> Hi Bhupinder, >> >> I think the commit message is a bit misleading. >> Actually you *rename* functions and their call sites, and also this >> touches the

[Xen-devel] [PATCH v2 03/16] xen/arm: mm: Use typesafe mfn for xenheap_mfn_*

Add more safety when using xenheap_mfn_*. Signed-off-by: Julien Grall --- I haven't introduced mfn_less_than() and mfn_greather_than() as there would be only a couple of usage. We would be able to introduce them and replace the open-coding easily in the future

[Xen-devel] [PATCH v2 14/16] xen/arm: mm: Use lpae_valid and lpae_table in create_xen_entries

This newly introduced lpae_valid and lpae_table helpers will recude the code and make more readable. Signed-off-by: Julien Grall --- Changes in v2: - Patch added --- xen/arch/arm/mm.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git

[Xen-devel] [linux-linus test] 110560: regressions - FAIL

flight 110560 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/110560/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 5 kernel-build fail REGR. vs. 110515

[Xen-devel] [PATCH v2 01/16] xen/mm: Don't use _{g, m}fn for defining INVALID_{G, M}FN

INVALID_{G,M}FN are defined using static inline helpers _{g,m}fn. This means, they cannot be used to initialize a build time static variable: In file included from mm.c:24:0: xen/xen/include/xen/mm.h:59:26: error: initializer element is not constant #define INVALID_MFN _mfn(~0UL)

[Xen-devel] [PATCH v2 06/16] xen/arm: domain_build: Redefine virt_to_mfn to support typesafe

The file xen/arch/arm/domain_build.c is using typesafe MFN in most of the place. The only caller to virt_to_mfn is using prefixed with _mfn(...). To avoid extra _mfn(...), re-define virt_to_mfn within arch/arm/domain_build.c to handle typesafe MFN. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v2 16/16] xen/arm: mm: Use __func__ rather than plain name in format string

Signed-off-by: Julien Grall --- Changes in v2: - Patch added --- xen/arch/arm/mm.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index 657fee0b17..91af4c8743 100644 ---

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

> The method I found to work is getting the maximum_gpfn from the guest > and then calling populate_physmap with ++max_gpfn. The only problem > then is that I don't see a way to "unpopulate" the page from the > domain and free the corresponding mfn while the domain is running. Is > that currently

[Xen-devel] [PATCH v2 13/16] xen/arm: p2m: Move lpae_* helpers in lpae.h

lpae_* helpers can work on any LPAE translation tables. Move them in lpae.h to allow other part of Xen to use them. Signed-off-by: Julien Grall --- Cc: prosku...@sec.in.tum.de Changes in v2: - Patch added --- xen/arch/arm/p2m.c | 23

[Xen-devel] [PATCH v2 09/16] xen/arm: create_xen_entries: Use typesafe MFN

Add a bit more safety when using create_xen_entries. Also when destroying/modifying mapping, the MFN is currently not used. Rather than passing _mfn(0) use INVALID_MFN to stay consistent with the other usage. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini

[Xen-devel] [PATCH v2 08/16] xen/arm: livepatch: Redefine virt_to_mfn to support typesafe

The file xen/arch/arm/livepatch.c is using typesafe MFN in most of the place. The only caller to virt_to_mfn is using with _mfn(...). To avoid extra _mfn(...), re-define virt_to_mfn within xen/arch/arm/livepatch.c to handle typesafe MFN. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v2 11/16] xen/arm: lpae: Fix comments coding style

Also adding one missing full stop + fix description Signed-off-by: Julien Grall --- Cc: prosku...@sec.in.tum.de I haven't retained Stefano's reviewed-by because of the description update. Changes in v2: - Fix description regarding x86 page-table ---

[Xen-devel] [PATCH v2 10/16] xen/arm: Move LPAE definition in a separate header

page.h is getting bigger. Move out every LPAE definitions in a separate header. There is no functional changes. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Cc: prosku...@sec.in.tum.de Changes in v2: - Move comment

[Xen-devel] [PATCH v2 07/16] xen/arm: alternative: Redefine virt_to_mfn to support typesafe

The file xen/arch/arm/alternative.c is using typesafe MFN in most of the place. The only caller to virt_to_mfn is using with _mfn(...). To avoid extra _mfn(...), re-define virt_to_mfn within xen/arch/arm/alternative.c to handle typesafe MFN. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v2 05/16] xen/arm: mm: Redefine virt_to_mfn to support typesafe

The file xen/arch/arm/mm.c is using the typesafe MFN in most of the place. This requires all caller of virt_to_mfn to prefixed by _mfn(...). To avoid the extra _mfn(...), re-defined virt_to_mfn within arch/arm/mm.c to handle typesafe MFN. This patch also introduce __virt_to_mfn, so virt_to_mfn

[Xen-devel] [PATCH v2 15/16] xen/arm: mm: Introduce temporary variable in create_xen_entries

This is improving the code readability and avoid to dereference the table every single time we need to access the entry. Signed-off-by: Julien Grall --- Changes in v2: - Patch added --- xen/arch/arm/mm.c | 22 -- 1 file changed, 12

[Xen-devel] [PATCH v2 00/16] xen/arm: Clean-up memory subsystems

Hi all, This is a merged of the remainder of 2 series + new clean-up patches: - xen/arm: Extend the usage of typesafe MFN [1] - xen/arm: Move LPAE definition in a separate header. [2] Cheers, [1] <20170613161323.25196-1-julien.gr...@arm.com> [2]

[Xen-devel] [PATCH v2 12/16] xen/arm: p2m: Rename p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage

The helpers p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage are not specific to the stage-2 translation tables. They can also work on any LPAE translation tables. So rename then to lpae_* and use pte.walk to look for the value of the field. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v2 04/16] xen/arm: p2m: Redefine mfn_to_page and page_to_mfn to use typesafe

The file xen/arch/arm/p2m.c is using typesafe MFN in most of the place. This requires caller to mfn_to_page and page_to_mfn to use _mfn/mfn_x. To avoid extra _mfn/mfn_x, re-define mfn_to_page and page_to_mfn within xen/arch/arm/p2m.c to handle typesafe MFN. Signed-off-by: Julien Grall

[Xen-devel] [PATCH v2 02/16] xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64

xenheap_mfn_end is storing an MFN and not a physical address. Xen is not currently using xenheap_mfn_end and the value will be reset after the loop. So drop this bogus xenheap_mfn_end. Signed-off-by: Julien Grall --- Changes in v2: - Update commit message ---

Re: [Xen-devel] [PATCH 02/14 v4] xen/arm: vpl011: Define generic vreg_reg* access functions in vreg.h

Hi Andre, On 19 June 2017 at 15:03, Andre Przywara wrote: > Hi Bhupinder, > > I think the commit message is a bit misleading. > Actually you *rename* functions and their call sites, and also this > touches the VGIC code, so shouldn't it mention both in the first line of >

Re: [Xen-devel] [PATCH v2 05/20] rb_tree: remove redundant if()-condition in rb_erase()

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > Furthermore, notice that the initial checks: > > if (!node->rb_left) > child = node->rb_right; > else if (!node->rb_right) > child = node->rb_left; > else >    

Re: [Xen-devel] [PATCH v2 04/20] rb_tree: make clear distinction between two different cases in rb_erase()

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > There are two cases when a node, having 2 childs, is erased: > 'normal case': the successor is not the right-hand-child of the node > to be > erased > 'special case': the successor is the right-hand child of the node to > be erased > >

Re: [Xen-devel] [PATCH v2 03/20] rb_tree: reorganize code in rb_erase() for additional changes

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > First, move some code around in order to make the next change more > obvious. > > [a...@linux-foundation.org: coding-style fixes] > Signed-off-by: Peter Zijlstra > Signed-off-by: Wolfram Strepp >

Re: [Xen-devel] [PATCH v4.1 3/4] x86/pt: enable binding of GSIs to a PVH Dom0

On Wed, Jun 07, 2017 at 07:17:16AM -0600, Jan Beulich wrote: > >>> On 02.06.17 at 15:58, wrote: > > --- a/xen/drivers/passthrough/io.c > > +++ b/xen/drivers/passthrough/io.c > > @@ -164,6 +164,25 @@ static void pt_irq_time_out(void *data) > > > >

Re: [Xen-devel] [PATCH 02/20] lib/rbtree.c: optimize rb_erase()

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > Tfour 4 redundant if-conditions in function __rb_erase_color() in > lib/rbtree.c are removed. > > In pseudo-source-code, the structure of the code is as follows: > > if ((!A || B) && (!C || D)) { > . > . > . > } else { > if

Re: [Xen-devel] [PATCH 01/20] rbtree: add const qualifier to some functions

On Sat, 2017-06-17 at 15:02 +0530, Praveen Kumar wrote: > The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls > take a pointer to an RB node or RB root. They do not change the > pointed objects, so add a 'const' qualifier in order to make life > of the users of these functions easier.

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On Mon, Jun 19, 2017 at 9:34 AM, Julien Grall wrote: > > > On 19/06/17 15:57, Tamas K Lengyel wrote: >> >> On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall >> wrote: >>> >>> >>> >>> On 19/06/17 15:39, Tamas K Lengyel wrote: On Mon, Jun 19,

Re: [Xen-devel] [RFC PATCH v3 08/10] arm/mem_access: Add long-descriptor based gpt

On 19/06/17 16:43, Sergej Proskurin wrote: Hi Julien, [...] On 06/19/2017 02:45 PM, Julien Grall wrote: Hi Sergej, +/* Normalized page granule size indices. */ +#define GRANULE_SIZE_INDEX_4K (0) +#define GRANULE_SIZE_INDEX_16K (1) +#define GRANULE_SIZE_INDEX_64K

Re: [Xen-devel] [RFC PATCH v3 08/10] arm/mem_access: Add long-descriptor based gpt

Hi Julien, [...] On 06/19/2017 02:45 PM, Julien Grall wrote: > Hi Sergej, > >> +/* Normalized page granule size indices. */ >> +#define GRANULE_SIZE_INDEX_4K (0) >> +#define GRANULE_SIZE_INDEX_16K (1) >> +#define GRANULE_SIZE_INDEX_64K (2) > > Why this is

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On 19/06/17 15:57, Tamas K Lengyel wrote: On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall wrote: On 19/06/17 15:39, Tamas K Lengyel wrote: On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall wrote: Hi, On 19/06/17 09:15, Jan Beulich wrote: On

[Xen-devel] [linux-4.9 test] 110557: regressions - FAIL

flight 110557 linux-4.9 real [real] http://logs.test-lab.xenproject.org/osstest/logs/110557/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 110456 Tests which

Re: [Xen-devel] [PATCH 06/44] iommu/dma: don't rely on DMA_ERROR_CODE

On 16/06/17 19:10, Christoph Hellwig wrote: > DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu > driver already implements a proper ->mapping_error method, so it's only > using the value internally. Add a new local define using the value > that arm64 which is the only

Re: [Xen-devel] ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)

On Mon, Jun 19, 2017 at 03:36:47PM +0100, Ian Jackson wrote: > osstest service owner writes ("[linux-linus bisection] complete > build-i386-pvops"): > > branch xen-unstable > > xenbranch xen-unstable > > job build-i386-pvops > > testid kernel-build > > > > Tree: linux > >

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On Mon, Jun 19, 2017 at 8:52 AM, Julien Grall wrote: > > > On 19/06/17 15:39, Tamas K Lengyel wrote: >> >> On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall >> wrote: >>> >>> Hi, >>> >>> >>> On 19/06/17 09:15, Jan Beulich wrote: >>> >>> >>> On

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On Mon, Jun 19, 2017 at 8:54 AM, George Dunlap wrote: > On 19/06/17 15:48, Tamas K Lengyel wrote: >> On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap >> wrote: >>> On 19/06/17 09:15, Jan Beulich wrote: >>> On 18.06.17 at 21:19,

Re: [Xen-devel] [PATCH for-4.9] xen/test/Makefile: Fix clean target, broken by pattern rule

On Mon, Jun 19, 2017 at 03:23:26PM +0100, Ian Jackson wrote: > In "xen/test/livepatch: Regularise Makefiles" we reworked > xen/test/Makefile to use a pattern rule. However, there are two > problems with this. Both are related to the way that xen/Rules.mk is > implicitly part of this Makefile

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On 19/06/17 15:48, Tamas K Lengyel wrote: > On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap > wrote: >> On 19/06/17 09:15, Jan Beulich wrote: >> On 18.06.17 at 21:19, wrote: On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper

Re: [Xen-devel] blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)

On Mon, Jun 19, 2017 at 03:27:01PM +0100, Ian Jackson wrote: > Konrad Rzeszutek Wilk writes ("Re: blkback shutdown problem ? (Re: [linux-4.9 > test] 110513: regressions - FAIL)"): > > On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote: > > > This has already been noticed and fixed by

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On 19/06/17 15:39, Tamas K Lengyel wrote: On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall wrote: Hi, On 19/06/17 09:15, Jan Beulich wrote: On 18.06.17 at 21:19, wrote: On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper

Re: [Xen-devel] [PATCH v4 2/2] xen-access: write_ctrlreg_c4 test

On Mon, Jun 19, 2017 at 6:24 AM, Petre Pircalabu wrote: > Add test for write_ctrlreg event handling. > > Signed-off-by: Petre Pircalabu Acked-by: Tamas K Lengyel > --- > tools/tests/xen-access/xen-access.c | 53 >

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On Mon, Jun 19, 2017 at 3:11 AM, George Dunlap wrote: > On 19/06/17 09:15, Jan Beulich wrote: > On 18.06.17 at 21:19, wrote: >>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper >>> wrote: On 04/04/17 14:14,

Re: [Xen-devel] [PATCH 01/20] rbtree: add const qualifier to some functions

>>> On 19.06.17 at 16:09, wrote: > On Mon, Jun 19, 2017 at 7:19 PM, Jan Beulich wrote: > On 17.06.17 at 11:32, wrote: >>> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls >>> take a pointer to an RB node or

Re: [Xen-devel] [PATCH 2/2] memory: don't hand MFN info to translated guests

On Mon, Jun 19, 2017 at 3:09 AM, Julien Grall wrote: > Hi, > > > On 19/06/17 09:15, Jan Beulich wrote: > > On 18.06.17 at 21:19, wrote: >>> >>> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper >>> wrote:

[Xen-devel] ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)

osstest service owner writes ("[linux-linus bisection] complete build-i386-pvops"): > branch xen-unstable > xenbranch xen-unstable > job build-i386-pvops > testid kernel-build > > Tree: linux > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > Tree: linuxfirmware

Re: [Xen-devel] blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)

Konrad Rzeszutek Wilk writes ("Re: blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)"): > On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote: > > This has already been noticed and fixed by Juergen [0], however AFAIK > > the patches are not yet in Jens/Linus

[Xen-devel] [xen-unstable test] 110556: regressions - FAIL

flight 110556 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/110556/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-xsm 5 xen-build fail in 110510 REGR. vs. 110465 Tests which are

[Xen-devel] [xen-unstable-smoke test] 110567: tolerable trouble: broken/pass - PUSHED

flight 110567 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/110567/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 12

[Xen-devel] [PATCH for-4.9] xen/test/Makefile: Fix clean target, broken by pattern rule

In "xen/test/livepatch: Regularise Makefiles" we reworked xen/test/Makefile to use a pattern rule. However, there are two problems with this. Both are related to the way that xen/Rules.mk is implicitly part of this Makefile because of the way that Makefiles under xen/ are invoked by their parent

Re: [Xen-devel] [PATCH 01/20] rbtree: add const qualifier to some functions

Hi Jan, On Mon, Jun 19, 2017 at 7:19 PM, Jan Beulich wrote: On 17.06.17 at 11:32, wrote: >> The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls >> take a pointer to an RB node or RB root. They do not change the >> pointed objects, so

Re: [Xen-devel] [PATCH 01/20] rbtree: add const qualifier to some functions

>>> On 17.06.17 at 11:32, wrote: > The 'rb_first()', 'rb_last()', 'rb_next()' and 'rb_prev()' calls > take a pointer to an RB node or RB root. They do not change the > pointed objects, so add a 'const' qualifier in order to make life > of the users of these functions

[Xen-devel] [linux-linus bisection] complete build-i386-pvops

branch xen-unstable xenbranch xen-unstable job build-i386-pvops testid kernel-build Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git *** Found and reproduced problem changeset *** Bug is in

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

Thanks Jianfeng for giving new ideas. There is not much activity on Xen side. Is there someone working on DPDK+Xen? Any news? The technical board requested to re-consider Xen support in DPDK. It will be discussed in the next techboard meeting:

Re: [Xen-devel] blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)

On Mon, Jun 19, 2017 at 12:27:33PM +0100, Roger Pau Monné wrote: > On Mon, Jun 19, 2017 at 11:55:14AM +0100, Ian Jackson wrote: > > osstest service owner writes ("[linux-4.9 test] 110513: regressions - > > FAIL"): > > > flight 110513 linux-4.9 real [real] > > >

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

Hi Wei, On 19 June 2017 at 17:17, Wei Liu wrote: > On Mon, Jun 19, 2017 at 12:01:32PM +0100, Julien Grall wrote: >> >> >> On 19/06/17 11:59, Bhupinder Thakur wrote: >> > Hi Julien, >> > >> > I was mistaken in my earlier mail about vpl011 init working if it is >> > moved to

Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide way to ship livepatch tests

On 19/06/17 13:59, Ian Jackson wrote: > Julien Grall writes ("Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide > way to ship livepatch tests"): >> I don't see the patches in staging. Do you still plan to have those >> patches in Xen 4.9? > As you'll have seen, they went to staging last

Re: [Xen-devel] [linux-4.9 test] 110371: regressions - FAIL

Julien Grall writes ("Re: [Xen-devel] [linux-4.9 test] 110371: regressions - FAIL"): > There are now in Linux 4.9 stable branch. Now the testing is blocked > because of again local migration [1]. The migration test seem less > reliable than the Arndale these days... is there anything we can do?

Re: [Xen-devel] [PATCH] ipxe: update to newer commit

Wei Liu writes ("Re: [PATCH] ipxe: update to newer commit"): > On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote: > > To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. > > > > The only patch we have applies cleanly. > > > > Reported-by: Zhongze Liu >

Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide way to ship livepatch tests

Julien Grall writes ("Re: [Xen-devel] [PATCH for-4.9 0/4] Makefiles: Provide way to ship livepatch tests"): > I don't see the patches in staging. Do you still plan to have those > patches in Xen 4.9? As you'll have seen, they went to staging last week and are now in xen.git#master. I have just

Re: [Xen-devel] Implementation of single-stepping for Xen on ARMv7

Hello Julien, thank you for your answer and sorry for the delay. 2017-06-14 14:26 GMT+02:00 Julien Grall : > > > On 06/12/2017 10:34 AM, Florian Jakobsmeier wrote: > >> Dear all, >> > > Hello Florian, > > > I don't have much experience with the debug registers, I have

Re: [Xen-devel] [RFC PATCH v3 08/10] arm/mem_access: Add long-descriptor based gpt

Hi Sergej, On 15/06/17 12:05, Sergej Proskurin wrote: This commit adds functionality to walk the guest's page tables using the long-descriptor translation table format for both ARMv7 and ARMv8. Similar to the hardware architecture, the implementation supports different page granularities (4K,

[Xen-devel] [PATCH v4 2/2] xen-access: write_ctrlreg_c4 test

Add test for write_ctrlreg event handling. Signed-off-by: Petre Pircalabu --- tools/tests/xen-access/xen-access.c | 53 - 1 file changed, 52 insertions(+), 1 deletion(-) diff --git a/tools/tests/xen-access/xen-access.c

[Xen-devel] [PATCH v4 1/2] x86/monitor: add masking support for write_ctrlreg events

Add support for filtering out the write_ctrlreg monitor events if they are generated only by changing certains bits. A new parameter (bitmask) was added to the xc_monitor_write_ctrlreg function in order to mask the event generation if the changed bits are set. Signed-off-by: Petre Pircalabu

[Xen-devel] [PATCH v4 0/2] write_ctrlreg event masking

This patchset enables masking the reception of write_ctrlreg events depending on the value of certain bits in that register. The most representative example is filtering out events when the CR4.PGE bit is being flipped (global TLB flushes) --- Changed since v2 * fix coding style * use

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On Mon, Jun 19, 2017 at 12:01:32PM +0100, Julien Grall wrote: > > > On 19/06/17 11:59, Bhupinder Thakur wrote: > > Hi Julien, > > > > I was mistaken in my earlier mail about vpl011 init working if it is > > moved to libxl__arch_domain_create(). It is failing because as you > > have mentioned

Re: [Xen-devel] [PATCH v3] tools: fix several "format-truncation" warnings with GCC 7

On Wed, Jun 14, 2017 at 09:11:48AM +0800, Zhongze Liu wrote: > GCC 7.1.1 complains that several buffers passed to snprintf() in xenpmd > and tools/ocmal/xc are too small to hold the largest possible resulting > string, > which is calculated by adding up the maximum length of all the substrings. >

Re: [Xen-devel] [PATCH] ipxe: update to newer commit

On Mon, Jun 12, 2017 at 04:04:17PM +0100, Wei Liu wrote: > To get 5f85cbb9ee1c00cec81a848a9e871ad5d1e7f53f to placate gcc 7. > > The only patch we have applies cleanly. > > Reported-by: Zhongze Liu > Signed-off-by: Wei Liu Ping?

Re: [Xen-devel] blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)

On Mon, Jun 19, 2017 at 11:55:14AM +0100, Ian Jackson wrote: > osstest service owner writes ("[linux-4.9 test] 110513: regressions - FAIL"): > > flight 110513 linux-4.9 real [real] > > http://logs.test-lab.xenproject.org/osstest/logs/110513/ > > > > Regressions :-( > > > > Tests which did not

Re: [Xen-devel] Operf and Opreport outputs

Hello, Thanks a lot for the detailed explanation. I could understand the working of operf and opreport. Unlike operf, ocount counts each occurrence of the monitored event. In such a case, why ocount also gives varying values of CPU_CLK_UNHALTED even when the monitored code doesn't get changed.

Re: [Xen-devel] [RFC PATCH v3 07/10] arm/mem_access: Add software guest-page-table walk

On 15/06/17 12:05, Sergej Proskurin wrote: The function p2m_mem_access_check_and_get_page in mem_access.c translates a gva to an ipa by means of the hardware functionality of the ARM architecture. This is implemented in the function gva_to_ipa. If mem_access is active, hardware-based gva to

Re: [Xen-devel] [PATCH] libxc: add xc_domain_add_to_physmap_batch to wrap XENMEM_add_to_physmap_batch

On Fri, Jun 16, 2017 at 05:36:18PM +0800, Zhongze Liu wrote: > Hi Jan, > > > 2017-06-16 16:45 GMT+08:00 Jan Beulich : > On 16.06.17 at 06:55, wrote: > >> currently there is no wrapper for XENMEM_add_to_physmap_batch in libxc. > >> add a wrapper to

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On 19/06/17 11:59, Bhupinder Thakur wrote: Hi Julien, I was mistaken in my earlier mail about vpl011 init working if it is moved to libxl__arch_domain_create(). It is failing because as you have mentioned vuart_pfn is allocated later in xc_dom_build_image(). Can we delay mapping of this page

Re: [Xen-devel] [OSSTEST PATCH v11 00/20] Have OpenStack tested on top of xen's master and libvirt's master.

On Fri, Jun 16, 2017 at 06:56:44PM +0100, Anthony PERARD wrote: > Changes in V11: > - plenty of new patches, on top of the original 3 patches that were acked. > - and an attempt at creating a flight for a stable branch of openstack. But > there is many git tree to pull the branch from. And here

Re: [Xen-devel] [PATCH 06/14 v4] xen/arm: vpl011: Add a new domctl API to initialize vpl011

Hi Julien, I was mistaken in my earlier mail about vpl011 init working if it is moved to libxl__arch_domain_create(). It is failing because as you have mentioned vuart_pfn is allocated later in xc_dom_build_image(). Can we delay mapping of this page in Xen until the ring buffer is actually

[Xen-devel] blkback shutdown problem ? (Re: [linux-4.9 test] 110513: regressions - FAIL)

osstest service owner writes ("[linux-4.9 test] 110513: regressions - FAIL"): > flight 110513 linux-4.9 real [real] > http://logs.test-lab.xenproject.org/osstest/logs/110513/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: >

  1   2   >