First of all there's no point considering the "shift == width" case,
when immediately before that check we mask "shift" by "width - 1". And
then truncate_word() use can be reduced too: dst.val, as obtained by
generic operand fetching code, is already suitably truncated, and its
use can also be made
Commit d18627583d ("memory: don't hand MFN info to translated guests")
wrongly added a null-handle check there - just like stated in its
description for memory_exchange(), the array is also an input for
populate_physmap() (and hence can't reasonably be null). I have no idea
how I've managed to over
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 t
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
Applyin
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, 24 insertions(+), 2 delet
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: d
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
buil
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
close
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 question is whether Xen shoul
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 forwa
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 bo
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
test-amd64-amd64-pai
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 beca
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 the performance of
> EL0 ap
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 livepatch or not (irrespective
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 EL0 apps: I am
> assumin
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
> >>> +++ b/xen/arch/arm/arm32/livepatch.c
> >>>
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 the vGIC. If it doesn't, the
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...
>
> I can confirm that commit
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 for all other 32-bit platfor
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 mig
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)) && rb_is
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 mor
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 ty
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
> -#d
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 int vioapic_hwdom_map_g
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 88d19
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 VGIC code, so shouldn't it m
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 grepping
mfn_x().
-
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 a/xen/arch/arm/mm.c b/xe
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
test-amd64-amd64-xl
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)
Signed-off
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
Reviewed-by: Stefan
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
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/m
> 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 p
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
Reviewed-by: Stefano Stabellin
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/include/asm-
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
---
Changes in v2:
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/include/asm-arm/lpae
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 after the #endif rather than before
- A
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
Reviewed-by: Stefano Stabe
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 ca
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 insertions(+), 10 deletions(-)
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] <20170615203057.755-1-julien.gr...@arm.com
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
---
Cc: prosku...@se
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
---
Th
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
---
xen/arch/arm/setup.c | 2
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
> the commit message? Afte
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
>
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
>
> Here
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
> Signed-off-by: Andrew Morton
> Signed-off
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)
> >
> > spin_lock(&irq_map->dom->event_lock);
> >
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 (
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.
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, 2017 at 3:09 AM, Julien Grall
wrote:
>>
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
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 e
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 18.06.17 at 21:19, wrote:
On Tue, Apr 4, 2
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 ar
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 curre
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
> > git://git.kernel.org/pu
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 18.06.17 at 21:19, wrote:
>
>
>
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, wrote:
> On Tue, Apr 4, 2017 at 1:04 PM, Andrew Cooper
>
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 beca
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
wrote:
> On 04/04/17 14:14, Jan Beulich wrote:
>> We s
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
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
wrote:
On 04/04/17 14:14, Jan Beulich wrote:
We shouldn't hand MFN in
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
> -
> 1 file changed, 52 insertions(+), 1 de
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, Jan Beulich wrote:
> We shouldn't hand MFN info back from increase-reservation
>>> 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 RB root. They do not change the
>>> pointed objects, so add a 'const'
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:
On 04/04/17 14:14, Jan Beulich wrote:
>
> We shouldn't hand MFN info
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 git://xenbi
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
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 fa
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 mig
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
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 add a 'const' qualifier in order to make lif
>>> 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 easier.
>
> Indeed, if I have
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 tre
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:
https://annuel.framapad.org/p/r.0c3cc4d1e0112
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]
> > > http://logs.test-lab.xenproject.org/
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 libxl__arch_domain_crea
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 week
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?
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
> > Signed-off-by: Wei Li
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
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 CCed some
> folks who may
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, 16
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
b/tools/tests/xen-access/xen-access.c
i
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
Acked
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 ARRAY_S
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 vua
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.
>
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?
___
Xen-devel mailin
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 suc
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. Is
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 ipa
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 do that.
> >
> > It may help acceptance if
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
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
1 - 100 of 122 matches
Mail list logo