[Xen-devel] [PATCH] x86emul: simplify SHLD/SHRD handling

[Jan Beulich]

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 symmetric in the main conditional expression (on
only left shift results). Finally masking the result of a right shift
is not necessary when the left hand operand doesn't have more than
"width" significant bits.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6414,16 +6414,14 @@ x86_emulate(
 }
 if ( (shift &= width - 1) == 0 )
 break;
-dst.orig_val = truncate_word(dst.val, dst.bytes);
-dst.val = ((shift == width) ? src.val :
-   (b & 8) ?
-   /* shrd */
-   ((dst.orig_val >> shift) |
-truncate_word(src.val << (width - shift), dst.bytes)) :
-   /* shld */
-   ((dst.orig_val << shift) |
-((src.val >> (width - shift)) & ((1ull << shift) - 1;
-dst.val = truncate_word(dst.val, dst.bytes);
+dst.orig_val = dst.val;
+dst.val = (b & 8) ?
+  /* shrd */
+  ((dst.orig_val >> shift) |
+   truncate_word(src.val << (width - shift), dst.bytes)) :
+  /* shld */
+  (truncate_word(dst.orig_val << shift, dst.bytes) |
+   (src.val >> (width - shift)));
 _regs.eflags &= ~(X86_EFLAGS_OF | X86_EFLAGS_SF | X86_EFLAGS_ZF |
   X86_EFLAGS_PF | X86_EFLAGS_CF);
 if ( (dst.val >> ((b & 8) ? (shift - 1) : (width - shift))) & 1 )



x86emul: simplify SHLD/SHRD handling

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 symmetric in the main conditional expression (on
only left shift results). Finally masking the result of a right shift
is not necessary when the left hand operand doesn't have more than
"width" significant bits.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -6414,16 +6414,14 @@ x86_emulate(
 }
 if ( (shift &= width - 1) == 0 )
 break;
-dst.orig_val = truncate_word(dst.val, dst.bytes);
-dst.val = ((shift == width) ? src.val :
-   (b & 8) ?
-   /* shrd */
-   ((dst.orig_val >> shift) |
-truncate_word(src.val << (width - shift), dst.bytes)) :
-   /* shld */
-   ((dst.orig_val << shift) |
-((src.val >> (width - shift)) & ((1ull << shift) - 1;
-dst.val = truncate_word(dst.val, dst.bytes);
+dst.orig_val = dst.val;
+dst.val = (b & 8) ?
+  /* shrd */
+  ((dst.orig_val >> shift) |
+   truncate_word(src.val << (width - shift), dst.bytes)) :
+  /* shld */
+  (truncate_word(dst.orig_val << shift, dst.bytes) |
+   (src.val >> (width - shift)));
 _regs.eflags &= ~(X86_EFLAGS_OF | X86_EFLAGS_SF | X86_EFLAGS_ZF |
   X86_EFLAGS_PF | X86_EFLAGS_CF);
 if ( (dst.val >> ((b & 8) ? (shift - 1) : (width - shift))) & 1 )
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] memory: don't suppress P2M update in populate_physmap()

[Jan Beulich]

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 overlook this.

Signed-off-by: Jan Beulich 

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -248,8 +248,7 @@ static void populate_physmap(struct memo
 
 guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), a->extent_order);
 
-if ( !paging_mode_translate(d) &&
- !guest_handle_is_null(a->extent_list) )
+if ( !paging_mode_translate(d) )
 {
 for ( j = 0; j < (1U << a->extent_order); j++ )
 set_gpfn_from_mfn(mfn + j, gpfn + j);



memory: don't suppress P2M update in populate_physmap()

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 overlook this.

Signed-off-by: Jan Beulich 

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -248,8 +248,7 @@ static void populate_physmap(struct memo
 
 guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), a->extent_order);
 
-if ( !paging_mode_translate(d) &&
- !guest_handle_is_null(a->extent_list) )
+if ( !paging_mode_translate(d) )
 {
 for ( j = 0; j < (1U << a->extent_order); j++ )
 set_gpfn_from_mfn(mfn + j, gpfn + j);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 test-case:
 [PATCH v1 OSSTEST 3/3] ts-livepatch: Expand testcase to include global/local 
symbols

which expands the regression testing (and it is smart enough to not do the
test-case is the test-case file does not exist).

The Xen diff stat is as follow:

 xen/common/livepatch.c | 21 +-
 xen/include/xen/livepatch.h|  3 +-
 xen/include/xen/livepatch_elf.h|  7 +
 xen/test/livepatch/Makefile| 10 ++-
 xen/test/livepatch/xen_local_symbols.c | 52 ++
 5 files changed, 84 insertions(+), 9 deletions(-)


Konrad Rzeszutek Wilk (2):
  livepatch: Add local and global symbol resolution.
  livepatch: Add xen_local_symbols test-case


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v1 2/3] livepatch: Add xen_local_symbols test-case

[Konrad Rzeszutek Wilk]

To exercise the local/global visibility.

With "livepatch: Add local and global symbol resolution."
we can load both xen_hello_world and xen_local_symbols
without having to worry about:

-bash-4.1# xen-livepatch load xen_hello_world.livepatch
Uploading xen_hello_world.livepatch... completed
Applying xen_hello_world... completed
-bash-4.1# xen-livepatch list
 ID | status
+
xen_hello_world | APPLIED
-bash-4.1# xen-livepatch upload xen_local_symbols xen_local_symbols.livepatch
Uploading xen_local_symbols.livepatch... failed
(XEN) livepatch.c:819: livepatch: xen_local_symbols: duplicate new symbol: 
revert_hook

In fact you will see:

livepatch: xen_hello_world: new local symbol revert_hook
livepatch: xen_hello_world: new local symbol apply_hook
livepatch: xen_hello_world: new local symbol check_fnc
livepatch: xen_hello_world: new local symbol hello_world_patch_this_fnc

...
livepatch: xen_local_symbols: new local symbol revert_hook
livepatch: xen_local_symbols: new local symbol apply_hook
livepatch: xen_local_symbols: new local symbol hello_world_patch_this_fnc
..

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/test/livepatch/Makefile| 10 ++-
 xen/test/livepatch/xen_local_symbols.c | 52 ++
 2 files changed, 61 insertions(+), 1 deletion(-)
 create mode 100644 xen/test/livepatch/xen_local_symbols.c

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 6831383d..b9ad291 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -19,11 +19,13 @@ LIVEPATCH := xen_hello_world.livepatch
 LIVEPATCH_BYE := xen_bye_world.livepatch
 LIVEPATCH_REPLACE := xen_replace_world.livepatch
 LIVEPATCH_NOP := xen_nop.livepatch
+LIVEPATCH_LOCAL := xen_local_symbols.livepatch
 
 LIVEPATCHES += $(LIVEPATCH)
 LIVEPATCHES += $(LIVEPATCH_BYE)
 LIVEPATCHES += $(LIVEPATCH_REPLACE)
 LIVEPATCHES += $(LIVEPATCH_NOP)
+LIVEPATCHES += $(LIVEPATCH_LOCAL)
 
 LIVEPATCH_DEBUG_DIR ?= $(DEBUG_DIR)/xen-livepatch
 
@@ -107,5 +109,11 @@ xen_nop.o: config.h
 $(LIVEPATCH_NOP): xen_nop.o note.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
 
+xen_local_symbols.o: config.h
+
+.PHONY: $(LIVEPATCH_LOCAL)
+$(LIVEPATCH_LOCAL): xen_hello_world_func.o xen_local_symbols.o note.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_LOCAL) $^
+
 .PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP) 
$(LIVEPATCH_LOCAL)
diff --git a/xen/test/livepatch/xen_local_symbols.c 
b/xen/test/livepatch/xen_local_symbols.c
new file mode 100644
index 000..eb01b69
--- /dev/null
+++ b/xen/test/livepatch/xen_local_symbols.c
@@ -0,0 +1,52 @@
+/*
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include "config.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Same name as in xen_hello_world */
+static const char hello_world_patch_this_fnc[] = "xen_extra_version";
+extern const char *xen_hello_world(void);
+
+/*
+ * The hooks are static here (LOCAL) and also in xen_hello_world.c
+ * and their name is exactly the same.
+ */
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "local_symbols: Hook unloaded.\n");
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+struct livepatch_func __section(".livepatch.funcs") 
livepatch_xen_local_symbols = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.name = hello_world_patch_this_fnc,
+.new_addr = xen_hello_world,
+.old_addr = xen_extra_version,
+.new_size = NEW_CODE_SZ,
+.old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.9.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 deletions(-)

diff --git a/ts-livepatch-run b/ts-livepatch-run
index f119458..1eaceff 100755
--- a/ts-livepatch-run
+++ b/ts-livepatch-run
@@ -27,6 +27,7 @@ my @livepatch_files = qw(xen_hello_world.livepatch
  xen_bye_world.livepatch
 xen_nop.livepatch);
 
+my $livepatch_dir="/usr/lib/debug/xen-livepatch";
 my $xen_extra_info;
 my $xen_minor_ver;
 
@@ -128,6 +129,24 @@ my @livepatch_tests = (
 { C => "xen-livepatch unload xen_nop" },
 );
 
+my @livepatch_tests_symbols = (
+{ C => "xen-livepatch load xen_hello_world.livepatch" },
+{ C => "xen-livepatch list",
+  OutputCheck => sub { m/xen_hello_world/ } },
+{ C => "xl info",
+  OutputCheck => \&check_for_hello_world },
+# This would normally fail as xen_local_symbols has the same local
+# symbols as xen_hello_world.livepatch but with
+# "livepatch: Add local and global symbol resolution." it works.
+{ C => "xen-livepatch upload xen_local_symbols 
xen_local_symbols.livepatch" },
+{ C => "xen-livepatch replace xen_local_symbols" },
+{ C => "xl info",
+  OutputCheck => \&check_for_hello_world },
+{ C => "xen-livepatch revert xen_local_symbols" },
+{ C => "xen-livepatch unload xen_hello_world" },
+{ C => "xen-livepatch unload xen_local_symbols" },
+);
+
 our $ho = selecthost('host');
 
 sub livepatch_test () {
@@ -138,7 +157,7 @@ sub livepatch_test () {
 foreach my $test (@livepatch_tests) {
 # Default rc is zero.
 my $expected_rc = defined($test->{rc}) ? $test->{rc} : 0;
-my $cmd = "(set -e;cd /usr/lib/debug/xen-livepatch;$test->{C})";
+my $cmd = "(set -e;cd $livepatch_dir;$test->{C})";
 my ($rc, $output) = target_cmd_output_root_status($ho, $cmd);
 
 if ($rc != $expected_rc) {
@@ -158,10 +177,13 @@ sub livepatch_test () {
 
 sub livepatch_check () {
 foreach my $file (@livepatch_files) {
-if (!target_file_exists($ho, "/usr/lib/debug/xen-livepatch/$$file")) {
+if (!target_file_exists($ho, "$$livepatch_dir/$$file")) {
 die "$file is missing!\n";
 }
 }
+if (target_file_exists($ho, "$livepatch_dir/xen_local_symbols.livepatch")) 
{
+@livepatch_tests = (@livepatch_tests, @livepatch_tests_symbols);
+}
 }
 
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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: duplicate new symbol: revert_hook

when loading the new livepatch (before doing the replace).

This due to livepatch assuming that all symbols are all
global. With this patch:

readelf --symbols xen_hello_world.livepatch
File: xen_hello_world.livepatch

Symbol table '.symtab' contains 55 entries:
   Num:Value  Size TypeBind   Vis  Ndx Name
..snip..
34:  4 OBJECT  LOCAL  DEFAULT   25 cnt
35: 000a 8 OBJECT  LOCAL  DEFAULT7 __func__.4654
36: 006523 FUNCLOCAL  DEFAULT2 revert_hook
37: 007c23 FUNCLOCAL  DEFAULT2 apply_hook
38: 009354 FUNCLOCAL  DEFAULT2 check_fnc
..snip..

47: 54 FUNCGLOBAL HIDDEN 2 xen_hello_world
48:  0 NOTYPE  GLOBAL HIDDEN   UND xen_extra_version
..snip..
52:  0 NOTYPE  GLOBAL HIDDEN   UND printk
53: 64 OBJECT  GLOBAL HIDDEN23 
livepatch_xen_hello_world

All the 'GLOBAL' have to be unique per livepatch. But the
'LOCAL' can all be the same which means the semantic of 'static'
on functions and data variables is the right one.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/livepatch.c  | 21 ++---
 xen/include/xen/livepatch.h |  3 ++-
 xen/include/xen/livepatch_elf.h |  7 +++
 3 files changed, 23 insertions(+), 8 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index df67a1a..2a86218 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -181,7 +181,10 @@ unsigned long livepatch_symbols_lookup_by_name(const char 
*symname)
 if ( !data->symtab[i].new_symbol )
 continue;
 
-if ( !strcmp(data->symtab[i].name, symname) )
+if ( strcmp(data->symtab[i].name, symname) )
+continue;
+
+if ( data->symtab[i].global_symbol )
 return data->symtab[i].value;
 }
 }
@@ -791,6 +794,7 @@ static int build_symbol_table(struct payload *payload,
 symtab[nsyms].size = elf->sym[i].sym->st_size;
 symtab[nsyms].value = elf->sym[i].sym->st_value;
 symtab[nsyms].new_symbol = 0; /* May be overwritten below. */
+symtab[nsyms].global_symbol = 
livepatch_sym_is_global(elf->sym[i].sym);
 strtab_len += strlcpy(strtab + strtab_len, elf->sym[i].name,
   KSYM_NAME_LEN) + 1;
 nsyms++;
@@ -815,21 +819,24 @@ static int build_symbol_table(struct payload *payload,
 if ( symbols_lookup_by_name(symtab[i].name) ||
  livepatch_symbols_lookup_by_name(symtab[i].name) )
 {
-dprintk(XENLOG_ERR, LIVEPATCH "%s: duplicate new symbol: %s\n",
-elf->name, symtab[i].name);
+dprintk(XENLOG_ERR, LIVEPATCH "%s: duplicate new %s symbol: 
%s\n",
+elf->name, symtab[i].global_symbol ? "global" : 
"local",
+symtab[i].name);
 xfree(symtab);
 xfree(strtab);
 return -EEXIST;
 }
 symtab[i].new_symbol = 1;
-dprintk(XENLOG_DEBUG, LIVEPATCH "%s: new symbol %s\n",
- elf->name, symtab[i].name);
+dprintk(XENLOG_DEBUG, LIVEPATCH "%s: new %s symbol %s\n",
+ elf->name, symtab[i].global_symbol ? "global" : "local",
+ symtab[i].name);
 }
 else
 {
 /* new_symbol is not set. */
-dprintk(XENLOG_DEBUG, LIVEPATCH "%s: overriding symbol %s\n",
-elf->name, symtab[i].name);
+dprintk(XENLOG_DEBUG, LIVEPATCH "%s: overriding %s symbol %s\n",
+elf->name, symtab[i].global_symbol ? "global" : "local",
+symtab[i].name);
 }
 }
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 98ec012..fccff94 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -38,7 +38,8 @@ struct livepatch_symbol {
 const char *name;
 unsigned long value;
 unsigned int size;
-bool_t new_symbol;
+unsigned int new_symbol:1;
+unsigned int global_symbol:1;
 };
 
 int livepatch_op(struct xen_sysctl_livepatch_op *);
diff --git a/xen/include/xen/livepatch_elf.h b/xen/include/xen/livepatch_elf.h
index 9ad499e..870c4bc 100644
--- a/xen/include/xen/livepatch_elf.h
+++ b/xen/include/xen/livepatch_elf.h
@@ -50,6 +50,13 @@ static inline bool livepatch_elf_ignore_section(const 
Elf_Shdr *sec)
 {
 r

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

[osstest service owner]

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
 build-armhf-xsm   5 xen-buildfail REGR. vs. 110550

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 110542

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
110550
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 110542
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110550
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110550
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 build-amd64-prev  6 xen-build/dist-test  fail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 build-i386-prev   6 xen-build/dist-test  fail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 xen  2fb72b56bf0423e4b625cebc40e2dc7ea7734986
baseline version:
 xen  e197d29514165202308fe65db6effc4835aabfeb

Last test of basis   110550  2017-06-18 21:49:42 Z1 days
Testing same since   110568  2017-06-19 13:14:32 Z0 days1 attempts


People who touched revisions und

[Xen-devel] stub domain crash related to bind_interdomain

[Sarah Newman]

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(0)

It is not always remote port 0 that fails but typically is so.

We recently upgraded to xen 4.8.1. When I look at the code, what seems like the 
most likely case for failure is this check in
xen/event_channel.c:evtchn_bind_interdomain:

if ( (rchn->state != ECS_UNBOUND) ||
 (rchn->u.unbound.remote_domid != ld->domain_id) )
ERROR_EXIT_DOM(-EINVAL, rd);

But I don't know how this could happen.

Was there a fix for this since the 4.8.1 release that I missed? I was not 
successful in finding anything related in the xen-devel logs since April 10
or in the git repositories.

Please keep me CC'ed.

Thanks, Sarah

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Andrew Cooper]

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 should ever
>>> accept such a livepatch or not (irrespective of whether this exact
>>> relocation is permitted within the ELF spec).
>> Since the spec explicitly mentions that case, I think we'd better support it.
>> But it wouldn't be the end of the world if we didn't, as presumably there
>> aren't that many use cases for it.
> OK. In that case:
>
> Acked-by: Konrad Rzeszutek Wilk 
>
>
> Andrew,
>
> Do you think it would be possible to generate an test-case for this
> in arch/test/livepatch?

I can trivially cause this situation to occur with the current build
tools, but we are currently presuming a build tools bug to be the
underlying issue behind getting a STN_UNDEF relocation in the livepatch.

Given that a STN_UNDEF relocation (appears to) mean a NULL dereference
once the relocations are evaluated, I am not happy with supporting such
a case.

Therefore, I'm going to insist that we take a concrete decision as to
what to do in the hypervisor code, before adding a test case, and
advocate for excluding it outright rather than tolerating it in the
(certain?) knowledge that Xen will subsequently crash.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Stefano Stabellini]

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 forwarded interrupts (Dom0 only so far) this may lead to a
> > > deadlock with the following call chain:
> > > - MMIO access to change the IRQ affinity, calling the ITARGETSR handler
> > > - this handler takes the appropriate rank lock and calls
> > > vgic_store_itargetsr()
> > > - vgic_store_itargetsr() will eventually call vgic_migrate_irq()
> > > - if this IRQ is already in-flight, it will remove it from the old
> > >VCPU and inject it into the new one, by calling vgic_vcpu_inject_irq()
> > > - vgic_vcpu_inject_irq will call vgic_get_virq_priority()
> > > - vgic_get_virq_priority() tries to take the rank lock - again!
> > > It seems like this code path has never been exercised before.
> > > 
> > > Fix this by avoiding taking the lock in vgic_get_virq_priority() (like we
> > > do in vgic_get_target_vcpu()).
> > > Actually we are just reading one byte, and priority changes while
> > > interrupts are handled are a benign race that can happen on real hardware
> > > too. So it is safe to just prevent the compiler from reading from the
> > > struct more than once.
> > > 
> > > Signed-off-by: Andre Przywara 
> > 
> > Reviewed-by: Julien Grall 
> 
> As you mentioned in the cover letter, I think it would be good to get this
> fixed in Xen 4.9. Stefano what do you think?

Yes, I think it makes sense. Do you release-ack it?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Volodymyr Babchuk]

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 both HVC and SMC are valid conduits to call to a 
different

firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `smccc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/Makefile   |  1 +
 xen/arch/arm/smccc.c| 96 
+

 xen/arch/arm/traps.c| 10 -
 xen/include/asm-arm/smccc.h | 89 
+

 4 files changed, 194 insertions(+), 2 deletions(-)
 create mode 100644 xen/arch/arm/smccc.c
 create mode 100644 xen/include/asm-arm/smccc.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2..b8728cf 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -39,6 +39,7 @@ obj-y += psci.o
 obj-y += setup.o
 obj-y += shutdown.o
 obj-y += smc.o
+obj-y += smccc.o
 obj-y += smp.o
 obj-y += smpboot.o
 obj-y += sysctl.o
diff --git a/xen/arch/arm/smccc.c b/xen/arch/arm/smccc.c
new file mode 100644
index 000..5d10964
--- /dev/null
+++ b/xen/arch/arm/smccc.c


I would name this file vsmccc.c to show it is about virtual SMC. Also, I 
would have expected pretty everyone to use the SMCC, so I would even 
name the file vsmc.c



@@ -0,0 +1,96 @@
+/*
+ * xen/arch/arm/smccc.c
+ *
+ * Generic handler for SMC and HVC calls according to
+ * ARM SMC callling convention


s/callling/calling/


+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.


I know that some of the other headers are wrong about the GPL license. 
But Xen is GPLv2 only. Please update the copyright accordingly. I.e:


  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.


+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+
+#include 
+#include 
+#include 


Why this is included here? You don't use it.


+/* Need to include xen/sched.h before asm/domain.h or it breaks build*/


xen/sched.h will include asm/domain.h. So no need to include the latter 
here.



+#include 
+#include 
+#include 
+#include 
+#include 


You don't use this header here.


+#include 
+#include 
+
+#define XEN_SMCCC_UID ARM_SMCCC_UID(0xa71812dc, 0xc698, 0x4369, \
+0x9a, 0xcf, 0x79, 0xd1, \
+0x8d, 0xde, 0xe6, 0x67)


Please mention that this value was generated. This would avoid to wonder 
where this value comes from.



+
+/*
+ * We can't use XEN version here:
+ * Major revision should change every time SMC/HVC function is removed.
+ * Minor revision should change every time SMC/HVC function is added.
+ * So, it is SMCCC protocol revision code, not XEN version


It would be nice to say this is a requirement of the spec. Also missing 
full stop.



+ */
+#define XEN_SMCCC_MAJOR_REVISION 0
+#define XEN_SMCCC_MINOR_REVISION 1


I first thought the revision was 0.1.3 and was about to ask why. But 
then noticed XEN_SMCC_FUNCTION_COUNT is not part of the revision.


So please add a newline for clarity.


+#define XEN_SMCCC_FUNCTION_COUNT 3
+
+/* SMCCC interface for hypervisor. Tell about self */


Tell about itself. + missing full stop.

+static bool handle_hypervisor(struct cpu_user_regs *regs, const union 
hsr hsr)


hsr is already part of regs.


+{
+switch ( ARM_SMCCC_FUNC_NUM(get_user_reg(regs, 0)) )
+{
+case ARM_SMCCC_FUNC_CALL_COUNT:
+set_user_reg(regs, 0, XEN_SMCCC_FUNCTION_COUNT);
+return true;
+case ARM_SMCCC_FUNC_CALL_UID:
+set_user_reg(regs, 0, XEN_SMCCC_UID.a[0]);
+set_user_reg(r

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

[osstest service owner]

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-pair20 guest-start/debian   fail REGR. vs. 110547

Tests which did not succeed, but are not blocking:
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 build-i386-pvops  5 kernel-build fail  like 110547
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 110547
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 110547
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110547
 build-armhf-pvops 5 kernel-build fail  like 110547
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-i

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

[Konrad Rzeszutek Wilk]

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 because of the way that Makefiles
> under xen/ are invoked by their parent directory Makefiles.
> 
> Firstly, the Rules.mk `clean' target overrides the pattern rule in
> xen/test/Makefile.  The result is that `make -C xen clean' does not
> actually run the livepatch clean target.
> 
> The Rules.mk clean target does have provision for recursing into
> subdirectories, but that feature is tangled up with complex object
> file iteration machinery which is not desirable here.  However, we can
> extend the Rules.mk clean target since it is a double-colon rules.
> 
> Sadly this involves duplicating the SUBDIR iteration boilerplate.  (A
> make function could be used but the cure would be worse than the
> disease.)
> 
> Secondly, Rules.mk has a number of -include directives.  make likes to
> try to (re)build files mentioned in includes.  With the % pattern
> rule, this applies to those files too.
> 
> As a result, make -C xen clean would try to build `.*.d' (for example)
> in xen/test.  This would fail with an error message.  The error would
> be ignored because of the `-', but it's annoying and ugly.
> 
> Solve this by limiting the % pattern rule to the targets we expect it
> to handle.  These are those listed in the top-level Makefile, apart
> from: those which are subdir- or component-qualified; clean targets
> (which are handled specially, even distclean); and dist,
> src-tarball-*, etc. (which are converted to install by an earlier
> Makefile).
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Ian Jackson 

And
Tested-by: Konrad Rzeszutek Wilk 

> ---
>  xen/test/Makefile | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/test/Makefile b/xen/test/Makefile
> index aa1a23b..aaa4996 100644
> --- a/xen/test/Makefile
> +++ b/xen/test/Makefile
> @@ -7,7 +7,12 @@ ifneq ($(XEN_TARGET_ARCH),x86_32)
>  SUBDIRS += livepatch
>  endif
>  
> -%:
> +install build subtree-force-update uninstall: %:
>   set -e; for s in $(SUBDIRS); do \
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $*; \
>   done
> +
> +clean::
> + set -e; for s in $(SUBDIRS); do \
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $@; \
> + done
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Volodymyr Babchuk]

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 apps vs. stubdoms with a PoC, which is much more than most Xen
> contributors do. Nodoby provided numbers for a faster ARM context switch
> yet. I don't know on whom should fall the burden of proving that a
> lighter context switch can match the EL0 app numbers. I am not sure it
> would be fair to ask Volodymyr to do it.
Thanks. Actually, we discussed this topic internally today. Main
concern today is not a SMCs and OP-TEE (I will be happy to do this
right in XEN), but vcopros and GPU virtualization. Because of legal
issues, we can't put this in XEN. And because of vcpu framework nature
we will need multiple calls to vgpu driver per one vcpu context
switch.
I'm going to create worst case scenario, where multiple vcpu are
active and there are no free pcpu, to see how credit or credit2
scheduler will call my stubdom.
Also, I'm very interested in Julien's idea about stubdom without GIC.
Probably, I'll try to hack something like that to see how it will
affect overall switching latency.

-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 of whether this exact
> >relocation is permitted within the ELF spec).
> 
> Since the spec explicitly mentions that case, I think we'd better support it.
> But it wouldn't be the end of the world if we didn't, as presumably there
> aren't that many use cases for it.

OK. In that case:

Acked-by: Konrad Rzeszutek Wilk 


Andrew,

Do you think it would be possible to generate an test-case for this
in arch/test/livepatch?

> 
> Jan
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Volodymyr Babchuk]

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
> assuming that EL0 apps don't need to handle interrupts, but if they do,
> then they might need something like a vGIC.
 Hm. Correct me, but if we want make stubdom to handle some requests
 (e.g. emulate MMIO access), then it needs events, and thus it needs
 interrupts. At least, I'm not aware about any other mechanism, that
 allows hypervisor to signal to a domain.
 On other hand, EL0 app (as I see them) does not need such events.
 Basically, you just call function `handle_mmio()` right in the app.
 So, apps can live without interrupts and they still be able to handle
 request.
>>>
>>> So remember that "interrupt" and "event" are basically the same as
>>> "structured callback".  When anything happens that Xen wants to tell the
>>> EL0 app about, it has to have a way of telling it.  If the EL0 app is
>>> handling a device, it has to have some way of getting interrupts from
>>> that device; if it needs to emulate devices sent to the guest, it needs
>>> some way to tell Xen to deliver an interrupt to the guest.
>> Basically yes. There should be mechanism to request something from
>> native application. Question is how this mechanism can be implemented.
>> Classical approach is a even-driven loop:
>>
>> while(1) {
>> wait_for_event();
>> handle_event_event();
>> return_back_results();
>> }
>>
>> wait_for_event() can by anything from WFI instruction to read() on
>> socket. This is how stubdoms are working. I agree with you: there are
>> no sense to repeat this in native apps.
>>
>>> Now, we could make the EL0 app interface "interruptless".  Xen could
>>> write information about pending events in a shared memory region, and
>>> the EL0 app could check that before calling some sort of block()
>>> hypercall, and check it again when it returns from the block() call.
>>
>>> But the shared event information starts to look an awful lot like events
>>> and/or pending bits on an interrupt controller -- the only difference
>>> being that you aren't interrupted if you're already running.
>>
>> Actually there are third way, which I have used. I described it in
>> original email (check out [1]).
>> Basically, native application is dead until it is needed by
>> hypervisor. When hypervisor wants some services from app, it setups
>> parameters, switches mode to EL0 and jumps at app entry point.
>
> What's the difference between "jumps to an app entry point" and "jumps
> to an interrupt handling routine"?
"Jumps to an app entry point" and "Unblocks vcpu that waits for an
interrupt". That would be more precise. There are two differences:
first approach is synchronous, no need to wait scheduler to schedule
vcpu. Also vGIC code can be omitted, which decreases switch latency.


>  And what's the difference between
> "Tells Xen about the location of the app entry point" and "tells Xen
> about the location of the interrupt handling routine"?
There are no difference at all.

> If you want this "EL0 app" thing to be able to provide extra security
> over just running the code inside of Xen, then the code must not be able
> to DoS the host by spinning forever instead of returning.
Right. This is a problem. Fortunately, it is running with interrupts
enabled, so next timer tick will switch back to XEN. There you can
terminate app which is running too long.

> What happens if two different pcpus in Xen decide they want to activate
> some "app" functionality?
There are two possibilities: we can make app single threaded, then
second pcpu can be assigned with another vcpu until app is busy. But I
don't like this approach.
I think that all apps should be multi threaded. They can use simple
spinlocks to control access to shared resources.

>>> I'm pretty sure you could run in this mode using the existing interfaces
>>> if you didn't want the hassle of dealing with asynchrony.  If that's the
>>> case, then why bother inventing an entirely new interface, with its own
>>> bugs and duplication of functionality?  Why not just use what we already
>>> have?
>> Because we are concerned about latency. In my benchmark, my native app
>> PoC is 1.6 times faster than stubdom.
>
> 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.
Yes. Question is: can context switching in ARM be optimized more? I don't know.

> Just to be clear -- I'm not adamantly opposed to a new interface similar
> to what you're describing above.  But I would be opposed to introducing
> a new interface that doesn't achieve the stated goals (more secure, &c),
> or a new interface that is the same as the old one but rewritten a bit.
>
> The point of having this desig

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

[Konrad Rzeszutek Wilk]

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
> >>> @@ -224,21 +224,21 @@ int arch_livepatch_perform(struct livepatch_elf 
> >>> *elf,
> >>> const struct livepatch_elf_sec *rela,
> >>> bool use_rela)
> >>>  {
> >>> -const Elf_RelA *r_a;
> >>> -const Elf_Rel *r;
> >>> -unsigned int symndx, i;
> >>> -uint32_t val;
> >>> -void *dest;
> >>> +unsigned int i;
> >>>  int rc = 0;
> >>>  
> >>>  for ( i = 0; i < (rela->sec->sh_size / rela->sec->sh_entsize); i++ )
> >>>  {
> >>> +unsigned int symndx;
> >>> +uint32_t val;
> >>> +void *dest;
> >>>  unsigned char type;
> >>> -s32 addend = 0;
> >>> +s32 addend;
> >>>  
> >>>  if ( use_rela )
> >>>  {
> >>> -r_a = rela->data + i * rela->sec->sh_entsize;
> >>> +const Elf_RelA *r_a = rela->data + i * rela->sec->sh_entsize;
> >>> +
> >>>  symndx = ELF32_R_SYM(r_a->r_info);
> >>>  type = ELF32_R_TYPE(r_a->r_info);
> >>>  dest = base->load_addr + r_a->r_offset; /* P */
> >>> @@ -246,10 +246,12 @@ int arch_livepatch_perform(struct livepatch_elf 
> >>> *elf,
> >>>  }
> >>>  else
> >>>  {
> >>> -r = rela->data + i * rela->sec->sh_entsize;
> >>> +const Elf_Rel *r = rela->data + i * rela->sec->sh_entsize;
> >>> +
> >>>  symndx = ELF32_R_SYM(r->r_info);
> >>>  type = ELF32_R_TYPE(r->r_info);
> >>>  dest = base->load_addr + r->r_offset; /* P */
> >>> +addend = get_addend(type, dest);
> >>>  }
> >>>  
> >>>  if ( symndx > elf->nsym )
> >>> @@ -259,13 +261,11 @@ int arch_livepatch_perform(struct livepatch_elf 
> >>> *elf,
> >>>  return -EINVAL;
> >>>  }
> >>>  
> >>> -if ( !use_rela )
> >>> -addend = get_addend(type, dest);
> >> This was added right after the symndx > elf->nsym check as
> >> way to make sure we won't dereference the dest (b/c the symbol
> >> may be outside the bounds).
> > But symndx isn't being used here.
> 
> Indeed.  r->r_offset (and therefore dest) has no direct bearing on symndx.

/me nods.
> 
> Having said that, there is no sanity check that r->r_offset is within
> base->load_addr + sec->sh_size in arm32, whereas both arm64 and x86
> appear to do this check.

True.

And the tricky part (it was to me at least) was that ARM32 is all
REL and not RELA so the opcode gets modified after the operation.

Which means it gets a bit complex to add a boundary check in
'get_addend' .

Hm, it would seem the best way is to add a

if ( r->r_offset >= base->sec->sh_size ||   
(r->r_offset + sizeof(uint32_t)) > base->sec->sh_size ) 

that is common for use_rela and not.

Anyhow I can do that as I would want to check this
on real hardware :-)

For your patch (as is)
Acked-by: Konrad Rzeszutek Wilk 

Are you OK committing it in?
> 
> ~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Stefano Stabellini]

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, then we can skip the
>  vGIC. However, we would have a similar problem with EL0 apps: I am
>  assuming that EL0 apps don't need to handle interrupts, but if they do,
>  then they might need something like a vGIC.
> >>> Hm. Correct me, but if we want make stubdom to handle some requests
> >>> (e.g. emulate MMIO access), then it needs events, and thus it needs
> >>> interrupts. At least, I'm not aware about any other mechanism, that
> >>> allows hypervisor to signal to a domain.
> >>> On other hand, EL0 app (as I see them) does not need such events.
> >>> Basically, you just call function `handle_mmio()` right in the app.
> >>> So, apps can live without interrupts and they still be able to handle
> >>> request.
> >>
> >> So remember that "interrupt" and "event" are basically the same as
> >> "structured callback".  When anything happens that Xen wants to tell the
> >> EL0 app about, it has to have a way of telling it.  If the EL0 app is
> >> handling a device, it has to have some way of getting interrupts from
> >> that device; if it needs to emulate devices sent to the guest, it needs
> >> some way to tell Xen to deliver an interrupt to the guest.
> > Basically yes. There should be mechanism to request something from
> > native application. Question is how this mechanism can be implemented.
> > Classical approach is a even-driven loop:
> > 
> > while(1) {
> > wait_for_event();
> > handle_event_event();
> > return_back_results();
> > }
> > 
> > wait_for_event() can by anything from WFI instruction to read() on
> > socket. This is how stubdoms are working. I agree with you: there are
> > no sense to repeat this in native apps.
> > 
> >> Now, we could make the EL0 app interface "interruptless".  Xen could
> >> write information about pending events in a shared memory region, and
> >> the EL0 app could check that before calling some sort of block()
> >> hypercall, and check it again when it returns from the block() call.
> > 
> >> But the shared event information starts to look an awful lot like events
> >> and/or pending bits on an interrupt controller -- the only difference
> >> being that you aren't interrupted if you're already running.
> > 
> > Actually there are third way, which I have used. I described it in
> > original email (check out [1]).
> > Basically, native application is dead until it is needed by
> > hypervisor. When hypervisor wants some services from app, it setups
> > parameters, switches mode to EL0 and jumps at app entry point.
> 
> What's the difference between "jumps to an app entry point" and "jumps
> to an interrupt handling routine"?  And what's the difference between
> "Tells Xen about the location of the app entry point" and "tells Xen
> about the location of the interrupt handling routine"?
> 
> If you want this "EL0 app" thing to be able to provide extra security
> over just running the code inside of Xen, then the code must not be able
> to DoS the host by spinning forever instead of returning.

I think that the "extra security" was mostly Julien's and my goal.
Volodymyr would be OK with having the code in Xen, if I recall correctly
from past conversations.

In any case, wouldn't the usual Xen timer interrupt prevent this scenario
from happening?


> What happens if two different pcpus in Xen decide they want to activate
> some "app" functionality?

It should work fine as long as the app code is written to be able to
cope with it (spin_locks, etc).


> >> I'm pretty sure you could run in this mode using the existing interfaces
> >> if you didn't want the hassle of dealing with asynchrony.  If that's the
> >> case, then why bother inventing an entirely new interface, with its own
> >> bugs and duplication of functionality?  Why not just use what we already
> >> have?
> > Because we are concerned about latency. In my benchmark, my native app
> > PoC is 1.6 times faster than stubdom.
> 
> 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 apps vs. stubdoms with a PoC, which is much more than most Xen
contributors do. Nodoby provided numbers for a faster ARM context switch
yet. I don't know on whom should fall the burden of proving that a
lighter context switch can match the EL0 app numbers. I am not sure it
would be fair to ask Volodymyr to do it.


> Just to be clear -- I'm not adamantly opposed to a new interface similar
> to what you're describing above.  But I would be opposed to introducing
> a new interface that doesn't achieve the stated goals (more secure, &c),
> or a new interface that is the 

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

[Al Viro]

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 fixes the build for m68k.
> Let's hope it fixes the build for all other 32-bit platforms, too ;-)
> 
> If I'm not mistaken, the commit that caused the breakage was never part of
> linux-next before it entered mainline?
> Can you please make sure all commits cook a few days in linux-next before
> they are sent upstream?

It's not an excuse, but I got too used to 0-day buildbot catching that kind
of stuff within a day or so ;-/  Should've done cross-builds myself, of course -
my fault...

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Geert Uytterhoeven]

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 platforms, too ;-)

If I'm not mistaken, the commit that caused the breakage was never part of
linux-next before it entered mainline?
Can you please make sure all commits cook a few days in linux-next before
they are sent upstream?

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  461b2165346de236fff2d00d1c318062f1daab08
baseline version:
 xen  2d78f78a14528752266982473c07118f1bc336e3

Last test of basis   110567  2017-06-19 12:01:58 Z0 days
Testing same since   110573  2017-06-19 15:01:32 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=461b2165346de236fff2d00d1c318062f1daab08
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
461b2165346de236fff2d00d1c318062f1daab08
+ branch=xen-unstable-smoke
+ revision=461b2165346de236fff2d00d1c318062f1daab08
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x461b2165346de236fff2d00d1c318062f1daab08 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.

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

[Dario Faggioli]

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_red(parent))
> +while (true)
>  {
>
And here we are again. (I.e., in the cited Linux's commit, this is
being turned into 'while (true) {`.

So, I think we should gather others' opinion about how to deal with
these aspects of this series. So, I'll stop my review for now, and
chase feedback.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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 more.  However at that point the node's parent would always be
> black,
> which would cause us to exit the loop.
> 
> We can make the code flow more obvious by just adding a break
> statement
> after the tree rotations, where we know we are done.  Additionally,
> in the
> cases where two tree rotations are necessary, we don't have to update
> the
> 'node' pointer as it wouldn't be used until the next loop iteration,
> which
> we now avoid due to this break statement.
> 
> Signed-off-by: Michel Lespinasse 
> Cc: Andrea Arcangeli 
> Acked-by: David Woodhouse 
> Cc: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Daniel Santos 
> Cc: Jens Axboe 
> Cc: "Eric W. Biederman" 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 1f0528653e41ec230c60f5738820e8a544731399]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
Now the patch has all the hunks. There's again some difference in '{'
placement, though, between this patch and the Linux commit.

More specifically, in the Linux commit, this:
> --- a/xen/common/rbtree.c
> +++ b/xen/common/rbtree.c
> @@ -110,16 +110,14 @@ void rb_insert_color(struct rb_node *node,
> struct rb_root *root)
>  
>  if (parent->rb_right == node)
>  {
>
Becomes:

  if (parent->rb_right == node) {

I appreciate that you may not be applying this specific modification
because the Xen style is different. But I actually think you should, as
this file is going to end up being mixed style anyway, so I'd
prioritize staying identical to Linux's commit.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 typesafe MFN.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 

Acked-by: Konrad Rzeszutek Wilk 

> ---
> 
> Cc: Ross Lagerwall 
> Cc: Konrad Rzeszutek Wilk 
> 
> Changes in v2:
> - Add Stefano's reviewed-by
> - Still missing an ack from Konrad and/or Ross.
> ---
>  xen/arch/arm/livepatch.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
> index de95e54744..3e53524365 100644
> --- a/xen/arch/arm/livepatch.c
> +++ b/xen/arch/arm/livepatch.c
> @@ -12,6 +12,10 @@
>  #include 
>  #include 
>  
> +/* Override macros from asm/page.h to make them work with mfn_t */
> +#undef virt_to_mfn
> +#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> +
>  void *vmap_of_xen_text;
>  
>  int arch_livepatch_quiesce(void)
> @@ -22,7 +26,7 @@ int arch_livepatch_quiesce(void)
>  if ( vmap_of_xen_text )
>  return -EINVAL;
>  
> -text_mfn = _mfn(virt_to_mfn(_start));
> +text_mfn = virt_to_mfn(_start);
>  text_order = get_order_from_bytes(_end - _start);
>  
>  /*
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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
> -#define RB_BLACK 1
> +unsigned long  __rb_parent_color;
>  struct rb_node *rb_right;
>  struct rb_node *rb_left;
>  };
> @@ -33,21 +31,7 @@ struct rb_root
>
...this struct here into:

struct rb_root {

The rest looks ok to me.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Roger Pau Monne]

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_gsi(unsigned int gsi, unsigned int trig,
> > + unsigned int pol)
> > +{
> > +struct domain *d = current->domain;
> 
> currd or curr_d please. With that
> Reviewed-by: Jan Beulich 

I've changed it and added your RB, thanks.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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 88d19cf37952 ("timers: Add rb_init_node() to allow for stack
> allocated rb nodes") to avoid some issue with the empty node's color
> not
> being initialized.
> 
> I'm not sure what the RB_EMPTY_NODE checks in rb_prev() / rb_next()
> are
> doing there, though.  axboe introduced them in commit 10fd48f2376d
> ("rbtree: fixed reversed RB_EMPTY_NODE and rb_next/prev").  The way I
> see it, the 'empty node' abstraction is only used by rbtree users to
> flag nodes that they haven't inserted in any rbtree, so asking the
> predecessor or successor of such nodes doesn't make any sense.
> 
> One final rb_init_node() caller was recently added in sysctl code to
> implement faster sysctl name lookups.  This code doesn't make use of
> RB_EMPTY_NODE at all, and from what I could see it only called
> rb_init_node() under the mistaken assumption that such initialization
> was
> required before node insertion.
> 
> [s...@canb.auug.org.au: fix net/ceph/osd_client.c build]
> Signed-off-by: Michel Lespinasse 
> Cc: Andrea Arcangeli 
> Acked-by: David Woodhouse 
> Cc: Rik van Riel 
> Cc: Peter Zijlstra 
> Cc: Daniel Santos 
> Cc: Jens Axboe 
> Cc: "Eric W. Biederman" 
> Cc: John Stultz 
> Signed-off-by: Stephen Rothwell 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 4c199a93a2d36b277a9fd209a0f2793f8460a215]
> 
> Ported rbtree.h and rbtree.c changes which are relevant to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
I was about to say:

Reviewed-by: Dario Faggioli 

Although...

> diff --git a/xen/include/xen/rbtree.h b/xen/include/xen/rbtree.h
> index 3eb527eb37..f74b68ce62 100644
> --- a/xen/include/xen/rbtree.h
> +++ b/xen/include/xen/rbtree.h
> @@ -52,9 +52,12 @@ static inline void rb_set_color(struct rb_node
> *rb, int color)
>  #define RB_ROOT (struct rb_root) { NULL, }
>  #define rb_entry(ptr, type, member) container_of(ptr, type, member)
>  
> -#define RB_EMPTY_ROOT(root) ((root)->rb_node == NULL)
> -#define RB_EMPTY_NODE(node) (rb_parent(node) == node)
> -#define RB_CLEAR_NODE(node) (rb_set_parent(node, node))
> +#define RB_EMPTY_ROOT(root)  ((root)->rb_node == NULL)
> +
> +/* 'empty' nodes are nodes that are known not to be inserted in an
> rbree */
> +#define RB_EMPTY_NODE(node)  ((node)->rb_parent_color == (unsigned
> long)(node))
> +#define RB_CLEAR_NODE(node)  ((node)->rb_parent_color = (unsigned
> long)(node))
> +
> 
...There's again divergence between this patch and Linux's commit (in
this case, there is one blank line added, which is not in Linux patch).

I'm again uncertain about the severity of this, and about the best
course of action, but please, try to avoid things like this... When
reviewing patches like this, it's very hard to spot the differences,
and these only add noise, and make it even harder :-/

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Andre Przywara]

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 mention both in the first line of
>> the commit message? After all this patch really has not much to do with
>> vpl011.
>>
> I will modify the commit message to indicate this commit renames
> vgic_reg* to vreg_reg*
> and modifies all the places where this call is made.

Thanks!

>> On 06/06/17 18:25, Bhupinder Thakur wrote:
>>> This patch redefines the vgic_reg* access functions to vreg_reg* functions.
>>> These are generic functions, which will be used by the vgic emulation code
>>> to access the vgic registers.
>>>
>>> PL011 emulation code will also use vreg_reg* access functions.
>>
>> Also I am sorry to be the bearer of bad news (and also for being the
>> origin of this), but I am afraid you have to rework this when you rebase
>> it against origin/staging, since the ITS emulation has been merged.
>> So while actual conflicts seem to be trivial, there are now many new
>> users of vgic_reg??_* which you have to change as well.
>> Should be rather mechanical, though.
>>
> I will rebase it on origin/staging and merge the changes.

Thanks - and sorry for the mess ;-)

> How do I
> enable ITS code compilation to verify that it is compiling fine with
> new vreg_reg* functions? Is ITS code not compiled in by default?

You need to add "XEN_CONFIG_EXPERT=y" to every make invocation, so both
for any configuration and for the actual build.
If it doesn't prompt you for the ITS, please type:
$ make -C xen menuconfig XEN_CONFIG_EXPERT=y
then select "GICv3 ITS MSI controller support" under "Architecture
Features" (should only be needed once).
You should check xen/.config for having a line with "CONFIG_HAS_ITS=y".

Cheers,
Andre.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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().
---
 xen/arch/arm/mm.c| 16 
 xen/arch/arm/setup.c | 18 +-
 xen/include/asm-arm/mm.h | 11 ++-
 3 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 7b313ca123..452c1e26c3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -138,8 +138,8 @@ uint64_t init_ttbr;
 static paddr_t phys_offset;
 
 /* Limits of the Xen heap */
-unsigned long xenheap_mfn_start __read_mostly = ~0UL;
-unsigned long xenheap_mfn_end __read_mostly;
+mfn_t xenheap_mfn_start __read_mostly = INVALID_MFN;
+mfn_t xenheap_mfn_end __read_mostly;
 vaddr_t xenheap_virt_end __read_mostly;
 #ifdef CONFIG_ARM_64
 vaddr_t xenheap_virt_start __read_mostly;
@@ -801,8 +801,8 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 
 /* Record where the xenheap is, for translation routines. */
 xenheap_virt_end = XENHEAP_VIRT_START + nr_mfns * PAGE_SIZE;
-xenheap_mfn_start = base_mfn;
-xenheap_mfn_end = base_mfn + nr_mfns;
+xenheap_mfn_start = _mfn(base_mfn);
+xenheap_mfn_end = _mfn(base_mfn + nr_mfns);
 }
 #else /* CONFIG_ARM_64 */
 void __init setup_xenheap_mappings(unsigned long base_mfn,
@@ -816,16 +816,16 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 mfn = base_mfn & ~((FIRST_SIZE>>PAGE_SHIFT)-1);
 
 /* First call sets the xenheap physical and virtual offset. */
-if ( xenheap_mfn_start == ~0UL )
+if ( mfn_eq(xenheap_mfn_start, INVALID_MFN) )
 {
-xenheap_mfn_start = base_mfn;
+xenheap_mfn_start = _mfn(base_mfn);
 xenheap_virt_start = DIRECTMAP_VIRT_START +
 (base_mfn - mfn) * PAGE_SIZE;
 }
 
-if ( base_mfn < xenheap_mfn_start )
+if ( base_mfn < mfn_x(xenheap_mfn_start) )
 panic("cannot add xenheap mapping at %lx below heap start %lx",
-  base_mfn, xenheap_mfn_start);
+  base_mfn, mfn_x(xenheap_mfn_start));
 
 end_mfn = base_mfn + nr_mfns;
 
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index ab4d8e4218..3b34855668 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -555,8 +555,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
  * and enough mapped pages for copying the DTB.
  */
 dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
-boot_mfn_start = xenheap_mfn_end - dtb_pages - 1;
-boot_mfn_end = xenheap_mfn_end;
+boot_mfn_start = mfn_x(xenheap_mfn_end) - dtb_pages - 1;
+boot_mfn_end = mfn_x(xenheap_mfn_end);
 
 init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
 
@@ -591,11 +591,11 @@ static void __init setup_mm(unsigned long dtb_paddr, 
size_t dtb_size)
 e = bank_end;
 
 /* Avoid the xenheap */
-if ( s < pfn_to_paddr(xenheap_mfn_start+xenheap_pages)
- && pfn_to_paddr(xenheap_mfn_start) < e )
+if ( s < mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages))
+ && mfn_to_maddr(xenheap_mfn_start) < e )
 {
-e = pfn_to_paddr(xenheap_mfn_start);
-n = pfn_to_paddr(xenheap_mfn_start+xenheap_pages);
+e = mfn_to_maddr(xenheap_mfn_start);
+n = mfn_to_maddr(mfn_add(xenheap_mfn_start, xenheap_pages));
 }
 
 dt_unreserved_regions(s, e, init_boot_pages, 0);
@@ -610,7 +610,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 
 /* Add xenheap memory that was not already added to the boot
allocator. */
-init_xenheap_pages(pfn_to_paddr(xenheap_mfn_start),
+init_xenheap_pages(mfn_to_maddr(xenheap_mfn_start),
pfn_to_paddr(boot_mfn_start));
 }
 #else /* CONFIG_ARM_64 */
@@ -662,8 +662,8 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 total_pages += ram_size >> PAGE_SHIFT;
 
 xenheap_virt_end = XENHEAP_VIRT_START + ram_end - ram_start;
-xenheap_mfn_start = ram_start >> PAGE_SHIFT;
-xenheap_mfn_end = ram_end >> PAGE_SHIFT;
+xenheap_mfn_start = maddr_to_mfn(ram_start);
+xenheap_mfn_end = maddr_to_mfn(ram_end);
 
 /*
  * Need enough mapped pages for copying the DTB.
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 274b1752b3..b2e7ea7761 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -115,7 +115,7 @@ struct page_info
 #define PGC_count_width   PG_shift(9)
 #define PGC_count_mask((1UL<= xenheap_mfn_start && _mfn < xenheap_mfn_end);  \
+(_mfn >= mfn_x(xenheap_mfn_start) &&\
+ _mfn < mfn_x(xenheap_mfn_end));  

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

[Julien Grall]

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/xen/arch/arm/mm.c
index 8d34ae7279..6241c53821 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -991,8 +991,7 @@ static int create_xen_entries(enum xenmap_operation op,
 
 for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
-if ( !xen_second[second_linear_offset(addr)].pt.valid ||
- !xen_second[second_linear_offset(addr)].pt.table )
+if ( !lpae_table(xen_second[second_linear_offset(addr)]) )
 {
 rc = create_xen_table(&xen_second[second_linear_offset(addr)]);
 if ( rc < 0 ) {
@@ -1001,14 +1000,14 @@ static int create_xen_entries(enum xenmap_operation op,
 }
 }
 
-BUG_ON(!xen_second[second_linear_offset(addr)].pt.valid);
+BUG_ON(!lpae_valid(xen_second[second_linear_offset(addr)]));
 
 third = mfn_to_virt(xen_second[second_linear_offset(addr)].pt.base);
 
 switch ( op ) {
 case INSERT:
 case RESERVE:
-if ( third[third_table_offset(addr)].pt.valid )
+if ( lpae_valid(third[third_table_offset(addr)]) )
 {
 printk("create_xen_entries: trying to replace an existing 
mapping addr=%lx mfn=%"PRI_mfn"\n",
addr, mfn_x(mfn));
@@ -1022,7 +1021,7 @@ static int create_xen_entries(enum xenmap_operation op,
 break;
 case MODIFY:
 case REMOVE:
-if ( !third[third_table_offset(addr)].pt.valid )
+if ( !lpae_valid(third[third_table_offset(addr)]) )
 {
 printk("create_xen_entries: trying to %s a non-existing 
mapping addr=%lx\n",
op == REMOVE ? "remove" : "modify", addr);
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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-qemuu-win7-amd64 14 guest-saverestore.2 fail REGR. vs. 
110515
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
110515
 build-armhf-pvops 5 kernel-build fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu

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

[Julien Grall]

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-by: Julien Grall 
Acked-by: Tim Deegan 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v2:
- Add Tim's acked
- The solution suggested in v1 is also working for non-debug
build. So keep the code as it is.
---
 xen/include/xen/mm.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index c9198232e2..e61b6e991c 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -56,7 +56,7 @@
 
 TYPE_SAFE(unsigned long, mfn);
 #define PRI_mfn  "05lx"
-#define INVALID_MFN  _mfn(~0UL)
+#define INVALID_MFN  (mfn_t){ ~0UL }
 
 #ifndef mfn_t
 #define mfn_t /* Grep fodder: mfn_t, _mfn() and mfn_x() are defined above */
@@ -89,7 +89,7 @@ static inline bool_t mfn_eq(mfn_t x, mfn_t y)
 
 TYPE_SAFE(unsigned long, gfn);
 #define PRI_gfn  "05lx"
-#define INVALID_GFN  _gfn(~0UL)
+#define INVALID_GFN  (gfn_t){ ~0UL }
 
 #ifndef gfn_t
 #define gfn_t /* Grep fodder: gfn_t, _gfn() and gfn_x() are defined above */
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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: Stefano Stabellini 
---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/domain_build.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c6776d76fc..1bec4fa23d 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -45,6 +45,10 @@ struct map_range_data
 p2m_type_t p2mt;
 };
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -1903,7 +1907,7 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
 rc = map_regions_p2mt(d,
   gaddr_to_gfn(d->arch.efi_acpi_gpa),
   PFN_UP(d->arch.efi_acpi_len),
-  _mfn(virt_to_mfn(d->arch.efi_acpi_table)),
+  virt_to_mfn(d->arch.efi_acpi_table),
   p2m_mmio_direct_c);
 if ( rc != 0 )
 {
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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/mm.c
@@ -996,7 +996,7 @@ static int create_xen_entries(enum xenmap_operation op,
 {
 rc = create_xen_table(entry);
 if ( rc < 0 ) {
-printk("create_xen_entries: L2 failed\n");
+printk("%s: L2 failed\n", __func__);
 goto out;
 }
 }
@@ -1011,8 +1011,8 @@ static int create_xen_entries(enum xenmap_operation op,
 case RESERVE:
 if ( lpae_valid(*entry) )
 {
-printk("create_xen_entries: trying to replace an existing 
mapping addr=%lx mfn=%"PRI_mfn"\n",
-   addr, mfn_x(mfn));
+printk("%s: trying to replace an existing mapping addr=%lx 
mfn=%"PRI_mfn"\n",
+   __func__, addr, mfn_x(mfn));
 return -EINVAL;
 }
 if ( op == RESERVE )
@@ -1025,8 +1025,8 @@ static int create_xen_entries(enum xenmap_operation op,
 case REMOVE:
 if ( !lpae_valid(*entry) )
 {
-printk("create_xen_entries: trying to %s a non-existing 
mapping addr=%lx\n",
-   op == REMOVE ? "remove" : "modify", addr);
+printk("%s: trying to %s a non-existing mapping 
addr=%lx\n",
+   __func__, op == REMOVE ? "remove" : "modify", addr);
 return -EINVAL;
 }
 if ( op == REMOVE )
@@ -1038,8 +1038,8 @@ static int create_xen_entries(enum xenmap_operation op,
 pte.pt.xn = PTE_NX_MASK(ai);
 if ( !pte.pt.ro && !pte.pt.xn )
 {
-printk("create_xen_entries: Incorrect combination for 
addr=%lx\n",
-   addr);
+printk("%s: Incorrect combination for addr=%lx\n",
+   __func__, addr);
 return -EINVAL;
 }
 }
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

> 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 possible to do?

Never mind, evidently XENMEM_remove_from_physmap seems to be the
answer, it just lacks a libxc wrapper so I didn't notice it.

Cheers,
Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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 Stabellini 
---

Cc: Ross Lagerwall 
Cc: Konrad Rzeszutek Wilk 

Changes in v2:
- Add Stefano's reviewed-by
- Still missing an ack from Konrad and/or Ross.
---
 xen/arch/arm/livepatch.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index de95e54744..3e53524365 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -12,6 +12,10 @@
 #include 
 #include 
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
 void *vmap_of_xen_text;
 
 int arch_livepatch_quiesce(void)
@@ -22,7 +26,7 @@ int arch_livepatch_quiesce(void)
 if ( vmap_of_xen_text )
 return -EINVAL;
 
-text_mfn = _mfn(virt_to_mfn(_start));
+text_mfn = virt_to_mfn(_start);
 text_order = get_order_from_bytes(_end - _start);
 
 /*
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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-arm/lpae.h | 25 +
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1136d837fb..f9145f052f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -52,29 +52,6 @@ static const paddr_t level_masks[] =
 static const uint8_t level_orders[] =
 { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
 
-static inline bool_t lpae_valid(lpae_t pte)
-{
-return pte.walk.valid;
-}
-/*
- * These two can only be used on L0..L2 ptes because L3 mappings set
- * the table bit and therefore these would return the opposite to what
- * you would expect.
- */
-static inline bool_t lpae_table(lpae_t pte)
-{
-return lpae_valid(pte) && pte.walk.table;
-}
-static inline bool_t lpae_mapping(lpae_t pte)
-{
-return lpae_valid(pte) && !pte.walk.table;
-}
-
-static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
-{
-return (level < 3) && lpae_mapping(pte);
-}
-
 static void p2m_flush_tlb(struct p2m_domain *p2m);
 
 /* Unlock the flush and do a P2M TLB flush if necessary */
diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index aa85cb8112..6fbf7c606c 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -126,6 +126,31 @@ typedef union {
 lpae_walk_t walk;
 } lpae_t;
 
+static inline bool_t lpae_valid(lpae_t pte)
+{
+return pte.walk.valid;
+}
+
+/*
+ * These two can only be used on L0..L2 ptes because L3 mappings set
+ * the table bit and therefore these would return the opposite to what
+ * you would expect.
+ */
+static inline bool_t lpae_table(lpae_t pte)
+{
+return lpae_valid(pte) && pte.walk.table;
+}
+
+static inline bool_t lpae_mapping(lpae_t pte)
+{
+return lpae_valid(pte) && !pte.walk.table;
+}
+
+static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
+{
+return (level < 3) && lpae_mapping(pte);
+}
+
 #endif /* __ASSEMBLY__ */
 
 /*
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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:
- Add Stefano's reviewed-by
---
 xen/arch/arm/mm.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 5612834dfc..8d34ae7279 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -980,7 +980,7 @@ enum xenmap_operation {
 
 static int create_xen_entries(enum xenmap_operation op,
   unsigned long virt,
-  unsigned long mfn,
+  mfn_t mfn,
   unsigned long nr_mfns,
   unsigned int ai)
 {
@@ -989,7 +989,7 @@ static int create_xen_entries(enum xenmap_operation op,
 lpae_t pte;
 lpae_t *third = NULL;
 
-for(; addr < addr_end; addr += PAGE_SIZE, mfn++)
+for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
 if ( !xen_second[second_linear_offset(addr)].pt.valid ||
  !xen_second[second_linear_offset(addr)].pt.table )
@@ -1010,13 +1010,13 @@ static int create_xen_entries(enum xenmap_operation op,
 case RESERVE:
 if ( third[third_table_offset(addr)].pt.valid )
 {
-printk("create_xen_entries: trying to replace an existing 
mapping addr=%lx mfn=%lx\n",
-   addr, mfn);
+printk("create_xen_entries: trying to replace an existing 
mapping addr=%lx mfn=%"PRI_mfn"\n",
+   addr, mfn_x(mfn));
 return -EINVAL;
 }
 if ( op == RESERVE )
 break;
-pte = mfn_to_xen_entry(_mfn(mfn), ai);
+pte = mfn_to_xen_entry(mfn, ai);
 pte.pt.table = 1;
 write_pte(&third[third_table_offset(addr)], pte);
 break;
@@ -1061,24 +1061,25 @@ int map_pages_to_xen(unsigned long virt,
  unsigned long nr_mfns,
  unsigned int flags)
 {
-return create_xen_entries(INSERT, virt, mfn, nr_mfns, flags);
+return create_xen_entries(INSERT, virt, _mfn(mfn), nr_mfns, flags);
 }
 
 int populate_pt_range(unsigned long virt, unsigned long mfn,
   unsigned long nr_mfns)
 {
-return create_xen_entries(RESERVE, virt, mfn, nr_mfns, 0);
+return create_xen_entries(RESERVE, virt, _mfn(mfn), nr_mfns, 0);
 }
 
 int destroy_xen_mappings(unsigned long v, unsigned long e)
 {
-return create_xen_entries(REMOVE, v, 0, (e - v) >> PAGE_SHIFT, 0);
+return create_xen_entries(REMOVE, v, INVALID_MFN, (e - v) >> PAGE_SHIFT, 
0);
 }
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
 ASSERT((flags & (PTE_NX | PTE_RO)) == flags);
-return create_xen_entries(MODIFY, s, 0, (e - s) >> PAGE_SHIFT, flags);
+return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
+  flags);
 }
 
 enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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.h | 49 ++
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index ad8c571ea5..aa85cb8112 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -3,10 +3,12 @@
 
 #ifndef __ASSEMBLY__
 
-/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
- * level and l4 is the root of the trie, the ARM pagetables follow ARM's
- * documentation: the levels are called first, second &c in the order
- * that the MMU walks them (i.e. "first" is the root of the trie). */
+/*
+ * WARNING!  Unlike the x86 pagetable code, where l1 is the lowest level and
+ * l4 is the root of the trie, the ARM pagetables follow ARM's documentation:
+ * the levels are called first, second &c in the order that the MMU walks them
+ * (i.e. "first" is the root of the trie).
+ */
 
 /**
  * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
@@ -17,15 +19,18 @@
  * different place from those in leaf nodes seems to be to allow linear
  * pagetable tricks.  If we're not doing that then the set of permission
  * bits that's not in use in a given node type can be used as
- * extra software-defined bits. */
+ * extra software-defined bits.
+ */
 
 typedef struct __packed {
 /* These are used in all kinds of entry. */
 unsigned long valid:1;  /* Valid mapping */
 unsigned long table:1;  /* == 1 in 4k map entries too */
 
-/* These ten bits are only used in Block entries and are ignored
- * in Table entries. */
+/*
+ * These ten bits are only used in Block entries and are ignored
+ * in Table entries.
+ */
 unsigned long ai:3; /* Attribute Index */
 unsigned long ns:1; /* Not-Secure */
 unsigned long user:1;   /* User-visible */
@@ -38,30 +43,38 @@ typedef struct __packed {
 unsigned long long base:36; /* Base address of block or next table */
 unsigned long sbz:4;/* Must be zero */
 
-/* These seven bits are only used in Block entries and are ignored
- * in Table entries. */
+/*
+ * These seven bits are only used in Block entries and are ignored
+ * in Table entries.
+ */
 unsigned long contig:1; /* In a block of 16 contiguous entries */
 unsigned long pxn:1;/* Privileged-XN */
 unsigned long xn:1; /* eXecute-Never */
 unsigned long avail:4;  /* Ignored by hardware */
 
-/* These 5 bits are only used in Table entries and are ignored in
- * Block entries */
+/*
+ * These 5 bits are only used in Table entries and are ignored in
+ * Block entries.
+ */
 unsigned long pxnt:1;   /* Privileged-XN */
 unsigned long xnt:1;/* eXecute-Never */
 unsigned long apt:2;/* Access Permissions */
 unsigned long nst:1;/* Not-Secure */
 } lpae_pt_t;
 
-/* The p2m tables have almost the same layout, but some of the permission
- * and cache-control bits are laid out differently (or missing) */
+/*
+ * The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing).
+ */
 typedef struct __packed {
 /* These are used in all kinds of entry. */
 unsigned long valid:1;  /* Valid mapping */
 unsigned long table:1;  /* == 1 in 4k map entries too */
 
-/* These ten bits are only used in Block entries and are ignored
- * in Table entries. */
+/*
+ * These ten bits are only used in Block entries and are ignored
+ * in Table entries.
+ */
 unsigned long mattr:4;  /* Memory Attributes */
 unsigned long read:1;   /* Read access */
 unsigned long write:1;  /* Write access */
@@ -73,8 +86,10 @@ typedef struct __packed {
 unsigned long long base:36; /* Base address of block or next table */
 unsigned long sbz3:4;
 
-/* These seven bits are only used in Block entries and are ignored
- * in Table entries. */
+/*
+ * These seven bits are only used in Block entries and are ignored
+ * in Table entries.
+ */
 unsigned long contig:1; /* In a block of 16 contiguous entries */
 unsigned long sbz2:1;
 unsigned long xn:1; /* eXecute-Never */
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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
- Add Stefano's reviewed-by
---
 xen/include/asm-arm/lpae.h | 169 +
 xen/include/asm-arm/page.h | 152 +---
 2 files changed, 170 insertions(+), 151 deletions(-)
 create mode 100644 xen/include/asm-arm/lpae.h

diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
new file mode 100644
index 00..ad8c571ea5
--- /dev/null
+++ b/xen/include/asm-arm/lpae.h
@@ -0,0 +1,169 @@
+#ifndef __ARM_LPAE_H__
+#define __ARM_LPAE_H__
+
+#ifndef __ASSEMBLY__
+
+/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
+ * level and l4 is the root of the trie, the ARM pagetables follow ARM's
+ * documentation: the levels are called first, second &c in the order
+ * that the MMU walks them (i.e. "first" is the root of the trie). */
+
+/**
+ * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
+ * 40-bit output addresses.  Tables at all levels have 512 64-bit entries
+ * (i.e. are 4Kb long).
+ *
+ * The bit-shuffling that has the permission bits in branch nodes in a
+ * different place from those in leaf nodes seems to be to allow linear
+ * pagetable tricks.  If we're not doing that then the set of permission
+ * bits that's not in use in a given node type can be used as
+ * extra software-defined bits. */
+
+typedef struct __packed {
+/* These are used in all kinds of entry. */
+unsigned long valid:1;  /* Valid mapping */
+unsigned long table:1;  /* == 1 in 4k map entries too */
+
+/* These ten bits are only used in Block entries and are ignored
+ * in Table entries. */
+unsigned long ai:3; /* Attribute Index */
+unsigned long ns:1; /* Not-Secure */
+unsigned long user:1;   /* User-visible */
+unsigned long ro:1; /* Read-Only */
+unsigned long sh:2; /* Shareability */
+unsigned long af:1; /* Access Flag */
+unsigned long ng:1; /* Not-Global */
+
+/* The base address must be appropriately aligned for Block entries */
+unsigned long long base:36; /* Base address of block or next table */
+unsigned long sbz:4;/* Must be zero */
+
+/* These seven bits are only used in Block entries and are ignored
+ * in Table entries. */
+unsigned long contig:1; /* In a block of 16 contiguous entries */
+unsigned long pxn:1;/* Privileged-XN */
+unsigned long xn:1; /* eXecute-Never */
+unsigned long avail:4;  /* Ignored by hardware */
+
+/* These 5 bits are only used in Table entries and are ignored in
+ * Block entries */
+unsigned long pxnt:1;   /* Privileged-XN */
+unsigned long xnt:1;/* eXecute-Never */
+unsigned long apt:2;/* Access Permissions */
+unsigned long nst:1;/* Not-Secure */
+} lpae_pt_t;
+
+/* The p2m tables have almost the same layout, but some of the permission
+ * and cache-control bits are laid out differently (or missing) */
+typedef struct __packed {
+/* These are used in all kinds of entry. */
+unsigned long valid:1;  /* Valid mapping */
+unsigned long table:1;  /* == 1 in 4k map entries too */
+
+/* These ten bits are only used in Block entries and are ignored
+ * in Table entries. */
+unsigned long mattr:4;  /* Memory Attributes */
+unsigned long read:1;   /* Read access */
+unsigned long write:1;  /* Write access */
+unsigned long sh:2; /* Shareability */
+unsigned long af:1; /* Access Flag */
+unsigned long sbz4:1;
+
+/* The base address must be appropriately aligned for Block entries */
+unsigned long long base:36; /* Base address of block or next table */
+unsigned long sbz3:4;
+
+/* These seven bits are only used in Block entries and are ignored
+ * in Table entries. */
+unsigned long contig:1; /* In a block of 16 contiguous entries */
+unsigned long sbz2:1;
+unsigned long xn:1; /* eXecute-Never */
+unsigned long type:4;   /* Ignore by hardware. Used to store p2m types 
*/
+
+unsigned long sbz1:5;
+} lpae_p2m_t;
+
+/* Permission mask: xn, write, read */
+#define P2M_PERM_MASK (0x004000C0ULL)
+#define P2M_CLEAR_PERM(pte) ((pte).bits & ~P2M_PERM_MASK)
+
+/*
+ * Walk is the common bits of p2m and pt entries which are needed to
+ * simply walk the table (e.g. for debug).
+ */
+typedef struct __packed {
+/* These are used in all kinds of entry. */
+unsigned long valid:1;  /* Valid mapping */
+unsigned long table:1;  /* == 1 in 4k map entries too */
+

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

[Julien Grall]

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 Stabelllini 
---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/alternative.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 4d7e5b6155..a3bcda3117 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -32,6 +32,10 @@
 #include 
 #include 
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
 extern const struct alt_instr __alt_instructions[], __alt_instructions_end[];
 
 struct alt_region {
@@ -154,7 +158,7 @@ static int __apply_alternatives_multi_stop(void *unused)
 {
 int ret;
 struct alt_region region;
-mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+mfn_t xen_mfn = virt_to_mfn(_start);
 paddr_t xen_size = _end - _start;
 unsigned int xen_order = get_order_from_bytes(xen_size);
 void *xenmap;
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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 can be
re-defined easily.

Signed-off-by: Julien Grall 
---
Changes in v2:
- Use __virt_to_mfn rather than mfn_x(virt_to_mfn()).
---
 xen/arch/arm/mm.c| 16 ++--
 xen/include/asm-arm/mm.h |  3 ++-
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 452c1e26c3..5612834dfc 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -44,6 +44,10 @@
 
 struct domain *dom_xen, *dom_io, *dom_cow;
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+
 /* Static start-of-day pagetables that we use before the allocators
  * are up. These are used by all CPUs during bringup before switching
  * to the CPUs own pagetables.
@@ -479,7 +483,7 @@ unsigned long domain_page_map_to_mfn(const void *ptr)
 unsigned long offset = (va>>THIRD_SHIFT) & LPAE_ENTRY_MASK;
 
 if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END )
-return virt_to_mfn(va);
+return __virt_to_mfn(va);
 
 ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
 ASSERT(map[slot].pt.avail != 0);
@@ -764,7 +768,7 @@ int init_secondary_pagetables(int cpu)
  * domheap mapping pages. */
 for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
 {
-pte = mfn_to_xen_entry(_mfn(virt_to_mfn(domheap+i*LPAE_ENTRIES)),
+pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
WRITEALLOC);
 pte.pt.table = 1;
 write_pte(&first[first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
@@ -961,7 +965,7 @@ static int create_xen_table(lpae_t *entry)
 if ( p == NULL )
 return -ENOMEM;
 clear_page(p);
-pte = mfn_to_xen_entry(_mfn(virt_to_mfn(p)), WRITEALLOC);
+pte = mfn_to_xen_entry(virt_to_mfn(p), WRITEALLOC);
 pte.pt.table = 1;
 write_pte(entry, pte);
 return 0;
@@ -1216,7 +1220,7 @@ int xenmem_add_to_physmap_one(
 unsigned long idx,
 gfn_t gfn)
 {
-unsigned long mfn = 0;
+mfn_t mfn = INVALID_MFN;
 int rc;
 p2m_type_t t;
 struct page_info *page = NULL;
@@ -1302,7 +1306,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-mfn = page_to_mfn(page);
+mfn = _mfn(page_to_mfn(page));
 t = p2m_map_foreign;
 
 rcu_unlock_domain(od);
@@ -1321,7 +1325,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
+rc = guest_physmap_add_entry(d, gfn, mfn, 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index b2e7ea7761..6e2b3c7f2b 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -264,7 +264,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
unsigned int flags)
 #define __va(x) (maddr_to_virt(x))
 
 /* Convert between Xen-heap virtual addresses and machine frame numbers. */
-#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
+#define __virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
 #define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
 
 /*
@@ -274,6 +274,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
unsigned int flags)
  */
 #define mfn_to_page(mfn)__mfn_to_page(mfn)
 #define page_to_mfn(pg) __page_to_mfn(pg)
+#define virt_to_mfn(va) __virt_to_mfn(va)
 
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6241c53821..657fee0b17 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -986,28 +986,30 @@ static int create_xen_entries(enum xenmap_operation op,
 {
 int rc;
 unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
-lpae_t pte;
+lpae_t pte, *entry;
 lpae_t *third = NULL;
 
 for(; addr < addr_end; addr += PAGE_SIZE, mfn = mfn_add(mfn, 1))
 {
-if ( !lpae_table(xen_second[second_linear_offset(addr)]) )
+entry = &xen_second[second_linear_offset(addr)];
+if ( !lpae_table(*entry) )
 {
-rc = create_xen_table(&xen_second[second_linear_offset(addr)]);
+rc = create_xen_table(entry);
 if ( rc < 0 ) {
 printk("create_xen_entries: L2 failed\n");
 goto out;
 }
 }
 
-BUG_ON(!lpae_valid(xen_second[second_linear_offset(addr)]));
+BUG_ON(!lpae_valid(*entry));
 
-third = mfn_to_virt(xen_second[second_linear_offset(addr)].pt.base);
+third = mfn_to_virt(entry->pt.base);
+entry = &third[third_table_offset(addr)];
 
 switch ( op ) {
 case INSERT:
 case RESERVE:
-if ( lpae_valid(third[third_table_offset(addr)]) )
+if ( lpae_valid(*entry) )
 {
 printk("create_xen_entries: trying to replace an existing 
mapping addr=%lx mfn=%"PRI_mfn"\n",
addr, mfn_x(mfn));
@@ -1017,11 +1019,11 @@ static int create_xen_entries(enum xenmap_operation op,
 break;
 pte = mfn_to_xen_entry(mfn, ai);
 pte.pt.table = 1;
-write_pte(&third[third_table_offset(addr)], pte);
+write_pte(entry, pte);
 break;
 case MODIFY:
 case REMOVE:
-if ( !lpae_valid(third[third_table_offset(addr)]) )
+if ( !lpae_valid(*entry) )
 {
 printk("create_xen_entries: trying to %s a non-existing 
mapping addr=%lx\n",
op == REMOVE ? "remove" : "modify", addr);
@@ -1031,7 +1033,7 @@ static int create_xen_entries(enum xenmap_operation op,
 pte.bits = 0;
 else
 {
-pte = third[third_table_offset(addr)];
+pte = *entry;
 pte.pt.ro = PTE_RO_MASK(ai);
 pte.pt.xn = PTE_NX_MASK(ai);
 if ( !pte.pt.ro && !pte.pt.xn )
@@ -1041,7 +1043,7 @@ static int create_xen_entries(enum xenmap_operation op,
 return -EINVAL;
 }
 }
-write_pte(&third[third_table_offset(addr)], pte);
+write_pte(entry, pte);
 break;
 default:
 BUG();
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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>

Julien Grall (16):
  xen/mm: Don't use _{g,m}fn for defining INVALID_{G,M}FN
  xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64
  xen/arm: mm: Use typesafe mfn for xenheap_mfn_*
  xen/arm: p2m: Redefine mfn_to_page and page_to_mfn to use typesafe
  xen/arm: mm: Redefine virt_to_mfn to support typesafe
  xen/arm: domain_build: Redefine virt_to_mfn to support typesafe
  xen/arm: alternative: Redefine virt_to_mfn to support typesafe
  xen/arm: livepatch: Redefine virt_to_mfn to support typesafe
  xen/arm: create_xen_entries: Use typesafe MFN
  xen/arm: Move LPAE definition in a separate header
  xen/arm: lpae: Fix comments coding style
  xen/arm: p2m: Rename p2m_valid, p2m_table, p2m_mapping and
p2m_is_superpage
  xen/arm: p2m: Move lpae_* helpers in lpae.h
  xen/arm: mm: Use lpae_valid and lpae_table in create_xen_entries
  xen/arm: mm: Introduce temporary variable in create_xen_entries
  xen/arm: mm: Use __func__ rather than plain name in format string

 xen/arch/arm/alternative.c  |   6 +-
 xen/arch/arm/domain_build.c |   6 +-
 xen/arch/arm/livepatch.c|   6 +-
 xen/arch/arm/mm.c   |  84 +-
 xen/arch/arm/p2m.c  |  72 ++-
 xen/arch/arm/setup.c|  20 ++---
 xen/include/asm-arm/lpae.h  | 209 
 xen/include/asm-arm/mm.h|  14 +--
 xen/include/asm-arm/page.h  | 152 +---
 xen/include/xen/mm.h|   4 +-
 10 files changed, 317 insertions(+), 256 deletions(-)
 create mode 100644 xen/include/asm-arm/lpae.h

-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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...@sec.in.tum.de

Changes in v2:
- Patch added
---
 xen/arch/arm/p2m.c | 45 +++--
 1 file changed, 23 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6c1ac70044..1136d837fb 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -52,27 +52,27 @@ static const paddr_t level_masks[] =
 static const uint8_t level_orders[] =
 { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
 
-static inline bool_t p2m_valid(lpae_t pte)
+static inline bool_t lpae_valid(lpae_t pte)
 {
-return pte.p2m.valid;
+return pte.walk.valid;
 }
 /*
  * These two can only be used on L0..L2 ptes because L3 mappings set
  * the table bit and therefore these would return the opposite to what
  * you would expect.
  */
-static inline bool_t p2m_table(lpae_t pte)
+static inline bool_t lpae_table(lpae_t pte)
 {
-return p2m_valid(pte) && pte.p2m.table;
+return lpae_valid(pte) && pte.walk.table;
 }
-static inline bool_t p2m_mapping(lpae_t pte)
+static inline bool_t lpae_mapping(lpae_t pte)
 {
-return p2m_valid(pte) && !pte.p2m.table;
+return lpae_valid(pte) && !pte.walk.table;
 }
 
-static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
+static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
 {
-return (level < 3) && p2m_mapping(pte);
+return (level < 3) && lpae_mapping(pte);
 }
 
 static void p2m_flush_tlb(struct p2m_domain *p2m);
@@ -281,7 +281,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
read_only,
 
 entry = *table + offset;
 
-if ( !p2m_valid(*entry) )
+if ( !lpae_valid(*entry) )
 {
 if ( read_only )
 return GUEST_TABLE_MAP_FAILED;
@@ -292,7 +292,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
read_only,
 }
 
 /* The function p2m_next_level is never called at the 3rd level */
-if ( p2m_mapping(*entry) )
+if ( lpae_mapping(*entry) )
 return GUEST_TABLE_SUPER_PAGE;
 
 mfn = _mfn(entry->p2m.base);
@@ -372,7 +372,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
 
 entry = table[offsets[level]];
 
-if ( p2m_valid(entry) )
+if ( lpae_valid(entry) )
 {
 *t = entry.p2m.type;
 
@@ -577,7 +577,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t 
*entry)
 lpae_t *p;
 lpae_t pte;
 
-ASSERT(!p2m_valid(*entry));
+ASSERT(!lpae_valid(*entry));
 
 page = alloc_domheap_page(NULL, 0);
 if ( page == NULL )
@@ -645,7 +645,7 @@ enum p2m_operation {
  */
 static void p2m_put_l3_page(const lpae_t pte)
 {
-ASSERT(p2m_valid(pte));
+ASSERT(lpae_valid(pte));
 
 /*
  * TODO: Handle other p2m types
@@ -673,11 +673,11 @@ static void p2m_free_entry(struct p2m_domain *p2m,
 struct page_info *pg;
 
 /* Nothing to do if the entry is invalid. */
-if ( !p2m_valid(entry) )
+if ( !lpae_valid(entry) )
 return;
 
 /* Nothing to do but updating the stats if the entry is a super-page. */
-if ( p2m_is_superpage(entry, level) )
+if ( lpae_is_superpage(entry, level) )
 {
 p2m->stats.mappings[level]--;
 return;
@@ -733,7 +733,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
lpae_t *entry,
  * a superpage.
  */
 ASSERT(level < target);
-ASSERT(p2m_is_superpage(*entry, level));
+ASSERT(lpae_is_superpage(*entry, level));
 
 page = alloc_domheap_page(NULL, 0);
 if ( !page )
@@ -870,7 +870,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 /* We need to split the original page. */
 lpae_t split_pte = *entry;
 
-ASSERT(p2m_is_superpage(*entry, level));
+ASSERT(lpae_is_superpage(*entry, level));
 
 if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets) )
 {
@@ -944,12 +944,12 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
  * sequence when updating the translation table (D4.7.1 in ARM DDI
  * 0487A.j).
  */
-if ( p2m_valid(orig_pte) )
+if ( lpae_valid(orig_pte) )
 p2m_remove_pte(entry, p2m->clean_pte);
 
 if ( mfn_eq(smfn, INVALID_MFN) )
 /* Flush can be deferred if the entry is removed */
-p2m->need_flush |= !!p2m_valid(orig_pte);
+p2m->need_flush |= !!lpae_valid(orig_pte);
 else
 {
 lpae_t pte = mfn_to_p2m_entry(smfn, t, a);
@@ -964,7 +964,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
  * Although, it could be defered when only the permissions are
  * changed (e.g in case of memaccess).
  */
-if ( p2m_valid(orig_pte) )
+if ( lpae_valid(orig_pte) )
 {
 if (

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

[Julien Grall]

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 
---
The idea behind redefining locally mfn_to_page and page_to_mfn is
splitting the introduction of typesafe MFN in smaller series and
between multiple people. We know the file is typesafe ready and if
we decide to make the main helper typesafe, we would just need to
drop the definition at the top of the file.
---
 xen/arch/arm/p2m.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 266d1c3bd6..6c1ac70044 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -38,6 +38,12 @@ static unsigned int __read_mostly max_vmid = MAX_VMID_8_BIT;
 
 #define P2M_ROOT_PAGES(1root, page_to_mfn(p2m->root));
+   p2m->root, mfn_x(page_to_mfn(p2m->root)));
 
 dump_pt_walk(page_to_maddr(p2m->root), addr,
  P2M_ROOT_LEVEL, P2M_ROOT_PAGES);
@@ -591,7 +597,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t 
*entry)
  * The access value does not matter because the hardware will ignore
  * the permission fields for table entry.
  */
-pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
+pte = mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid,
p2m->default_access);
 
 p2m_write_pte(entry, pte, p2m->clean_pte);
@@ -650,9 +656,9 @@ static void p2m_put_l3_page(const lpae_t pte)
  */
 if ( p2m_is_foreign(pte.p2m.type) )
 {
-unsigned long mfn = pte.p2m.base;
+mfn_t mfn = _mfn(pte.p2m.base);
 
-ASSERT(mfn_valid(_mfn(mfn)));
+ASSERT(mfn_valid(mfn));
 put_page(mfn_to_page(mfn));
 }
 }
@@ -702,7 +708,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
 mfn = _mfn(entry.p2m.base);
 ASSERT(mfn_valid(mfn));
 
-pg = mfn_to_page(mfn_x(mfn));
+pg = mfn_to_page(mfn);
 
 page_list_del(pg, &p2m->pages);
 free_domheap_page(pg);
@@ -780,7 +786,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
lpae_t *entry,
 
 unmap_domain_page(table);
 
-pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
+pte = mfn_to_p2m_entry(page_to_mfn(page), p2m_invalid,
p2m->default_access);
 
 /*
@@ -1443,7 +1449,7 @@ struct page_info *get_page_from_gva(struct vcpu *v, 
vaddr_t va,
 if ( !mfn_valid(maddr_to_mfn(maddr)) )
 goto err;
 
-page = mfn_to_page(mfn_x(maddr_to_mfn(maddr)));
+page = mfn_to_page(maddr_to_mfn(maddr));
 ASSERT(page);
 
 if ( unlikely(!get_page(page, d)) )
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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 --
 1 file changed, 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index f00f29a45b..ab4d8e4218 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -654,8 +654,6 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 if ( e > bank_end )
 e = bank_end;
 
-xenheap_mfn_end = e;
-
 dt_unreserved_regions(s, e, init_boot_pages, 0);
 s = n;
 }
-- 
2.11.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Bhupinder Thakur]

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? After all this patch really has not much to do with
> vpl011.
>
I will modify the commit message to indicate this commit renames
vgic_reg* to vreg_reg*
and modifies all the places where this call is made.

> On 06/06/17 18:25, Bhupinder Thakur wrote:
>> This patch redefines the vgic_reg* access functions to vreg_reg* functions.
>> These are generic functions, which will be used by the vgic emulation code
>> to access the vgic registers.
>>
>> PL011 emulation code will also use vreg_reg* access functions.
>
> Also I am sorry to be the bearer of bad news (and also for being the
> origin of this), but I am afraid you have to rework this when you rebase
> it against origin/staging, since the ITS emulation has been merged.
> So while actual conflicts seem to be trivial, there are now many new
> users of vgic_reg??_* which you have to change as well.
> Should be rather mechanical, though.
>
I will rebase it on origin/staging and merge the changes. How do I
enable ITS code compilation to verify that it is compiling fine with
new
vreg_reg* functions? Is ITS code not compiled in by default?

Regards,
Bhupinder

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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
> {
> ...
> }
> guarantee that old->rb_right is set in the final else branch,
> therefore
> we can omit checking that again.
> 
> Signed-off-by: Wolfram Strepp 
> Signed-off-by: Peter Zijlstra 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 4b324126e0c6c3a5080ca3ec0981e8766ed6f1ee]
> 
And yet, the actual patch is slightly different. As in...

> --- a/xen/common/rbtree.c
> +++ b/xen/common/rbtree.c
> @@ -250,15 +250,16 @@ void rb_erase(struct rb_node *node, struct
> rb_root *root)
>  if (child)
>  rb_set_parent(child, parent);
>  parent->rb_left = child;
> +
> +node->rb_right = old->rb_right;
> +rb_set_parent(old->rb_right, node);
>  }
>  
>  node->rb_parent_color = old->rb_parent_color;
> -node->rb_right = old->rb_right;
>  node->rb_left = old->rb_left;
>  
...In the Linux commit, this blank line is removed too.

>  rb_set_parent(old->rb_left, node);
> -if (old->rb_right)
> -rb_set_parent(old->rb_right, node);
> +
>  goto color;
>  }
>  
I don't think this is too big of a deal per se, I'd I'd leave to
maintainers and committers to decide whether something like this is
enough for asking a resend, or whether it can be fixed upon commit or
even left as it is.

For sure, we know that these patches really needs to be, as much as
possible, 1:1 copies of Linux's ones, even in the smallest detail. And
the reason is to make the life of someone wanting to do another round
of import, in future, as easy as possible.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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 some ascii-art, with following symbols (referring to the code):
> O: node to be deleted
> N: the successor of O
> P: parent of N
> C: child of N
> L: some other node
> 
> normal case:
> 
>    O N
>   / \   / \
>  /   \ /   \
> L \   L \
>    / \ P  >  / \ P
>   / \   / \
>  / /
> N C
>  \   / \
>   \
>    C
>   / \
> 
> special case:
>   O|PN
>   / \   / \
>  /   \ /   \
> L \   L \
>    / \ N  >  /   C
> \   / \
>  \
>   C
>  / \
> 
> Notice that for the special case we don't have to reconnect C to N.
> 
> Signed-off-by: Wolfram Strepp 
> Signed-off-by: Peter Zijlstra 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 4c60117811171d867d4f27f17ea07d7419d45dae]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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-by: Linus Torvalds 
> [Linux commit 16c047add3ceaf0ab882e3e094d1ec904d02312d]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Roger Pau Monne]

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);
> >  
> > +if ( irq_map->flags & HVM_IRQ_DPCI_IDENTITY_GSI )
> > +{
> > +struct pirq *pirq = dpci_pirq(irq_map);
> 
> This could (and hence should) be const. However, ...
> 
> > +ASSERT(is_hardware_domain(irq_map->dom));
> > +/*
> > + * Identity mapped, no need to iterate over the guest GSI list to 
> > find
> > + * other pirqs sharing the same guest GSI.
> > + *
> > + * In the identity mapped case the EOI can also be done now, this 
> > way
> > + * the iteration over the list of domain pirqs is avoided.
> > + */
> > +hvm_gsi_deassert(irq_map->dom, pirq->pirq);
> 
> ... this is its only use, so I'm not convinced a local variable is
> needed at all.

Done, I've removed the local variable.

> > @@ -274,10 +293,16 @@ int pt_irq_create_bind(
> >  spin_lock(&d->event_lock);
> >  
> >  hvm_irq_dpci = domain_get_irq_dpci(d);
> > -if ( hvm_irq_dpci == NULL )
> > +if ( hvm_irq_dpci == NULL && !is_hardware_domain(d) )
> 
> Would you mind at once switching to the shorter !hvm_irq_dpci
> (also further down), the more that you're using the inverse
> without " != NULL" elsewhere?

Done.

> >  {
> >  unsigned int i;
> >  
> > +/*
> > + * NB: the hardware domain doesn't use a hvm_irq_dpci struct 
> > because
> > + * it's only allowed to identity map GSIs, and so the data 
> > contained in
> > + * that struct (used to map guest GSIs into machine GSIs and 
> > perform
> > + * interrupt routing) it's completely useless to it.
> 
> "is completely ..."

Fixed.

> > @@ -422,35 +447,52 @@ int pt_irq_create_bind(
> >  case PT_IRQ_TYPE_PCI:
> >  case PT_IRQ_TYPE_MSI_TRANSLATE:
> >  {
> > -unsigned int bus = pt_irq_bind->u.pci.bus;
> > -unsigned int device = pt_irq_bind->u.pci.device;
> > -unsigned int intx = pt_irq_bind->u.pci.intx;
> > -unsigned int guest_gsi = hvm_pci_intx_gsi(device, intx);
> > -unsigned int link = hvm_pci_intx_link(device, intx);
> > -struct dev_intx_gsi_link *digl = xmalloc(struct dev_intx_gsi_link);
> > -struct hvm_girq_dpci_mapping *girq =
> > -xmalloc(struct hvm_girq_dpci_mapping);
> > +struct dev_intx_gsi_link *digl = NULL;
> > +struct hvm_girq_dpci_mapping *girq = NULL;
> > +unsigned int guest_gsi;
> >  
> > -if ( !digl || !girq )
> > +/*
> > + * Mapping GSIs for the hardware domain is different than doing it 
> > for
> > + * an unpriviledged guest, the hardware domain is only allowed to
> > + * identity map GSIs, and as such all the data in the u.pci union 
> > is
> > + * discarded.
> > + */
> > +if ( !is_hardware_domain(d) )
> 
> I think I did indicate before that it would feel more safe if you
> checked hvm_irq_dpci here (which is NULL if and only if d is
> hwdom). At the very least I'd expect a respective ASSERT()
> below (but I think the alternative condition here and
> ASSERT(is_hardware_domain(d)) in the "else" block would be
> better).

I've changed this to:

if ( hvm_irq_dpci )
{
...
}
else
{
ASSERT(is_hardware_domain(d));
...
}

> >  {
> > -spin_unlock(&d->event_lock);
> > -xfree(girq);
> > -xfree(digl);
> > -return -ENOMEM;
> > -}
> > +unsigned int link;
> > +
> > +digl = xmalloc(struct dev_intx_gsi_link);
> > +girq = xmalloc(struct hvm_girq_dpci_mapping);
> >  
> > -hvm_irq_dpci->link_cnt[link]++;
> > +if ( !digl || !girq )
> > +{
> > +spin_unlock(&d->event_lock);
> > +xfree(girq);
> > +xfree(digl);
> > +return -ENOMEM;
> > +}
> > +
> > +girq->bus = digl->bus = pt_irq_bind->u.pci.bus;
> > +girq->device = digl->device = pt_irq_bind->u.pci.device;
> > +girq->intx = digl->intx = pt_irq_bind->u.pci.intx;
> > +list_add_tail(&digl->list, &pirq_dpci->digl_list);
> >  
> > -digl->bus = bus;
> > -digl->device = device;
> > -digl->intx = intx;
> > -list_add_tail(&digl->list, &pirq_dpci->digl_list);
> > +guest_gsi = hvm_pci_intx_gsi(digl->device, digl->intx);
> > +link = hvm_pci_intx_link(digl->device, digl->intx);
> >  
> > -girq->bus = bus;
> > -girq->device = device;
> > -girq->intx = intx;
> > -girq->machine_gsi = pirq;
> > -list_add_tail(&girq->list, &hvm_irq_dpci->girq[guest_gsi]);
> > +hvm_irq_dpci->link_cnt[link]++;
> > +

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

[Dario Faggioli]

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 (!C || D) {//if this is true, it implies: (A ==
> true) && (B == false)
>   if (A) {//hence this always evaluates
> to 'true'...
>   .
>   }
>   .
>   //at this point, C always becomes true,
> because of:
>   __rb_rotate_right/left();
>   //and:
>   other = parent->rb_right/left;
>   }
>   .
>   .
>   if (C) {//...and this too !
>   .
>   }
> }
> 
> Signed-off-by: Wolfram Strepp 
> Acked-by: Peter Zijlstra 
> Cc: Andrea Arcangeli 
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> [Linux commit 55a63998b8967615a15e2211ba0ff3a84a565824]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
Reviewed-by: Dario Faggioli 

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Dario Faggioli]

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.
> 
> Indeed, if I have my own constant pointer &const struct my_type *p,
> and I call 'rb_next(&p->rb)', I get a GCC warning:
> 
> warning: passing argument 1 of ‘rb_next’ discards qualifiers from
> pointer target
> type
> 
> Signed-off-by: Artem Bityutskiy 
> Signed-off-by: David Woodhouse 
> Signed-off-by: Linus Torvalds 
> [Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 
>
With authorship (the From: field) fixed as Jan suggested,

Reviewed-by: Dario Faggioli 

(The remark on the authorship applies of course to all the patches,
even if I don't explicitly state it again).

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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:
>
>
> 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 back from increase-reservation for
> translated domains, just like we don't for populate-physmap and
> memory-exchange. For full symmetry also check for a NULL guest
> handle
> in populate_physmap() (but note this makes no sense in
> memory_exchange(), as there the array is also an input).
>
> Signed-off-by: Jan Beulich 




 Reviewed-by: Andrew Cooper 
>>>
>>>
>>>
>>>
>>> Unfortunately I just had time to do testing with this change and I
>>> have to report that introduces a critical regression for my tools.
>>> With this change in-place performing increase_reservation on a target
>>> domain no longer reports the guest frame number for external tools,
>>> thus completely breaking advanced use-cases that require this
>>> information to be able to do altp2m gfn remapping. This is a critical
>>> step in being able to introduce shadow-pages that are used to hide
>>> breakpoints and other memory modifications from the guest.
>>
>>
>>
>>
>> While I can see your point, I'm afraid that's not how the
>> interface was meant to be used. The mere fact that
>> populate-physmap and memory-exchange didn't return the
>> MFN(s) suggests to me that you already need to have a way
>> to deal with having to find out another way. Or are you
>> suggesting you rely on guests not using these interfaces?
>>
>> As to a solution, I could possibly see us relax the change to
>> return the MFN(s) when the current and subject domains differ,
>> or even check paging mode of the caller domain instead of the
>> subject one (which would mean PVH Dom0 still wouldn't get to
>> see them). But if we do, imo we should do this consistently for
>> all three operations, rather than just for increase-reservation.
>>
>>> If at all possible, I would like to request this change not to be
>>> part
>>> of the 4.9 release.
>>
>>
>>
>>
>> Hmm, it's been there for all of the RCs, so I'm not really happy
>> to consider the option of reverting at this point in time. But
>> Julien will have the final say anyway.
>
>
>
>
> I am a bit confuse with the description of the problem. I understood
> "guest
> frame number" as GFN. But AFAICT, this hypercall was returning MFN even
> for
> HVM guests. So how this change is breaking altp2m remapping?



 For HVM guests this hypercall returns a GFN that can subsequently be
 populated into the guest physmap:

 xc_domain_increase_reservation_exact(xch, domid, 1, 0, 0, &new_gfn);
 xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &new_gfn);
>>>
>>>
>>>
>>> I am sorry, I can't see how this can return a GFN for the HVM. Looking at
>>> the implementation of increase_reservation in Xen:
>>>
>>> mfn = page_to_mfn(page);
>>> if ( unlikely(__copy_to_guest_offset(a->extent_list, i, &mfn, 1)) )
>>>   goto out;
>>>
>>> This is an MFN and not a GFN. Except the strict check before, the code
>>> has
>>> not change for a while.
>>>
>>> AFAICT, the purpose of increase_reservation is not to allocate a new GFN,
>>> it
>>> will just allocate the host memory for it. At least on ARM we have
>>> nothing
>>> to say "this GFN region is free". I would be surprised that such things
>>> exists on x86.
>>>
>>
>> It returns memory that can be mapped into the guest physmap
>> subsequently. So I have been referring to it as a GFN that is not
>> mapped into the physmap - similar to the magic ring pages when they
>> are in use.
>
>
> Reading the implementation, roughly:
>
> * increase_reservation will only allocate host memory and return the
> corresponding MFN
> * populate_physmap will allocate host memory and map to a specific address
>
> So by calling both, you will effectively allocate twice memory and never be
> able to free the memory allocated by increase_reservation until the guest is
> destroyed. This will *never* allocate the corresponding GFN and I think is
> just working by luck in your case.

Ough, yes, you are correct.

After digging into the implementation of populate_physmap more closely
it indeed seems like it was pure luck that my use of it was

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

[Julien Grall]

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  (2)


Why this is exported? You only use them internally.



In v2 you pointed out that it is hard to read hardcoded values. I would
gladly change these changes back as I agree on this point: I also don't
like having exported indices, as well. Or would you like to see these
defines (and the TTBRx_VALID values beyond) directly within the
guest_walk.c?


The latter please + probably using enum rather than define to make them 
safe. But...





+
+/* Represent whether TTBR0 or TTBR1 is valid. */
+#define TTBR0_VALID (0)
+#define TTBR1_VALID (1)


look at that again. You are using bool as the type. So they should be 
true/false. Or if it is an index, they type should be int. Though, the 
enum would make it clearer.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Sergej Proskurin]

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 exported? You only use them internally.
>

In v2 you pointed out that it is hard to read hardcoded values. I would
gladly change these changes back as I agree on this point: I also don't
like having exported indices, as well. Or would you like to see these
defines (and the TTBRx_VALID values beyond) directly within the
guest_walk.c?

>> +
>> +/* Represent whether TTBR0 or TTBR1 is valid. */
>> +#define TTBR0_VALID (0)
>> +#define TTBR1_VALID (1)
>
> Ditto.

Cheers,
~Sergej


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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, 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 for
translated domains, just like we don't for populate-physmap and
memory-exchange. For full symmetry also check for a NULL guest handle
in populate_physmap() (but note this makes no sense in
memory_exchange(), as there the array is also an input).

Signed-off-by: Jan Beulich 




Reviewed-by: Andrew Cooper 




Unfortunately I just had time to do testing with this change and I
have to report that introduces a critical regression for my tools.
With this change in-place performing increase_reservation on a target
domain no longer reports the guest frame number for external tools,
thus completely breaking advanced use-cases that require this
information to be able to do altp2m gfn remapping. This is a critical
step in being able to introduce shadow-pages that are used to hide
breakpoints and other memory modifications from the guest.




While I can see your point, I'm afraid that's not how the
interface was meant to be used. The mere fact that
populate-physmap and memory-exchange didn't return the
MFN(s) suggests to me that you already need to have a way
to deal with having to find out another way. Or are you
suggesting you rely on guests not using these interfaces?

As to a solution, I could possibly see us relax the change to
return the MFN(s) when the current and subject domains differ,
or even check paging mode of the caller domain instead of the
subject one (which would mean PVH Dom0 still wouldn't get to
see them). But if we do, imo we should do this consistently for
all three operations, rather than just for increase-reservation.


If at all possible, I would like to request this change not to be part
of the 4.9 release.




Hmm, it's been there for all of the RCs, so I'm not really happy
to consider the option of reverting at this point in time. But
Julien will have the final say anyway.




I am a bit confuse with the description of the problem. I understood
"guest
frame number" as GFN. But AFAICT, this hypercall was returning MFN even
for
HVM guests. So how this change is breaking altp2m remapping?



For HVM guests this hypercall returns a GFN that can subsequently be
populated into the guest physmap:

xc_domain_increase_reservation_exact(xch, domid, 1, 0, 0, &new_gfn);
xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &new_gfn);



I am sorry, I can't see how this can return a GFN for the HVM. Looking at
the implementation of increase_reservation in Xen:

mfn = page_to_mfn(page);
if ( unlikely(__copy_to_guest_offset(a->extent_list, i, &mfn, 1)) )
  goto out;

This is an MFN and not a GFN. Except the strict check before, the code has
not change for a while.

AFAICT, the purpose of increase_reservation is not to allocate a new GFN, it
will just allocate the host memory for it. At least on ARM we have nothing
to say "this GFN region is free". I would be surprised that such things
exists on x86.



It returns memory that can be mapped into the guest physmap
subsequently. So I have been referring to it as a GFN that is not
mapped into the physmap - similar to the magic ring pages when they
are in use.


Reading the implementation, roughly:

* increase_reservation will only allocate host memory and return the 
corresponding MFN

* populate_physmap will allocate host memory and map to a specific address

So by calling both, you will effectively allocate twice memory and never 
be able to free the memory allocated by increase_reservation until the 
guest is destroyed. This will *never* allocate the corresponding GFN and 
I think is just working by luck in your case.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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 are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 110545 
pass in 110557
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 110545 
pass in 110557
 test-armhf-armhf-libvirt-raw 14 guest-start/debian.repeat fail in 110545 pass 
in 110557
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 110545
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 110545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
110456
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 110456
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 110456
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110456
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux050639ef5810e8ad17fb6a426eff3c63e616350c
baseline version:
 linux  

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

[Robin Murphy]

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 current user of dma-iommu.

I was angling at just open-coding 0/!dma_addr/etc. for simplicity rather
than having anything #defined at all - nothing except the 4th and final
hunks actually have any relevance to  dma_mapping_error(), and I reckon
it's plenty clear enough in context. The rest is just proactively
blatting address arguments with "arbitrary definitely-invalid value",
which is more paranoia than anything else (and arguably unnecessary).

It's not the biggest deal, though, so either way:

Reviewed-by: Robin Murphy 

> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/iommu/dma-iommu.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 62618e77bedc..9403336f1fa6 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -31,6 +31,8 @@
>  #include 
>  #include 
>  
> +#define IOMMU_MAPPING_ERROR  0
> +
>  struct iommu_dma_msi_page {
>   struct list_headlist;
>   dma_addr_t  iova;
> @@ -500,7 +502,7 @@ void iommu_dma_free(struct device *dev, struct page 
> **pages, size_t size,
>  {
>   __iommu_dma_unmap(iommu_get_domain_for_dev(dev), *handle, size);
>   __iommu_dma_free_pages(pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
> - *handle = DMA_ERROR_CODE;
> + *handle = IOMMU_MAPPING_ERROR;
>  }
>  
>  /**
> @@ -533,7 +535,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
> size, gfp_t gfp,
>   dma_addr_t iova;
>   unsigned int count, min_size, alloc_sizes = domain->pgsize_bitmap;
>  
> - *handle = DMA_ERROR_CODE;
> + *handle = IOMMU_MAPPING_ERROR;
>  
>   min_size = alloc_sizes & -alloc_sizes;
>   if (min_size < PAGE_SIZE) {
> @@ -627,11 +629,11 @@ static dma_addr_t __iommu_dma_map(struct device *dev, 
> phys_addr_t phys,
>  
>   iova = iommu_dma_alloc_iova(domain, size, dma_get_mask(dev), dev);
>   if (!iova)
> - return DMA_ERROR_CODE;
> + return IOMMU_MAPPING_ERROR;
>  
>   if (iommu_map(domain, iova, phys - iova_off, size, prot)) {
>   iommu_dma_free_iova(cookie, iova, size);
> - return DMA_ERROR_CODE;
> + return IOMMU_MAPPING_ERROR;
>   }
>   return iova + iova_off;
>  }
> @@ -671,7 +673,7 @@ static int __finalise_sg(struct device *dev, struct 
> scatterlist *sg, int nents,
>  
>   s->offset += s_iova_off;
>   s->length = s_length;
> - sg_dma_address(s) = DMA_ERROR_CODE;
> + sg_dma_address(s) = IOMMU_MAPPING_ERROR;
>   sg_dma_len(s) = 0;
>  
>   /*
> @@ -714,11 +716,11 @@ static void __invalidate_sg(struct scatterlist *sg, int 
> nents)
>   int i;
>  
>   for_each_sg(sg, s, nents, i) {
> - if (sg_dma_address(s) != DMA_ERROR_CODE)
> + if (sg_dma_address(s) != IOMMU_MAPPING_ERROR)
>   s->offset += sg_dma_address(s);
>   if (sg_dma_len(s))
>   s->length = sg_dma_len(s);
> - sg_dma_address(s) = DMA_ERROR_CODE;
> + sg_dma_address(s) = IOMMU_MAPPING_ERROR;
>   sg_dma_len(s) = 0;
>   }
>  }
> @@ -836,7 +838,7 @@ void iommu_dma_unmap_resource(struct device *dev, 
> dma_addr_t handle,
>  
>  int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
>  {
> - return dma_addr == DMA_ERROR_CODE;
> + return dma_addr == IOMMU_MAPPING_ERROR;
>  }
>  
>  static struct iommu_dma_msi_page *iommu_dma_get_msi_page(struct device *dev,
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Al Viro]

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/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 tree:  linux 
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> >   Bug introduced:  edf9364d3f924aff6f77176b8e52a4b68e5c30d6
> >   Bug not present: 791a9a666d1afe2603bcb2c6a4852d684e879252
> >   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110566/
> 
> This is a merge commit, so the bisection result is not very useful:
> 
>git-log --pretty=oneline 
> 791a9a666d1afe2603bcb2c6a4852d684e879252..edf9364d3f924aff6f77176b8e52a4b68e5c30d6
>  | wc -l
>2233
> 
> The error message is this:
> 
>ERROR: "__udivdi3" [fs/ufs/ufs.ko] undefined!
>scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>make[1]: *** [__modpost] Error 1

It's 64bit ->s_dsize going through "multiply by this, divide by 100".
Can be papered over by using mul_64_u32_div() in ufs_new_fragments(),
but
* expression remains unchanged, so it's better done at
mount time
* there's a braino (since circa 2002) in the same code
- the expression(s) are for the levels of fragmentation that
trigger switches in hysteresis loop and both switches lead to
the same state due to cut'n'paste damage
* for really low minfree we get those levels too close
to each other - at minfree 5 we get 0.025 .. 0.03, at minfree 4
they outright merge and below that the upper bound is less than
the lower one.  We'd copied the original 4.4BSD here; at 1995
FreeBSD got switched to "minfree 5 or below means using OPTSPACE
all the time".

Fixed in vfs.git#ufs-fixes; see commit 77e9ce327d9b607cd6e57c0f4524a654dc59c4b1
there.  Not sure if it's worth splitting...

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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, 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 for
>>> translated domains, just like we don't for populate-physmap and
>>> memory-exchange. For full symmetry also check for a NULL guest handle
>>> in populate_physmap() (but note this makes no sense in
>>> memory_exchange(), as there the array is also an input).
>>>
>>> Signed-off-by: Jan Beulich 
>>
>>
>>
>> Reviewed-by: Andrew Cooper 
>
>
>
> Unfortunately I just had time to do testing with this change and I
> have to report that introduces a critical regression for my tools.
> With this change in-place performing increase_reservation on a target
> domain no longer reports the guest frame number for external tools,
> thus completely breaking advanced use-cases that require this
> information to be able to do altp2m gfn remapping. This is a critical
> step in being able to introduce shadow-pages that are used to hide
> breakpoints and other memory modifications from the guest.



 While I can see your point, I'm afraid that's not how the
 interface was meant to be used. The mere fact that
 populate-physmap and memory-exchange didn't return the
 MFN(s) suggests to me that you already need to have a way
 to deal with having to find out another way. Or are you
 suggesting you rely on guests not using these interfaces?

 As to a solution, I could possibly see us relax the change to
 return the MFN(s) when the current and subject domains differ,
 or even check paging mode of the caller domain instead of the
 subject one (which would mean PVH Dom0 still wouldn't get to
 see them). But if we do, imo we should do this consistently for
 all three operations, rather than just for increase-reservation.

> If at all possible, I would like to request this change not to be part
> of the 4.9 release.



 Hmm, it's been there for all of the RCs, so I'm not really happy
 to consider the option of reverting at this point in time. But
 Julien will have the final say anyway.
>>>
>>>
>>>
>>> I am a bit confuse with the description of the problem. I understood
>>> "guest
>>> frame number" as GFN. But AFAICT, this hypercall was returning MFN even
>>> for
>>> HVM guests. So how this change is breaking altp2m remapping?
>>
>>
>> For HVM guests this hypercall returns a GFN that can subsequently be
>> populated into the guest physmap:
>>
>> xc_domain_increase_reservation_exact(xch, domid, 1, 0, 0, &new_gfn);
>> xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &new_gfn);
>
>
> I am sorry, I can't see how this can return a GFN for the HVM. Looking at
> the implementation of increase_reservation in Xen:
>
> mfn = page_to_mfn(page);
> if ( unlikely(__copy_to_guest_offset(a->extent_list, i, &mfn, 1)) )
>   goto out;
>
> This is an MFN and not a GFN. Except the strict check before, the code has
> not change for a while.
>
> AFAICT, the purpose of increase_reservation is not to allocate a new GFN, it
> will just allocate the host memory for it. At least on ARM we have nothing
> to say "this GFN region is free". I would be surprised that such things
> exists on x86.
>

It returns memory that can be mapped into the guest physmap
subsequently. So I have been referring to it as a GFN that is not
mapped into the physmap - similar to the magic ring pages when they
are in use.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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 
> wrote:
>> On 04/04/17 14:14, Jan Beulich wrote:
>>> We shouldn't hand MFN info back from increase-reservation for
>>> translated domains, just like we don't for populate-physmap and
>>> memory-exchange. For full symmetry also check for a NULL guest handle
>>> in populate_physmap() (but note this makes no sense in
>>> memory_exchange(), as there the array is also an input).
>>>
>>> Signed-off-by: Jan Beulich 
>>
>> Reviewed-by: Andrew Cooper 
>
> Unfortunately I just had time to do testing with this change and I
> have to report that introduces a critical regression for my tools.
> With this change in-place performing increase_reservation on a target
> domain no longer reports the guest frame number for external tools,
> thus completely breaking advanced use-cases that require this
> information to be able to do altp2m gfn remapping. This is a critical
> step in being able to introduce shadow-pages that are used to hide
> breakpoints and other memory modifications from the guest.

 While I can see your point, I'm afraid that's not how the
 interface was meant to be used.
>>>
>>> Well the first question to ask is, is that hypercall part of the stable
>>> interface?  If so, then the standard should be, "Don't break people who
>>> call it unless there is really no other way around it."  Sure, it was a
>>> mistake whoever introduced that, but if Tamas is building on a "stable"
>>> interface he should be able to rely on that interface being maintained,
>>> at least until we can find a suitable replacement.
>>>
>>>  -George
>>>
>>
>> Of course if a suitable replacement can be made that gets me the
>> information I need that would work too. At the moment I'm not aware of
>> any other hypercall I could use for this purpose.
>
> So actually -- it sounds like both Jan and I misunderstood the
> situation.  The header file clearly says:
>
>  * XENMEM_increase_reservation:
>  *   OUT: MFN (*not* GMFN) bases of extents that were allocated
>
> Are you saying that for HVM guests, that statement is false?
>

Well, it would certainly appear so as I  have been using it to add
memory to a guest and then map it into the guest physmap as a new gfn.
I've been using it like that since Xen 4.6 without any problems.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 because of the way that Makefiles
> under xen/ are invoked by their parent directory Makefiles.
> 
> Firstly, the Rules.mk `clean' target overrides the pattern rule in
> xen/test/Makefile.  The result is that `make -C xen clean' does not
> actually run the livepatch clean target.
> 
> The Rules.mk clean target does have provision for recursing into
> subdirectories, but that feature is tangled up with complex object
> file iteration machinery which is not desirable here.  However, we can
> extend the Rules.mk clean target since it is a double-colon rules.
> 
> Sadly this involves duplicating the SUBDIR iteration boilerplate.  (A
> make function could be used but the cure would be worse than the
> disease.)
> 
> Secondly, Rules.mk has a number of -include directives.  make likes to
> try to (re)build files mentioned in includes.  With the % pattern
> rule, this applies to those files too.
> 
> As a result, make -C xen clean would try to build `.*.d' (for example)
> in xen/test.  This would fail with an error message.  The error would
> be ignored because of the `-', but it's annoying and ugly.

Aaah.
> 
> Solve this by limiting the % pattern rule to the targets we expect it
> to handle.  These are those listed in the top-level Makefile, apart
> from: those which are subdir- or component-qualified; clean targets
> (which are handled specially, even distclean); and dist,
> src-tarball-*, etc. (which are converted to install by an earlier
> Makefile).
> 
> Reported-by: Andrew Cooper 
> Signed-off-by: Ian Jackson 

Acked-by: Konrad Rzeszutek Wilk 


> ---
>  xen/test/Makefile | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/test/Makefile b/xen/test/Makefile
> index aa1a23b..aaa4996 100644
> --- a/xen/test/Makefile
> +++ b/xen/test/Makefile
> @@ -7,7 +7,12 @@ ifneq ($(XEN_TARGET_ARCH),x86_32)
>  SUBDIRS += livepatch
>  endif
>  
> -%:
> +install build subtree-force-update uninstall: %:
>   set -e; for s in $(SUBDIRS); do \
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $*; \
>   done
> +
> +clean::
> + set -e; for s in $(SUBDIRS); do \
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $@; \
> + done
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[George Dunlap]

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 shouldn't hand MFN info back from increase-reservation for
>> translated domains, just like we don't for populate-physmap and
>> memory-exchange. For full symmetry also check for a NULL guest handle
>> in populate_physmap() (but note this makes no sense in
>> memory_exchange(), as there the array is also an input).
>>
>> Signed-off-by: Jan Beulich 
>
> Reviewed-by: Andrew Cooper 

 Unfortunately I just had time to do testing with this change and I
 have to report that introduces a critical regression for my tools.
 With this change in-place performing increase_reservation on a target
 domain no longer reports the guest frame number for external tools,
 thus completely breaking advanced use-cases that require this
 information to be able to do altp2m gfn remapping. This is a critical
 step in being able to introduce shadow-pages that are used to hide
 breakpoints and other memory modifications from the guest.
>>>
>>> While I can see your point, I'm afraid that's not how the
>>> interface was meant to be used.
>>
>> Well the first question to ask is, is that hypercall part of the stable
>> interface?  If so, then the standard should be, "Don't break people who
>> call it unless there is really no other way around it."  Sure, it was a
>> mistake whoever introduced that, but if Tamas is building on a "stable"
>> interface he should be able to rely on that interface being maintained,
>> at least until we can find a suitable replacement.
>>
>>  -George
>>
> 
> Of course if a suitable replacement can be made that gets me the
> information I need that would work too. At the moment I'm not aware of
> any other hypercall I could use for this purpose.

So actually -- it sounds like both Jan and I misunderstood the
situation.  The header file clearly says:

 * XENMEM_increase_reservation:
 *   OUT: MFN (*not* GMFN) bases of extents that were allocated

Are you saying that for HVM guests, that statement is false?

 -George

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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 Juergen [0], however AFAIK
> > > the patches are not yet in Jens/Linus tree, so it's too early to
> > > request a backport.
> ...
> > I will send the git pull tomorrow. Thanks.
> 
> Thanks.
> 
> >From the pov of updating osstest to Linux 4.9:
> 
> 13:55  juergen_gross: Re your patch series "xen/blkback:
>several fixes of resource management", DYK how long
>this problem has existed ?
> 13:55  Specifically, DYK if it is a problem in 3.18 ?
> 
> 14:10  Diziet: I think this was introduced with the multiqueue
>blkback patches, or at least it make it easier to
>surface
> 
> I think the last thing we want in our main kernel for osstest is more
> heisenbugs.  So I propose to wait for this fix to make it into
> osstest-tested version of linux-4.9.
> 
> Konrad, can you please CC me on the pull request so I can track this ?

Of course.
> 
> Thanks,
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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 info back from increase-reservation for
translated domains, just like we don't for populate-physmap and
memory-exchange. For full symmetry also check for a NULL guest handle
in populate_physmap() (but note this makes no sense in
memory_exchange(), as there the array is also an input).

Signed-off-by: Jan Beulich 



Reviewed-by: Andrew Cooper 



Unfortunately I just had time to do testing with this change and I
have to report that introduces a critical regression for my tools.
With this change in-place performing increase_reservation on a target
domain no longer reports the guest frame number for external tools,
thus completely breaking advanced use-cases that require this
information to be able to do altp2m gfn remapping. This is a critical
step in being able to introduce shadow-pages that are used to hide
breakpoints and other memory modifications from the guest.



While I can see your point, I'm afraid that's not how the
interface was meant to be used. The mere fact that
populate-physmap and memory-exchange didn't return the
MFN(s) suggests to me that you already need to have a way
to deal with having to find out another way. Or are you
suggesting you rely on guests not using these interfaces?

As to a solution, I could possibly see us relax the change to
return the MFN(s) when the current and subject domains differ,
or even check paging mode of the caller domain instead of the
subject one (which would mean PVH Dom0 still wouldn't get to
see them). But if we do, imo we should do this consistently for
all three operations, rather than just for increase-reservation.


If at all possible, I would like to request this change not to be part
of the 4.9 release.



Hmm, it's been there for all of the RCs, so I'm not really happy
to consider the option of reverting at this point in time. But
Julien will have the final say anyway.



I am a bit confuse with the description of the problem. I understood "guest
frame number" as GFN. But AFAICT, this hypercall was returning MFN even for
HVM guests. So how this change is breaking altp2m remapping?


For HVM guests this hypercall returns a GFN that can subsequently be
populated into the guest physmap:

xc_domain_increase_reservation_exact(xch, domid, 1, 0, 0, &new_gfn);
xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &new_gfn);


I am sorry, I can't see how this can return a GFN for the HVM. Looking 
at the implementation of increase_reservation in Xen:


mfn = page_to_mfn(page);
if ( unlikely(__copy_to_guest_offset(a->extent_list, i, &mfn, 1)) )
  goto out;

This is an MFN and not a GFN. Except the strict check before, the code 
has not change for a while.


AFAICT, the purpose of increase_reservation is not to allocate a new 
GFN, it will just allocate the host memory for it. At least on ARM we 
have nothing to say "this GFN region is free". I would be surprised that 
such things exists on x86.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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 deletion(-)
>
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index 238011e..1e69e25 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -57,6 +57,13 @@
>  #define X86_TRAP_DEBUG  1
>  #define X86_TRAP_INT3   3
>
> +/* From xen/include/asm-x86/x86-defns.h */
> +#define X86_CR4_PGE0x0080 /* enable global pages */
> +
> +#ifndef ARRAY_SIZE
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
> +#endif
> +
>  typedef struct vm_event {
>  domid_t domain_id;
>  xenevtchn_handle *xce_handle;
> @@ -314,6 +321,24 @@ static void get_request(vm_event_t *vm_event, 
> vm_event_request_t *req)
>  }
>
>  /*
> + * X86 control register names
> + */
> +static const char* get_x86_ctrl_reg_name(uint32_t index)
> +{
> +static const char* names[] = {
> +[VM_EVENT_X86_CR0]  = "CR0",
> +[VM_EVENT_X86_CR3]  = "CR3",
> +[VM_EVENT_X86_CR4]  = "CR4",
> +[VM_EVENT_X86_XCR0] = "XCR0",
> +};
> +
> +if ( index >= ARRAY_SIZE(names) || names[index] == NULL )
> +return "";
> +
> +return names[index];
> +}
> +
> +/*
>   * Note that this function is not thread safe.
>   */
>  static void put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
> @@ -337,7 +362,7 @@ void usage(char* progname)
>  {
>  fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
>  #if defined(__i386__) || defined(__x86_64__)
> -fprintf(stderr, 
> "|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access");
> +fprintf(stderr, 
> "|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4");
>  #elif defined(__arm__) || defined(__aarch64__)
>  fprintf(stderr, "|privcall");
>  #endif
> @@ -369,6 +394,7 @@ int main(int argc, char *argv[])
>  int debug = 0;
>  int cpuid = 0;
>  int desc_access = 0;
> +int write_ctrlreg_cr4 = 1;
>  uint16_t altp2m_view_id = 0;
>
>  char* progname = argv[0];
> @@ -439,6 +465,10 @@ int main(int argc, char *argv[])
>  {
>  desc_access = 1;
>  }
> +else if ( !strcmp(argv[0], "write_ctrlreg_cr4") )
> +{
> +write_ctrlreg_cr4 = 1;
> +}
>  #elif defined(__arm__) || defined(__aarch64__)
>  else if ( !strcmp(argv[0], "privcall") )
>  {
> @@ -596,6 +626,18 @@ int main(int argc, char *argv[])
>  }
>  }
>
> +if ( write_ctrlreg_cr4 )
> +{
> +/* Mask the CR4.PGE bit so no events will be generated for global 
> TLB flushes. */
> +rc = xc_monitor_write_ctrlreg(xch, domain_id, VM_EVENT_X86_CR4, 1, 1,
> +  X86_CR4_PGE, 1);
> +if ( rc < 0 )
> +{
> +ERROR("Error %d setting write control register trapping with 
> vm_event\n", rc);
> +goto exit;
> +}
> +}
> +
>  /* Wait for access */
>  for (;;)
>  {
> @@ -806,6 +848,15 @@ int main(int argc, char *argv[])
> req.u.desc_access.is_write);
>  rsp.flags |= VM_EVENT_FLAG_EMULATE;
>  break;
> +case VM_EVENT_REASON_WRITE_CTRLREG:
> +printf("Control register written: rip=%016"PRIx64", vcpu %d: 
> "
> +   "reg=%s, old_value=%016"PRIx64", 
> new_value=%016"PRIx64"\n",
> +   req.data.regs.x86.rip,
> +   req.vcpu_id,
> +   get_x86_ctrl_reg_name(req.u.write_ctrlreg.index),
> +   req.u.write_ctrlreg.old_value,
> +   req.u.write_ctrlreg.new_value);
> +break;
>  default:
>  fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
>  }
> --
> 2.7.4

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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 for
> translated domains, just like we don't for populate-physmap and
> memory-exchange. For full symmetry also check for a NULL guest handle
> in populate_physmap() (but note this makes no sense in
> memory_exchange(), as there the array is also an input).
>
> Signed-off-by: Jan Beulich 

 Reviewed-by: Andrew Cooper 
>>>
>>> Unfortunately I just had time to do testing with this change and I
>>> have to report that introduces a critical regression for my tools.
>>> With this change in-place performing increase_reservation on a target
>>> domain no longer reports the guest frame number for external tools,
>>> thus completely breaking advanced use-cases that require this
>>> information to be able to do altp2m gfn remapping. This is a critical
>>> step in being able to introduce shadow-pages that are used to hide
>>> breakpoints and other memory modifications from the guest.
>>
>> While I can see your point, I'm afraid that's not how the
>> interface was meant to be used.
>
> Well the first question to ask is, is that hypercall part of the stable
> interface?  If so, then the standard should be, "Don't break people who
> call it unless there is really no other way around it."  Sure, it was a
> mistake whoever introduced that, but if Tamas is building on a "stable"
> interface he should be able to rely on that interface being maintained,
> at least until we can find a suitable replacement.
>
>  -George
>

Of course if a suitable replacement can be made that gets me the
information I need that would work too. At the moment I'm not aware of
any other hypercall I could use for this purpose.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> 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' qualifier in order to make life
>>> of the users of these functions easier.
>>>
>>> Indeed, if I have my own constant pointer &const struct my_type *p,
>>> and I call 'rb_next(&p->rb)', I get a GCC warning:
>>>
>>> warning: passing argument 1 of ‘rb_next’ discards qualifiers from pointer 
>>> target
>>> type
>>>
>>> Signed-off-by: Artem Bityutskiy 
>>> Signed-off-by: David Woodhouse 
>>> Signed-off-by: Linus Torvalds 
>>> [Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]
>>>
>>> Ported to Xen.
>>>
>>> Signed-off-by: Praveen Kumar 
>>
>> This looks okay now from a content pov, but I still have a question
>> and a remark.
>>
>> Question: Who's the original author? According to the Linux commit,
>> it's Artem, but without an explicit From: tag I think anyone trying to
>> "git am" you mail would put you in as the author. With this taken
>> care of (which the committer may be willing to do)
>> Acked-by: Jan Beulich 
>>
> 
> Thanks for your input.
> Pardon me, I am new to the forum. The Ack you added is only for this patch.

Yes.

> Also, do you want me to add 'From' and resend ?

As said, I think the committer may be able to take care of this. So
re-sending just because of this is likely not required.

> To be precise in below order  :
> 
> Signed-off-by: Artem Bityutskiy 
> Signed-off-by: David Woodhouse 
> Signed-off-by: Linus Torvalds 
> [Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]
> 
> Ported to Xen.
> 
> From: Artem Bityutskiy 
> Signed-off-by: Praveen Kumar 

Normally From: would go first (before the description text) I think.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Tamas K Lengyel]

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 back from increase-reservation for
> translated domains, just like we don't for populate-physmap and
> memory-exchange. For full symmetry also check for a NULL guest handle
> in populate_physmap() (but note this makes no sense in
> memory_exchange(), as there the array is also an input).
>
> Signed-off-by: Jan Beulich 


 Reviewed-by: Andrew Cooper 
>>>
>>>
>>> Unfortunately I just had time to do testing with this change and I
>>> have to report that introduces a critical regression for my tools.
>>> With this change in-place performing increase_reservation on a target
>>> domain no longer reports the guest frame number for external tools,
>>> thus completely breaking advanced use-cases that require this
>>> information to be able to do altp2m gfn remapping. This is a critical
>>> step in being able to introduce shadow-pages that are used to hide
>>> breakpoints and other memory modifications from the guest.
>>
>>
>> While I can see your point, I'm afraid that's not how the
>> interface was meant to be used. The mere fact that
>> populate-physmap and memory-exchange didn't return the
>> MFN(s) suggests to me that you already need to have a way
>> to deal with having to find out another way. Or are you
>> suggesting you rely on guests not using these interfaces?
>>
>> As to a solution, I could possibly see us relax the change to
>> return the MFN(s) when the current and subject domains differ,
>> or even check paging mode of the caller domain instead of the
>> subject one (which would mean PVH Dom0 still wouldn't get to
>> see them). But if we do, imo we should do this consistently for
>> all three operations, rather than just for increase-reservation.
>>
>>> If at all possible, I would like to request this change not to be part
>>> of the 4.9 release.
>>
>>
>> Hmm, it's been there for all of the RCs, so I'm not really happy
>> to consider the option of reverting at this point in time. But
>> Julien will have the final say anyway.
>
>
> I am a bit confuse with the description of the problem. I understood "guest
> frame number" as GFN. But AFAICT, this hypercall was returning MFN even for
> HVM guests. So how this change is breaking altp2m remapping?

For HVM guests this hypercall returns a GFN that can subsequently be
populated into the guest physmap:

xc_domain_increase_reservation_exact(xch, domid, 1, 0, 0, &new_gfn);
xc_domain_populate_physmap_exact(xch, domid, 1, 0, 0, &new_gfn);

...
Copy page contents from old_gfn to new_gfn and inject breakpoints,
make other memory modifications
...

xc_altp2m_change_gfn(xch, domid, altp2m_id, old_gfn, new_gfn);

Without being able to introduce a new gfn into the HVM guest's
physmap, we are unable to create a shadow page. It doesn't break
altp2m remapping itself, it breaks a per-requisite step in introducing
the page to remap to.

Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

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://xenbits.xen.org/osstest/linux-firmware.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>   Bug introduced:  edf9364d3f924aff6f77176b8e52a4b68e5c30d6
>   Bug not present: 791a9a666d1afe2603bcb2c6a4852d684e879252
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110566/

This is a merge commit, so the bisection result is not very useful:

   git-log --pretty=oneline 
791a9a666d1afe2603bcb2c6a4852d684e879252..edf9364d3f924aff6f77176b8e52a4b68e5c30d6
 | wc -l
   2233

The error message is this:

   ERROR: "__udivdi3" [fs/ufs/ufs.ko] undefined!
   scripts/Makefile.modpost:91: recipe for target '__modpost' failed
   make[1]: *** [__modpost] Error 1

I searched the commit log and CC'd a couple of people who have fixed
similar bugs elsewhere.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

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 tree, so it's too early to
> > request a backport.
...
> I will send the git pull tomorrow. Thanks.

Thanks.

From the pov of updating osstest to Linux 4.9:

13:55  juergen_gross: Re your patch series "xen/blkback:
   several fixes of resource management", DYK how long
   this problem has existed ?
13:55  Specifically, DYK if it is a problem in 3.18 ?

14:10  Diziet: I think this was introduced with the multiqueue
   blkback patches, or at least it make it easier to
   surface

I think the last thing we want in our main kernel for osstest is more
heisenbugs.  So I propose to wait for this fix to make it into
osstest-tested version of linux-4.9.

Konrad, can you please CC me on the pull request so I can track this ?

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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 failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 110510 
pass in 110556
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 110533 pass in 110510
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
110533
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
110533

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 110533 REGR. vs. 
110465

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 110510 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 110510 n/a
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail in 110510 blocked in 
110465
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail in 110510 
like 110465
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 110465
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 110465
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 110465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 110465
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110465
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 110465
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 110465
 build-amd64-prev  6 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 build-i386-prev   6 xen-build/dist-test  fail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never p

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

[osstest service owner]

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 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2d78f78a14528752266982473c07118f1bc336e3
baseline version:
 xen  7251b0d2b28552bf8d7287af9dc2504b4a43278b

Last test of basis   110492  2017-06-16 15:01:25 Z2 days
Testing same since   110567  2017-06-19 12:01:58 Z0 days1 attempts


People who touched revisions under test:
  Wei Liu 
  Zhongze Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2d78f78a14528752266982473c07118f1bc336e3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2d78f78a14528752266982473c07118f1bc336e3
+ branch=xen-unstable-smoke
+ revision=2d78f78a14528752266982473c07118f1bc336e3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x2d78f78a14528752266982473c07118f1bc336e3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.

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

[Ian Jackson]

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 directory Makefiles.

Firstly, the Rules.mk `clean' target overrides the pattern rule in
xen/test/Makefile.  The result is that `make -C xen clean' does not
actually run the livepatch clean target.

The Rules.mk clean target does have provision for recursing into
subdirectories, but that feature is tangled up with complex object
file iteration machinery which is not desirable here.  However, we can
extend the Rules.mk clean target since it is a double-colon rules.

Sadly this involves duplicating the SUBDIR iteration boilerplate.  (A
make function could be used but the cure would be worse than the
disease.)

Secondly, Rules.mk has a number of -include directives.  make likes to
try to (re)build files mentioned in includes.  With the % pattern
rule, this applies to those files too.

As a result, make -C xen clean would try to build `.*.d' (for example)
in xen/test.  This would fail with an error message.  The error would
be ignored because of the `-', but it's annoying and ugly.

Solve this by limiting the % pattern rule to the targets we expect it
to handle.  These are those listed in the top-level Makefile, apart
from: those which are subdir- or component-qualified; clean targets
(which are handled specially, even distclean); and dist,
src-tarball-*, etc. (which are converted to install by an earlier
Makefile).

Reported-by: Andrew Cooper 
Signed-off-by: Ian Jackson 
---
 xen/test/Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/test/Makefile b/xen/test/Makefile
index aa1a23b..aaa4996 100644
--- a/xen/test/Makefile
+++ b/xen/test/Makefile
@@ -7,7 +7,12 @@ ifneq ($(XEN_TARGET_ARCH),x86_32)
 SUBDIRS += livepatch
 endif
 
-%:
+install build subtree-force-update uninstall: %:
set -e; for s in $(SUBDIRS); do \
$(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $*; \
done
+
+clean::
+   set -e; for s in $(SUBDIRS); do \
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C $$s $@; \
+   done
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Praveen Kumar]

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 life
>> of the users of these functions easier.
>>
>> Indeed, if I have my own constant pointer &const struct my_type *p,
>> and I call 'rb_next(&p->rb)', I get a GCC warning:
>>
>> warning: passing argument 1 of ‘rb_next’ discards qualifiers from pointer 
>> target
>> type
>>
>> Signed-off-by: Artem Bityutskiy 
>> Signed-off-by: David Woodhouse 
>> Signed-off-by: Linus Torvalds 
>> [Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]
>>
>> Ported to Xen.
>>
>> Signed-off-by: Praveen Kumar 
>
> This looks okay now from a content pov, but I still have a question
> and a remark.
>
> Question: Who's the original author? According to the Linux commit,
> it's Artem, but without an explicit From: tag I think anyone trying to
> "git am" you mail would put you in as the author. With this taken
> care of (which the committer may be willing to do)
> Acked-by: Jan Beulich 
>

Thanks for your input.
Pardon me, I am new to the forum. The Ack you added is only for this patch.

Also, do you want me to add 'From' and resend ?
To be precise in below order  :

Signed-off-by: Artem Bityutskiy 
Signed-off-by: David Woodhouse 
Signed-off-by: Linus Torvalds 
[Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]

Ported to Xen.

From: Artem Bityutskiy 
Signed-off-by: Praveen Kumar 

Please do correct me if my understanding is wrong. Thanks.

> Remark: You've sent v3 of the series. This patch has no version
> indicator at all, and most other patches say v2. This is all quite
> inconsistent, and prevents easily identifying the various pieces
> belonging together when not using a threaded view. If you add
> new patches to a series, don't start them at v1. Instead in the
> brief revision info (after the first --- marker) simply say "New in
> v3."
>

Sure, my mistake. I was not aware of the same. I will take care in
future patches.
Thanks for your input.

Regards,

~Praveen.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> 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 my own constant pointer &const struct my_type *p,
> and I call 'rb_next(&p->rb)', I get a GCC warning:
> 
> warning: passing argument 1 of ‘rb_next’ discards qualifiers from pointer 
> target
> type
> 
> Signed-off-by: Artem Bityutskiy 
> Signed-off-by: David Woodhouse 
> Signed-off-by: Linus Torvalds 
> [Linux commit f4b477c47332367d35686bd2b808c2156b96d7c7]
> 
> Ported to Xen.
> 
> Signed-off-by: Praveen Kumar 

This looks okay now from a content pov, but I still have a question
and a remark.

Question: Who's the original author? According to the Linux commit,
it's Artem, but without an explicit From: tag I think anyone trying to
"git am" you mail would put you in as the author. With this taken
care of (which the committer may be willing to do)
Acked-by: Jan Beulich 

Remark: You've sent v3 of the series. This patch has no version
indicator at all, and most other patches say v2. This is all quite
inconsistent, and prevents easily identifying the various pieces
belonging together when not using a threaded view. If you add
new patches to a series, don't start them at v1. Instead in the
brief revision info (after the first --- marker) simply say "New in
v3."

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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 tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  edf9364d3f924aff6f77176b8e52a4b68e5c30d6
  Bug not present: 791a9a666d1afe2603bcb2c6a4852d684e879252
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110566/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/build-i386-pvops.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/build-i386-pvops.kernel-build 
--summary-out=tmp/110566.bisection-summary --basis-template=110515 
--blessings=real,real-bisect linux-linus build-i386-pvops kernel-build
Searching for failure / basis pass:
 110547 fail [host=huxelrebe1] / 110515 [host=nobling1] 110486 [host=nobling1] 
110464 [host=italia1] 110427 [host=baroque1] 110399 [host=nobling0] 110380 
[host=rimava1] 110346 [host=rimava1] 110288 [host=baroque1] 110236 
[host=nobling1] 110131 [host=huxelrebe0] 110093 [host=elbling0] 110060 
[host=rimava0] 110038 [host=elbling0] 110025 [host=nobling1] 110016 
[host=chardonnay1] 110006 [host=huxelrebe0] 109994 [host=chardonnay1] 109963 
[host=chardonnay0] 109943 [host=pinot0] 109920 [host=nobling1] 109889 
[host=nobling1] 109858 [host=nobling1] 109839 [host=nobling1] 109832 
[host=nobling1] 109821 [host=baroque1] 109809 [host=baroque1] 109801 
[host=elbling1] 109778 [host=rimava0] 109758 [host=rimava0] 109724 
[host=nobling1] 109706 [host=nobling1] 109697 [host=nobling1] 109685 
[host=nobling1] 109675 [host=nobling1] 109656 [host=baroque1] 109633 
[host=rimava1] 109598 [host=baroque1] 109572 [host=nobling1] 109552 
[host=chardonnay0] 109505 [host=baroque1] 109469 [host=pinot0] 109449 
[host=fiano0] 109428 [host=fiano0] 109404 [host=elbling1] 109390 
[host=baroque1] 109361 [host=pinot0] 109334 [host=baroque1] 109315 ok.
Failure / basis pass flights: 110547 / 109315
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
Latest edf9364d3f924aff6f77176b8e52a4b68e5c30d6 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass 791a9a666d1afe2603bcb2c6a4852d684e879252 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#791a9a666d1afe2603bcb2c6a4852d684e879252-edf9364d3f924aff6f77176b8e52a4b68e5c30d6
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 2 nodes in revision graph
Searching for test results:
 77143 pass irrelevant
 77218 [host=chardonnay0]
 77215 [host=italia1]
 77360 [host=italia0]
 77558 [host=chardonnay0]
 77554 [host=chardonnay1]
 77721 [host=fiano1]
 77716 [host=fiano1]
 77837 [host=pinot1]
 77830 pass irrelevant
 77902 [host=baroque1]
 77965 [host=italia1]
 78054 [host=chardonnay0]
 78147 [host=italia0]
 78227 [host=pinot1]
 78319 [host=italia0]
 78404 [host=pinot0]
 78480 [host=rimava1]
 78586 [host=chardonnay0]
 78487 [host=italia1]
 78670 [host=fiano1]
 78786 [host=italia0]
 78977 [host=chardonnay1]
 79068 [host=fiano1]
 79155 [host=rimava1]
 79208 [host=italia1]
 79349 [host=italia1]
 79352 [host=italia1]
 79389 [host=italia1]
 79450 [host=fiano1]
 79587 [host=italia1]
 79778 [host=italia0]
 79918 [host=italia1]
 80122 pass irrelevant
 80381 pass irrelevant
 80627 [host=italia1]
 81161 [host=huxelrebe0]
 81424 [host=italia0]
 81734 [host=italia0]
 82065 [host=rimava0]
 82419 [host=italia0]
 82614 [host=rimava0]
 82764 [host=italia0]
 82911 [host=italia1]
 83118 [host=italia1]
 83452 [host=italia0]
 83655 [host=italia0]
 83810 [host=italia0]
 84169 [host=huxelrebe0]
 84300 pass irrelevant
 84379 [host=huxelrebe0]
 84472 [host=huxelrebe0]
 84616 [host=pinot1]
 85168 [host=pinot1]
 85353 [host=chardonnay1]
 85509 [host=rimava0]
 85614 [host=huxelrebe0]
 85667 [host=huxelrebe0]
 85725 [host=baroque0]
 85776 [host=fiano1]
 85870 [host=huxelrebe0]
 85988 [host=pinot1]
 86111 [host=fiano1]
 86047 [host=baroque0]
 86187 [host=baroque0]
 86279 [host=huxelrebe0]
 86368 [host=elbling1]
 86449 [host=elbling1]
 86542 [host=baroque0]
 86626 [host=huxelrebe0]
 86811 [host=chardonnay0]
 86715 [host=huxelrebe0]
 86882 [host=huxelrebe0]
 87133 [host=chardonnay1]
 87236 [host=elbling1]
 87315 [host=huxelrebe0]
 87418 [host=elbling0]
 87558 [host=huxelrebe0]
 87701 [host=baroque0]
 87832 [host=baroque0]
 87977 [host=nocera0]
 

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

[Thomas Monjalon]

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.0c3cc4d1e011214183872a98f6b5c7db


11/05/2017 13:41, Tan, Jianfeng:
> Hi  Thomas and all,
> 
> Apologize for being an unqualified maintainer.
> 
> > -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> 
> > Ping
> > 
> > The Xen dom0 support in DPDK seems dead.
> > 
> > Reminder:
> > Last time we talked about, it was because of a severe bug which is not
> > fixed yet:
> > http://dpdk.org/ml/archives/dev/2016-July/044207.html
> 
> For this bug, we removed the userspace memset(0) and suppose it has been done 
> by kernel, however, xen0 uses __get_free_pages() kernel API to map hugepages 
> and reseve memseg, I think it makes sense to zero the hugepage for xen0 in 
> rte_dom0_mm kernel module (instead of some special code for xen0 in 
> userspace) to keep aligned behavior.
> 
> > http://dpdk.org/ml/archives/dev/2016-July/044376.html
> 
> It does not make any sense to upstream a netfront PMD before we have a 
> netback PMD, as the legacy netback driver would be the bottleneck. Anyone has 
> plan on this? And a question mark keeps in my mind that is it a must to 
> implement netback in dom0?
> 
> From another perspective, instead of using netfront/netback, we can also use 
> virtio/vhost as the device model; however, xl tool in xen only supports 
> vhost-kernel backend instead of vhost-user backend. So anyone has plan to 
> enhance xl tool so that we can accelerate dom0 just using vswitch like 
> OVS-DPDK?
> 
> A third solution is to use xenvirtio as the frontend, and vhost_xen as the 
> backend. This solution is to use virtio ring on grant table mechanism of xen. 
> Honestly, I don't even know if it still work now. And to make it more usable, 
> better to upstream vhost_xen inside popular vswitch like OVS-DPDK.
> 
> > The request (9 months ago) was to give more time for feedbacks:
> > http://dpdk.org/ml/archives/dev/2016-July/044847.html
> 
> Apologize again that I volunteer to maintain these files, but spend very few 
> time on this.
> 
> Thanks,
> Jianfeng




___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

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/osstest/logs/110513/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >  test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail REGR. vs. 
> > > 110456
> > 
> > In the spirit of trying to chase down heisenbugs: failures like this
> > seem to occur occasionally.  Here are the job-specific logs:
> > 
> >  
> > http://logs.test-lab.xenproject.org/osstest/logs/110513/test-amd64-amd64-xl-credit2/info.html
> > 
> > My observations looking at the logs:
> > 
> >  * The test was declared a failure because something, almost certainly
> >blkback, still had the LV open when osstest wanted to restart the
> >guest.  This occurred 14 seconds after `xl shutdown -w' had
> >completed and `xl list' said the domain did not exist, so it is
> >not a simple race between the old and new domains.
> > 
> >  * The xenstored access log shows the toolstack deleting the vbd
> >backend during the shutdown, as expected.
> > 
> >  * `xl list' shows two zombie domains: 17 (the recently-shut-down
> >guest) and 16 (the previous one).
> > 
> >  * The toolstack log shows that xl thinks it successfully shut down
> >domain 17 and then destroyed it.
> > 
> >  * The hotplug script log is empty.
> > 
> >  * I see nothing relevant in the dom0 serial log, before the failure
> > 
> > I conjecture that blkback is not shutting down properly.
> > 
> > I haven't investigated which osstest branches this occurs on and what
> > the failure frequency is like.
> 
> This has already been noticed and fixed by Juergen [0], however AFAIK
> the patches are not yet in Jens/Linus tree, so it's too early to
> request a backport.
> 
> Roger.
> 
> [0] http://marc.info/?l=xen-devel&m=149512136831508&w=2

I will send the git pull tomorrow. Thanks.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Bhupinder Thakur]

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_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 required by the emulation code for reading/writing data. By
>> > that time, the page would have been physically mapped.
>>
>> You would not be able to report an error if you fail to map it. But this
>> looks like to me a workaround for a tool problem.
>>
>> Anyway, as I said, I'd like feedback from the tools maintainers to see how
>> we can proceed.
>>
>
> Is there a summary of the problem, is there a particular email in this
> thread I should look at? Sorry I'm swamped by emails and patches at the
> moment.

I will summarize the problem.

It was decided to call domain_vpl011_init() from inside
libxl__arch_domain_create() to initialize vpl011. However,
domain_vpl011_init() fails to map the the vuart GFN because it has not
been physically mapped yet by the toolstack.

The following call flows highlights the issue.

libxl__domain_build() ---> libxl__build_pv ---> libxl__build_dom()
> xc_dom_build_image() ---> alloc_magic_pages() > vuart GFN
allocated/mapped here

libxl__domain_build() > libxl__build_pre()  >
libxl__arch_domain_create() > domain_vpl011_init() ---> this call
fails as the vuart GFN has not been physically mapped yet as shown in
the first call flow.

However, libxl__build_pv() is called after libxl__build_pre(). It
means that the domain_vpl011_init() is called before
alloc_magic_pages() is called and hence the initialization fails.

For that reason, I had introduced a new function
libxl__arch_domain_create_finish() which will be called from
libxl__build_post(). I moved the domain_vpl011_init() there. However,
Julien pointed out that vuart should be initialized early in
libxl__arch_domain_create() function.

So the issue is what is the right place to call domain_vpl011_init()?

I hope it clarifies the issue.

Regards,
Bhupinder

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Andrew Cooper]

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 and are now in
> xen.git#master.  I have just applied them to staging-4.9 (and
> staging-4.8).

Unfortunately, the `make -C xen clean` target is now broken.

make -f /local/xen.git/xen/Rules.mk -C test clean
make[2]: Entering directory '/local/xen.git/xen/test'
set -e; for s in livepatch; do \
make -f /local/xen.git/xen/Rules.mk -C $s .*.d; \
done
make[3]: Entering directory '/local/xen.git/xen/test/livepatch'
make[3]: *** No rule to make target '.*.d'.  Stop.
make[3]: Leaving directory '/local/xen.git/xen/test/livepatch'

I think the %: rule is too general, and needs restricting to the primary
commands.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

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?

I have an osstest branch which we think will help with the Windows
migration problems.  It's currently in the osstest self-push-gate.

You'll see from my mail earlier today that I force pushed linux-4.9.

Currently I'm waiting for Juergen to tell me whether (if we know) the
bugs fixed by his series "xen/blkback: several fixes of resource
management" are present in earlier versions of Linux, such as the 3.18
that osstest is currently using.

If those bugs are present there too then moving to Linux 4.9 would not
be a regression introducing heisenbugs.  If they are then I think we
should still wait (and hope that Linux 4.9 doesn't break any further).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

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 Liu 
> 
> Ping?

I don't think I have any basis to withhold an ack.  Please update this
in xen.git#staging:Config.mk.  Obviously this isn't really suitable
for staging-4.9.

Acked-by: Ian Jackson 

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

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 applied them to staging-4.9 (and
staging-4.8).

Thanks,
Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Florian Jakobsmeier]

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 have looked at it.
>
> as part of my Bachelor's Thesis I'm trying to implement a single-stepping
>> functionality for Xen on ARMv7. My problem with this is, that I'm not able
>> to trigger a Hardware Breakpoint, which is configured to use Instruction
>> Address Mismatch and route the exception to Xen.
>>
>
> You are looking at single-stepping for guest, right?
>
>
 Yes I'm trying to implement guest single stepping.



>
>> I took the x86 single_step implementation as a reference. To test my
>> implementation I extended the given "xen-access" tool test, in order to
>> forward the SS request from xen-access.c to ./xen/arch/arm/monitor.c to the
>> "arch_monitor_domctl_event" function (just like the x86 implementation)
>>
>> There, I set the necessary registers according to the ARM Architectur
>> Manual (ARM DDI 0406C-b). My basic idea is to perform the following steps
>> (in this order):
>> 1) Configure the system to route debug exceptions to Hyp Mode
>> 2) Initialize one breakpoint for Address Mismatching in Non-Secure PL1/PL0
>> 3) Define the "to be compared" address as "~0x3" (which is all 1s except
>> Bit[1:0])
>> 4) Set the MDBGen to 1 in order to enable Monitor Debug Mode
>>
>> To check whether or not my values are set in the registers I print every
>> value before and after manipulation to ensure that my values are adopted.
>> To access the registers I used the already defines Makros (DBGBCR0), but
>> for testing reasons I work with the general definition (e.g.
>> WRITE_SYSREG(#VALUE,p14,0,c0,c0,5) for DBGBCR0 ).
>>
>> Preparation:
>>
>> I ensured that the DBGen Signal is High, I checked the Debug Version
>> which is v7.1 (read from the DBGAUTHSTATUS). I also made sure that the
>> underlying system supports sufficient breakpoints.
>>
>> These are the values I set in the different registers (in this order
>> again). Every bit that I don't mention is set to 0
>>
>> - HDCR.{TDRA,TDOSA,TDA,TDE = 1}
>> which enables routing to Hyp. According to the ARM ARM setting
>> TDRA,TDOSA,TDA is required when setting TDE
>>
>> - DBGBCR0.{BT=0b0100, SSC=0b01, PMC=0b11, E=0b1}=  0x404007
>> this should enable unlinked Address Musmatch, for Non-Secure PL0 >
>> - DBGBVR0.{IA = ~0x3}
>> which sets every bit to 1 (this address should never be reached as it is
>> mismatched)
>>
>> - DBGDSCREXT.{MDBGen=1}
>> which enables Monitor Debug Mode
>>
>>
>> With the value set in HVBAR (hyp_traps_vector in
>> /xen/arch/arm/arm32/entry.S) the generated HypTrap (HypTrap instead of
>> PrefetchAbort because of the routing) should be handled in
>> do_trap_guest_sync. In this method the "hsr.ec " Bits
>> should indicate a PrefetchAbort exception (hsr.ec =0x20)
>> whenever the Breakpoint triggers.
>>
>> I added a simple if statement to print a string when such a exception was
>> thrown.
>>
>> Unfortunately these prints are never generated, which indicates that
>> either I'm searching for the exception handling on the wrong location or my
>> breakpoints are not correctly configured.
>>
>> To check if my configuration is wrong, I also tried the KDB configuration
>> for the DBGBCR (which is DBGBCR=0x4001E7 as far as I understood). But this
>> changed nothing in the behaviour.
>>
>> As Hardware I tested my code with an Arndale as well as a Odroid XU board
>> (Exynos 5250).
>>
>> It would be great if anyone, who has experience with the ARM
>> architecture, could help me in finding the missing information that is
>> required to successfully set up an address mismatch breakpoint and
>> succesfully route the associated exceptions to Xen.
>>
>
> I've looked at the spec and your description seem to match it. Where do
> you configure the debug registers? Is it the vm_event handler or when
> returning to the guest vCPU?
>
> Ok thats good to hear. As mentioned, my approach is to extend the
xen_access test file. Which sets the registers in the Monitor.c in
/xen/xen/arch/arm (so from within the Hypervisor). Startet is this routin
from DOM0. So the execution starts in /tools/tests/xen-access and gets
forwarded to this function. I "trigger" this event by starting the compiled
xen-access.com file from within the Dom0

But I'm not quite sure whether this is what you wanted to know.




> Also, would you mind to share your code?
>
>
Here are the important parts: This is the extended Switch-Case in
monitor.c/arch_monitor_domctl_event()

+++ Github/xen/xen/arch/arm/monitor.c2017-06-19 14:40:41.156356471 +0200
@@ -28,6 +28,7 @@
   struct xen_domctl_monitor_op *mop)
 {
 struct arch_domain *ad = &d->arch;
 bool_t requested_status = (XEN_DOMCTL_MONITOR_OP_ENABLE == mop->op);

 switch ( mop->event )
@

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

[Julien Grall]

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, 16K, and 64K). The implementation is
based on ARM DDI 0487B-a J1-5922, J1-5999, and ARM DDI 0406C-b B3-1510.


NIT: The spec is 0487B.a and not 0487B-a.



Note that the current implementation lacks support for Large VA/PA on
ARMv8.2 architectures (LVA/LPA, 52-bit virtual and physical address
sizes). The associated location in the code is marked appropriately.


I am a bit confused, you are stating the 52-bit is not supported, but 
you seem to implement it below.


I don't want to see a feature half supported as this means rotten code. 
Given that 52-bit support in Xen is not implemented (and would require 
some work), 52-bit guest cannot be supported. So I would prefer that to 
see no code at all. Though I would keep the comment in the commit message.




Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Use TCR_SZ_MASK instead of TTBCR_SZ_MASK for ARM 32-bit guests using
the long-descriptor translation table format.

Cosmetic fixes.

v3: Move the implementation to ./xen/arch/arm/guest_copy.c.

Remove the array strides and declare the array grainsizes as static
const instead of just const to reduce the function stack overhead.

Move parts of the funtion guest_walk_ld into the static functions
get_ttbr_and_gran_64bit and get_top_bit to reduce complexity.

Use the macro BIT(x) instead of (1UL << x).

Add more comments && Cosmetic fixes.
---
 xen/arch/arm/guest_walk.c| 397 ++-
 xen/include/asm-arm/guest_walk.h |   9 +
 2 files changed, 404 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index f2f3533665..90bcc218ec 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -16,6 +16,8 @@
  */

 #include 
+#include 
+#include 

 /*
  * The function guest_walk_sd translates a given GVA into an IPA using the
@@ -32,6 +34,92 @@ static int guest_walk_sd(struct domain *d,
 return -EFAULT;
 }

+#ifdef CONFIG_ARM_64


It is fairly confusing. Sometimes you #ifdef the AArch64 code, sometimes 
not (see below the if is_64bit_domain below). Can you stay consistent 
across the file please.


IHMO, we should really limit the #ifdef CONFIG_ARM_64. This makes more 
difficult to follow the code and has limited benefits if all definitions 
also exist for AArch32 too.



+/*
+ * Select the TTBR(0|1)_EL1 that will be used for address translation using the
+ * long-descriptor translation table format and return the page granularity
+ * that is used by the selected TTBR.
+ */
+static bool get_ttbr_and_gran_64bit(uint64_t *ttbr, unsigned int *gran,
+register_t tcr, bool ttbrx)
+{
+bool disabled;
+
+if ( ttbrx == TTBR0_VALID )
+{
+/* Normalize granule size. */
+switch ( tcr & TCR_TG0_MASK )
+{
+case TCR_TG0_16K:
+*gran = GRANULE_SIZE_INDEX_16K;
+break;
+case TCR_TG0_64K:
+*gran = GRANULE_SIZE_INDEX_64K;
+break;
+default:
+*gran = GRANULE_SIZE_INDEX_4K;
+}
+
+/* Use TTBR0 for GVA to IPA translation. */
+*ttbr = READ_SYSREG64(TTBR0_EL1);
+
+/* If TCR.EPD0 is set, translations using TTBR0 are disabled. */
+disabled = tcr & TCR_EPD0;
+}
+else
+{
+/* Normalize granule size. */
+switch ( tcr & TCR_EL1_TG1_MASK )
+{
+case TCR_EL1_TG1_16K:
+*gran = GRANULE_SIZE_INDEX_16K;
+break;
+case TCR_EL1_TG1_64K:
+*gran = GRANULE_SIZE_INDEX_64K;
+break;
+default:
+*gran = GRANULE_SIZE_INDEX_4K;
+}
+
+/* Use TTBR1 for GVA to IPA translation. */
+*ttbr = READ_SYSREG64(TTBR1_EL1);
+
+/* If TCR.EPD1 is set, translations using TTBR1 are disabled. */
+disabled = tcr & TCR_EPD1;
+}
+
+return disabled;
+}
+#endif
+
+/*
+ * Get the MSB number of the GVA, according to "AddrTop" pseudocode
+ * implementation in ARM DDI 0487B-a J1-6066.


NIT: The spec is 0487B.a and not 0487B-a.


+ */
+static unsigned int get_top_bit(struct domain *d, vaddr_t gva, register_t tcr)
+{
+unsigned int topbit;
+
+/*
+ * IF EL1 is using AArch64 then addresses from EL0 using AArch32 are
+ * zero-extended to 64 bits (ARM DDI 0487B-a J1-6066).
+ */
+if ( is_32bit_domain(d) )
+topbit = 31;
+#ifdef CONFIG_ARM_64
+else if ( is_64bit_domain(d) )
+{
+if ( ((gva & BIT(55)) && (tcr & TCR_EL1_TBI1)) ||
+ (!(gva & BIT(55)) && (tcr & TCR_EL1_TBI0)) )
+topbit = 55;
+else
+topbit = 

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

[Petre Pircalabu]

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
index 238011e..1e69e25 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -57,6 +57,13 @@
 #define X86_TRAP_DEBUG  1
 #define X86_TRAP_INT3   3
 
+/* From xen/include/asm-x86/x86-defns.h */
+#define X86_CR4_PGE0x0080 /* enable global pages */
+
+#ifndef ARRAY_SIZE
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+#endif
+
 typedef struct vm_event {
 domid_t domain_id;
 xenevtchn_handle *xce_handle;
@@ -314,6 +321,24 @@ static void get_request(vm_event_t *vm_event, 
vm_event_request_t *req)
 }
 
 /*
+ * X86 control register names
+ */
+static const char* get_x86_ctrl_reg_name(uint32_t index)
+{
+static const char* names[] = {
+[VM_EVENT_X86_CR0]  = "CR0",
+[VM_EVENT_X86_CR3]  = "CR3",
+[VM_EVENT_X86_CR4]  = "CR4",
+[VM_EVENT_X86_XCR0] = "XCR0",
+};
+
+if ( index >= ARRAY_SIZE(names) || names[index] == NULL )
+return "";
+
+return names[index];
+}
+
+/*
  * Note that this function is not thread safe.
  */
 static void put_response(vm_event_t *vm_event, vm_event_response_t *rsp)
@@ -337,7 +362,7 @@ void usage(char* progname)
 {
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
-fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access");
+fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid|desc_access|write_ctrlreg_cr4");
 #elif defined(__arm__) || defined(__aarch64__)
 fprintf(stderr, "|privcall");
 #endif
@@ -369,6 +394,7 @@ int main(int argc, char *argv[])
 int debug = 0;
 int cpuid = 0;
 int desc_access = 0;
+int write_ctrlreg_cr4 = 1;
 uint16_t altp2m_view_id = 0;
 
 char* progname = argv[0];
@@ -439,6 +465,10 @@ int main(int argc, char *argv[])
 {
 desc_access = 1;
 }
+else if ( !strcmp(argv[0], "write_ctrlreg_cr4") )
+{
+write_ctrlreg_cr4 = 1;
+}
 #elif defined(__arm__) || defined(__aarch64__)
 else if ( !strcmp(argv[0], "privcall") )
 {
@@ -596,6 +626,18 @@ int main(int argc, char *argv[])
 }
 }
 
+if ( write_ctrlreg_cr4 )
+{
+/* Mask the CR4.PGE bit so no events will be generated for global TLB 
flushes. */
+rc = xc_monitor_write_ctrlreg(xch, domain_id, VM_EVENT_X86_CR4, 1, 1,
+  X86_CR4_PGE, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting write control register trapping with 
vm_event\n", rc);
+goto exit;
+}
+}
+
 /* Wait for access */
 for (;;)
 {
@@ -806,6 +848,15 @@ int main(int argc, char *argv[])
req.u.desc_access.is_write);
 rsp.flags |= VM_EVENT_FLAG_EMULATE;
 break;
+case VM_EVENT_REASON_WRITE_CTRLREG:
+printf("Control register written: rip=%016"PRIx64", vcpu %d: "
+   "reg=%s, old_value=%016"PRIx64", 
new_value=%016"PRIx64"\n",
+   req.data.regs.x86.rip,
+   req.vcpu_id,
+   get_x86_ctrl_reg_name(req.u.write_ctrlreg.index),
+   req.u.write_ctrlreg.old_value,
+   req.u.write_ctrlreg.new_value);
+break;
 default:
 fprintf(stderr, "UNKNOWN REASON CODE %d\n", req.reason);
 }
-- 
2.7.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Petre Pircalabu]

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-by: Tamas K Lengyel 
---
 tools/libxc/include/xenctrl.h | 2 +-
 tools/libxc/xc_monitor.c  | 5 -
 xen/arch/x86/hvm/monitor.c| 3 ++-
 xen/arch/x86/monitor.c| 9 +
 xen/include/asm-x86/domain.h  | 1 +
 xen/include/public/domctl.h   | 8 
 6 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f41..8c26cb4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1999,7 +1999,7 @@ int xc_monitor_get_capabilities(xc_interface *xch, 
domid_t domain_id,
 uint32_t *capabilities);
 int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
  uint16_t index, bool enable, bool sync,
- bool onchangeonly);
+ uint64_t bitmask, bool onchangeonly);
 /*
  * A list of MSR indices can usually be found in /usr/include/asm/msr-index.h.
  * Please consult the Intel/AMD manuals for more information on
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index f99b6e3..b44ce93 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -70,7 +70,7 @@ int xc_monitor_get_capabilities(xc_interface *xch, domid_t 
domain_id,
 
 int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
  uint16_t index, bool enable, bool sync,
- bool onchangeonly)
+ uint64_t bitmask, bool onchangeonly)
 {
 DECLARE_DOMCTL;
 
@@ -82,6 +82,9 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t 
domain_id,
 domctl.u.monitor_op.u.mov_to_cr.index = index;
 domctl.u.monitor_op.u.mov_to_cr.sync = sync;
 domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
+domctl.u.monitor_op.u.mov_to_cr.bitmask = bitmask;
+domctl.u.monitor_op.u.mov_to_cr.pad1 = 0;
+domctl.u.monitor_op.u.mov_to_cr.pad2 = 0;
 
 return do_domctl(xch, &domctl);
 }
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index bde5fd0..a7ccfc4 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -38,7 +38,8 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 
 if ( (ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask) &&
  (!(ad->monitor.write_ctrlreg_onchangeonly & ctrlreg_bitmask) ||
-  value != old) )
+  value != old) &&
+ (!((value ^ old) & ad->monitor.write_ctrlreg_mask[index])) )
 {
 bool_t sync = !!(ad->monitor.write_ctrlreg_sync & ctrlreg_bitmask);
 
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 449c64c..bedf13c 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -136,6 +136,9 @@ int arch_monitor_domctl_event(struct domain *d,
 if ( unlikely(mop->u.mov_to_cr.index > 31) )
 return -EINVAL;
 
+if ( unlikely(mop->u.mov_to_cr.pad1 || mop->u.mov_to_cr.pad2) )
+return -EINVAL;
+
 ctrlreg_bitmask = monitor_ctrlreg_bitmask(mop->u.mov_to_cr.index);
 old_status = !!(ad->monitor.write_ctrlreg_enabled & ctrlreg_bitmask);
 
@@ -155,9 +158,15 @@ int arch_monitor_domctl_event(struct domain *d,
 ad->monitor.write_ctrlreg_onchangeonly &= ~ctrlreg_bitmask;
 
 if ( requested_status )
+{
+ad->monitor.write_ctrlreg_mask[mop->u.mov_to_cr.index] = 
mop->u.mov_to_cr.bitmask;
 ad->monitor.write_ctrlreg_enabled |= ctrlreg_bitmask;
+}
 else
+{
+ad->monitor.write_ctrlreg_mask[mop->u.mov_to_cr.index] = 0;
 ad->monitor.write_ctrlreg_enabled &= ~ctrlreg_bitmask;
+}
 
 if ( VM_EVENT_X86_CR3 == mop->u.mov_to_cr.index )
 {
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 924caac..27d80ee 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -406,6 +406,7 @@ struct arch_domain
 unsigned int cpuid_enabled   : 1;
 unsigned int descriptor_access_enabled   : 1;
 struct monitor_msr_bitmap *msr_bitmap;
+uint64_t write_ctrlreg_mask[4];
 } monitor;
 
 /* Mem_access emulation control */
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index f7cbc0a..ff39762 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1107,6 +1107,14 @@ struct xen_domctl_monitor_op {
 uint8_t sync;
 /* Send event only on a change of value */
 uint8_t onchangeonly;
+/* Allignment padding */
+uint8_t pad1;
+

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

[Petre Pircalabu]

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_SIZE and named indexes for x86 ctrl register resolution
  * add allignment padding for xen_domctl_monitor_op

Changed since v3
  * Fix index condition in get_x86_ctrl_reg_name

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

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 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 required by the emulation code for reading/writing data. By
> > that time, the page would have been physically mapped.
> 
> You would not be able to report an error if you fail to map it. But this
> looks like to me a workaround for a tool problem.
> 
> Anyway, as I said, I'd like feedback from the tools maintainers to see how
> we can proceed.
> 

Is there a summary of the problem, is there a particular email in this
thread I should look at? Sorry I'm swamped by emails and patches at the
moment.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

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.
> 
> The warnings are treated as errors by -Werror, and goes like this 
> (abbreviated):
> 
> xenpmd.c:94:36: error: ‘%s’ directive output may be truncated writing up to
> 255 bytes into a region of size 13 [-Werror=format-truncation=]
>  #define BATTERY_INFO_FILE_PATH "/proc/acpi/battery/%s/info"
> ^
> xenpmd.c:113:13: note: ‘snprintf’ output between 25 and 280 bytes into a
> destination of size 32
> 
> xenpmd.c:95:37: error: ‘%s’ directive output may be truncated writing up to
> 255 bytes into a region of size 13 [-Werror=format-truncation=]
>  #define BATTERY_STATE_FILE_PATH "/proc/acpi/battery/%s/state"
>  ^
> xenpmd.c:116:13: note: ‘snprintf’ output between 26 and 281 bytes into a
> destination of size 32
> 
> xenctrl_stubs.c:65:15: error: ‘%s’ directive output may be truncated writing
> up to 1023 bytes into a region of size 252 [-Werror=format-truncation=]
>   "%d: %s: %s", error->code,
>^~
> xenctrl_stubs.c:64:4: note: ‘snprintf’ output 5 or more bytes (assuming 1028)
> into a destination of size 256
> 
> Enlarge the size of these buffers as suggested by the complier
> (and slightly rounded) to fix the warnings.
> 
> No functional changes.
> 
> Signed-off-by: Zhongze Liu 
> Acked-by: Wei Liu 

Applied.

Julien, consider this for 4.9?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

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 mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Roger Pau Monné]

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 succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail REGR. vs. 
> > 110456
> 
> In the spirit of trying to chase down heisenbugs: failures like this
> seem to occur occasionally.  Here are the job-specific logs:
> 
>  
> http://logs.test-lab.xenproject.org/osstest/logs/110513/test-amd64-amd64-xl-credit2/info.html
> 
> My observations looking at the logs:
> 
>  * The test was declared a failure because something, almost certainly
>blkback, still had the LV open when osstest wanted to restart the
>guest.  This occurred 14 seconds after `xl shutdown -w' had
>completed and `xl list' said the domain did not exist, so it is
>not a simple race between the old and new domains.
> 
>  * The xenstored access log shows the toolstack deleting the vbd
>backend during the shutdown, as expected.
> 
>  * `xl list' shows two zombie domains: 17 (the recently-shut-down
>guest) and 16 (the previous one).
> 
>  * The toolstack log shows that xl thinks it successfully shut down
>domain 17 and then destroyed it.
> 
>  * The hotplug script log is empty.
> 
>  * I see nothing relevant in the dom0 serial log, before the failure
> 
> I conjecture that blkback is not shutting down properly.
> 
> I haven't investigated which osstest branches this occurs on and what
> the failure frequency is like.

This has already been noticed and fixed by Juergen [0], however AFAIK
the patches are not yet in Jens/Linus tree, so it's too early to
request a backport.

Roger.

[0] http://marc.info/?l=xen-devel&m=149512136831508&w=2

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Operf and Opreport outputs

[dhara buch]

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 it because of background
processes? If so, then can we get event count for only monitored command?

Thank you,

On Fri, Jun 16, 2017 at 4:52 PM, Michael Petlan  wrote:

> On Fri, 16 Jun 2017, dhara buch wrote:
> > Hello,
> >
> > Many days ago you had helped me a lot in using Oprofile in Virtual
> Machine. That time, I also had a query regarding
> > getting information from 'opreport --symbols --debuginfo' command.
>
> Hello,
>
> yeah, I remember...
>
> >
> > Actually, I am profiling a file1.c file with the following commands...
> >
> > 1. gcc -g file1.c -o file1
> >
> > 2. operf ./file1 --events=CPU_CLK_UNHALTED
> >
> > 3. opreport --symbols --debuginfo
> >
> > the output contains various lines where one line look follows:
> >
> > samples  %linenr info image name
> symbol name
> >
> > 2   12.5000  rsaimp.c:16 rsaimp   MM
> > 212.5000  rsaimp.c:34 rsaimp
> main
> >
> > When I execute commands 2 and 3 multiple times, each time I gwt the
> output for symbole name MM (which is UDF in the
> > program) but I don't get output for main every time.
> >
> This is kind of random, see below.
>
> > Additionally,'' the sample % also vary every time I file operf command.
> I do not understand the working of operf that
> > how it gives different outputs for the same program.
> >
>
> How _counting_ works:
>
> Each time an event happens in CPU (in our case -- CPU_CLK_UNHALTED -- one
> CPU tick), its counter is incremented by one. This way, you can get the
> whole number of how many times the event happened:
>
> $ ocount ls
> Events were actively counted for 1863267 nanoseconds.
> Event counts (actual) for /bin/ls:
>   EventCount% time counted
>   CPU_CLK_UNHALTED 2,672,309100.00
>
> This means that there were 2.672 million CPU ticks necessary to execute
> `ls`.
>
> The tool for counting is *ocount*.
>
>
> How _profiling_ works:
>
> For profiling, events are counted the same way as when counting, but only
> once per N event occurrences a "sample" is taken. A sample is a piece of
> information about where in the code it happened, what was the context and
> potentially call-stack, etc. This sample is saved into the oprofile_data
> dir structure. When you finish profiling, opreport generates some overview
> from the samples recorded.
>
> Of course, taking sample causes some overhead. Thus, you cannot take it
> each time the event counter increments. For this purpose, there is "sample
> rate" value which divides the event counter and takes a sample only once
> per "sample rate" occurrences. Thus, it is pretty random, which event
> occurrence is picked for a sample.
>
> Of course, your main() consumes CPU ticks and the counter is incremented,
> but sometimes, one of these incrementations produces sample, sometimes not,
> thus the function is missing.
>
> You have 2 samples on each of the line in the report. That is really a low
> number, so it is very probable that sometimes the samples hit main() and
> sometimes not.
>
> $ operf ls
> Profiling done.
>
> $ opreport
> Using /root/oprofile_data/samples/ for samples directory.
> CPU: Core 2, speed 2267 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit
> mask of 0x00 (Unhalted core cycles) count 10
> CPU_CLK_UNHALT...|
>   samples|  %|
> --
>  -->   37 100.000 ls
>CPU_CLK_UNHALT...|
>  samples|  %|
>  --
>   27 72.9730 kallsyms
>5 13.5135 libc-2.19.so
>2  5.4054 ld-2.19.so
>1  2.7027 ls
>1  2.7027 ext4
>1  2.7027 libattr.so.1.1.0
>
> You see that out of (estimated) 2.5-3.5 mil of event occurrences (which is
> the scale `ls` usually needs on my PC), I got only 37 samples.
>
> The sample rate for each event are in `ophelp` as "min count".
>
> Why did I get 37 samples? My default setting of default event is:
>
> $ ophelp -d
> CPU_CLK_UNHALTED:10:0:1:1
> ---^^
>
> This means that there is 1 sample per 10 event occurrences.
>
> You can tweak this value a bit, but note that oprofile won't let you set
> the value to be too low, due to the overhead reasons.
>
> Let's try 1 (sampling 10 times more often):
>
> $ operf -e CPU_CLK_UNHALTED:1 ls
> WARNING: Lost samples detected! See /root/oprofile_data/samples/operf.log
> for details.
> Lowering the sampling rate may reduce or eliminate lost samples.
> See the '--events' option description in the operf man page for help.
> Profiling done.
>
> $ opreport

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

[Julien Grall]

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 translation might fail,
as gva_to_ipa uses the guest's translation tables, access to which might
be restricted by the active VTTBR. To address this issue, in this commit
we add a software-based guest-page-table walk, which will be used by the
function p2m_mem_access_check_and_get_page perform the gva to ipa
translation in software in one of the following commits.

Note: The introduced function guest_walk_tables assumes that the domain,
the gva of which is to be translated, is running on the currently active
vCPU. To walk the guest's page tables on a different vCPU, the following
registers would need to be loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and
SCTLR_EL1.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Rename p2m_gva_to_ipa to p2m_walk_gpt and move it to p2m.c.

Move the functionality responsible for walking long-descriptor based
translation tables out of the function p2m_walk_gpt. Also move out
the long-descriptor based translation out of this commit.

Change function parameters in order to return access access rights
to a requested gva.

Cosmetic fixes.

v3: Rename the introduced functions to guest_walk_(tables|sd|ld) and
move the implementation to guest_copy.(c|h).

Set permissions in guest_walk_tables also if the MMU is disabled.

Change the function parameter of type "struct p2m_domain *" to
"struct vcpu *" in the functions guest_walk_(tables|sd|ld).
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/guest_walk.c| 92 
 xen/include/asm-arm/guest_walk.h | 19 +
 3 files changed, 112 insertions(+)
 create mode 100644 xen/arch/arm/guest_walk.c
 create mode 100644 xen/include/asm-arm/guest_walk.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2f84..282d2c2949 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_HAS_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-lpi.o
 obj-y += guestcopy.o
+obj-y += guest_walk.o
 obj-y += hvm.o
 obj-y += io.o
 obj-y += irq.o
diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
new file mode 100644
index 00..f2f3533665
--- /dev/null
+++ b/xen/arch/arm/guest_walk.c
@@ -0,0 +1,92 @@
+/*
+ * Guest page table walk
+ * Copyright (c) 2017 Sergej Proskurin 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+
+/*
+ * The function guest_walk_sd translates a given GVA into an IPA using the
+ * short-descriptor translation table format in software. This function assumes
+ * that the domain is running on the currently active vCPU. To walk the guest's
+ * page table on a different vCPU, the following registers would need to be
+ * loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and SCTLR_EL1.
+ */
+static int guest_walk_sd(struct domain *d,


As I said in v2, it should be a vcpu and not a domain here  because 
page-table are per-vCPU.



+ vaddr_t gva, paddr_t *ipa,
+ unsigned int *perms)
+{
+/* Not implemented yet. */
+return -EFAULT;
+}
+
+/*
+ * The function guest_walk_ld translates a given GVA into an IPA using the
+ * long-descriptor translation table format in software. This function assumes
+ * that the domain is running on the currently active vCPU. To walk the guest's
+ * page table on a different vCPU, the following registers would need to be
+ * loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and SCTLR_EL1.
+ */
+static int guest_walk_ld(struct domain *d,
+ vaddr_t gva, paddr_t *ipa,
+ unsigned int *perms)


Ditto.


+{
+/* Not implemented yet. */
+return -EFAULT;
+}
+
+int guest_walk_tables(const struct vcpu *v, vaddr_t gva,
+  paddr_t *ipa, unsigned int *perms)
+{
+uint32_t sctlr = READ_SYSREG(SCTLR_EL1);
+register_t tcr = READ_SYSREG(TCR_EL1);
+struct domain *d = v->domain;
+unsigned int _perms = GV2M_READ;
+
+/* We assume that the domain is running on the currently active domain. */
+if ( v != current )
+  

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

[Wei Liu]

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 you say why all of the sudden a wrapper
> > is needed.
> >
> 
> It's indeed a preparation for my GSoC project:
> https://lists.xen.org/archives/html/xen-devel/2017-05/msg01288.html
> 
> Thanks for the suggestion.
> 
> >
> >> --- a/tools/libxc/include/xenctrl.h
> >> +++ b/tools/libxc/include/xenctrl.h
> >> @@ -1372,6 +1372,15 @@ int xc_domain_add_to_physmap(xc_interface *xch,
> >>   unsigned long idx,
> >>   xen_pfn_t gpfn);
> >>
> >> +int xc_domain_add_to_physmap_batch(xc_interface *xch,
> >> +   uint32_t domid,
> >> +   uint32_t foreign_domid,
> >
> > I'm not exactly sure what the libxc coding rules are, but I'd expect
> > these both to be domid_t, ...
> >
> 
> I was planning to make them domid_t, but according to the other
> domid-parameters' types
> in the file, and they are all uint32_t, so I finally decided on uint32_t.

Both are used. We should use domid_t for new code.

> 
> >> +   unsigned int space,
> >> +   uint16_t size,
> >
> > ... this one to be unsigned int, ...
> 
> In the xen_add_to_physmap_batch struct, both @space and @size are
> uint16_t, so I think
> I should have made @space uint16_t, too. I'll fix this. Or do you have
> any good reasons to
> make both of them unsigned int?
> 

I agree with what Jan said.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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 in Xen until the ring buffer is
actually required by the emulation code for reading/writing data. By
that time, the page would have been physically mapped.


You would not be able to report an error if you fail to map it. But this 
looks like to me a workaround for a tool problem.


Anyway, as I said, I'd like feedback from the tools maintainers to see 
how we can proceed.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Anthony PERARD]

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 is a branch(tag) for all those commits:
https://xenbits.xen.org/git-http/people/aperard/osstest.git
tag: openstack-v11

> Anthony PERARD (17):
>   ts-openstack-deploy: Deploy OpenStack on a host with devstack
>   ts-openstack-tempest: Run Tempest to check OpenStack
>   Create a flight to test OpenStack with xen-unstable and libvirt
>   ts-openstack-deploy: Keep CURL_CA_BUNDLE when sudo is called
>   ts-openstack-deploy: Try to disable use of SYSTEMD
>   ts-kernel-build: Enable network related modules for Neutron
>   ts-openstack-deploy: Switch to Neutron for network
>   ts-openstack-deploy: Increase fd and memory limits for rabbitmq
>   make-flight: Increase dom0_mem for openstack flight
>   ts-openstack-deploy: Apply a Tempest patch
>   ts-openstack-deploy: Ignore libvirt-python version and use latest
>   ts-openstack-tempest: Fix tempest invocation
>   ts-openstack-tempest: Update list of skipped tests
>   ts-openstack-deploy: Move logs to /var/log/openstack
>   ts-logs-capture: Capture OpenStack logs
>   ts-openstack-deploy: Increase devstack timeout
>   Introduce flight for stable branches of OpenStack
> 
> Ian Jackson (3):
>   ts-openstack-deploy: Set http proxy
>   TestSupport: provide target_https_mitm_proxy_cert_path
>   ts-openstack-deploy: set CURL_CA_BUNDLE
> 
>  Osstest/TestSupport.pm |   7 +
>  ap-common  |  19 ++
>  ap-fetch-version   |  20 +++
>  ap-fetch-version-old   |  13 ++
>  ap-print-url   |   3 +
>  ap-push|  11 ++
>  cr-daily-branch|  36 
>  cr-for-branches|   2 +-
>  cri-common |   1 +
>  make-flight|  46 -
>  sg-run-job |   6 +
>  ts-kernel-build|  17 +-
>  ts-logs-capture|   6 +
>  ts-openstack-deploy| 190 
>  ts-openstack-tempest   |  63 +++
>  15 files changed, 436 insertions(+), 4 deletions(-)
>  create mode 100755 ts-openstack-deploy
>  create mode 100755 ts-openstack-tempest
> 
> -- 
> Anthony PERARD
> 

-- 
Anthony PERARD

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel