[Xen-devel] [xen-4.6-testing test] 100936: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 100936 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100936/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 4 host-build-prep  fail REGR. vs. 100895
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 100907 REGR. 
vs. 100895

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 100907 pass in 100936
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 100907 pass 
in 100936
 test-amd64-i386-freebsd10-i386 18 guest-start/freebsd.repeat fail pass in 
100907
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
100907
 test-amd64-amd64-amd64-pvgrub  9 debian-di-install fail pass in 100907
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
100907
 test-amd64-i386-xl-qemuu-debianhvm-amd64 17 guest-start/debianhvm.repeat fail 
pass in 100907

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-startfail in 100907 REGR. vs. 100895
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100895
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100895
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100895
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100895

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   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-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 100907 never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail in 100907 never pass
 test-armhf-armhf-xl-credit2 12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 100907 never 
pass
 test-armhf-armhf-libvirt12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail in 100907 never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 100907 never 
pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore  fail in 100907 never pass
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 100907 never pass
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 100907 never 
pass
 test-armhf-armhf-xl 12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 100907 never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 100907 never 
pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-check fail in 100907 
never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 100907 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 100907 
never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 100907 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 100907 never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never 

[Xen-devel] [ovmf test] 100940: all pass - PUSHED

[osstest service owner]

flight 100940 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100940/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d947fbed72226011961e5e2691f09baebf128795
baseline version:
 ovmf dd82465a9f0f0beff0e4d74c6e3192b966853332

Last test of basis   100932  2016-09-13 12:59:53 Z0 days
Testing same since   100940  2016-09-13 23:19:04 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=d947fbed72226011961e5e2691f09baebf128795
+ . ./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 ovmf 
d947fbed72226011961e5e2691f09baebf128795
+ branch=ovmf
+ revision=d947fbed72226011961e5e2691f09baebf128795
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xd947fbed72226011961e5e2691f09baebf128795 = 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.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

[Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan]

On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.

Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
to xen. It means how much memory user would like to be allocated
in lower 4GB memory space. If there is not enough memory for
dom0_lowmem, higher memory will be allocated.

Thinking such a memory layout on an AArch64 SoC:
Region 0: 2GB(0x8000 - 0x)
Region 1: 4GB(0x88000 - 0x97fff)
If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

RFC->V1:
 This patch is to resolve the issue in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
 No code change since RFC.
 Tested on xen-4.8 unstable with AArch64. See partial log:
 "dom0_mem = 2048M  dom0_lowmem=128M"
 (XEN) Allocated 0x008800-0x009000 (128MB/2048MB, order 15)
 (XEN) Allocated 0x088000-0x08c000 (1024MB/1920MB, order 18)
 (XEN) Allocated 0x09c000-0x09e000 (512MB/896MB, order 17)
 (XEN) Allocated 0x09e000-0x09f000 (256MB/384MB, order 16)
 (XEN) Allocated 0x08f800-0x09 (128MB/128MB, order 15)

 "dom0_mem = 2048M  dom0_lowmem=1024M"
 (XEN) Allocated 0x00a000-0x00c000 (512MB/2048MB, order 17)
 (XEN) Allocated 0x00c000-0x00e000 (512MB/1536MB, order 17)
 (XEN) Allocated 0x088000-0x08c000 (1024MB/1024MB, order 18)

 "dom0_mem = 1024M  dom0_lowmem=1024M"
 (XEN) Allocated 0x00a000-0x00c000 (512MB/1024MB, order 17)
 (XEN) Allocated 0x00c000-0x00e000 (512MB/512MB, order 17)

 xen/arch/arm/domain_build.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0f53bba 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -33,6 +33,8 @@ int dom0_11_mapping = 1;
 
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+/* Only for AArch64 */
+static u64 __initdata dom0_lowmem;
 
 static void __init parse_dom0_mem(const char *s)
 {
@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+static void __init parse_dom0_lowmem(const char *s)
+{
+dom0_lowmem = parse_size_and_unit(s, );
+}
+custom_param("dom0_lowmem", parse_dom0_lowmem);
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;
 
-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem;
 unsigned int bits;
 
 /*
@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  * First try and allocate the largest thing we can as low as
  * possible to be bank 0.
  */
+if ( dom0_lowmem )
+order = get_order_from_bytes(dom0_lowmem);
+
 while ( order >= min_low_order )
 {
 for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 
  got_bank0:
 
+if ( dom0_lowmem ) {
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+
 if ( !insert_11_bank(d, kinfo, pg, order) )
 BUG(); /* Cannot fail for first bank */
 
@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
+if ( dom0_lowmem && lowmem )
+{
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+else
+{
+lowmem = false;
+}
+
 /*
  * Success, next time around try again to get the largest order
  * allocation possible.
@@ -2098,6 +2124,8 @@ int construct_dom0(struct domain *d)
 
 d->max_pages = ~0U;
 
+BUG_ON(dom0_mem < dom0_lowmem);
+
 kinfo.unassigned_mem = dom0_mem;
 
 rc = kernel_probe();
-- 
2.6.6


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

[Xen-devel] [xen-4.5-testing baseline-only test] 67706: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67706 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67706/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 67683
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 67683
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 67683
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 67683
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67683
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67683

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-2  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-2   34 xtf/test-hvm64-invlpg~shadow fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-invlpg~shadow fail   never pass
 test-xtf-amd64-amd64-4  26 xtf/test-hvm32pae-invlpg~shadow fail never pass
 test-xtf-amd64-amd64-4   34 xtf/test-hvm64-invlpg~shadow fail   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-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 xen  c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
baseline version:
 xen  433ebca120e8750eb8085745ccac703e47358e6f

Last test of basis67683  2016-09-09 14:16:04 Z4 days
Testing same since67706  2016-09-13 20:15:55 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 

Re: [Xen-devel] [PATCH v3 12/19] libacpi: Build DSDT for PVH guests

[Shannon Zhao]

On 2016/9/8 2:59, Boris Ostrovsky wrote:
> PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
> objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
> that it can be included in ASLs for both HVM and PVH2.
> 
> Signed-off-by: Boris Ostrovsky 
> ---
> Changes in v3:
> * Added comment to dsdt_acpi_info.asl indicating that the structure
>   there must match struct acpi_info
> * Use QEMU_NONE in mk_dsdt.c
> * Makefile tweaks
> 
>  tools/libacpi/Makefile   | 13 ++---
>  tools/libacpi/dsdt.asl   | 20 
>  tools/libacpi/dsdt_acpi_info.asl | 26 ++
>  tools/libacpi/mk_dsdt.c  |  8 
>  4 files changed, 44 insertions(+), 23 deletions(-)
>  create mode 100644 tools/libacpi/dsdt_acpi_info.asl
> 
> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> index 6325cd0..12b081e 100644
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -18,7 +18,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
>  MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>  
>  # Sources to be generated
> -C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
> dsdt_anycpu_qemu_xen.c)
> +C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
>  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
> ssdt_tpm.h)
>  
Hi Bros,

It looks like you forgot to add 'C_SRC-$(CONFIG_X86)' here. Will you add
it in your next version?

Thanks,
-- 
Shannon


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

[Xen-devel] [ovmf baseline-only test] 67707: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67707 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67707/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf dd82465a9f0f0beff0e4d74c6e3192b966853332
baseline version:
 ovmf 8c0b0b34f7875571ee9d3a2a1a28484cef36d969

Last test of basis67700  2016-09-12 19:48:41 Z1 days
Testing same since67707  2016-09-13 23:20:39 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit dd82465a9f0f0beff0e4d74c6e3192b966853332
Author: Ard Biesheuvel 
Date:   Fri Sep 9 09:01:56 2016 +0100

ArmPkg/ArmMmuLib: base page table VA size on GCD memory map size

As reported by Eugene, the practice of sizing the address space in the
virtual memory system based on the maximum address in the table passed
to ArmConfigureMmu() is problematic, since it fails to take into account
the fact that the GCD memory space may be extended at a later time, both
for memory and for MMIO. So instead, choose the VA size identical to the
GCD memory map size, which is based on PcdPrePiCpuMemorySize on ARM
systems.

Reported-by: Eugene Cohen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Eugene Cohen 
Reviewed-by: Leif Lindholm 

commit d32702d2c2aa23e828363a7f88829b78ce36c3af
Author: Ard Biesheuvel 
Date:   Fri Sep 9 09:50:21 2016 +0100

ArmPkg/ArmMmuLib: use a pool allocation for the root table

Currently, we allocate a full page for the root translation table, even
if the configured translation only requires two entries (16 bytes) for
the root level, which happens to be the case for a 40 bit VA. Likewise,
for a 36-bit VA space, the root table only needs 16 entries of 8 bytes
each, adding up to 128 bytes.

So switch to a pool allocation for the root table if we can, but take into
account that the architecture requires it to be naturally aligned to its
size, i.e., a 64 byte table requires 64 byte alignment, whereas pool
allocations in general are only guaranteed to be aligned to 8 bytes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 674e127ef64b07a1e6e6bcc5ecbaead50ea81134
Author: Ard Biesheuvel 
Date:   Fri Sep 9 11:19:18 2016 +0100

ArmPkg/ArmMmuLib: remove bogus alignment of page allocations

In commit 7d189f99d81c ("ArmPkg/Mmu: Fix bug of aligning new allocated
page table"), we fixed a flaw in the logic regarding alignment of newly
allocated translation table pages. However, we all failed to spot that
aligning page based allocations to page size is rather pointless to
begin with, so simply allocate a single page each time we add new pages
to the translation tables.

Also, drop the unnecessary cast.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit e93cb72e597df7b37aad7910787b8ecaeac31382
Author: Ard Biesheuvel 
Date:   Fri Sep 9 10:52:25 2016 +0100

ArmPkg/ArmMmuLib: deobfuscate GetRootTranslationTableInfo ()

The relations between T0SZ, the number of translation levels and the
size/alignment of the root table 

[Xen-devel] [xen-unstable baseline-only test] 67705: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67705 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67705/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 67693
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 67693

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67693
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67693
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67693
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67693
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67693
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67693
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67693
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67693
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67693
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67693
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67693
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67693
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67693
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67693

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-amd64-amd64-libvirt 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-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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61
baseline version:
 xen  a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc

Last 

[Xen-devel] [xen-unstable test] 100933: tolerable FAIL

[osstest service owner]

flight 100933 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100933/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100902
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100902
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100902
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100902
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100902

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61
baseline version:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61

Last test of basis   100933  2016-09-13 13:03:38 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17058 days0 attempts

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

> -Original Message-
> From: Wu, Feng
> Sent: Monday, September 5, 2016 11:12 AM
> To: Jan Beulich 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; Wu, Feng 
> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> 
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: Friday, September 2, 2016 9:55 PM
> > To: Wu, Feng 
> > Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> > de...@lists.xen.org
> > Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> > PI hooks
> >
> > >>> On 02.09.16 at 15:15,  wrote:
> >
> > >
> > >> -Original Message-
> > >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> Sent: Friday, September 2, 2016 6:46 PM
> > >> To: Wu, Feng 
> > >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> > >> de...@lists.xen.org
> > >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> > assigning
> > >> PI hooks
> > >>
> > >> >>> On 02.09.16 at 12:30,  wrote:
> > >>
> > >> >
> > >> >> -Original Message-
> > >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> >> Sent: Friday, September 2, 2016 5:26 PM
> > >> >> To: Wu, Feng 
> > >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> > >> >> de...@lists.xen.org
> > >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> > >> assigning
> > >> >> PI hooks
> > >> >>
> > >> >> >>> On 02.09.16 at 10:40,  wrote:
> > >> >>
> > >> >> >
> > >> >> >> -Original Message-
> > >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> >> >> Sent: Friday, September 2, 2016 4:16 PM
> > >> >> >> To: Wu, Feng 
> > >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> > xen-
> > >> >> >> de...@lists.xen.org
> > >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> > >> >> assigning
> > >> >> >> PI hooks
> > >> >> >>
> > >> >> >> >>> On 02.09.16 at 09:31,  wrote:
> > >> >> >>
> > >> >> >> >
> > >> >> >> >> -Original Message-
> > >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
> > >> >> >> >> To: Wu, Feng 
> > >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> > >> xen-
> > >> >> >> >> de...@lists.xen.org
> > >> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain
> > before/after
> > >> >> >> assigning
> > >> >> >> >> PI hooks
> > >> >> >> >>
> > >> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
> > >> >> >> >>
> > >> >> >> >> >
> > >> >> >> >> >> -Original Message-
> > >> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> > >> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
> > >> >> >> >> >> To: Wu, Feng 
> > >> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> > >> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin
> > ;
> > >> >> xen-
> > >> >> >> >> >> de...@lists.xen.org
> > >> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
> > >> before/after
> > >> >> >> >> assigning
> > >> >> >> >> >> PI hooks
> > >> >> >> >> >>
> > >> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
> > >> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> > >> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> > >> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct
> > domain
> > >> *d)
> > >> >> >> >> >> >
> > >> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> > >> >> >> >> >> >
> > >> >> >> >> >> > +/*
> > >> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
> > >> >> >> >> >> > + * running and hence calling the hooks simultaneously
> > >> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
> > >> >> >> >> >> > + * all the appropriate state of PI descriptor is 
> > >> >> >> >> >> > actually
> > >> >> >> >> >> > + * set up for all vCPus before leaving this function.
> > >> >> >> >> >> > + */
> > >> >> >> >> >> > +domain_pause(d);
> > >> >> >> >> >> > +
> > >> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> > >> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume =
> > vmx_pi_do_resume;
> > >> >> >> 

Re: [Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

[Doug Goldstein]

On 9/13/16 2:40 PM, Derek Straka wrote:

> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 10985721..911fdfd 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -476,6 +476,7 @@ static void __init efi_arch_edd(void)
>  boot_edd_info_nr = EDD_INFO_MAX;
>  }
>  
> +#ifdef CONFIG_VGA
>  static void __init efi_arch_console_init(UINTN cols, UINTN rows)
>  {
>  vga_console_info.video_type = XEN_VGATYPE_TEXT_MODE_3;
> @@ -550,6 +551,12 @@ static void __init 
> efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>  (gop->Mode->FrameBufferSize + 0x) >> 16;
>  }
>  }
> +#else
> +static inline void __init efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL 
> *gop,
> +   UINTN info_size,
> +   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION 
> *mode_info) {}
> +static inline void __init efi_arch_console_init(UINTN cols, UINTN rows) {}
> +#endif

I'd technically intent these parameters to match the others.


> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 8ae897a..6358336 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -433,10 +433,12 @@ struct boot_video_info {
>  u16 vesapm_off; /* 0x26 */
>  u16 vesa_attrib;/* 0x28 */
>  };
> +
>  extern struct boot_video_info boot_vid_info;
>  

Extra white space. But honestly it makes it easier to read.


>  
>  static void __init kexec_reserve_area(struct e820map *e820)
> @@ -672,6 +675,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  printk("Command line: %s\n", cmdline);
>  
> +#ifdef CONFIG_VGA
>  printk("Video information:\n");
>  
>  /* Print VGA display mode information. */
> @@ -694,6 +698,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  printk(" No VGA detected\n");
>  break;
>  }
> +#endif

Not sure if the else case should be something like:
printk("Video information: None\n");


I'll leave it up to others to concur or disagree but if people disagree
then:
Reviewed-by: Doug Goldstein 

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan]

On Tue, Sep 13, 2016 at 02:24:31PM +0100, Julien Grall wrote:
>
>
>On 13/09/16 14:12, Peng Fan wrote:
>>Hi Julien,
>>On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote:
>>>Hello Peng,
>>>
>>>On 13/09/16 13:55, Peng Fan wrote:
On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.

Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
to xen. It means how much memory user would like to be allocated
in lower 4GB memory space. If there is not enough memory for
dom0_lowmem, higher memory will be allocated.

Thinking such a memory layout on an AArch64 SoC:
Region 0: 2GB(0x8000 - 0x)
Region 1: 4GB(0x88000 - 0x97fff)
If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
This patch not tested on latest 4.8-unstable, I only tested similar
patch on xen 4.7 on AArch64 platform.
>>>
>>>Please test any patch send upstream on 4.8-unstable. The code may have
>>>changed.
>>
>>I have rebase this patch based on 4.8-unstable.
>>latest commit:
>>"
>>commit a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
>>Author: Tamas K Lengyel 
>>Date:   Mon Aug 1 11:59:14 2016 -0600
>>
>>arm/vm_event: get/set registers
>>"
>>
>>Since I have not rebased my platform patches to 4.8-unstable, so have not 
>>tested.
>>
>>Please kindly comments whether introudcing "dom0_lowmem" is acceptable or not
>>to resolve the issue I met in 
>>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html.
>>
>>I'll rebase my platform patches and do some test.
>>
>>>

The idea of patch is that user could specify the lowmem that user would
like to use. I rethought the ideas in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
but that is not good. lowmem is precise, it maybe used for some IPs that 
maybe
passthrough to DomU, so we only allocate the needed memory for Dom0.
>>>
>>>Why? IPs passthrough to DomU will have to be protected by an SMMU so it does
>>>not matter whether Dom0 is using all the lowmem or not.
>>
>>I just think there maybe some cases that some physical memory need to be
>>reserved for DomU usage.
>>SMMU is not a must when we passthrough a non DMA capable device to DomU.
>>So I think an DRAM area can be encoded in dts, and passthrough to DomU.
>
>How do you make sure that DomU will program the device with the correct
>address? A malicious DomU could decide to use a physical address belonging to
>another DomU or even Xen and would be able to read/write on it.

When I debug DomU, I use a uart port as an early console for DomU.
I just marked the uart with xen,passthrough and status disabled in Dom0 dts,
then in DomU dts, I create a uart node, and in xl cfg, I mapped the address
space. I did not use SMMU here. Just mapped the uart physical address
to DomU uart guest physical address. And DomU can access the uart for my
debug usage.

>
>So if a device needs to access the physical memory it either needs to be
>protected by an SMMU or Xen/DOM0 is programming the device on behalf of the
>guest. All other solutions are IHMO unsafe.

My understanding about reserve lowmem for DomU maybe not that correct.
I'll test this patch based on 4.8 and send out V2 later.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall

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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Stefano Stabellini]

On Wed, 14 Sep 2016, Shannon Zhao wrote:
> On 2016/9/13 23:17, Julien Grall wrote:
> > 
> > 
> > On 13/09/16 14:06, Shannon Zhao wrote:
> >> Hi Julien,
> > 
> > Hello Shannon,
> > 
> >> On 2016/9/13 19:56, Julien Grall wrote:
> >>> Hi Shannon,
> >>>
> >>> On 02/09/16 03:55, Shannon Zhao wrote:
>  From: Shannon Zhao 
> 
>  The design of this feature is described as below.
>  Firstly, the toolstack (libxl) generates the ACPI tables according the
>  number of vcpus and gic controller.
> 
>  Then, it copies these ACPI tables to DomU non-RAM memory map space and
>  passes them to UEFI firmware through the "ARM multiboot" protocol.
> 
>  At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>  and installs these tables like the usual way and passes both ACPI
>  and DT
>  information to the Xen DomU.
> 
>  Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT
>  tables
>  since it's enough now.
> 
>  This has been tested using guest kernel with the Dom0 ACPI support
>  patches which could be fetched from linux master or:
>  https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> 
> 
>  The UEFI binary could be fetched from or built from edk2 master branch:
>  http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
> >>>
> >>> On which commit this EFI binary is based? I am trying to rebuild myself,
> >>> and go no luck to boot it so far.
> >>>
> >> I forgot the exact commit. But I just tried below commit which adds the
> >> support to edk2 and the guest can boot up successfully with ACPI.
> >>
> >> 402dde6 ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
> > 
> > Thanks, the commit does not build on my platform. After some help for
> > Ard I managed to boot UEFI with the patch [1] applied.
> > 
> > However Linux does not boot when passing acpi=on and abort with the
> > following message:
> > 
> > (d86) 6RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
> > (d86) 6NR_IRQS:64 nr_irqs:64 0
> > (d86) 3No valid GICC entries exist
> > (d86) 0Kernel panic - not syncing: No interrupt controller found.
> > (d86) dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6+ #420
> > (d86) dHardware name: XENVM-4.8 (DT)
> > (d86) Call trace:
> > (d86) [] dump_backtrace+0x0/0x1a8
> > (d86) [] show_stack+0x14/0x20
> > (d86) [] dump_stack+0x94/0xb8
> > (d86) [] panic+0x10c/0x250
> > (d86) [] init_IRQ+0x24/0x2c
> > (d86) [] start_kernel+0x238/0x394
> > (d86) [] __primary_switched+0x30/0x74
> > (d86) 0---[ end Kernel panic - not syncing: No interrupt controller found.
> > 
> > This is because the header.length for GICC is not valid for ACPI 5.1
> > (see BAD_MADT_GICC_ENTRY). So please check all the size of each table
> > against ACPI 5.1.
> > 
> Oops. The reason is that acpi_madt_generic_interrupt in Xen is already
> updated to ACPI 6.0 and the length is 80 not 76 of ACPI 5.1.
> One solution is that we still use ACPI 5.1 and make gicc->header.length
> 76. Other one is that we update to ACPI 6.0 since the Xen ARM ACPI
> support in Linux was introduced after ACPI 6.0.
> 
> Which one do you prefer?

Certainly the versions of all tables need to be consistent. I would
prefer to have ACPI 6.0 but 5.1 is acceptable too (especially if
upgrading to 6.0 causes a large amount of changes to your patches).

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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016/9/13 23:17, Julien Grall wrote:
> 
> 
> On 13/09/16 14:06, Shannon Zhao wrote:
>> Hi Julien,
> 
> Hello Shannon,
> 
>> On 2016/9/13 19:56, Julien Grall wrote:
>>> Hi Shannon,
>>>
>>> On 02/09/16 03:55, Shannon Zhao wrote:
 From: Shannon Zhao 

 The design of this feature is described as below.
 Firstly, the toolstack (libxl) generates the ACPI tables according the
 number of vcpus and gic controller.

 Then, it copies these ACPI tables to DomU non-RAM memory map space and
 passes them to UEFI firmware through the "ARM multiboot" protocol.

 At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
 and installs these tables like the usual way and passes both ACPI
 and DT
 information to the Xen DomU.

 Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT
 tables
 since it's enough now.

 This has been tested using guest kernel with the Dom0 ACPI support
 patches which could be fetched from linux master or:
 https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen



 The UEFI binary could be fetched from or built from edk2 master branch:
 http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
>>>
>>> On which commit this EFI binary is based? I am trying to rebuild myself,
>>> and go no luck to boot it so far.
>>>
>> I forgot the exact commit. But I just tried below commit which adds the
>> support to edk2 and the guest can boot up successfully with ACPI.
>>
>> 402dde6 ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM
> 
> Thanks, the commit does not build on my platform. After some help for
> Ard I managed to boot UEFI with the patch [1] applied.
> 
> However Linux does not boot when passing acpi=on and abort with the
> following message:
> 
> (d86) 6RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
> (d86) 6NR_IRQS:64 nr_irqs:64 0
> (d86) 3No valid GICC entries exist
> (d86) 0Kernel panic - not syncing: No interrupt controller found.
> (d86) dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6+ #420
> (d86) dHardware name: XENVM-4.8 (DT)
> (d86) Call trace:
> (d86) [] dump_backtrace+0x0/0x1a8
> (d86) [] show_stack+0x14/0x20
> (d86) [] dump_stack+0x94/0xb8
> (d86) [] panic+0x10c/0x250
> (d86) [] init_IRQ+0x24/0x2c
> (d86) [] start_kernel+0x238/0x394
> (d86) [] __primary_switched+0x30/0x74
> (d86) 0---[ end Kernel panic - not syncing: No interrupt controller found.
> 
> This is because the header.length for GICC is not valid for ACPI 5.1
> (see BAD_MADT_GICC_ENTRY). So please check all the size of each table
> against ACPI 5.1.
> 
Oops. The reason is that acpi_madt_generic_interrupt in Xen is already
updated to ACPI 6.0 and the length is 80 not 76 of ACPI 5.1.
One solution is that we still use ACPI 5.1 and make gicc->header.length
76. Other one is that we update to ACPI 6.0 since the Xen ARM ACPI
support in Linux was introduced after ACPI 6.0.

Which one do you prefer?

Thanks,
-- 
Shannon


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

[Xen-devel] [qemu-mainline test] 100915: tolerable FAIL - PUSHED

[osstest service owner]

flight 100915 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100915/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100877
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100877
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100877

Tests which did not succeed, but are not blocking:
 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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu7263da78045dc91cc207f350911efe4259e99b3c
baseline version:
 qemuuc2a57aae9a1c3dd7de77daf5478df10379aeeebf

Last test of basis   100877  2016-09-10 15:16:34 Z3 days
Failing since100892  2016-09-12 12:13:11 Z1 days3 attempts
Testing same since   100900  2016-09-12 18:44:03 Z1 days2 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Gonglei 
  Greg Kurz 
  Greg Kurz 
  Jason Wang 
  Ladi Prosek 
  Longpeng(Mike) 
  Marcel Apfelbaum 
  Mark Cave-Ayland 
  Michael S. Tsirkin 
  Peter Maydell 
  Stefan Hajnoczi 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvops 

[Xen-devel] [ovmf test] 100932: all pass - PUSHED

[osstest service owner]

flight 100932 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100932/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf dd82465a9f0f0beff0e4d74c6e3192b966853332
baseline version:
 ovmf 8c0b0b34f7875571ee9d3a2a1a28484cef36d969

Last test of basis   100894  2016-09-12 13:14:28 Z1 days
Testing same since   100932  2016-09-13 12:59:53 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Thomas Huth 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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=ovmf
+ revision=dd82465a9f0f0beff0e4d74c6e3192b966853332
+ . ./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 ovmf 
dd82465a9f0f0beff0e4d74c6e3192b966853332
+ branch=ovmf
+ revision=dd82465a9f0f0beff0e4d74c6e3192b966853332
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xdd82465a9f0f0beff0e4d74c6e3192b966853332 = 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.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH RFC 1/6] xen/arm: platforms: Add earlyprintk and serial support for Tegra boards.

[Konrad Rzeszutek Wilk]

On Mon, Sep 05, 2016 at 06:13:56AM -0400, Kyle Temkin wrote:
> From: "Kyle J. Temkin" 
> 
> Tegra boards feature a NS16550-compatible serial mapped into the MMIO
> space. Add support for its use both as a full-featured serial port and
> as an earlyprintk driver.
> 
> Adds a new "needs_rtoie" (requires Rx Timeout Interrupt) quirk, as some
> platforms-- including Tegra-- require the NS16550 Rx timeout interrupt
> to be enabled for receive to function properly. The same quirk is
> applied in the eqvuialent Linux driver [1].
> 
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4539c24fe4f92c09ee668ef959d3e8180df619b9
> 
> Signed-off-by: Kyle Temkin 
> ---
>  xen/arch/arm/Rules.mk   |  1 +
>  xen/drivers/char/ns16550.c  | 16 +++-
>  xen/include/xen/8250-uart.h |  1 +
>  3 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
> index 93304be..2a1473a 100644
> --- a/xen/arch/arm/Rules.mk
> +++ b/xen/arch/arm/Rules.mk
> @@ -44,6 +44,7 @@ EARLY_PRINTK_vexpress   := pl011,0x1c09
>  EARLY_PRINTK_xgene-mcdivitt := 8250,0x1c021000,2
>  EARLY_PRINTK_xgene-storm:= 8250,0x1c02,2
>  EARLY_PRINTK_zynqmp := cadence,0xff00
> +EARLY_PRINTK_tegra  := 8250,0x70006000,2
>  
>  ifneq ($(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)),)
>  EARLY_PRINTK_CFG := $(subst $(comma), 
> ,$(EARLY_PRINTK_$(CONFIG_EARLY_PRINTK)))
> diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
> index 1da103a..bffdb35 100644
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -64,6 +64,7 @@ static struct ns16550 {
>  unsigned int timeout_ms;
>  bool_t intr_works;
>  bool_t dw_usr_bsy;
> +bool_t needs_rtoie;

Those three states all look like tri-states? Or could you potentially
have them independenty enabled? As in dw_usr_bsy and needs_rtoie?


>  #ifdef CONFIG_HAS_PCI
>  /* PCI card parameters. */
>  bool_t pb_bdf_enable;   /* if =1, pb-bdf effective, port behind bridge */
> @@ -652,12 +653,23 @@ static void ns16550_setup_postirq(struct ns16550 *uart)
>  {
>  if ( uart->irq > 0 )
>  {
> +u8 ier_value = 0;
> +
>  /* Master interrupt enable; also keep DTR/RTS asserted. */
>  ns_write_reg(uart,
>   UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS);
>  
>  /* Enable receive interrupts. */
> -ns_write_reg(uart, UART_IER, UART_IER_ERDAI);
> +ier_value = UART_IER_ERDAI;
> +
> +/*
> + * If we're on a platform that needs Rx timeouts enabled, also
> + * set Rx TimeOut Interrupt Enable (RTOIE).
> + */
> +if ( uart->needs_rtoie )
> +  ier_value |= UART_IER_RTOIE;
> +
> +ns_write_reg(uart, UART_IER, ier_value);
>  }
>  
>  if ( uart->irq >= 0 )
> @@ -1273,6 +1285,7 @@ static int __init ns16550_uart_dt_init(struct 
> dt_device_node *dev,
>  uart->irq = res;
>  
>  uart->dw_usr_bsy = dt_device_is_compatible(dev, "snps,dw-apb-uart");
> +uart->needs_rtoie = dt_device_is_compatible(dev, "nvidia,tegra20-uart");
>  
>  uart->vuart.base_addr = uart->io_base;
>  uart->vuart.size = uart->io_size;
> @@ -1293,6 +1306,7 @@ static const struct dt_device_match ns16550_dt_match[] 
> __initconst =
>  DT_MATCH_COMPATIBLE("ns16550"),
>  DT_MATCH_COMPATIBLE("ns16550a"),
>  DT_MATCH_COMPATIBLE("snps,dw-apb-uart"),
> +DT_MATCH_COMPATIBLE("nvidia,tegra20-uart"),
>  { /* sentinel */ },
>  };
>  
> diff --git a/xen/include/xen/8250-uart.h b/xen/include/xen/8250-uart.h
> index c6b62c8..2ad0ee6 100644
> --- a/xen/include/xen/8250-uart.h
> +++ b/xen/include/xen/8250-uart.h
> @@ -41,6 +41,7 @@
>  #define UART_IER_ETHREI   0x02/* tx reg. empty*/
>  #define UART_IER_ELSI 0x04/* rx line status   */
>  #define UART_IER_EMSI 0x08/* MODEM status */
> +#define UART_IER_RTOIE0x10/* rx timeout   */
>  
>  /* Interrupt Identificatiegister */
>  #define UART_IIR_NOINT0x01/* no interrupt pending */
> -- 
> 2.9.2
> 
> 
> ___
> 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] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

[Konrad Rzeszutek Wilk]

On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
> Windows 8, 10 and Server 2012 guests hang intermittently while booting
> on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs, shortly after the Windows
> logo appears and the little dots start spinning.
> 
> Running strace on qemu shows its main thread doing the following every
> couple of milliseconds:
> 
>  ppoll([..., {fd=30, events=POLLIN|POLLERR|POLLHUP},
> ...], ...) = 1 ([{fd=30, revents=POLLIN}], ...)
>  read(30, "^\0\0\0", 4) = 4
>  write(30, "^\0\0\0", 4) = 4
>  ioctl(30, IOCTL_EVTCHN_NOTIFY, 0x7f1f9449d310) = 0
>  clock_gettime(CLOCK_MONOTONIC, {6937, 449468262}) = 0
>  clock_gettime(CLOCK_MONOTONIC, {6937, 449582903}) = 0
>  gettimeofday({1472251376, 673434}, NULL) = 0
>  clock_gettime(CLOCK_MONOTONIC, {6937, 449856205}) = 0
>  gettimeofday({1472251376, 673679}, NULL) = 0
> 
> The event channel (identified by '^' or 94 in this example) is always
> the third of the domain's four channels.
> 
> Two recent qemu patches (http://git.qemu.org/?p=qemu.git;h=9596ef7c and
> http://git.qemu.org/?p=qemu.git;h=74004e8c) seem to address similar
> issues, but don't help in this case.
> 
> The proposed fix from
> https://bugzilla.redhat.com/show_bug.cgi?id=874406#c78 makes the hang
> go away. It's not clear to me why it works, or if it's just papering
> over a bug elsewhere, or if there are any possible side effects.

CC-ing Denis.


Is the fix below based on reading the spec or more of instrumenting?

Thanks.
> 
> Suggested-by: Andrew Jones 
> Signed-off-by: Ed Swierk 
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index 6eac66d..c891b67 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -293,6 +293,8 @@ set_interrupt_cause(E1000State *s, int index, uint32_t 
> val)
>  uint32_t pending_ints;
>  uint32_t mit_delay;
>  
> +val &= s->mac_reg[IMS];
> +
>  s->mac_reg[ICR] = val;
>  
>  /*
> @@ -305,7 +307,7 @@ set_interrupt_cause(E1000State *s, int index, uint32_t 
> val)
>   */
>  s->mac_reg[ICS] = val;
>  
> -pending_ints = (s->mac_reg[IMS] & s->mac_reg[ICR]);
> +pending_ints = s->mac_reg[ICR];
>  if (!s->mit_irq_level && pending_ints) {
>  /*
>   * Here we detect a potential raising edge. We postpone raising the
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

[Xen-devel] [xen-4.5-testing test] 100909: tolerable FAIL - PUSHED

[osstest service owner]

flight 100909 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100909/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-3  19 xtf/test-hvm32-invlpg~shadow fail baseline untested
 test-xtf-amd64-amd64-3 26 xtf/test-hvm32pae-invlpg~shadow fail baseline 
untested
 test-xtf-amd64-amd64-3  34 xtf/test-hvm64-invlpg~shadow fail baseline untested
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 100814
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 100828
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100828
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100828
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100828
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100828

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail 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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  c18dfbb88670e9f2cabd93bbb32f661b71ffb73a
baseline version:
 xen  433ebca120e8750eb8085745ccac703e47358e6f

Last test of basis   100828  2016-09-08 21:42:35 Z4 days
Failing since100897  2016-09-12 14:42:24 Z1 days2 attempts
Testing same since   100909  2016-09-13 02:09:03 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass
 test-amd64-amd64-xl 

[Xen-devel] [PATCH] x86: add a user configurable Kconfig option for the VGA

[Derek Straka]

Allows for the conditional inclusion of VGA driver on the x86 platform
rather than having it always enabled.

The default configuration for the CONFIG_VGA option remains 'y' on x86, so the
behavior out of the box remains unchanged.  The addition of the option allows
advanced users to enable/disable the inclusion of the VGA driver.

Signed-off-by: Derek Straka 
---
 xen/arch/x86/Kconfig| 1 -
 xen/arch/x86/efi/efi-boot.h | 7 +++
 xen/arch/x86/setup.c| 5 +
 xen/drivers/video/Kconfig   | 3 ++-
 xen/include/asm-x86/setup.h | 5 +
 xen/include/xen/console.h   | 8 
 6 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 265fd79..9e10591 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -20,7 +20,6 @@ config X86
select HAS_PCI
select HAS_PDX
select NUMA
-   select VGA
 
 config ARCH_DEFCONFIG
string
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index 10985721..911fdfd 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -476,6 +476,7 @@ static void __init efi_arch_edd(void)
 boot_edd_info_nr = EDD_INFO_MAX;
 }
 
+#ifdef CONFIG_VGA
 static void __init efi_arch_console_init(UINTN cols, UINTN rows)
 {
 vga_console_info.video_type = XEN_VGATYPE_TEXT_MODE_3;
@@ -550,6 +551,12 @@ static void __init 
efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
 (gop->Mode->FrameBufferSize + 0x) >> 16;
 }
 }
+#else
+static inline void __init efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL 
*gop,
+   UINTN info_size,
+   EFI_GRAPHICS_OUTPUT_MODE_INFORMATION 
*mode_info) {}
+static inline void __init efi_arch_console_init(UINTN cols, UINTN rows) {}
+#endif
 
 static void __init efi_arch_memory_setup(void)
 {
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 8ae897a..6358336 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -433,10 +433,12 @@ struct boot_video_info {
 u16 vesapm_off; /* 0x26 */
 u16 vesa_attrib;/* 0x28 */
 };
+
 extern struct boot_video_info boot_vid_info;
 
 static void __init parse_video_info(void)
 {
+#ifdef CONFIG_VGA
 struct boot_video_info *bvi = (boot_vid_info);
 
 /* The EFI loader fills vga_console_info directly. */
@@ -472,6 +474,7 @@ static void __init parse_video_info(void)
 vga_console_info.u.vesa_lfb.gbl_caps = bvi->capabilities;
 vga_console_info.u.vesa_lfb.mode_attrs = bvi->vesa_attrib;
 }
+#endif
 }
 
 static void __init kexec_reserve_area(struct e820map *e820)
@@ -672,6 +675,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 printk("Command line: %s\n", cmdline);
 
+#ifdef CONFIG_VGA
 printk("Video information:\n");
 
 /* Print VGA display mode information. */
@@ -694,6 +698,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 printk(" No VGA detected\n");
 break;
 }
+#endif
 
 /* Print VBE/DDC EDID information. */
 if ( bootsym(boot_edid_caps) != 0x1313 )
diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig
index 0ffbbd9..0f208fe 100644
--- a/xen/drivers/video/Kconfig
+++ b/xen/drivers/video/Kconfig
@@ -3,7 +3,8 @@ config VIDEO
bool
 
 config VGA
-   bool
+   bool "VGA"
+   default y if X86
select VIDEO
 
 config HAS_ARM_HDLCD
diff --git a/xen/include/asm-x86/setup.h b/xen/include/asm-x86/setup.h
index c65b79c..02e9b12 100644
--- a/xen/include/asm-x86/setup.h
+++ b/xen/include/asm-x86/setup.h
@@ -28,8 +28,13 @@ void arch_init_memory(void);
 void subarch_init_memory(void);
 
 void init_IRQ(void);
+#ifdef CONFIG_VGA
 void vesa_init(void);
 void vesa_mtrr_init(void);
+#else
+static inline void vesa_init(void) {}
+static inline void vesa_mtrr_init(void) {}
+#endif
 
 int construct_dom0(
 struct domain *d,
diff --git a/xen/include/xen/console.h b/xen/include/xen/console.h
index ea06fd8..2e7c22c 100644
--- a/xen/include/xen/console.h
+++ b/xen/include/xen/console.h
@@ -19,7 +19,15 @@ void console_init_postirq(void);
 void console_endboot(void);
 int console_has(const char *device);
 
+#ifdef CONFIG_VGA
 int fill_console_start_info(struct dom0_vga_console_info *);
+#else
+#include 
+static inline int fill_console_start_info(struct dom0_vga_console_info *ci) {
+(void) memset(ci, 0, sizeof(*ci));
+return 1;
+}
+#endif
 
 unsigned long console_lock_recursive_irqsave(void);
 void console_unlock_recursive_irqrestore(unsigned long flags);
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v3 14/38] arm/p2m: Add altp2m init/teardown routines

[Sergej Proskurin]

Hi Julien,

On 09/09/2016 06:56 PM, Julien Grall wrote:
> Hello Sergej
> 
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index 23aaf52..4a7f660 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -5,6 +5,7 @@ subdir-$(CONFIG_ARM_64) += efi
>>  subdir-$(CONFIG_ACPI) += acpi
>>
>>  obj-$(CONFIG_ALTERNATIVE) += alternative.o
>> +obj-y += altp2m.o
>>  obj-y += bootfdt.o
>>  obj-y += cpu.o
>>  obj-y += cpuerrata.o
>> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
>> new file mode 100644
>> index 000..66a373a
>> --- /dev/null
>> +++ b/xen/arch/arm/altp2m.c
>> @@ -0,0 +1,61 @@
>> +/*
>> + * arch/arm/altp2m.c
>> + *
>> + * Alternate p2m
>> + * Copyright (c) 2016 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 
>> +#include 
>> +
>> +int altp2m_init(struct domain *d)
>> +{
>> +unsigned int i;
>> +
>> +spin_lock_init(>arch.altp2m_lock);
>> +
>> +for ( i = 0; i < MAX_ALTP2M; i++ )
>> +d->arch.altp2m_p2m[i] = NULL;
> 
> The structure domain is already initialized to 0, so this loop is
> pointless.
> 

I will remove the loop, thank you.

>> +
>> +d->arch.altp2m_active = false;
>> +
>> +return 0;
>> +}
>> +
> 
> [...]
> 
>> diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
>> index 0711796..a156109 100644
>> --- a/xen/include/asm-arm/altp2m.h
>> +++ b/xen/include/asm-arm/altp2m.h
>> @@ -22,6 +22,9 @@
>>
>>  #include 
>>
>> +#define altp2m_lock(d)spin_lock(&(d)->arch.altp2m_lock)
>> +#define altp2m_unlock(d)  spin_unlock(&(d)->arch.altp2m_lock)
>> +
>>  /* Alternate p2m on/off per domain */
>>  static inline bool_t altp2m_active(const struct domain *d)
>>  {
>> @@ -36,4 +39,7 @@ static inline uint16_t altp2m_vcpu_idx(const struct
>> vcpu *v)
>>  return 0;
>>  }
>>
>> +int altp2m_init(struct domain *d);
>> +void altp2m_teardown(struct domain *d);
>> +
>>  #endif /* __ASM_ARM_ALTP2M_H */
>> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
>> index cc4bda0..a4e4762 100644
>> --- a/xen/include/asm-arm/domain.h
>> +++ b/xen/include/asm-arm/domain.h
>> @@ -127,8 +127,14 @@ struct arch_domain
>>  paddr_t efi_acpi_len;
>>  #endif
>>
>> +/*
>> + * Lock that protects access to altp2m related fields in both struct
>> + * arch_domain and struct p2m_domain.
> 
> This comment looks wrong. struct p2m_domain is protected by its own
> lock. altp2m lock should not protect it.
> 

In the next patch, I will provide a comment stating that the altp2m_lock
protects critical altp2m operation that must not be performed concurrently.

>> + */
>> +spinlock_t altp2m_lock;
>>  /* altp2m: allow multiple copies of host p2m */
>>  bool_t altp2m_active;
>> +struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
>>  }  __cacheline_aligned;
>>
>>  struct arch_vcpu
>> diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
>> index 1a004ed..de0c90a 100644
>> --- a/xen/include/asm-arm/p2m.h
>> +++ b/xen/include/asm-arm/p2m.h
>> @@ -9,6 +9,8 @@
>>  #include 
>>  #include 
>>
>> +#define MAX_ALTP2M 10   /* ARM might contain an arbitrary
>> number of
>> +   altp2m views. */
> 
> This should belong to altp2m.h and not p2m.h
>

Unfortunately, this won't work. We cannot move this define into altp2m.h
as it would result in an header conflict: The header asm/altp2m.h
includes xen/domain.h, which in turn includes asm/domain.h. So by
including asm/altp2m.h in asm/domain.h (as MAX_ALTP2M is used there), we
would create a loop of header dependencies.

>>  #define paddr_bits PADDR_BITS
>>
>>  #define INVALID_VTTBR (0UL)
>>

Cheers,
~Sergej

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

[Xen-devel] [libvirt test] 100912: regressions - FAIL

[osstest service owner]

flight 100912 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100912/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 100866

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  b87703cf79559157404667628802d7fe8f9f19a6
baseline version:
 libvirt  2692304c94e631720e8e9444e34a3e445e8da61a

Last test of basis   100866  2016-09-10 04:25:40 Z3 days
Testing same since   100912  2016-09-13 04:22:08 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Erik Skultety 
  Jiri Denemark 
  Joao Martins 
  John Ferlan 
  Laine Stump 
  Martin Kletzander 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd 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


Not pushing.


commit b87703cf79559157404667628802d7fe8f9f19a6
Author: Laine Stump 
Date:   Fri Sep 9 15:26:34 2016 -0400

conf: allow hotplugging "legacy PCI" device to manually addressed PCIe slot

In a full domain config, libvirt allows overriding the normal PCI
vs. PCI Express rules when a device address is explicitly provided

Re: [Xen-devel] [PATCH v3 15/18] bug/x86/arm: Align bug_frames sections.

[Konrad Rzeszutek Wilk]

On Tue, Sep 13, 2016 at 03:21:04AM -0600, Jan Beulich wrote:
> >>> On 11.09.16 at 22:35,  wrote:
> > Furthermore on x86 the bloat-o-meter detects that with this
> > change:
> > 
> > [konrad@char xen]$ ~/linux/scripts/bloat-o-meter xen-syms xen-syms.align4
> > add/remove: 0/0 grow/shrink: 3/14 up/down: 115/-1497 (-1382)
> > function old new   delta
> > mod_l1_entry14901587 +97
> > p2m_switch_domain_altp2m_by_id   520 533 +13
> > p2m_switch_vcpu_altp2m_by_id 453 458  +5
> > machine_kexec263 261  -2
> > hvm_do_IRQ_dpci  244 242  -2
> > sh_page_fault__guest_4  82528192 -60
> > sh_audit_gw 15291462 -67
> > validate_gl3e337 264 -73
> > validate_gl4e449 375 -74
> > p2m_altp2m_lazy_copy 730 652 -78
> > set_typed_p2m_entry 13461259 -87
> > virt_to_xen_l2e  491 365-126
> > sh_x86_emulate_write__guest_4443 288-155
> > p2m_mem_access_check17331576-157
> > sh_x86_emulate_cmpxchg__guest_4  512 349-163
> > __get_gfn_type_access709 542-167
> > map_pages_to_xen44304144-286
> > Total: Before=1974033, After=1972651, chg -0.07%
> > 
> > We end up making the binary file a bit smaller.
> 
> I'm fine with the change, but I'm having a very hard time buying the
> above: The change you do is to code used only in assembly files _and_

That is indeed fishy. I re-ran the test and got:

 ~/linux/scripts/bloat-o-meter /tmp/xen-syms.orig /tmp/xen-syms.p2malign 
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new   delta

which is more inline with what we expect.

> is not affecting .text (and I assume the sizes above are .text ones),
> yet all the functions listed above live in C ones. I can't help thinking
> that there must be something else going on, or that we had an actual
> problem before this.

I am not sure what I managed to screw up.
> 
> > --- a/xen/include/asm-x86/bug.h
> > +++ b/xen/include/asm-x86/bug.h
> > @@ -98,6 +98,7 @@ extern const struct bug_frame __start_bug_frames[],
> >  .popsection
> >  
> >  .pushsection .bug_frames.\type, "a", @progbits
> > +.p2align 2
> >  .L\@bf:
> >  .long (.L\@ud - .L\@bf) + \
> > ((\line >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH)
> 
> This ought to be accompanied by removing the enforcing of alignment
> in xen.lds.S.

/me nods. Done!
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH 03/17] x86emul: track only rIP in emulator state

[Andrew Cooper]

On 08/09/16 14:09, Jan Beulich wrote:
> Now that all decoding happens in x86_decode() there's no need to keep
> the local registers copy in struct x86_emulate_state. Only rIP gets
> updated in the decode phase, so only that register needs tracking
> there. All other (read-only) registers can be read from the original
> structure (but sadly, due to it getting passed to decode_register(),
> the pointer can't be made point to "const" to make the compiler help
> ensure no modification happens).

I was going to suggest making a second helper and casting away
constness, but that also has problems with the mark_regs_dirty() call.

However, on further consideration...

> @@ -2061,6 +2064,8 @@ x86_emulate(
>  struct x86_emulate_ctxt *ctxt,
>  const struct x86_emulate_ops *ops)
>  {
> +/* Shadow copy of register state. Committed on successful emulation. */
> +struct cpu_user_regs _regs = *ctxt->regs;
>  struct x86_emulate_state state;
>  int rc;
>  uint8_t b, d;
> @@ -2074,10 +2079,21 @@ x86_emulate(
>  if ( rc != X86EMUL_OKAY)
>  return rc;
>  
> +/* Sync rIP to post decode value. */
> +_regs.eip = state.eip;
> +
>  b = state.opcode;
>  d = state.desc;
>  #define state ()
>  
> +/* Re-vector ea's register pointer into our shadow registers. */
> +if ( ea.type == OP_REG )
> +{
> +unsigned int offs = (void *)ea.reg - (void *)state->regs;
> +
> +ea.reg = (void *)&_regs + offs;
> +}
> +

This is some very hairy pointer arithmetic.

Why do we need to decode registers in x86_decode()?

We don't need to decode the GPRs to calculate the length of the
instruction.  If the displacement is stashed in x86_emulate_state, the
calculation of ea can be deferred until the start of x86_emulate(), and
no arithmetic like this would be necessary.

~Andrew

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

Re: [Xen-devel] [PATCH 02/17] x86emul: fetch all insn bytes during the decode phase

[Andrew Cooper]

On 08/09/16 14:07, Jan Beulich wrote:
> This way we can offer to callers the service of just sizing
> instructions, and we also can better guarantee not to raise the wrong
> fault due to not having read all relevant bytes.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -129,8 +129,8 @@ static const opcode_desc_t opcode_table[
>  ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
>  ImplicitOps|Mov, ImplicitOps|Mov, ImplicitOps, ImplicitOps,
>  /* 0xA0 - 0xA7 */
> -ByteOp|DstEax|SrcImplicit|Mov, DstEax|SrcImplicit|Mov,
> -ByteOp|ImplicitOps|Mov, ImplicitOps|Mov,
> +ByteOp|DstEax|SrcMem|Mov, DstEax|SrcMem|Mov,
> +ByteOp|DstMem|SrcEax|Mov, DstMem|SrcEax|Mov,
>  ByteOp|ImplicitOps|Mov, ImplicitOps|Mov,
>  ByteOp|ImplicitOps, ImplicitOps,
>  /* 0xA8 - 0xAF */
> @@ -1602,6 +1602,45 @@ struct x86_emulate_state {
>  #define _regs (state->regs)
>  
>  static int
> +x86_decode_base(

What do you mean by decode_base here?

> +struct x86_emulate_state *state,
> +struct x86_emulate_ctxt *ctxt,
> +const struct x86_emulate_ops *ops)
> +{
> +int rc = X86EMUL_OKAY;
> +
> +switch ( state->opcode )
> +{
> +case 0x9a: /* call (far, absolute) */
> +case 0xea: /* jmp (far, absolute) */
> +generate_exception_if(mode_64bit(), EXC_UD, -1);
> +
> +imm1 = insn_fetch_bytes(op_bytes);
> +imm2 = insn_fetch_type(uint16_t);
> +break;
> +
> +case 0xa0: case 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
> +case 0xa2: case 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
> +/* Source EA is not encoded via ModRM. */
> +ea.mem.off = insn_fetch_bytes(ad_bytes);
> +break;
> +
> +case 0xb8 ... 0xbf: /* mov imm{16,32,64},r{16,32,64} */
> +if ( op_bytes == 8 ) /* Fetch more bytes to obtain imm64. */
> +imm1 = ((uint32_t)imm1 |
> +((uint64_t)insn_fetch_type(uint32_t) << 32));
> +break;
> +
> +case 0xc8: /* enter imm16,imm8 */
> +imm2 = insn_fetch_type(uint8_t);
> +break;
> +}
> +
> + done:
> +return rc;
> +}
> +
> +static int
>  x86_decode(
>  struct x86_emulate_state *state,
>  struct x86_emulate_ctxt *ctxt,
> @@ -1994,10 +2033,29 @@ x86_decode(
>  state->opcode = b;
>  state->desc = d;
>  
> +switch ( ext )
> +{
> +case ext_none:
> +rc = x86_decode_base(state, ctxt, ops);
> +break;
> +
> +case ext_0f:
> +case ext_0f38:
> +break;
> +
> +default:
> +ASSERT_UNREACHABLE();
> +return X86EMUL_UNHANDLEABLE;
> +}
> +
>   done:
>  return rc;
>  }
>  
> +/* No insn fetching past this point. */
> +#undef insn_fetch_bytes
> +#undef insn_fetch_type
> +
>  int
>  x86_emulate(
>  struct x86_emulate_ctxt *ctxt,
> @@ -2560,6 +2618,8 @@ x86_emulate(
>  case 0xc6 ... 0xc7: /* mov (sole member of Grp11) */
>  generate_exception_if((modrm_reg & 7) != 0, EXC_UD, -1);
>  case 0x88 ... 0x8b: /* mov */
> +case 0xa0 ... 0xa1: /* mov mem.offs,{%al,%ax,%eax,%rax} */
> +case 0xa2 ... 0xa3: /* mov {%al,%ax,%eax,%rax},mem.offs */
>  dst.val = src.val;
>  break;
>  
> @@ -2644,18 +2704,13 @@ x86_emulate(
>  
>  case 0x9a: /* call (far, absolute) */ {
>  struct segment_register reg;
> -uint16_t sel;
> -uint32_t eip;
>  
> -generate_exception_if(mode_64bit(), EXC_UD, -1);
> +ASSERT(!mode_64bit());

Are we going to strictly require that noone ever hand-crafts a
x86_emulate_state and hands it to x86_emulate()?

I would suggest leaving the generate_exception_if(mode_64bit(), EXC_UD,
-1); after the ASSERT() so even if we do end up in a wonky state, we
don't try to jump the guest to 0.

Similarly for jmp.

~Andrew

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

Re: [Xen-devel] BUG_ON() vs ASSERT()

[Andrew Cooper]

On 13/09/16 14:46, Mihai Donțu wrote:
> On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote:
>> On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote:
>>> All,
>>>
>>> in
>>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
>>> and
>>> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
>>> Andrew basically suggests that we should switch away from using
>>> ASSERT() and over to BUG_ON() in perhaps quite broad a set of
>>> cases. And honestly I'm not convinced of this: We've been adding
>>> quite a few ASSERT()s over the last years with the aim of doing
>>> sanity checking in debug builds, without adding overhead to non-
>>> debug builds. I can certainly see possible cases where using
>>> BUG_ON() to prevent further possible damage is appropriate, but
>>> I don't think we should overdo here.
>>>
>>> Thanks for other's opinions,  
>> I am in the mindset that ASSERTS are in the cases where a check
>> has been done earlier and the ASSERT is more of a catch if we ended up
>> somehow in the wrong state. We can then slowly follow the breadcrumbs to
>> see what changed the state. In other words - something that the hypervisor
>> has checked for and that invariant should have not changed.
>>
>> But a BUG_ON is in the same category - it should not have happend.
>>
>> Perhaps the distinction is that for ASSERTS() it is to catch me messing
>> things up. While BUG_ON() is something (or somebody) else messing things up.
>>
>> It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now
>> that I think of it ..
> I would see ASSERT() used to check for conditions that have immediate
> and visible consequences, like the ones that lead to lack of
> functionality (like a hw feature misdetection) or straight crashes
> (like NULL-dereference).

NULL dereferences in the context of PV guests are also a security issue,
as the PV guest controls what is mapped at 0.

>  BUG_ON(), on the other hand, would be an early
> warning for subtle corruptions that can lead to a hypervisor crash or
> corrupted data after many hours of use (close to impossible to track
> down).
>
> For example, a while ago I posted a small patch that would BUG_ON()
> when it detected that the heap chunks were not properly linked. That's
> the type of bug that's a pain to detect.

Speaking of, what happened to that patch?

~Andrew

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

Re: [Xen-devel] BUG_ON() vs ASSERT()

[Andrew Cooper]

On 12/09/16 16:23, Jan Beulich wrote:
> All,
>
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
> and
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
> Andrew basically suggests that we should switch away from using
> ASSERT() and over to BUG_ON() in perhaps quite broad a set of
> cases. And honestly I'm not convinced of this: We've been adding
> quite a few ASSERT()s over the last years with the aim of doing
> sanity checking in debug builds, without adding overhead to non-
> debug builds. I can certainly see possible cases where using
> BUG_ON() to prevent further possible damage is appropriate, but
> I don't think we should overdo here.

I am not advocating switching all ASSERT()s to BUG_ON()s.  That would be
silly.

However, ASSERT()'s as a bounds check very definitely are dangerous.  If
there is any uncertainty about the bounds, the check must not disappear
in a release build.  (Better yet, code which copes cleanly with
insufficient bounds).


For anyone reading this email who hasn't already worked out the details
of XSA-186, the data corruption issue is here:

static int hvmemul_insn_fetch(...)
{
unsigned int insn_off = offset - hvmemul_ctxt->insn_buf_eip;
...
ASSERT(insn_off + bytes <= sizeof(hvmemul_ctxt->insn_buf));
memcpy(_ctxt->insn_buf[insn_off], p_data, bytes);
...

It is left as an exercise to the reader to work out how to exploit this
on a release build of Xen, but it is hopefully obvious that the ASSERT()
isn't helpful.  A BUG_ON() in this case would have been a host DoS,
which is substantially better than a guest escape.

~Andrew

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

[Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Tamas K Lengyel]

When emulating instructions the emulator maintains a small i-cache fetched
from the guest memory. This patch extends the vm_event interface to allow
returning this i-cache via the vm_event response instead.

When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
normally has to remove the INT3 from memory - singlestep - place back INT3
to allow the guest to continue execution. This routine however is susceptible
to a race-condition on multi-vCPU guests. By allowing the subscriber to return
the i-cache to be used for emulation it can side-step the problem by returning
a clean buffer without the INT3 present.

As part of this patch we rename hvm_mem_access_emulate_one to
hvm_emulate_one_vm_event to better reflect that it is used in various vm_event
scenarios now, not just in response to mem_access events.

Signed-off-by: Tamas K Lengyel 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Julien Grall 

Note: This patch only has been compile-tested.
---
 xen/arch/x86/hvm/emulate.c| 44 ++-
 xen/arch/x86/hvm/hvm.c|  9 +---
 xen/arch/x86/hvm/vmx/vmx.c|  1 +
 xen/arch/x86/vm_event.c   |  9 +++-
 xen/common/vm_event.c |  1 -
 xen/include/asm-x86/hvm/emulate.h |  8 ---
 xen/include/asm-x86/vm_event.h|  3 ++-
 xen/include/public/vm_event.h | 16 +-
 8 files changed, 67 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc25676..504ed35 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int size)
 if ( curr->arch.vm_event )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event->emul_read.size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+memcpy(buffer, curr->arch.vm_event->emul_read.data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
@@ -827,7 +827,7 @@ static int hvmemul_read(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(p_data, bytes);
 
 return __hvmemul_read(
@@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 int rc = set_context_data(p_new, bytes);
 
@@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
 p2m_type_t p2mt;
 int rc;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
 bytes_per_rep, reps, ctxt);
 
@@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
 if ( buf == NULL )
 return X86EMUL_UNHANDLEABLE;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 rc = set_context_data(buf, bytes);
 
@@ -1470,7 +1470,7 @@ static int hvmemul_read_io(
 
 *val = 0;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(val, bytes);
 
 return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
@@ -1793,7 +1793,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 pfec |= PFEC_user_mode;
 
 hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+
+if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
+{
+hvmemul_ctxt->insn_buf_bytes = sizeof(curr->arch.vm_event->emul_insn);
+memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul_insn,
+   hvmemul_ctxt->insn_buf_bytes);
+}
+else if ( !vio->mmio_insn_bytes )
 {
 hvmemul_ctxt->insn_buf_bytes =
 hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
@@ -1931,7 +1938,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 return rc;
 }
 
-void hvm_mem_access_emulate_one(enum emul_kind kind, unsigned int trapnr,
+void hvm_emulate_one_vm_event(enum emul_kind kind, unsigned int trapnr,
 unsigned int errcode)
 {
 struct hvm_emulate_ctxt ctx 

[Xen-devel] [PATCH 1/2] vm_event: Sanitize vm_event response handling

[Tamas K Lengyel]

Setting response flags in vm_event are only ever safe if the vCPUs are paused.
To reflect this we move all checks within the if block that already checks
whether this is the case. Checks that are only supported on one architecture
we relocate the bitmask operations to the arch-specific handlers to avoid
the overhead on architectures that don't support it.

Furthermore, we clean-up the emulation checks so it more clearly represents the
decision-logic when emulation should take place. As part of this we also
set the stage to allow emulation in response to other types of events, not just
mem_access violations.

Signed-off-by: Tamas K Lengyel 
---
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/x86/mm/p2m.c  | 81 +++---
 xen/arch/x86/vm_event.c| 35 +-
 xen/common/vm_event.c  | 53 ++-
 xen/include/asm-arm/p2m.h  |  4 +--
 xen/include/asm-arm/vm_event.h |  9 -
 xen/include/asm-x86/p2m.h  |  4 +--
 xen/include/asm-x86/vm_event.h |  5 ++-
 xen/include/xen/mem_access.h   | 12 ---
 8 files changed, 113 insertions(+), 90 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 7d14c3b..6c01868 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1588,62 +1588,55 @@ void p2m_mem_paging_resume(struct domain *d, 
vm_event_response_t *rsp)
 }
 }
 
-void p2m_mem_access_emulate_check(struct vcpu *v,
-  const vm_event_response_t *rsp)
+bool_t p2m_mem_access_emulate_check(struct vcpu *v,
+const vm_event_response_t *rsp)
 {
-/* Mark vcpu for skipping one instruction upon rescheduling. */
-if ( rsp->flags & VM_EVENT_FLAG_EMULATE )
-{
-xenmem_access_t access;
-bool_t violation = 1;
-const struct vm_event_mem_access *data = >u.mem_access;
+xenmem_access_t access;
+bool_t violation = 1;
+const struct vm_event_mem_access *data = >u.mem_access;
 
-if ( p2m_get_mem_access(v->domain, _gfn(data->gfn), ) == 0 )
+if ( p2m_get_mem_access(v->domain, _gfn(data->gfn), ) == 0 )
+{
+switch ( access )
 {
-switch ( access )
-{
-case XENMEM_access_n:
-case XENMEM_access_n2rwx:
-default:
-violation = data->flags & MEM_ACCESS_RWX;
-break;
+case XENMEM_access_n:
+case XENMEM_access_n2rwx:
+default:
+violation = data->flags & MEM_ACCESS_RWX;
+break;
 
-case XENMEM_access_r:
-violation = data->flags & MEM_ACCESS_WX;
-break;
+case XENMEM_access_r:
+violation = data->flags & MEM_ACCESS_WX;
+break;
 
-case XENMEM_access_w:
-violation = data->flags & MEM_ACCESS_RX;
-break;
+case XENMEM_access_w:
+violation = data->flags & MEM_ACCESS_RX;
+break;
 
-case XENMEM_access_x:
-violation = data->flags & MEM_ACCESS_RW;
-break;
+case XENMEM_access_x:
+violation = data->flags & MEM_ACCESS_RW;
+break;
 
-case XENMEM_access_rx:
-case XENMEM_access_rx2rw:
-violation = data->flags & MEM_ACCESS_W;
-break;
+case XENMEM_access_rx:
+case XENMEM_access_rx2rw:
+violation = data->flags & MEM_ACCESS_W;
+break;
 
-case XENMEM_access_wx:
-violation = data->flags & MEM_ACCESS_R;
-break;
+case XENMEM_access_wx:
+violation = data->flags & MEM_ACCESS_R;
+break;
 
-case XENMEM_access_rw:
-violation = data->flags & MEM_ACCESS_X;
-break;
+case XENMEM_access_rw:
+violation = data->flags & MEM_ACCESS_X;
+break;
 
-case XENMEM_access_rwx:
-violation = 0;
-break;
-}
+case XENMEM_access_rwx:
+violation = 0;
+break;
 }
-
-v->arch.vm_event->emulate_flags = violation ? rsp->flags : 0;
-
-if ( (rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA) )
-v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
 }
+
+return violation;
 }
 
 void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index e938ca3..343b9c8 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -18,6 +18,7 @@
  * License along with this program; If not, see 

[Xen-devel] [xen-4.6-testing test] 100907: regressions - FAIL

[osstest service owner]

flight 100907 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100907/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100895
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 100895
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
100895

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail REGR. vs. 100895
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100895
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100895
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100895
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100895

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   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-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  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-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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass

version targeted for testing:
 xen  3cffa34537767dfdb6a0fa02c1a54fdfc7644b6d
baseline version:
 xen  6b5bb502a93bcb7617ea1f3f5a8712f2b9f33d90

Last test of basis   100895  2016-09-12 14:15:38 Z1 days
Testing same since   100907  2016-09-13 00:53:24 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   

Re: [Xen-devel] [PATCH 2/2] x86: add a user configurable Kconfig option for the EHCI UART

[Andrew Cooper]

On 13/09/16 18:35, Derek Straka wrote:
> Allows for the conditional inclusion of EHCI UART driver on the x86 platform
> rather than having it always enabled.
>
> The default configuration for the HAS_EHCI option remains 'y' on x86, so the
> behavior out of the box remains unchanged.  The addition of the option allows
> advanced users to enable/disable the inclusion of the EHCI UART driver.
>
> Signed-off-by: Derek Straka 
> ---
>  xen/arch/x86/Kconfig |  1 -
>  xen/drivers/char/Kconfig |  3 ++-
>  xen/include/xen/serial.h | 12 +++-
>  3 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 8a122df..2119c93 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -8,7 +8,6 @@ config X86
>   select COMPAT
>   select CORE_PARKING
>   select HAS_CPUFREQ
> - select HAS_EHCI
>   select HAS_GDBSX
>   select HAS_IOPORTS
>   select HAS_KEXEC
> diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
> index c87e018..08a60e0 100644
> --- a/xen/drivers/char/Kconfig
> +++ b/xen/drivers/char/Kconfig
> @@ -45,7 +45,8 @@ config HAS_SCIF
> say Y.
>  
>  config HAS_EHCI
> - bool
> + bool "EHCI UART" if EXPERT = "y"
> + default y if X86
>   help
> This selects the USB based EHCI debug port to be used as a UART. If
> you have an x86 based system with USB, say Y.
> diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
> index 343779c..8f87897 100644
> --- a/xen/include/xen/serial.h
> +++ b/xen/include/xen/serial.h
> @@ -174,11 +174,21 @@ void ns16550_init(int index, struct ns16550_defaults 
> *defaults);
>  static inline void ns16550_init(int index, struct ns16550_defaults 
> *defaults) {}
>  #endif
>  
> +#ifdef CONFIG_HAS_EHCI
>  void ehci_dbgp_init(void);
> -void arm_uart_init(void);
> +#else
> +static inline void ehci_dbgp_init(void) {}
> +#endif

It would be cleaner to have ehci_dbgp_init() and dbgp_op() beside each
other in a single #ifdef CONFIG_HAS_EHCI

With this, Acked-by: Andrew Cooper 

>  
> +void arm_uart_init(void);
> + 
>  struct physdev_dbgp_op;
> +
> +#ifdef CONFIG_HAS_EHCI
>  int dbgp_op(const struct physdev_dbgp_op *);
> +#else
> +static inline int dbgp_op(const struct physdev_dbgp_op *op) { return 0; }
> +#endif
>  
>  /* Baud rate was pre-configured before invoking the UART driver. */
>  #define BAUD_AUTO (-1)


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

Re: [Xen-devel] [PATCH 1/2] x86: add a user configurable Kconfig option for the NS16550 UART

[Andrew Cooper]

On 13/09/16 18:35, Derek Straka wrote:
> Allows for the conditional inclusion of NS16550 UART driver on the x86 
> platform
> rather than having it always enabled.
>
> The default configuration for the HAS_NS16550 option remains 'y' on x86, so 
> the
> behavior out of the box remains unchanged.  The addition of the option allows
> advanced users to enable/disable the inclusion of the NS16550 UART driver.
>
> Signed-off-by: Derek Straka 

Acked-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH Altp2m cleanup v4 2/4] altp2m cleanup work

[Lai, Paul]

On Mon, Sep 12, 2016 at 11:47:35AM +0100, George Dunlap wrote:
> On 08/09/16 17:45, Lai, Paul C wrote:
> > [Paul2] in-line
> 
> If you're going to engage in discussions on xen-devel it would really be
> worth your time to find a mail setup that allows you to actually quote
> properly such that you can reply in-line without these manual mark-ups.
> 
> If you can't configure your mail reader to do proper nested quoting, and
> you can't / don't want to change your mail reader, then you could
> consider doing what I do and signing up for a gmail account to get all
> the xen-devel mail and replying from there.
> 
> Thanks,
>  -George
> 

George,
Thanks for the suggestions.
Hopefully this reply illustrates that I can learn.

-Paul

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

[Xen-devel] [PATCH 1/2] x86: add a user configurable Kconfig option for the NS16550 UART

[Derek Straka]

Allows for the conditional inclusion of NS16550 UART driver on the x86 platform
rather than having it always enabled.

The default configuration for the HAS_NS16550 option remains 'y' on x86, so the
behavior out of the box remains unchanged.  The addition of the option allows
advanced users to enable/disable the inclusion of the NS16550 UART driver.

Signed-off-by: Derek Straka 
---
 xen/arch/x86/Kconfig | 1 -
 xen/drivers/char/Kconfig | 4 ++--
 xen/include/xen/serial.h | 7 ++-
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 265fd79..8a122df 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -15,7 +15,6 @@ config X86
select HAS_MEM_ACCESS
select HAS_MEM_PAGING
select HAS_MEM_SHARING
-   select HAS_NS16550
select HAS_PASSTHROUGH
select HAS_PCI
select HAS_PDX
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index 51343d0..c87e018 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -1,6 +1,6 @@
 config HAS_NS16550
-   bool
-   default y
+   bool "NS16550 UART" if EXPERT = "y"
+   default y if X86
help
  This selects the 16550-series UART support. For most systems, say Y.
 
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 1212a12..343779c 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -167,9 +167,14 @@ struct ns16550_defaults {
 int irq;   /* default irq */
 unsigned long io_base; /* default io_base address */
 };
+
+#ifdef CONFIG_HAS_NS16550
 void ns16550_init(int index, struct ns16550_defaults *defaults);
-void ehci_dbgp_init(void);
+#else
+static inline void ns16550_init(int index, struct ns16550_defaults *defaults) 
{}
+#endif
 
+void ehci_dbgp_init(void);
 void arm_uart_init(void);
 
 struct physdev_dbgp_op;
-- 
2.7.4


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

[Xen-devel] [PATCH 2/2] x86: add a user configurable Kconfig option for the EHCI UART

[Derek Straka]

Allows for the conditional inclusion of EHCI UART driver on the x86 platform
rather than having it always enabled.

The default configuration for the HAS_EHCI option remains 'y' on x86, so the
behavior out of the box remains unchanged.  The addition of the option allows
advanced users to enable/disable the inclusion of the EHCI UART driver.

Signed-off-by: Derek Straka 
---
 xen/arch/x86/Kconfig |  1 -
 xen/drivers/char/Kconfig |  3 ++-
 xen/include/xen/serial.h | 12 +++-
 3 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 8a122df..2119c93 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -8,7 +8,6 @@ config X86
select COMPAT
select CORE_PARKING
select HAS_CPUFREQ
-   select HAS_EHCI
select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig
index c87e018..08a60e0 100644
--- a/xen/drivers/char/Kconfig
+++ b/xen/drivers/char/Kconfig
@@ -45,7 +45,8 @@ config HAS_SCIF
  say Y.
 
 config HAS_EHCI
-   bool
+   bool "EHCI UART" if EXPERT = "y"
+   default y if X86
help
  This selects the USB based EHCI debug port to be used as a UART. If
  you have an x86 based system with USB, say Y.
diff --git a/xen/include/xen/serial.h b/xen/include/xen/serial.h
index 343779c..8f87897 100644
--- a/xen/include/xen/serial.h
+++ b/xen/include/xen/serial.h
@@ -174,11 +174,21 @@ void ns16550_init(int index, struct ns16550_defaults 
*defaults);
 static inline void ns16550_init(int index, struct ns16550_defaults *defaults) 
{}
 #endif
 
+#ifdef CONFIG_HAS_EHCI
 void ehci_dbgp_init(void);
-void arm_uart_init(void);
+#else
+static inline void ehci_dbgp_init(void) {}
+#endif
 
+void arm_uart_init(void);
+ 
 struct physdev_dbgp_op;
+
+#ifdef CONFIG_HAS_EHCI
 int dbgp_op(const struct physdev_dbgp_op *);
+#else
+static inline int dbgp_op(const struct physdev_dbgp_op *op) { return 0; }
+#endif
 
 /* Baud rate was pre-configured before invoking the UART driver. */
 #define BAUD_AUTO (-1)
-- 
2.7.4


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

[Xen-devel] trying to get started w/ osstest

[Lai, Paul C]

I'm looking to get started with osstest and running to some roadblocks.

The page 
https://blog.xenproject.org/2013/02/02/xen-automatic-test-system-osstest/ looks 
like the place to begin, but

1.   The README link returns 404 (file not found)
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=refs/heads/standalone

2.   When I try to clone the project via the https: URL, another file not 
found error returns.  The URL tried was 
https://xenbits.xen.org/git-http/osstest.git.

And it was taken from http://xenbits.xen.org/gitweb/?p=osstest.git;a=summary,

[ No, I can't use the git: address due to a company firewall.  Yes, I can use 
an http{s}:

URL for the regular Xen sources. ]

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

Re: [Xen-devel] OVMF compile error

[Olaf Hering]

> > > On Mon, Sep 12, 2016 at 07:31:42AM +, Chen, Farrah wrote:
> > > > When I compile xen with the latest commit in RHEL 6.7, it failed when 
> > > > make tools. Errors showed when running edk2 build for OvmfPkgX64.

> > > > erAsm.iii:315: error: invalid combination of opcode and operands

The included nasm package is likely too old, 2.10.something is
required.

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth]

On 13/09/2016 17:46, "George Dunlap"  wrote:

>On 12/09/16 17:20, Lars Kurth wrote:
>> Added RTC Policy
>> Added +2 ... -2 scheme for votes
>> Clarified lazy consensus (tallying and lazy voting)
>> Added Informal Votes/Surveys
>> Added Project Team Leadership role and Decision making
>> Added Community Decisions with Funding and Legal Implications
>> Changed Project Wide Decision making: per project based scheme
>> Clarified scope of Decision making
>
>Hey Lars,
>
>Would it be possible to break some of these down into separate patches?
>This is an awfully long "patch" to review all at once; and it seems like
>it would be nice for you as well to be able to get Acked / Reviewed-by's
>for some of the smaller and/or less contentious items as you go along.

I could, but it isn't really that long. And it makes life hard for me, as
there is only one file. Thus breaking it into bits and maintaining the
changes is hard in git.

Also, it is unclear whether we need to follow the regular process, as
technically we need to have a vote on the final proposal.

>There are a number of sections of this that I have read and basically
>approve of; a number that I have read and am still thinking about or
>some comments on; and a number that I haven't grokked yet and will want
>to do later.  (I'll think for a bit and maybe come back to this later
>this week.)

Thanks

Lars

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

Re: [Xen-devel] [PATCH v3 01/18] arm/x86: Add HAS_[ALTERNATIVE|EX_TABLE]

[Konrad Rzeszutek Wilk]

On Mon, Sep 12, 2016 at 04:31:20PM +0100, Julien Grall wrote:
> Hi,
> 
> On 12/09/16 16:28, Jan Beulich wrote:
> > > > > On 11.09.16 at 22:35,  wrote:
> > > x86 implements all of them by default - and we just
> > > add two extra HAS_ variables to be declared in autoconf.h.
> > > 
> > > ARM 64 only has alternative while ARM 32 has none of them.
> > > The ARM64 is going to be a bit funny as there is an
> > > ALTERNATIVE already and we end up selecting the HAS_ALTERNATIVE
> > > whenever the ALTERNATIVE is selected.
> > 
> > How about replacing ALTERNATIVE by HAS_ALTERNATIVE?
> 
> FWIW, I was about to suggest the same.

Fantastic! Got a new patch queued up.


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

Re: [Xen-devel] [PATCH v2 3/3] Significant changes to decision making; some new roles and minor changes

[George Dunlap]

On 12/09/16 17:20, Lars Kurth wrote:
> Added RTC Policy
> Added +2 ... -2 scheme for votes
> Clarified lazy consensus (tallying and lazy voting)
> Added Informal Votes/Surveys
> Added Project Team Leadership role and Decision making
> Added Community Decisions with Funding and Legal Implications
> Changed Project Wide Decision making: per project based scheme
> Clarified scope of Decision making

Hey Lars,

Would it be possible to break some of these down into separate patches?
This is an awfully long "patch" to review all at once; and it seems like
it would be nice for you as well to be able to get Acked / Reviewed-by's
for some of the smaller and/or less contentious items as you go along.

There are a number of sections of this that I have read and basically
approve of; a number that I have read and am still thinking about or
some comments on; and a number that I haven't grokked yet and will want
to do later.  (I'll think for a bit and maybe come back to this later
this week.)

 -George


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

[Xen-devel] [PATCH Altp2m cleanup v5 0/3] Cleaning up altp2m code

[Paul Lai]

Altp2m cleanup work

The altp2m clean work is motivated by the following URLs:
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04530.html

Most of the work has been:
Lots of white space, indentation, and other coding style preference
corrections.
Lots of moving altp2m functions to the altp2m file.
Lots of moving ept functions to the ept file.
Lots of function return type corrections (and checking).
Better sanity checking of values before processing in do_altp2m_op().
Just using 'return' after a if() clause instead of using a goto
if the block is can be a one liner.

Most importantly here, we help submit Ravi Sahita's dynamically allocated
altp2m domain for struct p2m.  Also, Ravi introduces set_altp2m_active()
and altp2m_active() APIs for better readability and maintainability.

Along the way, some dependencies have broken and we've waited for them
to be fixed.  Most recently the gfn() which caused a hang of the whole system.
The gfn fixes are currently in staging. We've have verified against the
staging branch that this series of patches functions as expected.

Paul Lai (3):
  altp2m cleanup work.
  Move altp2m specific functions to altp2m files.
  Making altp2m domain dynamically allocated.

 xen/arch/x86/hvm/hvm.c|  54 +--
 xen/arch/x86/hvm/vmx/vmx.c|   2 +-
 xen/arch/x86/mm/altp2m.c  |  57 
 xen/arch/x86/mm/hap/hap.c |  38 --
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/mm-locks.h|   4 +-
 xen/arch/x86/mm/p2m-ept.c |  39 ++
 xen/arch/x86/mm/p2m.c | 106 +-
 xen/common/monitor.c  |   1 +
 xen/include/asm-x86/altp2m.h  |  11 +++-
 xen/include/asm-x86/domain.h  |   6 +--
 xen/include/asm-x86/hvm/hvm.h |  22 ++--
 xen/include/asm-x86/hvm/vmx/vmx.h |   3 ++
 xen/include/asm-x86/p2m.h |  18 ---
 14 files changed, 216 insertions(+), 147 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH Altp2m cleanup v5 3/3] Making altp2m domain dynamically allocated.

[Paul Lai]

Ravi Sahita's dynamically allocated altp2m domain.
Introduce set_altp2m_active() and altp2m_active() api()s.

Signed-off-by: Ravi Sahita 
Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c|  8 +++---
 xen/arch/x86/hvm/vmx/vmx.c|  2 +-
 xen/arch/x86/mm/altp2m.c  | 16 +--
 xen/arch/x86/mm/mem_sharing.c |  2 +-
 xen/arch/x86/mm/mm-locks.h|  4 +--
 xen/arch/x86/mm/p2m-ept.c | 10 +++
 xen/arch/x86/mm/p2m.c | 63 ---
 xen/common/monitor.c  |  1 +
 xen/include/asm-x86/altp2m.h  |  7 -
 xen/include/asm-x86/domain.h  |  6 ++---
 xen/include/asm-x86/p2m.h |  9 ++-
 11 files changed, 73 insertions(+), 55 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 1bf2d01..ac692ab 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5259,7 +5259,7 @@ static int do_altp2m_op(
 
 if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
  (a.cmd != HVMOP_altp2m_set_domain_state) &&
- !d->arch.altp2m_active )
+ !altp2m_active(d) )
 {
 rc = -EOPNOTSUPP;
 goto out;
@@ -5293,11 +5293,11 @@ static int do_altp2m_op(
 break;
 }
 
-ostate = d->arch.altp2m_active;
-d->arch.altp2m_active = !!a.u.domain_state.state;
+ostate = altp2m_active(d);
+set_altp2m_active(d, a.u.domain_state.state);
 
 /* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+if ( altp2m_active(d) != ostate &&
  (ostate || !(rc = p2m_init_altp2m_by_id(d, 0))) )
 {
 for_each_vcpu( d, v )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bb7a329..699e9b1 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2018,7 +2018,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
 {
 v->arch.hvm_vmx.secondary_exec_control |= mask;
 __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
-__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m->eptp));
 
 if ( cpu_has_vmx_virt_exceptions )
 {
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 62801ae..7917a1e 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -87,20 +87,20 @@ altp2m_domain_init(struct domain *d)
 return 0;
 
 /* Init alternate p2m data. */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+if ( (d->arch.altp2m->eptp = alloc_xenheap_page()) == NULL )
 return -ENOMEM;
 
 for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+d->arch.altp2m->eptp[i] = mfn_x(INVALID_MFN);
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+rc = p2m_alloc_table(d->arch.altp2m->p2m[i]);
 if ( rc != 0 )
return rc;
 }
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, false);
 
 return rc;
 }
@@ -113,13 +113,13 @@ altp2m_domain_teardown(struct domain *d)
 if ( !hvm_altp2m_supported() )
 return;
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, false);
 
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
+free_xenheap_page(d->arch.altp2m->eptp);
+d->arch.altp2m->eptp = NULL;
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
+p2m_teardown(d->arch.altp2m->p2m[i]);
 }
 
 /*
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index e7c6b74..3fd8380 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -877,7 +877,7 @@ int mem_sharing_nominate_page(struct domain *d,
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-ap2m = d->arch.altp2m_p2m[i];
+ap2m = d->arch.altp2m->p2m[i];
 if ( !ap2m )
 continue;
 
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 74fdfc1..71d3891 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -266,8 +266,8 @@ declare_mm_order_constraint(per_page_sharing)
  */
 
 declare_mm_lock(altp2mlist)
-#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m_list_lock)
-#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m_list_lock)
+#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m->list_lock)
+#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m->list_lock)
 
 /* P2M lock (per-altp2m-table)
  *
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 04878f5..9459d87 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1331,14 +1331,14 @@ void setup_ept_dump(void)
 
 void p2m_init_altp2m_ept(struct domain *d, 

[Xen-devel] [PATCH Altp2m cleanup v5 2/3] Move altp2m specific functions to altp2m files.

[Paul Lai]

This makes the code a little easier to read.
Moving hvm_altp2m_supported() check into functions that use it
for better readability.
Moving ept code to ept specific files as requested in:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
Renamed p2m_init_altp2m_helper() to p2m_init_altp2m_ept().
Got rid of stray blanks after open paren after function names.
Defining _XEN_ASM_X86_P2M_H instead of _XEN_P2M_H for
xen/include/asm-x86/p2m.h.

Signed-off-by: Paul Lai 
---
 xen/arch/x86/mm/altp2m.c  | 57 +++
 xen/arch/x86/mm/hap/hap.c | 38 +++---
 xen/arch/x86/mm/p2m-ept.c | 39 +++
 xen/arch/x86/mm/p2m.c | 45 +++
 xen/include/asm-x86/altp2m.h  |  4 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 +++
 xen/include/asm-x86/p2m.h |  9 +++
 7 files changed, 117 insertions(+), 78 deletions(-)

diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2..62801ae 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,62 @@ altp2m_vcpu_destroy(struct vcpu *v)
 }
 
 /*
+ * altp2m_domain_init(struct domain *d))
+ *  allocate and initialize memory for altp2m portion of domain
+ *
+ *  returns < 0 on error
+ *  returns 0 on no operation (success)
+ *  returns > 0 on success
+ */
+int
+altp2m_domain_init(struct domain *d)
+{
+int rc;
+unsigned int i;
+
+if ( d == NULL)
+return 0;
+
+if ( !hvm_altp2m_supported() )
+return 0;
+
+/* Init alternate p2m data. */
+if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+return -ENOMEM;
+
+for ( i = 0; i < MAX_EPTP; i++ )
+d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+if ( rc != 0 )
+   return rc;
+}
+
+d->arch.altp2m_active = 0;
+
+return rc;
+}
+
+void
+altp2m_domain_teardown(struct domain *d)
+{
+unsigned int i;
+
+if ( !hvm_altp2m_supported() )
+return;
+
+d->arch.altp2m_active = 0;
+
+free_xenheap_page(d->arch.altp2m_eptp);
+d->arch.altp2m_eptp = NULL;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+p2m_teardown(d->arch.altp2m_p2m[i]);
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3218fa2..61c0c42 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -499,26 +500,17 @@ int hap_enable(struct domain *d, u32 mode)
goto out;
 }
 
-if ( hvm_altp2m_supported() )
+if ( (rv = altp2m_domain_init(d)) < 0 )
 {
-/* Init alternate p2m data */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
-{
-rv = -ENOMEM;
-goto out;
+for (i = 0; i < MAX_NESTEDP2M; i++) {
+p2m_teardown(d->arch.nested_p2m[i]);
 }
 
-for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
-if ( rv != 0 )
-   goto out;
-}
+if ( d->arch.paging.hap.total_pages != 0 )
+hap_teardown(d, NULL);
 
-d->arch.altp2m_active = 0;
+p2m_teardown(p2m_get_hostp2m(d));
+goto out;
 }
 
 /* Now let other users see the new mode */
@@ -533,19 +525,7 @@ void hap_final_teardown(struct domain *d)
 {
 unsigned int i;
 
-if ( hvm_altp2m_supported() )
-{
-d->arch.altp2m_active = 0;
-
-if ( d->arch.altp2m_eptp )
-{
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
-}
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
-}
+altp2m_domain_teardown(d);
 
 /* Destroy nestedp2m's first */
 for (i = 0; i < MAX_NESTEDP2M; i++) {
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 13cab24..04878f5 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
 register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
 }
 
+void p2m_init_altp2m_ept(struct domain *d, unsigned int i)
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct ept_data *ept;
+
+p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
+p2m->max_remapped_gfn = 0;
+ept = >ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+}
+
+unsigned int p2m_find_altp2m_by_eptp(struct domain 

Re: [Xen-devel] [PATCH v5 1/4] livepatch/docs: Document .bss not being cleared, and .data potentially having changed values

[Jan Beulich]

>>> On 13.09.16 at 17:59,  wrote:
> On Mon, Sep 12, 2016 at 01:49:51AM -0600, Jan Beulich wrote:
>> >>> On 11.09.16 at 17:48,  wrote:
>> > --- a/docs/misc/livepatch.markdown
>> > +++ b/docs/misc/livepatch.markdown
>> > @@ -875,6 +875,12 @@ section and the new function will reference the new 
>> > string in the new
>> >  
>> >  This is implemented in the Xen Project hypervisor.
>> >  
>> > +Note that the .bss section is only cleared when the ELF payload is 
>> > uploaded.
>> > +Subsequent apply/revert/apply operation do no clear the .bss (or reset the
>> > +.data to what it was when loaded). Hence it is the responsibility of the
>> > +creator of the payload to reset these values to known good state if they
>> > +depend on them having certain values at apply/revert states.
>> 
>> Was it, as an alternative, considered to disallow re-applying a
>> reverted patch without re-uploading?
> 
> I was thinking about it but not exactly sure of the ramifications.
> 
> That is if you go this route - revert a patch - we could go the
> next step and just unload it. But that puts some question on how
> to schedule that without corruption - say we have payload A,B and we
> are replacing A,B with C. A,B should be reverted and unloaded..
> 
> That means some form of list .. Ugh.
> 
> We could do a simpler way (which is what I think inline with your
> suggestion). This does the trick (and needs to be split up obviously)
> and also handles the case where you only have .text changes (like
> for NOPs).

At least that draft patch looks reasonable at a first glance.

Jan


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

Re: [Xen-devel] PC8 Residency on Broadwell hardware

[Nakajima, Jun]

> On Sep 13, 2016, at 2:05 AM, Andrew Cooper  wrote:
> 
> On 13/09/16 08:51, Jan Beulich wrote:
> On 12.09.16 at 19:28,  wrote:
>> Please try to get quoting right - your response was rather hard to
>> follow.
>> 
>>> On Sep 12, 2016, at 2:00 AM, Jan Beulich 
>>> > wrote:
>>> 
>>> On 12.09.16 at 10:47, 
>>> > wrote:
>>> c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
>>> MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).
>> I think this was misleading: 79 == 0x4f. Andrew, can you confirm in
>> your case please?
> 
> Very sorry for the confusion.  Yes, I was talking about model 0x4f.
> 
>>> Rereading the manual, it does indeed indicate that this MSR is available.
>>> 
>>> However, experimentally it is not.  All Broadwell hardware XenServer has
>>> (both SDPs and production systems) reliably take a #GP fault when trying
>>> to read this MSR.  Haswell hardware appears fine (and indeed, was
>>> reading that MSR before).
>>> 
>>> Where did you find the info? I think you are talking about 
>>> MSR_PKG_C8_RESIDENCY (630H).
>> Yes.
>> 
>>> The SDM says (35.13):
>>> 
>>> "Processors with signatures 06_3DH and 06_47H support the MSR interfaces 
>>> listed in Table 35-18, Table 35-19, Table 35-20, Table 35-23, Table 35-27, 
>>> Table 35-28, Table 35-32, and Table 35-33.”
>> Model 0x4f is what we're talking about, and table 35-36 has the information
>> on MSR_PKG_C8_RESIDENCY (630H).
> 
> Correct.
> 
> ~Andrew

OK. We are taking a look at that now. Thanks for the report.

---
Jun
Intel Open Source Technology Center
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[David Vrabel]

On 12/09/16 15:32, Jan Beulich wrote:
 On 09.09.16 at 17:16,  wrote:
>> The following code illustrates this idea:
>>
>> typedef struct dm_op_buffer {
>>  XEN_GUEST_HANDLE(void) h;
>>  size_t len;
>> } dm_op_buffer_t;
> 
> This implies that we'll lose all type safety on the handles passed, as
> is also emphasized by the use of raw_copy_from_guest() in the code
> outline further down.

This is an direct result of the requirement that the privcmd driver does
not know the types of the sub-ops themselves.  We can't have this
requirement and type safety.  Which do we want?

I would point out that Linux copy_from_user() and copy_to_user()
functions are not type safe and I'm not aware that this causes many
problems.

David

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

Re: [Xen-devel] [PATCH v5 2/4] livepatch: Add limit of 2MB to payload .bss sections.

[Ross Lagerwall]

On 09/11/2016 04:48 PM, Konrad Rzeszutek Wilk wrote:

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793
"xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the
size of the binary at 2MB. We follow that in capping the size
of the .BSSes to be at maximum 2MB.

Signed-off-by: Konrad Rzeszutek Wilk 



Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v3 33/38] arm/p2m: Add altp2m paging mechanism

[Sergej Proskurin]

Hi Julien,


On 09/13/2016 05:08 PM, Julien Grall wrote:
>
>
> On 13/09/16 16:06, Sergej Proskurin wrote:
 +}
 +
 +out:
 +p2m_read_unlock(hp2m);
 +
 +return true;
 +}
 +
  static inline void altp2m_reset(struct p2m_domain *p2m)
  {
  p2m_write_lock(p2m);
 diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
 index 0bf1653..a4c923c 100644
 --- a/xen/arch/arm/traps.c
 +++ b/xen/arch/arm/traps.c
 @@ -48,6 +48,8 @@
  #include 
  #include 

 +#include 
 +
  /* The base of the stack must always be double-word aligned, which
 means
   * that both the kernel half of struct cpu_user_regs (which is
 pushed in
   * entry.S) and struct cpu_info (which lives at the bottom of a Xen
 @@ -2397,6 +2399,24 @@ static inline bool hpfar_is_valid(bool s1ptw,
 uint8_t fsc)
  return s1ptw || (fsc == FSC_FLT_TRANS &&
 !check_workaround_834220());
  }

 +static bool_t try_handle_altp2m(struct vcpu *v,
 +paddr_t gpa,
 +struct npfec npfec)
>>>
>>> I am not convinced about the usefulness of this function.
>>>
>>
>> Your call. However, I believe it is better to have the altp2m handling
>> routine at one place.
>
> Then, why it is not done in altp2m_lazy_copy?

Alright, I will remove the function.

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v5 1/4] livepatch/docs: Document .bss not being cleared, and .data potentially having changed values

[Konrad Rzeszutek Wilk]

On Mon, Sep 12, 2016 at 01:49:51AM -0600, Jan Beulich wrote:
> >>> On 11.09.16 at 17:48,  wrote:
> > --- a/docs/misc/livepatch.markdown
> > +++ b/docs/misc/livepatch.markdown
> > @@ -875,6 +875,12 @@ section and the new function will reference the new 
> > string in the new
> >  
> >  This is implemented in the Xen Project hypervisor.
> >  
> > +Note that the .bss section is only cleared when the ELF payload is 
> > uploaded.
> > +Subsequent apply/revert/apply operation do no clear the .bss (or reset the
> > +.data to what it was when loaded). Hence it is the responsibility of the
> > +creator of the payload to reset these values to known good state if they
> > +depend on them having certain values at apply/revert states.
> 
> Was it, as an alternative, considered to disallow re-applying a
> reverted patch without re-uploading?

I was thinking about it but not exactly sure of the ramifications.

That is if you go this route - revert a patch - we could go the
next step and just unload it. But that puts some question on how
to schedule that without corruption - say we have payload A,B and we
are replacing A,B with C. A,B should be reverted and unloaded..

That means some form of list .. Ugh.

We could do a simpler way (which is what I think inline with your
suggestion). This does the trick (and needs to be split up obviously)
and also handles the case where you only have .text changes (like
for NOPs).

Interestingly, the linker always adds an .bss and .data section
even if the code does not produce it.

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index d9eeab1..4a1abb2 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -53,6 +53,8 @@ struct livepatch_build_id {
 struct payload {
 uint32_t state;  /* One of the LIVEPATCH_STATE_*. */
 int32_t rc;  /* 0 or -XEN_EXX. */
+bool_t reverted; /* Whether it was reverted. */
+bool_t safe_to_reapply;  /* Can apply safely after revert. */
 struct list_head list;   /* Linked to 'payload_list'. */
 const void *text_addr;   /* Virtual address of .text. */
 size_t text_size;/* .. and its size. */
@@ -313,7 +315,7 @@ static void calc_section(const struct livepatch_elf_sec 
*sec, size_t *size,
 static int move_payload(struct payload *payload, struct livepatch_elf *elf)
 {
 void *text_buf, *ro_buf, *rw_buf;
-unsigned int i;
+unsigned int i, rw_buf_sec, rw_buf_cnt = 0;
 size_t size = 0;
 unsigned int *offset;
 int rc = 0;
@@ -386,7 +388,11 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 if ( elf->sec[i].sec->sh_flags & SHF_EXECINSTR )
 buf = text_buf;
 else if ( elf->sec[i].sec->sh_flags & SHF_WRITE )
+{
 buf = rw_buf;
+rw_buf_sec = i;
+rw_buf_cnt++;
+}
 else
 buf = ro_buf;
 
@@ -407,6 +413,11 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 }
 }
 
+if ( rw_buf_cnt == 1 )
+{
+if ( !strcmp(elf->sec[rw_buf_sec].name, ELF_LIVEPATCH_FUNC) )
+payload->safe_to_reapply = true;
+}
  out:
 xfree(offset);
 
@@ -1120,6 +1131,7 @@ static int revert_payload(struct payload *data)
 list_del_rcu(>applied_list);
 unregister_virtual_region(>region);
 
+data->reverted = true;
 return 0;
 }
 
@@ -1501,6 +1513,19 @@ static int 
livepatch_action(xen_sysctl_livepatch_action_t *action)
 case LIVEPATCH_ACTION_APPLY:
 if ( data->state == LIVEPATCH_STATE_CHECKED )
 {
+/*
+ * It is unsafe to apply an reverted as the .data may not be in
+ * in pristine condition. Hence MUST unload and then apply patch
+ * again.
+ */
+if ( data->reverted && !data->safe_to_reapply )
+{
+dprintk(XENLOG_ERR, "%s%s: can't revert as payload has .data. 
Please unload!\n",
+LIVEPATCH, data->name);
+data->rc = -EINVAL;
+break;
+}
+
 rc = build_id_dep(data, !!list_empty(_list));
 if ( rc )
 break;
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 69b0cdd..e03a26d 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -72,7 +72,7 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
$(OBJCOPY) $(OBJCOPY_MAGIC) \
-  --rename-section=.data=.livepatch.depends -S $@.bin $@
+  
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin
 
 #
@@ -83,7 +83,7 @@ note.o:
 

Re: [Xen-devel] [PATCH v3 38/38] arm/p2m: Add test of xc_altp2m_change_gfn

[Sergej Proskurin]

Hi Wei,


On 08/24/2016 02:27 PM, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 12:17:14AM +0200, Sergej Proskurin wrote:
>> This commit extends xen-access by a simple test of the functionality
>> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
>> trapping gfn to another mfn, which holds the same content as the
>> original mfn. On success, the guest will continue to run. Subsequent
>> altp2m access violations will trap into Xen and be forced by xen-access
>> to switch to the default view (altp2m[0]) as before. The introduced test
>> can be invoked by providing the argument "altp2m_remap".
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Razvan Cojocaru 
>> Cc: Tamas K Lengyel 
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> ---
>> v3: Cosmetic fixes in "xenaccess_copy_gfn" and "xenaccess_change_gfn".
>>
>> Added munmap in "copy_gfn" in the second error case.
>>
>> Added option "altp2m_remap" selecting the altp2m-remap test.
>> ---
>>  tools/tests/xen-access/xen-access.c | 162 
>> +++-
>>  1 file changed, 158 insertions(+), 4 deletions(-)
>>
>> diff --git a/tools/tests/xen-access/xen-access.c 
>> b/tools/tests/xen-access/xen-access.c
>> index eafd7d6..5909a8a 100644
>> --- a/tools/tests/xen-access/xen-access.c
>> +++ b/tools/tests/xen-access/xen-access.c
>> @@ -38,6 +38,7 @@
>>  #include 
>>  #include 
>>  
>> +#define XC_WANT_COMPAT_MAP_FOREIGN_API
> I know Razvan already acked this, but general you shouldn't use the
> COMPAT APIs. You should use libs/foreignmemory library, which is a
> stable library.

Alright, I will adapt the implementation accordingly. Thanks for the hint.

>>  #include 
>>  #include 
>>  #include 
>> @@ -49,6 +50,8 @@
>>  #define START_PFN 0ULL
>>  #endif
>>  
>> +#define INVALID_GFN ~(0UL)
>> +
>>  #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
>>  #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
>>  #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
>> @@ -72,9 +75,14 @@ typedef struct xenaccess {
>>  xen_pfn_t max_gpfn;
>>  
>>  vm_event_t vm_event;
>> +
>> +unsigned int ap2m_idx;
>> +xen_pfn_t gfn_old;
>> +xen_pfn_t gfn_new;
>>  } xenaccess_t;
>>  
>>  static int interrupted;
>> +static int gfn_changed = 0;
>>  bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
>>  
>>  static void close_handler(int sig)
>> @@ -82,6 +90,100 @@ static void close_handler(int sig)
>>  interrupted = sig;
>>  }
>>  
>> +static int xenaccess_copy_gfn(xc_interface *xch,
>> +  domid_t domain_id,
>> +  xen_pfn_t dst_gfn,
>> +  xen_pfn_t src_gfn)
>> +{
>> +void *src_vaddr = NULL;
>> +void *dst_vaddr = NULL;
>> +
>> +src_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
>> + PROT_READ, src_gfn);
>> +if ( src_vaddr == MAP_FAILED || src_vaddr == NULL)
>> +return -1;
>> +
>> +dst_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
>> + PROT_WRITE, dst_gfn);
> You can have a look at libxc/xc_foreign_memory.c for how to replace this
> legacy call with the new function.

Will do, thanks.

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Jan Beulich]

>>> On 13.09.16 at 16:56,  wrote:

Seems like mistakenly dropped xen-devel in my earlier reply; re-added.

> On 9/13/2016 5:02 PM, Jan Beulich wrote:
> On 13.09.16 at 09:12,  wrote:
>>> On a machine with a mount of cpus, dump_timerq() lasts several seconds
>>> which may exceed watchdog timeout and cause Xen hyperviosr reboot.
>>> This patch is to disable watchdog when dump timer queues to fix the
>>> issue.
>>
>> But disabling the watchdog is not the resolution. Instead you
>> want to invoke process_pending_softirqs() every once in a while,
>> just like certain other key handlers do.
> 
> Actually, I have tried that way but it's not enough.
> Keyhandler may run in the timer handler and the following log shows
> calltrace. The timer subsystem run all expired timers' handler
> before programing next timer event. If keyhandler runs longer than
> timeout, there will be no chance to configure timer before triggering
> watchdog and hypervisor rebooting.
> 
> (XEN)[] handle_keypress+0x7b/0xa5
> (XEN)[] console.c#__serial_rx+0x16/0x54
> (XEN)[] console.c#serial_rx+0x94/0x9f
> (XEN)[] serial_rx_interrupt+0xa9/0xbf
> (XEN)[] ns16550.c#__ns16550_poll+0x53/0xb4
> (XEN)[] do_invalid_op+0x26d/0x49f
> (XEN)[] cpufreq.c#handle_exception_saved+0x2e/0x6c
> (XEN)[] ns16550.c#ns16550_poll+0x20/0x24
> (XEN)[] timer.c#execute_timer+0x4e/0x6c
> (XEN)[] timer.c#timer_softirq_action+0xea/0x222
> (XEN)[] softirq.c#__do_softirq+0x9b/0xac
> (XEN)[] do_softirq+0x13/0x15
> (XEN)[] domain.c#idle_loop+0x78/0x88

Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
happened after some already fatal event (in which case all bets
are off anyway).

> Another solution is to schedule a tasklet to run keyhandler in timer
> handler and invoke process_pending_softirqs() in the dump_timerq().
> This also works but it requires to rework keyhandler mechanism.
> 
> Disable watchdog seems to be simpler and I found dump_registers() also
> used the same way to deal with the issue.

That's true. Just that on large machines it defaults to the
alternative model, for which I'm not sure it actually needs the
watchdog disabled (as data for a single CPU shouldn't exceed
the threshold).

Jan

> Here is my draft patch of reworking keyhandler.
> diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
> index 16de6e8..579d076 100644
> --- a/xen/common/keyhandler.c
> +++ b/xen/common/keyhandler.c
> @@ -75,9 +75,10 @@ static struct keyhandler {
> 
>   static void keypress_action(unsigned long unused)
>   {
> -handle_keypress(keypress_key, NULL);
> +console_start_log_everything();
> +h->fn(keypress_key);
> +console_end_log_everything();
>   }
> -
>   static DECLARE_TASKLET(keypress_tasklet, keypress_action, 0);
> 
>   void handle_keypress(unsigned char key, struct cpu_user_regs *regs)
> @@ -87,10 +88,10 @@ void handle_keypress(unsigned char key, struct 
> cpu_user_regs *regs)
>   if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
>   return;
> 
> -if ( !in_irq() || h->irq_callback )
> +if (h->irq_callback))
>   {
>   console_start_log_everything();
> -h->irq_callback ? h->irq_fn(key, regs) : h->fn(key);
> +h->irq_fn(key, regs);
>   console_end_log_everything();
>   }
>   else
> 
> 
>>
>> Jan
>>




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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Julien Grall]

On 13/09/16 14:06, Shannon Zhao wrote:

Hi Julien,


Hello Shannon,


On 2016/9/13 19:56, Julien Grall wrote:

Hi Shannon,

On 02/09/16 03:55, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU non-RAM memory map space and
passes them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from linux master or:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen


The UEFI binary could be fetched from or built from edk2 master branch:
http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd


On which commit this EFI binary is based? I am trying to rebuild myself,
and go no luck to boot it so far.


I forgot the exact commit. But I just tried below commit which adds the
support to edk2 and the guest can boot up successfully with ACPI.

402dde6 ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM


Thanks, the commit does not build on my platform. After some help for 
Ard I managed to boot UEFI with the patch [1] applied.


However Linux does not boot when passing acpi=on and abort with the 
following message:


(d86) 6RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=1
(d86) 6NR_IRQS:64 nr_irqs:64 0
(d86) 3No valid GICC entries exist
(d86) 0Kernel panic - not syncing: No interrupt controller found.
(d86) dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6+ #420
(d86) dHardware name: XENVM-4.8 (DT)
(d86) Call trace:
(d86) [] dump_backtrace+0x0/0x1a8
(d86) [] show_stack+0x14/0x20
(d86) [] dump_stack+0x94/0xb8
(d86) [] panic+0x10c/0x250
(d86) [] init_IRQ+0x24/0x2c
(d86) [] start_kernel+0x238/0x394
(d86) [] __primary_switched+0x30/0x74
(d86) 0---[ end Kernel panic - not syncing: No interrupt controller found.

This is because the header.length for GICC is not valid for ACPI 5.1 
(see BAD_MADT_GICC_ENTRY). So please check all the size of each table 
against ACPI 5.1.


My configuration is Linux 4.8-rc6 on Juno r2 (e.g GICv2 interrupt 
controller).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 35/38] arm/p2m: Adjust debug information to altp2m

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 04:29 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/16 23:17, Sergej Proskurin wrote:
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Dump p2m information of the hostp2m and all altp2m views.
>> ---
>>  xen/arch/arm/p2m.c | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index dea3038..86e2a1d 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -162,6 +162,26 @@ void dump_p2m_lookup(struct domain *d, paddr_t
>> addr)
>>
>>  dump_pt_walk(page_to_maddr(p2m->root), addr,
>>   P2M_ROOT_LEVEL, P2M_ROOT_PAGES);
>> +printk("\n");
>> +
>> +if ( altp2m_active(d) )
>> +{
>> +unsigned int i;
>> +
>> +for ( i = 0; i < MAX_ALTP2M; i++ )
>> +{
>> +if ( d->arch.altp2m_p2m[i] == NULL )
>> +continue;
>> +
>> +p2m = d->arch.altp2m_p2m[i];
>> +
>> +printk("AP2M[%d] @ %p mfn:0x%lx\n",
>
> s/%d/%u/ as the p2m index is unsigned
> s/0x%lx/%#PRI_mfn/ because we should avoid open format from now.
>

Thank you.

>> +i, p2m->root, page_to_mfn(p2m->root));
>> +
>> +dump_pt_walk(page_to_maddr(p2m->root), addr,
>> P2M_ROOT_LEVEL, P2M_ROOT_PAGES);
>> +printk("\n");
>> +}
>> +}
>>  }
>>
>>  void p2m_save_state(struct vcpu *p)
>>

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v3 33/38] arm/p2m: Add altp2m paging mechanism

[Julien Grall]

On 13/09/16 16:06, Sergej Proskurin wrote:

+}
+
+out:
+p2m_read_unlock(hp2m);
+
+return true;
+}
+
 static inline void altp2m_reset(struct p2m_domain *p2m)
 {
 p2m_write_lock(p2m);
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0bf1653..a4c923c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -48,6 +48,8 @@
 #include 
 #include 

+#include 
+
 /* The base of the stack must always be double-word aligned, which
means
  * that both the kernel half of struct cpu_user_regs (which is
pushed in
  * entry.S) and struct cpu_info (which lives at the bottom of a Xen
@@ -2397,6 +2399,24 @@ static inline bool hpfar_is_valid(bool s1ptw,
uint8_t fsc)
 return s1ptw || (fsc == FSC_FLT_TRANS &&
!check_workaround_834220());
 }

+static bool_t try_handle_altp2m(struct vcpu *v,
+paddr_t gpa,
+struct npfec npfec)


I am not convinced about the usefulness of this function.



Your call. However, I believe it is better to have the altp2m handling
routine at one place.


Then, why it is not done in altp2m_lazy_copy?

Regards,
--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 33/38] arm/p2m: Add altp2m paging mechanism

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 04:18 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/16 23:17, Sergej Proskurin wrote:
>> This commit adds the function "altp2m_lazy_copy" implementing the altp2m
>> paging mechanism. The function "altp2m_lazy_copy" lazily copies the
>> hostp2m's mapping into the currently active altp2m view on 2nd stage
>> translation faults on instruction or data access.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v3: Cosmetic fixes.
>>
>> Locked hostp2m in the function "altp2m_lazy_copy" to avoid a mapping
>> being changed in hostp2m before it has been inserted into the
>> valtp2m view.
>>
>> Removed unnecessary calls to "p2m_mem_access_check" in the functions
>> "do_trap_instr_abort_guest" and "do_trap_data_abort_guest" after a
>> translation fault has been handled by the function
>> "altp2m_lazy_copy".
>>
>> Adapted "altp2m_lazy_copy" to return the value "true" if the
>> encountered translation fault encounters a valid entry inside of the
>> currently active altp2m view. If multiple vcpu's are using the same
>> altp2m, it is likely that both generate a translation fault, whereas
>> the first one will be already handled by "altp2m_lazy_copy". With
>> this change the 2nd vcpu will retry accessing the faulting address.
>>
>> Changed order of altp2m checking and MMIO emulation within the
>> function "do_trap_data_abort_guest".  Now, altp2m is checked and
>> handled only if the MMIO does not have to be emulated.
>>
>> Changed the function prototype of "altp2m_lazy_copy".  This commit
>> removes the unnecessary struct p2m_domain* from the previous
>> function prototype.  Also, this commit removes the unnecessary
>> argument gva.  Finally, this commit changes the address of the
>> function parameter gpa from paddr_t to gfn_t and renames it to gfn.
>>
>> Moved the altp2m handling mechanism into a separate function
>> "try_handle_altp2m".
>>
>> Moved the functions "p2m_altp2m_check" and
>> "altp2m_switch_vcpu_altp2m_by_id" out of this patch.
>>
>> Moved applied code movement into a separate patch.
>> ---
>>  xen/arch/arm/altp2m.c| 62
>> 
>>  xen/arch/arm/traps.c | 35 +
>>  xen/include/asm-arm/altp2m.h |  5 
>>  3 files changed, 102 insertions(+)
>>
>> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
>> index 11272e9..2009bad 100644
>> --- a/xen/arch/arm/altp2m.c
>> +++ b/xen/arch/arm/altp2m.c
>> @@ -165,6 +165,68 @@ out:
>>  return rc;
>>  }
>>
>> +/*
>> + * The function altp2m_lazy_copy returns "false" on error.  The
>> return value
>> + * "true" signals that either the mapping has been successfully
>> lazy-copied
>> + * from the hostp2m to the currently active altp2m view or that the
>> altp2m view
>> + * holds already a valid mapping. The latter is the case if multiple
>> vcpu's
>> + * using the same altp2m view generate a translation fault that is
>> led back in
>> + * both cases to the same mapping and the first fault has been
>> already handled.
>> + */
>> +bool_t altp2m_lazy_copy(struct vcpu *v,
>> +gfn_t gfn,
>> +struct npfec npfec)
>
> Please don't introduce parameters that are not used at all.
>

It was a stupid mistake from my part. Thanks for noticing.

>> +{
>> +struct domain *d = v->domain;
>> +struct p2m_domain *hp2m = p2m_get_hostp2m(d), *ap2m = NULL;
>> +p2m_type_t p2mt;
>> +p2m_access_t p2ma;
>> +mfn_t mfn;
>> +unsigned int page_order;
>> +int rc;
>> +
>> +ap2m = altp2m_get_altp2m(v);
>> +if ( ap2m == NULL)
>> +return false;
>> +
>> +/* Check if entry is part of the altp2m view. */
>> +mfn = p2m_lookup_attr(ap2m, gfn, NULL, NULL, NULL);
>> +if ( !mfn_eq(mfn, INVALID_MFN) )
>> +/*
>> + * If multiple vcpu's are using the same altp2m, it is
>> likely that both
>
> s/vcpu's/vcpus/
>

Ok.

>> + * generate a translation fault, whereas the first one will
>> be handled
>> + * successfully and the second will encounter a valid
>> mapping that has
>> + * already been added as a result of the previous
>> translation fault.
>> + * In this case, the 2nd vcpu need to retry accessing the
>> faulting
>
> s/need/needs/
>

Ok.

>> + * address.
>> + */
>> +return true;
>> +
>> +/*
>> + * Lock hp2m to prevent the hostp2m to change a mapping before
>> it is added
>> + * to the altp2m view.
>> + */
>> +p2m_read_lock(hp2m);
>> +
>> +/* Check if entry is part of the host p2m view. */
>> +mfn = p2m_lookup_attr(hp2m, gfn, , , _order);
>> +if ( mfn_eq(mfn, INVALID_MFN) )
>> +goto out;
>> +
>> +rc = modify_altp2m_entry(ap2m, gfn, mfn, p2mt, p2ma, 

Re: [Xen-devel] [PATCH v3 28/38] arm/p2m: Modify reference count only if hostp2m active

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 11:17 AM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/2016 23:17, Sergej Proskurin wrote:
>> This commit makes sure that the page reference count is updated through
>> the function "p2m_put_l3_page" only the entries have been freed from the
>> hosts's p2m.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>>  xen/arch/arm/p2m.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index cef05ed..df2b85b 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -754,7 +754,7 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>>  if ( !p2m_valid(entry) || p2m_is_superpage(entry, level) )
>>  return;
>>
>> -if ( level == 3 )
>> +if ( level == 3 && p2m_is_hostp2m(p2m) )
>
> This check should be pushed in p2m_put_l3_page as we want to have
> removing reference for all the callers of p2m_put_l3_page.
>

Make sense. Thank you.

>>  {
>>  p2m_put_l3_page(_mfn(entry.p2m.base), entry.p2m.type);
>>  return;
>>

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v3 24/38] arm/p2m: Make p2m_mem_access_check ready for altp2m

[Julien Grall]

On 13/09/16 15:00, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,


On 09/12/2016 11:02 AM, Julien Grall wrote:

On 16/08/2016 23:17, Sergej Proskurin wrote:

This commit extends the function "p2m_mem_access_check" and
"p2m_mem_access_check_and_get_page" to consider altp2m. The function
"p2m_mem_access_check_and_get_page" needs to translate the gva upon the
hostp2m's vttbr, as it contains all valid mappings while the currently
active altp2m view might not have the required gva mapping yet.

Also, the new implementation fills the request buffer to hold
altp2m-related information.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Extended the function "p2m_mem_access_check_and_get_page" to
consider altp2m. Similar to "get_page_from_gva", the function
"p2m_mem_access_check_and_get_page" needs to translate the gva upon
the hostp2m's vttbr. Although, the function "gva_to_ipa" (called in
"p2m_mem_access_check_and_get_page") performs a stage 1 table walk,
it will access page tables residing in memory. Accesses to this
memory are controlled by the underlying 2nd stage translation table
and hence require the original mappings of the hostp2m.
---
 xen/arch/arm/p2m.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5819ae0..ed9e0f0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -14,6 +14,7 @@
 #include 
 #include 

+#include 
 #include 

 #ifdef CONFIG_ARM_64
@@ -1479,9 +1480,32 @@ p2m_mem_access_check_and_get_page(struct vcpu
*v, vaddr_t gva, unsigned long fla
 xenmem_access_t xma;
 p2m_type_t t;
 struct page_info *page = NULL;
-struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
+struct domain *d = v->domain;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+/*
+ * If altp2m is active, we need to translate the gva upon the
hostp2m's
+ * vttbr, as it contains all valid mappings while the currently
active
+ * altp2m view might not have the required gva mapping yet.
Although, the
+ * function gva_to_ipa performs a stage 1 table walk, it will
access page
+ * tables residing in memory. Accesses to this memory are
controlled by the
+ * underlying 2nd stage translation table and hence require the
original
+ * mappings of the hostp2m.


As I already mentioned a few times now, this function is broken and
needs to be fixed before anymore change in it.

The underlying memory of stage-1 page table may have been restricted
and therefore hardware page table walk (gva_to_ipa) may fail.



Based on our previous discussion I believed that it would be enough to
temporary change the VTTBR to the one of the host's p2m as it is done in
the implementation below. Your argument was that (without changing the
VTTBR) it might come to an issue during the process address translation
as accesses to the memory view in the altp2m tables might be restricted.

Would it not be sufficient to temporary switch to the VTTBR of the
host's p2m (similarly as I did in the the following implementation)? In
this way, as far as I understand, changes in the active altp2m view
should not affect the process of address translation.


Well, p2m_set_mem_access could change the permission on view 0 (i.e the 
hostp2m). If the underlying memory of stage-1 page table have been 
restricted, the hardware will not be able to the address translation and 
gva_to_ipa will return an error.


copy_{from,to}_guest may fail because of memaccess restriction. However 
the goal of this function was to avoid those helpers to fail.


So switching to the hostp2m will not help here.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 24/38] arm/p2m: Make p2m_mem_access_check ready for altp2m

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 11:02 AM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/2016 23:17, Sergej Proskurin wrote:
>> This commit extends the function "p2m_mem_access_check" and
>> "p2m_mem_access_check_and_get_page" to consider altp2m. The function
>> "p2m_mem_access_check_and_get_page" needs to translate the gva upon the
>> hostp2m's vttbr, as it contains all valid mappings while the currently
>> active altp2m view might not have the required gva mapping yet.
>>
>> Also, the new implementation fills the request buffer to hold
>> altp2m-related information.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v3: Extended the function "p2m_mem_access_check_and_get_page" to
>> consider altp2m. Similar to "get_page_from_gva", the function
>> "p2m_mem_access_check_and_get_page" needs to translate the gva upon
>> the hostp2m's vttbr. Although, the function "gva_to_ipa" (called in
>> "p2m_mem_access_check_and_get_page") performs a stage 1 table walk,
>> it will access page tables residing in memory. Accesses to this
>> memory are controlled by the underlying 2nd stage translation table
>> and hence require the original mappings of the hostp2m.
>> ---
>>  xen/arch/arm/p2m.c | 43 +++
>>  1 file changed, 39 insertions(+), 4 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 5819ae0..ed9e0f0 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -14,6 +14,7 @@
>>  #include 
>>  #include 
>>
>> +#include 
>>  #include 
>>
>>  #ifdef CONFIG_ARM_64
>> @@ -1479,9 +1480,32 @@ p2m_mem_access_check_and_get_page(struct vcpu
>> *v, vaddr_t gva, unsigned long fla
>>  xenmem_access_t xma;
>>  p2m_type_t t;
>>  struct page_info *page = NULL;
>> -struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
>> +struct domain *d = v->domain;
>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>> +
>> +/*
>> + * If altp2m is active, we need to translate the gva upon the
>> hostp2m's
>> + * vttbr, as it contains all valid mappings while the currently
>> active
>> + * altp2m view might not have the required gva mapping yet.
>> Although, the
>> + * function gva_to_ipa performs a stage 1 table walk, it will
>> access page
>> + * tables residing in memory. Accesses to this memory are
>> controlled by the
>> + * underlying 2nd stage translation table and hence require the
>> original
>> + * mappings of the hostp2m.
>
> As I already mentioned a few times now, this function is broken and
> needs to be fixed before anymore change in it.
>
> The underlying memory of stage-1 page table may have been restricted
> and therefore hardware page table walk (gva_to_ipa) may fail.
>

Based on our previous discussion I believed that it would be enough to
temporary change the VTTBR to the one of the host's p2m as it is done in
the implementation below. Your argument was that (without changing the
VTTBR) it might come to an issue during the process address translation
as accesses to the memory view in the altp2m tables might be restricted.

Would it not be sufficient to temporary switch to the VTTBR of the
host's p2m (similarly as I did in the the following implementation)? In
this way, as far as I understand, changes in the active altp2m view
should not affect the process of address translation.

>> + */
>> +if ( unlikely(altp2m_active(d)) )
>> +{
>> +unsigned long flags = 0;
>> +uint64_t ovttbr = READ_SYSREG64(VTTBR_EL2);
>> +
>> +p2m_switch_vttbr_and_get_flags(ovttbr, p2m->vttbr, flags);
>> +
>> +rc = gva_to_ipa(gva, , flag);
>> +
>> +p2m_restore_vttbr_and_set_flags(ovttbr, flags);
>> +}
>> +else
>> +rc = gva_to_ipa(gva, , flag);
>>
>> -rc = gva_to_ipa(gva, , flag);
>>  if ( rc < 0 )
>>  goto err;
>>
>> @@ -1698,13 +1722,16 @@ bool_t p2m_mem_access_check(paddr_t gpa,
>> vaddr_t gla, const struct npfec npfec)
>>  xenmem_access_t xma;
>>  vm_event_request_t *req;
>>  struct vcpu *v = current;
>> -struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
>> +struct domain *d = v->domain;
>> +struct p2m_domain *p2m = p2m_get_active_p2m(v);
>>
>>  /* Mem_access is not in use. */
>>  if ( !p2m->mem_access_enabled )
>>  return true;
>>
>> -rc = p2m_get_mem_access(v->domain, _gfn(paddr_to_pfn(gpa)), );
>> +p2m_read_lock(p2m);
>> +rc = __p2m_get_mem_access(p2m, _gfn(paddr_to_pfn(gpa)), );
>> +p2m_read_unlock(p2m);
>>  if ( rc )
>>  return true;
>>
>> @@ -1810,6 +1837,14 @@ bool_t p2m_mem_access_check(paddr_t gpa,
>> vaddr_t gla, const struct npfec npfec)
>>  req->u.mem_access.flags |= npfec.insn_fetch ?
>> MEM_ACCESS_X : 0;
>>  req->vcpu_id = v->vcpu_id;
>>
>> +vm_event_fill_regs(req);
>
> I don't think 

[Xen-devel] [xen-4.7-testing test] 100905: tolerable FAIL - PUSHED

[osstest service owner]

flight 100905 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100905/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100813
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100830
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100830
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100830

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  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-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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-amd64-xl-qemut-win7-amd64 16 guest-stop fail 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-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-pvh-intel 11 guest-start  fail  never pass

version targeted for testing:
 xen  038aadd63752baf18b7cc9c7fbec0e5f3aa7c46a
baseline version:
 xen  0c9b94208f91032a06198d10a307d86a66e9f207

Last test of basis   100830  2016-09-08 22:10:57 Z4 days
Failing since100896  2016-09-12 14:15:50 Z0 days2 attempts
Testing same since   100905  2016-09-12 23:40:57 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 

Re: [Xen-devel] BUG_ON() vs ASSERT()

[Mihai Donțu]

On Tue, 13 Sep 2016 09:10:32 -0400 Konrad Rzeszutek Wilk wrote:
> On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote:
> > All,
> > 
> > in
> > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
> > and
> > https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
> > Andrew basically suggests that we should switch away from using
> > ASSERT() and over to BUG_ON() in perhaps quite broad a set of
> > cases. And honestly I'm not convinced of this: We've been adding
> > quite a few ASSERT()s over the last years with the aim of doing
> > sanity checking in debug builds, without adding overhead to non-
> > debug builds. I can certainly see possible cases where using
> > BUG_ON() to prevent further possible damage is appropriate, but
> > I don't think we should overdo here.
> > 
> > Thanks for other's opinions,  
> 
> I am in the mindset that ASSERTS are in the cases where a check
> has been done earlier and the ASSERT is more of a catch if we ended up
> somehow in the wrong state. We can then slowly follow the breadcrumbs to
> see what changed the state. In other words - something that the hypervisor
> has checked for and that invariant should have not changed.
> 
> But a BUG_ON is in the same category - it should not have happend.
> 
> Perhaps the distinction is that for ASSERTS() it is to catch me messing
> things up. While BUG_ON() is something (or somebody) else messing things up.
> 
> It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now
> that I think of it ..

I would see ASSERT() used to check for conditions that have immediate
and visible consequences, like the ones that lead to lack of
functionality (like a hw feature misdetection) or straight crashes
(like NULL-dereference). BUG_ON(), on the other hand, would be an early
warning for subtle corruptions that can lead to a hypervisor crash or
corrupted data after many hours of use (close to impossible to track
down).

For example, a while ago I posted a small patch that would BUG_ON()
when it detected that the heap chunks were not properly linked. That's
the type of bug that's a pain to detect.

-- 
Mihai Donțu

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

Re: [Xen-devel] OVMF for Xen PVH

[Anthony PERARD]

On Thu, Sep 08, 2016 at 12:24:46PM +0200, Laszlo Ersek wrote:
> On 09/08/16 11:38, Anthony PERARD wrote:
> > Hello,
> > 
> > We are introducing a new virtualisation mode in Xen called PVHv2 (also
> > called hvmlite in the past). We would like to have a UEFI firmware
> > running on it to make it easier to start a guest. (Right now, I think it
> > involves supplying the guest kernel to the guest config, like a PV
> > guest.)
> > 
> > I'm exploring different possibility of what could be done, and what
> > should be avoided. It would be nice to have only one binary for both
> > PVHv2 guest and HVM guest.
> > 
> > Would it be possible to introduce a different entry point in OVMF? The
> > current one cannot be used at the start of the day of a PVHv2 guest.
> > 
> > If not, we'll try to use the current entry point or create a new package
> > like it has been done for Xen on ARM.
> > 
> > Thanks for any feedback,
> > 
> 
> I've been thinking about having a shared OVMF binary for Xen and
> QEMU/KVM (from a different perspective), and I did recall that ArmVirt
> has separate platform DSCs / FDFs for Xen and QEMU.

Right now, I can already use the same OVMF binary for both KVM and Xen
HVM on x86.

> The question that made me think about this is the number and size of
> modules that we now build into the OVMF binary. The binary has been
> continuously growing (internally), and while Ard did some fantastic work
> on enabling -Os for a bunch of edk2 compilers and platforms, the
> compressed size (= the ultimate utilization of the flash chip) has not
> gone down significantly, if I recall correctly.
> 
> Growing the non-compressed DXEFV (which -Os mitigates significantly) is
> not terribly hard, as long as we don't outgrow OVMF_CODE.fd (1920 KB),
> i.e., the external thingy after compression. Outgrowing OVMF_CODE.fd
> might be major pain for distros however, so I've been thinking about
> trimming the builds statically.
> 
> There's some low hanging fruit for that; for example the virtio drivers
> should only go into the qemu/KVM build, same for the SMM driver stack,
> same for the pflash driver. Whereas the XenPV drivers, the FS-based
> varstore emulation, etc should go only into the Xen build.
> 
> So, from this (independent) POV, I'd prefer separate builds for Xen and
> qemu/KVM.

Yes, that might be an issue. We are going to need an extra module for
PV network if we want to boot from network in an environment where
there is no QEMU, so no emulated NIC.

> Regarding the entry point itself, the SMM work has complicated those
> early (= SEC / PEI) modules quite a bit (for example, grep OvmfPkg for
> "PcdSmmSmramRequire"). I think if you start with a separate platform,
> that will make your work easier (giving you more freedom in
> accommodating both PVHv2 and HVM, without regard to qemu/KVM), and allow
> me to keep my sanity -- think regressions, reviews, etc :)
> 
> Here's another point I've been thinking about, on-and-off: I find it
> regrettable that we don't have any official co-maintainer in
> Maintainers.txt for OvmfPkg's Xen parts. We've regressed Xen a few times
> in the past because none of the OvmfPkg co-maintainers run Xen. This
> should certainly be fixed.

Well, we do have our CI loop (osstest) running upstream OVMF with Xen,
but it still needs someone to look at the result. I usually try to keep
an eye on them.

> Now, if you create a new platform (DSC + FDF) for Xen, that sort of
> forces someone from the Xen community to assume co-maintainership for
> the Xen bits. (Hopefully those bits would be easily identifiable by
> pathname.) I'd welcome that *very much*.
> 
> So, I prefer a separate platform. I'd suggest to extract the Xen
> platform with the current functionality first (with all those additional
> benefits), then rework the new Xen platform to accommodate PVHv2 as well
> (possibly with different Sec / PlatformPei modules etc).
> 
> Do wait for feedback from Jordan please.

I'll wait.

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 23/38] arm/p2m: Cosmetic fixes -- __p2m_get_mem_access

[Julien Grall]

On 13/09/16 14:42, Sergej Proskurin wrote:

Hi Julien,


On 09/13/2016 03:30 PM, Julien Grall wrote:



On 13/09/16 14:27, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,



On 09/12/2016 10:53 AM, Julien Grall wrote:

Hello Sergej,

On 16/08/2016 23:16, Sergej Proskurin wrote:

This commit extends the function prototypes of the functions:
* __p2m_get_mem_access
* p2m_mem_access_check_and_get_page

We extend the function prototype of "__p2m_get_mem_access" to hold an
argument of type "struct p2m_domain*", as we need to distinguish
between
the host's p2m and different altp2m views. While doing so, we
needed to
extend the function's prototype of "p2m_mem_access_check_and_get_page"
to hold an argument of type "struct vcpu*".


Please details in the commit message why it is necessary to pass a
"struct vcpu *" to p2m_mem_access_check_and_get_page.



Actually, it is already sufficient to provide a "struct domain *".
Thanks for the hint. I will extend the commit message in the next patch
accordingly.


No it is not, the stage-1 page table (VTTBR0, VTTBR1...) are per-vCPU
and if the current vCPU is not the correct one, you will have to
context switch few registers before.

It is not handled today, but we should avoid to have a broken interface.


I see. Ok, since it is not really used today, I will state that we will
need the "struct vcpu*" to access vcpu-related registers in the future.
Would that be ok?


I would recommend you to have a think on the problem mentioned in patch 
#24 first. You may need the vCPU to fix the bug.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 23/38] arm/p2m: Cosmetic fixes -- __p2m_get_mem_access

[Sergej Proskurin]

Hi Julien,


On 09/13/2016 03:30 PM, Julien Grall wrote:
>
>
> On 13/09/16 14:27, Sergej Proskurin wrote:
>> Hi Julien,
>
> Hello Sergej,
>
>>
>> On 09/12/2016 10:53 AM, Julien Grall wrote:
>>> Hello Sergej,
>>>
>>> On 16/08/2016 23:16, Sergej Proskurin wrote:
 This commit extends the function prototypes of the functions:
 * __p2m_get_mem_access
 * p2m_mem_access_check_and_get_page

 We extend the function prototype of "__p2m_get_mem_access" to hold an
 argument of type "struct p2m_domain*", as we need to distinguish
 between
 the host's p2m and different altp2m views. While doing so, we
 needed to
 extend the function's prototype of "p2m_mem_access_check_and_get_page"
 to hold an argument of type "struct vcpu*".
>>>
>>> Please details in the commit message why it is necessary to pass a
>>> "struct vcpu *" to p2m_mem_access_check_and_get_page.
>>>
>>
>> Actually, it is already sufficient to provide a "struct domain *".
>> Thanks for the hint. I will extend the commit message in the next patch
>> accordingly.
>
> No it is not, the stage-1 page table (VTTBR0, VTTBR1...) are per-vCPU
> and if the current vCPU is not the correct one, you will have to
> context switch few registers before.
>
> It is not handled today, but we should avoid to have a broken interface.

I see. Ok, since it is not really used today, I will state that we will
need the "struct vcpu*" to access vcpu-related registers in the future.
Would that be ok?

Cheers,
~Sergej

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

Re: [Xen-devel] BUG_ON() vs ASSERT()

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Jan
> Beulich
> Sent: 12 September 2016 16:24
> To: xen-devel 
> Subject: [Xen-devel] BUG_ON() vs ASSERT()
> 
> All,
> 
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 09/msg01201.html
> and
> https://lists.xenproject.org/archives/html/xen-devel/2016-
> 09/msg01210.html
> Andrew basically suggests that we should switch away from using
> ASSERT() and over to BUG_ON() in perhaps quite broad a set of cases. And
> honestly I'm not convinced of this: We've been adding quite a few ASSERT()s
> over the last years with the aim of doing sanity checking in debug builds,
> without adding overhead to non- debug builds. I can certainly see possible
> cases where using
> BUG_ON() to prevent further possible damage is appropriate, but I don't
> think we should overdo here.
> 
> Thanks for other's opinions,

If there's a situation where code can survive a 'should not happen' then an 
ASSERT is good to catch the 'should not happen' when debugging, but being 
compiled out in production is fine. If the code is definitely not going to 
survive a 'should not happen' then I think a BUG_ON at the earliest opportunity 
is a good thing because it makes post mortem diagnosis much easier. Clearly 
this does have to be balanced against the cost of calculation of the subject of 
the BUG_ON though.

  Paul

> Jan
> 
> 
> ___
> 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 06/24] xen: credit2: implement yield()

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> When a vcpu explicitly yields it is usually giving
> us an advice of "let someone else run and come back
> to me in a bit."
> 
> Credit2 isn't, so far, doing anything when a vcpu
> yields, which means an yield is basically a NOP (well,
> actually, it's pure overhead, as it causes the scheduler
> kick in, but the result is --at least 99% of the time--
> that the very same vcpu that yielded continues to run).
> 
> Implement a "preempt bias", to be applied to yielding
> vcpus. Basically when evaluating what vcpu to run next,
> if a vcpu that has just yielded is encountered, we give
> it a credit penalty, and check whether there is anyone
> else that would better take over the cpu (of course,
> if there isn't the yielding vcpu will continue).
> 
> The value of this bias can be configured with a boot
> time parameter, and the default is set to 1 ms.
> 
> Also, add an yield performance counter, and fix the
> style of a couple of comments.
> 
> Signed-off-by: Dario Faggioli 

Cool!  A few comments...

> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
> Note that this *only* consider the bias during the very scheduling decision
> that retults from the vcpu calling yield. After that, the __CSFLAG_vcpu_yield
> flag is reset, and during all furute scheduling decisions, the vcpu will
> compete with the other ones with its own amount of credits.
> 
> Alternatively, we can actually _subtract_ some credits to a yielding vcpu.
> That will sort of make the effect of a call to yield last in time.

But normally we want the yield to be temporary, right?  The kinds of
places it typically gets called is when the vcpu is waiting for a
spinlock held by another (probably pre-empted) vcpu.  Doing a permanent
credit subtraction will bias the credit algorithm against cpus that have
a high amount of spinlock contention (since probably all the vcpus will
be calling yield pretty regularly)

> I'm not sure which path is best. Personally, I like the subtract approach
> (perhaps, with a smaller bias than 1ms), but I think the "one shot" behavior
> implemented here is a good starting point. It is _something_, which is better
> than nothing, which is what we have without this patch! :-) It's lightweight
> (in its impact on the crediting algorithm, I mean), and benchmarks looks nice,
> so I propose we go for this one, and explore the "permanent" --subtraction
> based-- solution a bit more.

Yes, this is simple and should be effective for now.  We can look at
improving it later.

> ---
>  docs/misc/xen-command-line.markdown |   10 ++
>  xen/common/sched_credit2.c  |   62 
> +++
>  xen/common/schedule.c   |2 +
>  xen/include/xen/perfc_defn.h|1 +
>  4 files changed, 68 insertions(+), 7 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index 3a250cb..5f469b1 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1389,6 +1389,16 @@ Choose the default scheduler.
>  ### sched\_credit2\_migrate\_resist
>  > `= `
>  
> +### sched\_credit2\_yield\_bias
> +> `= `
> +
> +> Default: `1000`
> +
> +Set how much a yielding vcpu will be penalized, in order to actually
> +give a chance to run to some other vcpu. This is basically a bias, in
> +favour of the non-yielding vcpus, expressed in microseconds (default
> +is 1ms).

Probably add _us to the end to indicate that the number is in microseconds.

> @@ -2247,10 +2267,22 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>  struct list_head *iter;
>  struct csched2_vcpu *snext = NULL;
>  struct csched2_private *prv = CSCHED2_PRIV(per_cpu(scheduler, cpu));
> +int yield_bias = 0;
>  
>  /* Default to current if runnable, idle otherwise */
>  if ( vcpu_runnable(scurr->vcpu) )
> +{
> +/*
> + * The way we actually take yields into account is like this:
> + * if scurr is yielding, when comparing its credits with other
> + * vcpus in the runqueue, act like those other vcpus had yield_bias
> + * more credits.
> + */
> +if ( unlikely(scurr->flags & CSFLAG_vcpu_yield) )
> +yield_bias = CSCHED2_YIELD_BIAS;
> +
>  snext = scurr;
> +}
>  else
>  snext = CSCHED2_VCPU(idle_vcpu[cpu]);
>  
> @@ -2268,6 +2300,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>  list_for_each( iter, >runq )
>  {
>  struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, 
> runq_elem);
> +int svc_credit = svc->credit + yield_bias;

Just curious, why did you decide to add yield_bias to everyone else,
rather than just subtracting it from snext->credit?

>  
>  /* Only consider vcpus that are 

Re: [Xen-devel] [PATCH v3 23/38] arm/p2m: Cosmetic fixes -- __p2m_get_mem_access

[Julien Grall]

On 13/09/16 14:27, Sergej Proskurin wrote:

Hi Julien,


Hello Sergej,



On 09/12/2016 10:53 AM, Julien Grall wrote:

Hello Sergej,

On 16/08/2016 23:16, Sergej Proskurin wrote:

This commit extends the function prototypes of the functions:
* __p2m_get_mem_access
* p2m_mem_access_check_and_get_page

We extend the function prototype of "__p2m_get_mem_access" to hold an
argument of type "struct p2m_domain*", as we need to distinguish between
the host's p2m and different altp2m views. While doing so, we needed to
extend the function's prototype of "p2m_mem_access_check_and_get_page"
to hold an argument of type "struct vcpu*".


Please details in the commit message why it is necessary to pass a
"struct vcpu *" to p2m_mem_access_check_and_get_page.



Actually, it is already sufficient to provide a "struct domain *".
Thanks for the hint. I will extend the commit message in the next patch
accordingly.


No it is not, the stage-1 page table (VTTBR0, VTTBR1...) are per-vCPU 
and if the current vCPU is not the correct one, you will have to context 
switch few registers before.


It is not handled today, but we should avoid to have a broken interface.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 23/38] arm/p2m: Cosmetic fixes -- __p2m_get_mem_access

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 10:53 AM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/2016 23:16, Sergej Proskurin wrote:
>> This commit extends the function prototypes of the functions:
>> * __p2m_get_mem_access
>> * p2m_mem_access_check_and_get_page
>>
>> We extend the function prototype of "__p2m_get_mem_access" to hold an
>> argument of type "struct p2m_domain*", as we need to distinguish between
>> the host's p2m and different altp2m views. While doing so, we needed to
>> extend the function's prototype of "p2m_mem_access_check_and_get_page"
>> to hold an argument of type "struct vcpu*".
>
> Please details in the commit message why it is necessary to pass a
> "struct vcpu *" to p2m_mem_access_check_and_get_page.
>

Actually, it is already sufficient to provide a "struct domain *".
Thanks for the hint. I will extend the commit message in the next patch
accordingly.

Cheers,
~Sergej


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

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Julien Grall]

On 13/09/16 14:12, Peng Fan wrote:

Hi Julien,
On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote:

Hello Peng,

On 13/09/16 13:55, Peng Fan wrote:

On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.

Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
to xen. It means how much memory user would like to be allocated
in lower 4GB memory space. If there is not enough memory for
dom0_lowmem, higher memory will be allocated.

Thinking such a memory layout on an AArch64 SoC:
Region 0: 2GB(0x8000 - 0x)
Region 1: 4GB(0x88000 - 0x97fff)
If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
This patch not tested on latest 4.8-unstable, I only tested similar
patch on xen 4.7 on AArch64 platform.


Please test any patch send upstream on 4.8-unstable. The code may have
changed.


I have rebase this patch based on 4.8-unstable.
latest commit:
"
commit a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
Author: Tamas K Lengyel 
Date:   Mon Aug 1 11:59:14 2016 -0600

arm/vm_event: get/set registers
"

Since I have not rebased my platform patches to 4.8-unstable, so have not 
tested.

Please kindly comments whether introudcing "dom0_lowmem" is acceptable or not
to resolve the issue I met in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html.

I'll rebase my platform patches and do some test.





The idea of patch is that user could specify the lowmem that user would
like to use. I rethought the ideas in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
but that is not good. lowmem is precise, it maybe used for some IPs that maybe
passthrough to DomU, so we only allocate the needed memory for Dom0.


Why? IPs passthrough to DomU will have to be protected by an SMMU so it does
not matter whether Dom0 is using all the lowmem or not.


I just think there maybe some cases that some physical memory need to be
reserved for DomU usage.
SMMU is not a must when we passthrough a non DMA capable device to DomU.
So I think an DRAM area can be encoded in dts, and passthrough to DomU.


How do you make sure that DomU will program the device with the correct 
address? A malicious DomU could decide to use a physical address 
belonging to another DomU or even Xen and would be able to read/write on it.


So if a device needs to access the physical memory it either needs to be 
protected by an SMMU or Xen/DOM0 is programming the device on behalf of 
the guest. All other solutions are IHMO unsafe.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan]

Hi Julien,
On Tue, Sep 13, 2016 at 01:59:01PM +0100, Julien Grall wrote:
>Hello Peng,
>
>On 13/09/16 13:55, Peng Fan wrote:
>>On AArch64 SoCs, some IPs may only have the capability to access
>>32bits address space. The physical memory assigned for Dom0 maybe
>>not in 4GB address space, then the IPs will not work properly.
>>
>>Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
>>to xen. It means how much memory user would like to be allocated
>>in lower 4GB memory space. If there is not enough memory for
>>dom0_lowmem, higher memory will be allocated.
>>
>>Thinking such a memory layout on an AArch64 SoC:
>>Region 0: 2GB(0x8000 - 0x)
>>Region 1: 4GB(0x88000 - 0x97fff)
>>If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
>>in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.
>>
>>Signed-off-by: Peng Fan 
>>Cc: Stefano Stabellini 
>>Cc: Julien Grall 
>>---
>>
>>This patch is to resolve the issue mentioned in
>>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
>>This patch not tested on latest 4.8-unstable, I only tested similar
>>patch on xen 4.7 on AArch64 platform.
>
>Please test any patch send upstream on 4.8-unstable. The code may have
>changed.

I have rebase this patch based on 4.8-unstable.
latest commit:
"
commit a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc
Author: Tamas K Lengyel 
Date:   Mon Aug 1 11:59:14 2016 -0600

arm/vm_event: get/set registers
"

Since I have not rebased my platform patches to 4.8-unstable, so have not 
tested.

Please kindly comments whether introudcing "dom0_lowmem" is acceptable or not
to resolve the issue I met in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html.

I'll rebase my platform patches and do some test.

>
>>
>>The idea of patch is that user could specify the lowmem that user would
>>like to use. I rethought the ideas in 
>>https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
>>but that is not good. lowmem is precise, it maybe used for some IPs that maybe
>>passthrough to DomU, so we only allocate the needed memory for Dom0.
>
>Why? IPs passthrough to DomU will have to be protected by an SMMU so it does
>not matter whether Dom0 is using all the lowmem or not.

I just think there maybe some cases that some physical memory need to be
reserved for DomU usage.
SMMU is not a must when we passthrough a non DMA capable device to DomU.
So I think an DRAM area can be encoded in dts, and passthrough to DomU.

Thanks,
Peng.
>
>Regards,
>
>>
>> xen/arch/arm/domain_build.c | 30 +-
>> 1 file changed, 29 insertions(+), 1 deletion(-)
>>
>>diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>>index 35ab08d..0f53bba 100644
>>--- a/xen/arch/arm/domain_build.c
>>+++ b/xen/arch/arm/domain_build.c
>>@@ -33,6 +33,8 @@ int dom0_11_mapping = 1;
>>
>> #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
>> static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
>>+/* Only for AArch64 */
>>+static u64 __initdata dom0_lowmem;
>>
>> static void __init parse_dom0_mem(const char *s)
>> {
>>@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s)
>> }
>> custom_param("dom0_mem", parse_dom0_mem);
>>
>>+static void __init parse_dom0_lowmem(const char *s)
>>+{
>>+dom0_lowmem = parse_size_and_unit(s, );
>>+}
>>+custom_param("dom0_lowmem", parse_dom0_lowmem);
>>+
>> //#define DEBUG_11_ALLOCATION
>> #ifdef DEBUG_11_ALLOCATION
>> # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
>>@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>> unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
>> int i;
>>
>>-bool_t lowmem = is_32bit_domain(d);
>>+bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem;
>> unsigned int bits;
>>
>> /*
>>@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>>  * First try and allocate the largest thing we can as low as
>>  * possible to be bank 0.
>>  */
>>+if ( dom0_lowmem )
>>+order = get_order_from_bytes(dom0_lowmem);
>>+
>> while ( order >= min_low_order )
>> {
>> for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
>>@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>>
>>  got_bank0:
>>
>>+if ( dom0_lowmem ) {
>>+dom0_lowmem -= pfn_to_paddr((1 << order));
>>+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
>>+}
>>+
>> if ( !insert_11_bank(d, kinfo, pg, order) )
>> BUG(); /* Cannot fail for first bank */
>>
>>@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct 
>>kernel_info *kinfo)
>> }
>> }
>>
>>+if ( dom0_lowmem && lowmem )
>>+{
>>+dom0_lowmem -= pfn_to_paddr((1 << order));

Re: [Xen-devel] BUG_ON() vs ASSERT()

[Konrad Rzeszutek Wilk]

On Mon, Sep 12, 2016 at 09:23:41AM -0600, Jan Beulich wrote:
> All,
> 
> in
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01201.html
> and
> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01210.html
> Andrew basically suggests that we should switch away from using
> ASSERT() and over to BUG_ON() in perhaps quite broad a set of
> cases. And honestly I'm not convinced of this: We've been adding
> quite a few ASSERT()s over the last years with the aim of doing
> sanity checking in debug builds, without adding overhead to non-
> debug builds. I can certainly see possible cases where using
> BUG_ON() to prevent further possible damage is appropriate, but
> I don't think we should overdo here.
> 
> Thanks for other's opinions,

I am in the mindset that ASSERTS are in the cases where a check
has been done earlier and the ASSERT is more of a catch if we ended up
somehow in the wrong state. We can then slowly follow the breadcrumbs to
see what changed the state. In other words - something that the hypervisor
has checked for and that invariant should have not changed.

But a BUG_ON is in the same category - it should not have happend.

Perhaps the distinction is that for ASSERTS() it is to catch me messing
things up. While BUG_ON() is something (or somebody) else messing things up.

It is kind of hard to describe the semantic of an ASSERT vs BUG_ON now
that I think of it ..

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

[Xen-devel] [distros-debian-snapshot test] 67704: regressions - FAIL

[Platform Team regression test user]

flight 67704 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67704/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-i386-current-netinst-pygrub 10 guest-start fail REGR. vs. 
67647

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 67647
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
67647
 test-amd64-i386-i386-daily-netboot-pvgrub  9 debian-di-install fail like 67647
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 67647
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail like 67647
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail like 67647
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 67647
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 67647
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail like 67647

baseline version:
 flight   67647

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

Hi Julien,

On 2016/9/13 19:56, Julien Grall wrote:
> Hi Shannon,
> 
> On 02/09/16 03:55, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU non-RAM memory map space and
>> passes them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from linux master or:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>>
>> The UEFI binary could be fetched from or built from edk2 master branch:
>> http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
> 
> On which commit this EFI binary is based? I am trying to rebuild myself,
> and go no luck to boot it so far.
> 
I forgot the exact commit. But I just tried below commit which adds the
support to edk2 and the guest can boot up successfully with ACPI.

402dde6 ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen ARM

Thanks,
-- 
Shannon


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

[Xen-devel] [xen-unstable-smoke test] 100924: tolerable all pass - PUSHED

[osstest service owner]

flight 100924 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100924/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 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  773522000cc17f6f4323a4d97423790138ea98f2
baseline version:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61

Last test of basis   100891  2016-09-12 11:01:22 Z1 days
Testing same since   100924  2016-09-13 11:01:31 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 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=773522000cc17f6f4323a4d97423790138ea98f2
+ . ./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 
773522000cc17f6f4323a4d97423790138ea98f2
+ branch=xen-unstable-smoke
+ revision=773522000cc17f6f4323a4d97423790138ea98f2
+ . ./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.7-testing
+ '[' x773522000cc17f6f4323a4d97423790138ea98f2 = 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.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v3 19/38] arm/p2m: Add HVMOP_altp2m_switch_p2m

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 10:47 AM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/2016 23:16, Sergej Proskurin wrote:
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v3: Extended the function "altp2m_switch_domain_altp2m_by_id" so that if
>> the guest domain indirectly calles this function, the current
>> vcpu also
>> changes the altp2m view without performing an explicit context
>> switch.
>>
>> Exchanged the check "altp2m_vttbr[idx] == INVALID_VTTBR" for
>> "altp2m_p2m[idx] == NULL" in "altp2m_switch_domain_altp2m_by_id".
>> ---
>>  xen/arch/arm/altp2m.c| 48
>> 
>>  xen/arch/arm/hvm.c   |  2 +-
>>  xen/include/asm-arm/altp2m.h |  4 
>>  3 files changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
>> index c14ab0b..ba345b9 100644
>> --- a/xen/arch/arm/altp2m.c
>> +++ b/xen/arch/arm/altp2m.c
>> @@ -32,6 +32,54 @@ struct p2m_domain *altp2m_get_altp2m(struct vcpu *v)
>>  return v->domain->arch.altp2m_p2m[index];
>>  }
>>
>> +int altp2m_switch_domain_altp2m_by_id(struct domain *d, unsigned int
>> idx)
>> +{
>> +struct vcpu *v;
>> +int rc = -EINVAL;
>> +
>> +if ( idx >= MAX_ALTP2M )
>> +return rc;
>> +
>> +domain_pause_except_self(d);
>> +
>> +altp2m_lock(d);
>> +
>> +if ( d->arch.altp2m_p2m[idx] != NULL )
>> +{
>> +for_each_vcpu( d, v )
>> +if ( idx != altp2m_vcpu(v).p2midx )
>
> Could you invert the condition to avoid another layer of nested if?
>

Did you mean checking for (idx == altp2m_vcpu(v).p2midx) and continue
the loop if the condition should be satisfied? If so, then sure thing :)

>> +{
>> +atomic_dec(_get_altp2m(v)->active_vcpus);
>> +altp2m_vcpu(v).p2midx = idx;
>> +atomic_inc(_get_altp2m(v)->active_vcpus);
>> +
>> +/*
>> + * In case it is the guest domain, which indirectly
>> called this
>> + * function, the current vcpu will not switch its
>> context
>> + * within the function "p2m_restore_state". That is,
>> changing
>> + * the altp2m_vcpu(v).p2midx will not lead to the
>> requested
>> + * altp2m switch on that specific vcpu. To achieve
>> the desired
>> + * behavior, we write to VTTBR_EL2 directly.
>> + */
>> +if ( v->domain == d && v == current )
>
> v == current is enough.
>

Ok.

>> +{
>> +struct p2m_domain *ap2m = d->arch.altp2m_p2m[idx];
>> +
>> +WRITE_SYSREG64(ap2m->vttbr, VTTBR_EL2);
>> +isb();
>
> I don't like the open-coding of VTTBR_EL2. I would much prefer a
> separate helper to update it.
>

Sure, I can introduce an UPDATE_VTTBR macro (including the isb call) in
p2m.h and adjust the remaining writes to VTTBR_EL2 in p2m.c as well. I
hope, I understood you correctly.

>> +}
>> +}
>> +
>> +rc = 0;
>> +}
>> +
>> +altp2m_unlock(d);
>> +
>> +domain_unpause_except_self(d);
>> +
>> +return rc;
>> +}
>> +
>>  static void altp2m_vcpu_reset(struct vcpu *v)
>>  {
>>  struct altp2mvcpu *av = _vcpu(v);
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index df973ef..9ac3422 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -132,7 +132,7 @@ static int
>> do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
>>  break;
>>
>>  case HVMOP_altp2m_switch_p2m:
>> -rc = -EOPNOTSUPP;
>> +rc = altp2m_switch_domain_altp2m_by_id(d, a.u.view.view);
>>  break;
>>
>>  case HVMOP_altp2m_set_mem_access:
>> diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
>> index 6074079..c2e44ab 100644
>> --- a/xen/include/asm-arm/altp2m.h
>> +++ b/xen/include/asm-arm/altp2m.h
>> @@ -52,6 +52,10 @@ void altp2m_vcpu_destroy(struct vcpu *v);
>>  /* Get current alternate p2m table. */
>>  struct p2m_domain *altp2m_get_altp2m(struct vcpu *v);
>>
>> +/* Switch alternate p2m for entire domain */
>> +int altp2m_switch_domain_altp2m_by_id(struct domain *d,
>> +  unsigned int idx);
>> +
>>  /* Make a specific alternate p2m valid. */
>>  int altp2m_init_by_id(struct domain *d,
>>unsigned int idx);
>>

Cheers,
~Sergej


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

Re: [Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Julien Grall]

Hello Peng,

On 13/09/16 13:55, Peng Fan wrote:

On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.

Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
to xen. It means how much memory user would like to be allocated
in lower 4GB memory space. If there is not enough memory for
dom0_lowmem, higher memory will be allocated.

Thinking such a memory layout on an AArch64 SoC:
Region 0: 2GB(0x8000 - 0x)
Region 1: 4GB(0x88000 - 0x97fff)
If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
This patch not tested on latest 4.8-unstable, I only tested similar
patch on xen 4.7 on AArch64 platform.


Please test any patch send upstream on 4.8-unstable. The code may have 
changed.




The idea of patch is that user could specify the lowmem that user would
like to use. I rethought the ideas in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
but that is not good. lowmem is precise, it maybe used for some IPs that maybe
passthrough to DomU, so we only allocate the needed memory for Dom0.


Why? IPs passthrough to DomU will have to be protected by an SMMU so it 
does not matter whether Dom0 is using all the lowmem or not.


Regards,



 xen/arch/arm/domain_build.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0f53bba 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -33,6 +33,8 @@ int dom0_11_mapping = 1;

 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+/* Only for AArch64 */
+static u64 __initdata dom0_lowmem;

 static void __init parse_dom0_mem(const char *s)
 {
@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);

+static void __init parse_dom0_lowmem(const char *s)
+{
+dom0_lowmem = parse_size_and_unit(s, );
+}
+custom_param("dom0_lowmem", parse_dom0_lowmem);
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;

-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem;
 unsigned int bits;

 /*
@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  * First try and allocate the largest thing we can as low as
  * possible to be bank 0.
  */
+if ( dom0_lowmem )
+order = get_order_from_bytes(dom0_lowmem);
+
 while ( order >= min_low_order )
 {
 for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)

  got_bank0:

+if ( dom0_lowmem ) {
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+
 if ( !insert_11_bank(d, kinfo, pg, order) )
 BUG(); /* Cannot fail for first bank */

@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 }
 }

+if ( dom0_lowmem && lowmem )
+{
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+   else
+{
+lowmem = false;
+}
+
 /*
  * Success, next time around try again to get the largest order
  * allocation possible.
@@ -2098,6 +2124,8 @@ int construct_dom0(struct domain *d)

 d->max_pages = ~0U;

+BUG_ON(dom0_mem < dom0_lowmem);
+
 kinfo.unassigned_mem = dom0_mem;

 rc = kernel_probe();



--
Julien Grall

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

[Xen-devel] [xen-unstable test] 100902: tolerable FAIL - PUSHED

[osstest service owner]

flight 100902 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100902/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  16 guest-start.2fail in 100893 pass in 100902
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 100893
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail pass in 
100893
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-installfail pass in 100893

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100887
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100887
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100887
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100887
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100887

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail in 100893 
never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass

version targeted for testing:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61
baseline version:
 xen  a3fe74e4345e66ddb7aa514395260a5e5f8b0cdc

Last test of basis   100887  2016-09-12 01:59:02 Z1 days
Testing same since   100893  2016-09-12 12:44:56 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64

[Xen-devel] [RFC] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan]

On AArch64 SoCs, some IPs may only have the capability to access
32bits address space. The physical memory assigned for Dom0 maybe
not in 4GB address space, then the IPs will not work properly.

Introduce dom0_lowmem bootargs, user could pass "dom0_lowmem=xx"
to xen. It means how much memory user would like to be allocated
in lower 4GB memory space. If there is not enough memory for
dom0_lowmem, higher memory will be allocated.

Thinking such a memory layout on an AArch64 SoC:
Region 0: 2GB(0x8000 - 0x)
Region 1: 4GB(0x88000 - 0x97fff)
If user would like to assign 2GB for Dom0 and 1GB of the 2GB memory
in Region 0, user could pass "dom0=2048M dom0_lowmem=1024M" to xen.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

This patch is to resolve the issue mentioned in
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00235.html
This patch not tested on latest 4.8-unstable, I only tested similar
patch on xen 4.7 on AArch64 platform.

The idea of patch is that user could specify the lowmem that user would
like to use. I rethought the ideas in 
https://lists.xen.org/archives/html/xen-devel/2016-09/msg00487.html,
but that is not good. lowmem is precise, it maybe used for some IPs that maybe
passthrough to DomU, so we only allocate the needed memory for Dom0.

 xen/arch/arm/domain_build.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 35ab08d..0f53bba 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -33,6 +33,8 @@ int dom0_11_mapping = 1;
 
 #define DOM0_MEM_DEFAULT 0x800 /* 128 MiB */
 static u64 __initdata dom0_mem = DOM0_MEM_DEFAULT;
+/* Only for AArch64 */
+static u64 __initdata dom0_lowmem;
 
 static void __init parse_dom0_mem(const char *s)
 {
@@ -42,6 +44,12 @@ static void __init parse_dom0_mem(const char *s)
 }
 custom_param("dom0_mem", parse_dom0_mem);
 
+static void __init parse_dom0_lowmem(const char *s)
+{
+dom0_lowmem = parse_size_and_unit(s, );
+}
+custom_param("dom0_lowmem", parse_dom0_lowmem);
+
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
 # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
@@ -244,7 +252,7 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 unsigned int order = get_11_allocation_size(kinfo->unassigned_mem);
 int i;
 
-bool_t lowmem = is_32bit_domain(d);
+bool_t lowmem = is_32bit_domain(d) || !!dom0_lowmem;
 unsigned int bits;
 
 /*
@@ -263,6 +271,9 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
  * First try and allocate the largest thing we can as low as
  * possible to be bank 0.
  */
+if ( dom0_lowmem )
+order = get_order_from_bytes(dom0_lowmem);
+
 while ( order >= min_low_order )
 {
 for ( bits = order ; bits <= (lowmem ? 32 : PADDR_BITS); bits++ )
@@ -278,6 +289,11 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 
  got_bank0:
 
+if ( dom0_lowmem ) {
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+
 if ( !insert_11_bank(d, kinfo, pg, order) )
 BUG(); /* Cannot fail for first bank */
 
@@ -325,6 +341,16 @@ static void allocate_memory(struct domain *d, struct 
kernel_info *kinfo)
 }
 }
 
+if ( dom0_lowmem && lowmem )
+{
+dom0_lowmem -= pfn_to_paddr((1 << order));
+lowmem = is_32bit_domain(d) || !!dom0_lowmem;
+}
+   else
+{
+lowmem = false;
+}
+
 /*
  * Success, next time around try again to get the largest order
  * allocation possible.
@@ -2098,6 +2124,8 @@ int construct_dom0(struct domain *d)
 
 d->max_pages = ~0U;
 
+BUG_ON(dom0_mem < dom0_lowmem);
+
 kinfo.unassigned_mem = dom0_mem;
 
 rc = kernel_probe();
-- 
2.6.6


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

Re: [Xen-devel] [PATCH v3 18/38] arm/p2m: Add HVMOP_altp2m_destroy_p2m

[Sergej Proskurin]

Hi Julien,


On 09/12/2016 10:41 AM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/2016 23:16, Sergej Proskurin wrote:
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Substituted the call to tlb_flush for p2m_flush_table.
>> Added comments.
>> Cosmetic fixes.
>>
>> v3: Changed the locking mechanism to "p2m_write_lock" inside the
>> function "altp2m_destroy_by_id".
>>
>> Do not flush but rather teardown the altp2m in the function
>> "altp2m_destroy_by_id".
>>
>> Exchanged the check "altp2m_vttbr[idx] == INVALID_VTTBR" for
>> "altp2m_p2m[idx] == NULL" in "altp2m_destroy_by_id".
>> ---
>>  xen/arch/arm/altp2m.c| 43
>> +++
>>  xen/arch/arm/hvm.c   |  2 +-
>>  xen/include/asm-arm/altp2m.h |  4 
>>  3 files changed, 48 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
>> index b5d1951..c14ab0b 100644
>> --- a/xen/arch/arm/altp2m.c
>> +++ b/xen/arch/arm/altp2m.c
>> @@ -190,6 +190,49 @@ void altp2m_flush(struct domain *d)
>>  altp2m_unlock(d);
>>  }
>>
>> +int altp2m_destroy_by_id(struct domain *d, unsigned int idx)
>> +{
>> +struct p2m_domain *p2m;
>> +int rc = -EBUSY;
>> +
>> +/*
>> + * The altp2m[0] is considered as the hostp2m and is used as a
>> safe harbor
>> + * to which you can switch as long as altp2m is active. After
>> deactivating
>> + * altp2m, the system switches back to the original hostp2m
>> view. That is,
>> + * altp2m[0] should only be destroyed/flushed/freed, when altp2m is
>> + * deactivated.
>> + */
>> +if ( !idx || idx >= MAX_ALTP2M )
>> +return rc;
>> +
>> +domain_pause_except_self(d);
>> +
>> +altp2m_lock(d);
>> +
>> +if ( d->arch.altp2m_p2m[idx] != NULL )
>> +{
>> +p2m = d->arch.altp2m_p2m[idx];
>> +
>> +if ( !_atomic_read(p2m->active_vcpus) )
>> +{
>> +p2m_write_lock(p2m);
>
> I am not sure why you take the lock here. It will not protect you from
> anything as the p2m will get freed just after. So if someone else is
> using it, it will be in big trouble.
>

I will remove the lock in the next patch, thank you.

>> +p2m_teardown_one(p2m);
>> +p2m_write_unlock(p2m);
>> +
>> +xfree(p2m);
>> +d->arch.altp2m_p2m[idx] = NULL;
>> +
>> +rc = 0;
>> +}
>> +}
>> +
>> +altp2m_unlock(d);
>> +
>> +domain_unpause_except_self(d);
>> +
>> +return rc;
>> +}
>> +
>>  void altp2m_teardown(struct domain *d)
>>  {
>>  unsigned int i;
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index a504dfd..df973ef 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -128,7 +128,7 @@ static int
>> do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
>>  break;
>>
>>  case HVMOP_altp2m_destroy_p2m:
>> -rc = -EOPNOTSUPP;
>> +rc = altp2m_destroy_by_id(d, a.u.view.view);
>>  break;
>>
>>  case HVMOP_altp2m_switch_p2m:
>> diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
>> index 5701012..6074079 100644
>> --- a/xen/include/asm-arm/altp2m.h
>> +++ b/xen/include/asm-arm/altp2m.h
>> @@ -63,4 +63,8 @@ int altp2m_init_next_available(struct domain *d,
>>  /* Flush all the alternate p2m's for a domain. */
>>  void altp2m_flush(struct domain *d);
>>
>> +/* Make a specific alternate p2m invalid */
>> +int altp2m_destroy_by_id(struct domain *d,
>> + unsigned int idx);
>> +
>>  #endif /* __ASM_ARM_ALTP2M_H */
>>

Cheers,
~Sergej

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

[Xen-devel] [xen-4.7-testing bisection] complete build-amd64

[osstest service owner]

branch xen-4.7-testing
xenbranch xen-4.7-testing
job build-amd64
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  129099ba0c2407c32cd7f02011bdf98b8d7cfc0d
  Bug not present: f515565bbae89bda4a1e1c11177fa0e4b32d4776
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/100928/


  commit 129099ba0c2407c32cd7f02011bdf98b8d7cfc0d
  Author: Andrew Cooper 
  Date:   Mon Sep 12 15:56:15 2016 +0200
  
  x86/hvm: Perform a user instruction fetch for a FEP in userspace
  
  This matches hardware behaviour, and prevents erroneous failures when a 
guest
  has SMEP/SMAP active and issues a FEP from userspace.
  
  Signed-off-by: Andrew Cooper 
  Reviewed-by: Jan Beulich 
  master commit: 0831e99446121636045cf6f616a1991d6ef22071
  master date: 2016-09-08 16:39:46 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.7-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.7-testing/build-amd64.xen-build 
--summary-out=tmp/100928.bisection-summary --basis-template=100830 
--blessings=real,real-bisect xen-4.7-testing build-amd64 xen-build
Searching for failure / basis pass:
 100896 fail [host=huxelrebe0] / 100830 [host=godello0] 100813 [host=godello0] 
100777 [host=godello1] 100635 [host=huxelrebe1] 100632 [host=huxelrebe1] 100499 
[host=italia0] 100491 [host=huxelrebe1] 99972 [host=godello1] 99961 
[host=godello1] 99754 [host=godello1] 96660 [host=godello0] 96628 
[host=baroque1] 96002 [host=italia1] 95554 [host=elbling1] 95489 [host=rimava0] 
95446 [host=pinot0] template as basis? using template as basis.
Failure / basis pass flights: 100896 / 100830
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
5c816c70474ada10effe4250b3b5d4779f81fd40
Basis pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
0c9b94208f91032a06198d10a307d86a66e9f207
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#698d6d6f8d095edadb0c23612b552a89dd3eee4c-698d6d6f8d095edadb0c23612b552a89dd3eee4c
 
git://xenbits.xen.org/qemu-xen.git#e927b5f5a809f07b73b063831527c8a87f053933-e927b5f5a809f07b73b063831527c8a87f053933
 
git://xenbits.xen.org/xen.git#0c9b94208f91032a06198d10a307d86a66e9f207-5c816c70474ada10effe4250b3b5d4779f81fd40
Loaded 1001 nodes in revision graph
Searching for test results:
 100830 [host=godello0]
 100829 [host=godello0]
 100813 [host=godello0]
 100842 [host=godello1]
 100896 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
5c816c70474ada10effe4250b3b5d4779f81fd40
 100917 pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
0c9b94208f91032a06198d10a307d86a66e9f207
 100918 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
5c816c70474ada10effe4250b3b5d4779f81fd40
 100919 pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
0c9b94208f91032a06198d10a307d86a66e9f207
 100920 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
5c816c70474ada10effe4250b3b5d4779f81fd40
 100921 pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
f515565bbae89bda4a1e1c11177fa0e4b32d4776
 100922 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
129099ba0c2407c32cd7f02011bdf98b8d7cfc0d
 100925 pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
f515565bbae89bda4a1e1c11177fa0e4b32d4776
 100926 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
129099ba0c2407c32cd7f02011bdf98b8d7cfc0d
 100927 pass 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
f515565bbae89bda4a1e1c11177fa0e4b32d4776
 100928 fail 698d6d6f8d095edadb0c23612b552a89dd3eee4c 
e927b5f5a809f07b73b063831527c8a87f053933 
129099ba0c2407c32cd7f02011bdf98b8d7cfc0d
Searching for interesting versions
 Result found: flight 100917 (pass), for basis pass
 Result found: flight 100918 (fail), for basis failure
 Repro found: flight 100919 (pass), for basis pass
 Repro found: flight 100920 (fail), for basis failure
 0 revisions 

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Julien Grall]

Hi Shannon,

On 02/09/16 03:55, Shannon Zhao wrote:

From: Shannon Zhao 

The design of this feature is described as below.
Firstly, the toolstack (libxl) generates the ACPI tables according the
number of vcpus and gic controller.

Then, it copies these ACPI tables to DomU non-RAM memory map space and
passes them to UEFI firmware through the "ARM multiboot" protocol.

At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
and installs these tables like the usual way and passes both ACPI and DT
information to the Xen DomU.

Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
since it's enough now.

This has been tested using guest kernel with the Dom0 ACPI support
patches which could be fetched from linux master or:
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen

The UEFI binary could be fetched from or built from edk2 master branch:
http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd


On which commit this EFI binary is based? I am trying to rebuild myself, 
and go no luck to boot it so far.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Jan Beulich]

>>> On 13.09.16 at 12:37,  wrote:
> On 12/09/16 15:32, Jan Beulich wrote:
> On 09.09.16 at 17:16,  wrote:
>>> The following code illustrates this idea:
>>>
>>> typedef struct dm_op_buffer {
>>>  XEN_GUEST_HANDLE(void) h;
>>>  size_t len;
>>> } dm_op_buffer_t;
>> 
>> This implies that we'll lose all type safety on the handles passed, as
>> is also emphasized by the use of raw_copy_from_guest() in the code
>> outline further down.
> 
> If most of the time the hypercalls are made by calling libxc functions,
> and the libxc functions have types as arguments, then the end caller has
> the same type safety.  We'll have to be careful inside the individual
> libxc functions, but that should be fairly straightforward to do.  So
> the places where we need to take extra care should be very localized.

My main fear isn't so much to get it wrong the first time round, but
to break things down the road by not adjusting types in all needed
places at once (because the compiler doesn't tell the programmer).

Jan


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

[Xen-devel] [seabios baseline-only test] 67703: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67703 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67703/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67610
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67610
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67610

Tests which did not succeed, but are not blocking:
 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

version targeted for testing:
 seabios  642db1905ab133007d7427b6758a2103fb09a19a
baseline version:
 seabios  f0cdc36d2f2424f6b40438f7ee7cc502c0eff4df

Last test of basis67610  2016-08-30 23:49:28 Z   13 days
Testing same since67703  2016-09-13 03:19:50 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 642db1905ab133007d7427b6758a2103fb09a19a
Author: Kevin O'Connor 
Date:   Mon Sep 5 13:49:18 2016 -0400

post: Map int 0x05 to entry point

int 0x05 was not assigned in the interrupt table - fix that.

Signed-off-by: Kevin O'Connor 

commit 1bdc9aeeaeddd7939522a160abae9331196ce547
Author: Kevin O'Connor 
Date:   Mon Sep 5 13:38:26 2016 -0400

kbd: Generate interrupt events for SysReq, PrtScr, and Break

Generate the appropriate interrupt events for the given keys.

Signed-off-by: Kevin O'Connor 

commit 9feb1eed4668a2d32192164bda89b2fcc22ddbcb
Author: Kevin O'Connor 
Date:   Mon Sep 5 13:05:36 2016 -0400

usb-hid: Generate Ctrl+Break and Alt+SysReq keys

Detect the sequences for generating Ctrl+Break and Alt+SysReq on USB
keyboards and produce the appropriate legacy scancodes.

Signed-off-by: Kevin O'Connor 

commit 6cd69b75ead91fea625951cb7d89ad47e94137d7
Author: Kevin O'Connor 
Date:   Mon Sep 5 11:56:03 2016 -0400

kbd: Ignore fake shift keys

AT keyboards can produce "fake" shift keys on some extended events.
It's not necessary to process these artificial events as the actual
extended keys are detected directly.

Signed-off-by: Kevin O'Connor 

commit fec2140c8601afae0ce997ffa7674d1dbd12de01
Author: Kevin O'Connor 
Date:   Fri Sep 2 20:58:11 2016 -0400

kbd: Move checking for special keys in __process_keys() into switch

Signed-off-by: Kevin 

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Dario Faggioli]

[using xendevel correct address]

On Tue, 2016-09-13 at 16:54 +0800, Wei Yang wrote:
> On Fri, 2016-09-09 at 17:41 +0800, Wei Yang wrote:
> > 
> > I'm not surprised by that. Yet, I'd be interested in hearing more
> > about this profiling you have done (things like, how you captured
> > the data, what workloads you are exactly considering, how you
> > determined what is the bottleneck, etc).
> Let me try to explain this.
> 
> Workload: a. Blue Screen in Windows Guests
>     b. some client using Windows to do some video
> processing
>    which need precise timestamp (we are not sure the
> core
>    reason but we see the system is very slow)
>
Do you mind sharing just a bit more, such as:
 - number of pcpus
 - number of vcpus of the various VMs

I also am not sure what "a. Blue screen in Windows guests" above
means... is there a workload called "Blue Screen"? Or is it that you
are hitting a BSOD in some of your guests (which ones, what were they
doing)? Or is it that you _want_ to provoke a BSOD on some of your
guests? Or is that something else? :-P

> Capture the data: lock profile
> Bottleneck Check: The schedule lock wait time is really high  
> 
Ok, cool. Interesting that lock profiling works on 4.1! :-O

> > The scheduler tries to see whether the v->processor of the waking
> > vcpu can be re-used, but that's not at all guaranteed, and again,
> > on a very loaded system, not even that likely!
> > 
> Hmm... I may missed something.
> 
> Took your assumption below for example. 
> In my mind, the process looks like this:
> 
> csched_vcpu_wake()
> __runq_insert(),  insert the vcpu in pcpu's 6 runq
> __runq_tickle(),  raise SCHEDULE_SOFTIRQ on pcpu 6 or other
> (1)
> 
Well, yes. More precisely, at least in current staging,
SCHEDULE_SOFTIRQ is raised for pcpu 6:
 - if pcpu 6 is idle, or
 - if pcpu 6 is not idle but there actually isn't any idle vcpu, and
   the waking vcpu is higher in priority than what is running on pcpu 6

> __do_softirq()
> schedule()
> csched_schedule(),  for pcpu 6, it may wake up d2v2 based
> on it's
> priority
>
Yes, but it is pcpu 6 that will run csched_schedule() only if the
conditions mentioned above are met. If not, it will be some other pcpu
that will do so (or none!).

But I just realized that the fact that you are actually working on 4.1
is going to be an issue. In fact, the code that it is now in Xen has
changed **a lot** since 4.1. In fact, you're missing all the soft-
affinity work (which you may or may not find useful) but also
improvements and bugfixing.

I'll have a quick look at how __runq_tickle() looks like in Xen 4.1,
but there's very few chances I'll be available to provide detailed
review, advice, testing, etc., on such an old codebase. :-(

> By looking at the code, what I missed may be in __runq_tickle(),
> which in case
> there are idle pcpu, schedule_softirq is also raised on them. By
> doing so,
> those idle pcpus would steal other busy tasks and may in chance get
> d2v2?
> 
Yes, it looks like, in Xen 4.1, this is more or less what happens. The
idea is to always tickle pcpu 6, if the priority of the waking vcpu is
higher than what is running there. 

If pcpu 6 was not idle, we also tickle one or more idle pcpus so that:
 - if the waking vcpu preempted what was running on pcpu 6, an idler
   can pick-up ("steal") such preempted vcpu and run it;
 - if the waking vcpu ended up in the runqueue, an idler can steal it

> BTW, if the system is in heavy load, how much chance would we have
> idle pcpu?
> 
It's not very likely that there will be idle pcpus in a very busy
system, I agree.

> > > We can divide this in three steps:
> > > a) Send IPI to the target CPU and tell it which vcpu we want it
> > > to 
> > > wake up.
> > > b) The interrupt handler on target cpu insert vcpu to a percpu
> > > queue 
> > > and raise
> > >    softirq.
> > > c) softirq will dequeue the vcpu and wake it up.
> > > 
> > I'm not sure I see how you think this would improve the situation.
> > 
> > So, quickly, right now:
> > 
> > - let's say vcpu 2 of domain 2 (from now d2v2) is waking up
> > - let's assume d2v2->processor = 6
> > - let's assume the wakeup is happening on pcpu 4
> > 
> > Right now:
> > 
> > - on pcpu 4, vcpu_wake(d2v2) takes the scheduler lock of d2v2,
> >   which is the runqueue lock of pcpu 6 (in Credit1, there is 1
> >   runqueue per pcpu, and locks are per-cpu already)
> > - in csched_vcpu_wake(d2v2), d2v2 is inserted in pcpu's 6 runqueue
> > - still executing on pcpu 4, __runq_tickle() is called, and it
> >   determines on which pcpu d2v2 should run
> > - it raises the SCHEDULE_SOFTIRQ for such pcpu. Let's look at the
> >   following two cases:
> >    a) if it was determined that d2v2 should run on pcpu 6:
> >    - in a (little, hopefully) while, pcpu 6 will schedule
> >    - it takes its own runqueue lock
> >    - it finds d2v2 

Re: [Xen-devel] [PATCH 05/24] xen: credit2: make tickling more deterministic

[George Dunlap]

On 17/08/16 18:18, Dario Faggioli wrote:
> Right now, the following scenario can occurr:
>  - upon vcpu v wakeup, v itself is put in the runqueue,
>and pcpu X is tickled;
>  - pcpu Y schedules (for whatever reason), sees v in
>the runqueue and picks it up.
> 
> This may seem ok (or even a good thing), but it's not.
> In fact, if runq_tickle() decided X is where v should
> run, it did it for a reason (load distribution, SMT
> support, cache hotness, affinity, etc), and we really
> should try as hard as possible to stick to that.
> 
> Of course, we can't be too strict, or we risk leaving
> vcpus in the runqueue while there is available CPU
> capacity. So, we only leave v in runqueue --for X to
> pick it up-- if we see that X has been tickled and
> has not scheduled yet, i.e., it will have a real chance
> of actually select and schedule v.
> 
> If that is not the case, we schedule it on Y (or, at
> least, we consider that), as running somewhere non-ideal
> is better than not running at all.
> 
> The commit also adds performance counters for each of
> the possible situations.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Anshul Makkar 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/common/sched_credit2.c   |   65 
> +++---
>  xen/include/xen/perfc_defn.h |3 ++
>  2 files changed, 64 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 12dfd20..a3d7beb 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -54,6 +54,7 @@
>  #define TRC_CSCHED2_LOAD_CHECK   TRC_SCHED_CLASS_EVT(CSCHED2, 16)
>  #define TRC_CSCHED2_LOAD_BALANCE TRC_SCHED_CLASS_EVT(CSCHED2, 17)
>  #define TRC_CSCHED2_PICKED_CPU   TRC_SCHED_CLASS_EVT(CSCHED2, 19)
> +#define TRC_CSCHED2_RUNQ_CANDIDATE   TRC_SCHED_CLASS_EVT(CSCHED2, 20)
>  
>  /*
>   * WARNING: This is still in an experimental phase.  Status and work can be 
> found at the
> @@ -398,6 +399,7 @@ struct csched2_vcpu {
>  int credit;
>  s_time_t start_time; /* When we were scheduled (used for credit) */
>  unsigned flags;  /* 16 bits doesn't seem to play well with 
> clear_bit() */
> +int tickled_cpu; /* cpu tickled for picking us up (-1 if none) */
>  
>  /* Individual contribution to load */
>  s_time_t load_last_update;  /* Last time average was updated */
> @@ -1049,6 +1051,10 @@ runq_tickle(const struct scheduler *ops, struct 
> csched2_vcpu *new, s_time_t now)
>  __cpumask_set_cpu(ipid, >tickled);
>  smt_idle_mask_clear(ipid, >smt_idle);
>  cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
> +
> +if ( unlikely(new->tickled_cpu != -1) )
> +SCHED_STAT_CRANK(tickled_cpu_overwritten);
> +new->tickled_cpu = ipid;
>  }
>  
>  /*
> @@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
> vcpu *vc, void *dd)
>  ASSERT(svc->sdom != NULL);
>  svc->credit = CSCHED2_CREDIT_INIT;
>  svc->weight = svc->sdom->weight;
> +svc->tickled_cpu = -1;
>  /* Starting load of 50% */
>  svc->avgload = 1ULL << (CSCHED2_PRIV(ops)->load_precision_shift - 1);
>  svc->load_last_update = NOW() >> LOADAVG_GRANULARITY_SHIFT;
> @@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
> vcpu *vc, void *dd)
>  else
>  {
>  ASSERT(svc->sdom == NULL);
> +svc->tickled_cpu = svc->vcpu->vcpu_id;
>  svc->credit = CSCHED2_IDLE_CREDIT;
>  svc->weight = 0;
>  }
> @@ -2233,7 +2241,8 @@ void __dump_execstate(void *unused);
>  static struct csched2_vcpu *
>  runq_candidate(struct csched2_runqueue_data *rqd,
> struct csched2_vcpu *scurr,
> -   int cpu, s_time_t now)
> +   int cpu, s_time_t now,
> +   unsigned int *pos)

I think I'd prefer if this were called "skipped" or something like that
-- to indicate how many vcpus in the runqueue had been skipped before
coming to this one.

>  {
>  struct list_head *iter;
>  struct csched2_vcpu *snext = NULL;
> @@ -2262,13 +2271,29 @@ runq_candidate(struct csched2_runqueue_data *rqd,
>  
>  /* Only consider vcpus that are allowed to run on this processor. */
>  if ( !cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity) )
> +{
> +(*pos)++;
>  continue;
> +}
> +
> +/*
> + * If a vcpu is meant to be picked up by another processor, and such
> + * processor has not scheduled yet, leave it in the runqueue for him.
> + */
> +if ( svc->tickled_cpu != -1 && svc->tickled_cpu != cpu &&
> + cpumask_test_cpu(svc->tickled_cpu, >tickled) )
> +{
> +(*pos)++;
> +SCHED_STAT_CRANK(deferred_to_tickled_cpu);
> +

Re: [Xen-devel] [PATCH 05/24] xen: credit2: make tickling more deterministic

[George Dunlap]

On 05/09/16 14:47, Dario Faggioli wrote:
> On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:
>> On 17/08/16 18:18, Dario Faggioli wrote:
>>>
>>> Right now, the following scenario can occurr:
>>>   - upon vcpu v wakeup, v itself is put in the runqueue,
>>> and pcpu X is tickled;
>>>   - pcpu Y schedules (for whatever reason), sees v in
>>> the runqueue and picks it up.
>>>
>>> This may seem ok (or even a good thing), but it's not.
>>> In fact, if runq_tickle() decided X is where v should
>>> run, it did it for a reason (load distribution, SMT
>>> support, cache hotness, affinity, etc), and we really
>>> should try as hard as possible to stick to that.
>>>
>>> Of course, we can't be too strict, or we risk leaving
>>> vcpus in the runqueue while there is available CPU
>>> capacity. So, we only leave v in runqueue --for X to
>>> pick it up-- if we see that X has been tickled and
>>> has not scheduled yet, i.e., it will have a real chance
>>> of actually select and schedule v.
>>>
>>> If that is not the case, we schedule it on Y (or, at
>>> least, we consider that), as running somewhere non-ideal
>>> is better than not running at all.
>>>
>>> The commit also adds performance counters for each of
>>> the possible situations.
>>>
>>> Signed-off-by: Dario Faggioli 
>>> ---
>>> Cc: George Dunlap 
>>> Cc: Anshul Makkar 
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> ---
>>>   xen/common/sched_credit2.c   |   65
>>> +++---
>>>   xen/include/xen/perfc_defn.h |3 ++
>>>   2 files changed, 64 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/xen/common/sched_credit2.c
>>> b/xen/common/sched_credit2.c
>>> index 12dfd20..a3d7beb 100644
>>> --- a/xen/common/sched_credit2.c
>>> +++ b/xen/common/sched_credit2.c
>>> @@ -54,6 +54,7 @@
>>>   #define TRC_CSCHED2_LOAD_CHECK   TRC_SCHED_CLASS_EVT(CSCHED2,
>>> 16)
>>>   #define TRC_CSCHED2_LOAD_BALANCE TRC_SCHED_CLASS_EVT(CSCHED2,
>>> 17)
>>>   #define TRC_CSCHED2_PICKED_CPU   TRC_SCHED_CLASS_EVT(CSCHED2,
>>> 19)
>>> +#define TRC_CSCHED2_RUNQ_CANDIDATE   TRC_SCHED_CLASS_EVT(CSCHED2,
>>> 20)
>>>
>>>   /*
>>>* WARNING: This is still in an experimental phase.  Status and
>>> work can be found at the
>>> @@ -398,6 +399,7 @@ struct csched2_vcpu {
>>>   int credit;
>>>   s_time_t start_time; /* When we were scheduled (used for
>>> credit) */
>>>   unsigned flags;  /* 16 bits doesn't seem to play well
>>> with clear_bit() */
>>> +int tickled_cpu; /* cpu tickled for picking us up (-1 if
>>> none) */
>>>
>>>   /* Individual contribution to load */
>>>   s_time_t load_last_update;  /* Last time average was updated
>>> */
>>> @@ -1049,6 +1051,10 @@ runq_tickle(const struct scheduler *ops,
>>> struct csched2_vcpu *new, s_time_t now)
>>>   __cpumask_set_cpu(ipid, >tickled);
>>>   smt_idle_mask_clear(ipid, >smt_idle);
>>>   cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
>>> +
>>> +if ( unlikely(new->tickled_cpu != -1) )
>>> +SCHED_STAT_CRANK(tickled_cpu_overwritten);
>>> +new->tickled_cpu = ipid;
>>>   }
>>>
>>>   /*
>>> @@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler
>>> *ops, struct vcpu *vc, void *dd)
>>>   ASSERT(svc->sdom != NULL);
>>>   svc->credit = CSCHED2_CREDIT_INIT;
>>>   svc->weight = svc->sdom->weight;
>>> +svc->tickled_cpu = -1;
>>>   /* Starting load of 50% */
>>>   svc->avgload = 1ULL << (CSCHED2_PRIV(ops)-
 load_precision_shift - 1);
>>>   svc->load_last_update = NOW() >>
>>> LOADAVG_GRANULARITY_SHIFT;
>>> @@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct scheduler
>>> *ops, struct vcpu *vc, void *dd)
>>>   else
>>>   {
>>>   ASSERT(svc->sdom == NULL);
>>> +svc->tickled_cpu = svc->vcpu->vcpu_id;
>> If I understood correctly, tickled_cpu refers to pcpu and not a
>> vcpu. 
>> Saving vcpu_id in tickled_cpu looks wrong.
>>
> Yes, and in fact, as you can see in the previous hunk, for pretty much
> all vcpus, tickled_cpu is initialized to -1.
> 
> Here, we are dealing with the vcpus of the idle domain. And for vcpus
> of the idle domain, their vcpu id is the same as the id of the pcpu
> they're associated to.

But what I haven't sussed out yet is why we need to initialize this for
the idle domain at all.  What benefit does it give you, and what effect
does it have?

 -George


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

Re: [Xen-devel] [PATCH v5 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Julien Grall]

Hi Shannon,

On 13/09/16 08:03, Shannon Zhao wrote:



On 2016/9/12 23:18, Julien Grall wrote:

Hi Shannon,

On 02/09/16 03:55, Shannon Zhao wrote:

From: Shannon Zhao 

Here it adds the ACPI tables size to set the target maxmem to avoid
providing less available memory for guest.

Signed-off-by: Shannon Zhao 
---
 tools/libxl/libxl_arch.h|  2 +-
 tools/libxl/libxl_arm.c | 18 +-
 tools/libxl/libxl_arm.h |  4 
 tools/libxl/libxl_arm_acpi.c| 20 
 tools/libxl/libxl_arm_no_acpi.c |  6 ++
 tools/libxl/libxl_dom.c |  2 +-
 tools/libxl/libxl_x86.c |  2 +-
 7 files changed, 50 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 337061f..d62fa4c 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -30,7 +30,7 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
 /* arch specific internal domain creation function */
 _hidden
 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config
*d_config,
-   uint32_t domid);
+  libxl__domain_build_state *state,
uint32_t domid);

 /* setup arch specific hardware description, i.e. DTB on ARM */
 _hidden
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index e73d65e..c7d4f65 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -101,8 +101,24 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
 }

 int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config
*d_config,
-  uint32_t domid)
+  libxl__domain_build_state *state,
uint32_t domid)
 {
+libxl_domain_build_info *const info = _config->b_info;
+libxl_ctx *ctx = libxl__gc_owner(gc);
+int size;
+
+/* Add the size of ACPI tables to maxmem if ACPI is enabled for
guest. */
+if (libxl_defbool_val(info->acpi)) {
+size = libxl__get_acpi_size(gc, info, state);
+if (size < 0)
+return ERROR_FAIL;
+if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
+LIBXL_MAXMEM_CONSTANT + (size + 1023)
/ 1024)) {


I still have some concern about use info->target_memkb +
LIBXL_MAXMEM_CONSTANT here. What if the generic code decide to change
the computation?

We may forgot to replicate here. My suggestion on the previous version
was to have in the common code

xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
LIBXL_MAXMEM_CONSTANT + libxl__arch_memory_constant());

Or a similar name.


Just to confirm, do you mean that having a arch function to get the size
each arch needs and adding the size in libxl__build_pre()?


That's correct. Wei, Ian, do you have any opinions on this?

Regards,

--
Julien Grall

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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[George Dunlap]

On 12/09/16 15:32, Jan Beulich wrote:
 On 09.09.16 at 17:16,  wrote:
>> The following code illustrates this idea:
>>
>> typedef struct dm_op_buffer {
>>  XEN_GUEST_HANDLE(void) h;
>>  size_t len;
>> } dm_op_buffer_t;
> 
> This implies that we'll lose all type safety on the handles passed, as
> is also emphasized by the use of raw_copy_from_guest() in the code
> outline further down.

If most of the time the hypercalls are made by calling libxc functions,
and the libxc functions have types as arguments, then the end caller has
the same type safety.  We'll have to be careful inside the individual
libxc functions, but that should be fairly straightforward to do.  So
the places where we need to take extra care should be very localized.

 -George


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

Re: [Xen-devel] OVMF compile error

[Wei Liu]

Really fix the address this time...

On Tue, Sep 13, 2016 at 10:39:02AM +0100, Wei Liu wrote:
> Hi,
> 
> I just realise that your xen-devel address is wrong.
> 
> It should be xen-devel@lists.xen.org.
> 
> On Tue, Sep 13, 2016 at 03:30:51AM +, Chen, Farrah wrote:
> > Hi Wei,
> > 
> > We have updated OVMF to the latest master and cleaned everything before 
> > rebuilding.
> > 
> > Steps:
> > make clean
> > make xen -j8
> > ./configure --enable-ovmf
> > make tools -j8
> >  
> > Then the error occurred.
> > 
> 
> Can you please attach attach the file that failed to build here?
> 
> Looking at the package name it is likely to be a bug in upstream edk2. I
> think it would be suitable to report it upstream. But I would like to
> check the file first.
> 
> Wei.
> 
> > 
> > Thanks,
> > Fan Chen
> > 
> > 
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com] 
> > Sent: Monday, September 12, 2016 3:53 PM
> > To: Chen, Farrah 
> > Cc: xen-devel-requ...@lists.xen.org; Hao, Xudong ; 
> > wei.l...@citrix.com
> > Subject: Re: OVMF compile error
> > 
> > Hi
> > 
> > On Mon, Sep 12, 2016 at 07:31:42AM +, Chen, Farrah wrote:
> > > Hi,
> > > 
> > > When I compile xen with the latest commit in RHEL 6.7, it failed when 
> > > make tools. Errors showed when running edk2 build for OvmfPkgX64.
> > > Bisected and this error occurred from commit 
> > > 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2.
> > > 
> > > commit 8c8b6fb02342f7aa78e611a5f0f63dcf8fbf48f2
> > > Author: Wei Liu 
> > > Date:   Tue Sep 6 12:54:47 2016 +0100
> > > 
> > > Config.mk: update OVMF commit
> > > 
> > > Signed-off-by: Wei Liu wei.l...@citrix.com
> > > 
> > > ………
> > > 
> > > make_tools.log:
> > > ……
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:173: error: invalid combination of opcode and operands
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:175: error: invalid combination of opcode and operands
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:177: error: invalid combination of opcode and operands
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:179: error: invalid combination of opcode and operands
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:313: error: invalid combination of opcode and operands
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > /ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuE
> > > xceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandl
> > > erAsm.iii:315: error: invalid combination of opcode and operands
> > > make[7]: Leaving directory 
> > > `/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib'
> > > make[7]: *** 
> > > [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmwar
> > > e/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/Cpu
> > > ExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHand
> > > lerAsm.obj] Error 1
> > > 
> > 
> > 
> > There seems to be something wrong with the generated file. It's likely to 
> > be a bug in upstream.
> > 
> > How did you compile OVMF? Did you clean everything before rebuilding?
> > Could you try updating OVMF to the latest master?
> > 
> > Wei.
> > 
> > > 
> > > build.py...
> > > : error 7000: Failed to execute command
> > > make tbuild 
> > > [/home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmwar
> > > e/ovmf-dir-remote/Build/OvmfX64/DEBUG_GCC44/X64/UefiCpuPkg/Library/Cpu
> > > ExceptionHandlerLib/DxeCpuExceptionHandlerLib]
> > > 
> > > 
> > > build.py...
> > > : error F002: Failed to build module
> > > 
> > > /home/www/builds_xen_unstable/xen-src-8c8b6fb0-20160912/tools/firmware
> > > 

Re: [Xen-devel] [PATCH v2 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

[Andrew Cooper]

On 13/09/16 09:27, Jan Beulich wrote:
 On 12.09.16 at 18:21,  wrote:
>> compress_xsave_states() mustn't read xstate_bv or xcomp_bv before first
>> confirming that the input buffer is large enough.  It also doesn't cope with
>> compressed input.  Make all of these problems the callers responsbility to
>> ensure.
>>
>> Simplify the decompression logic by inlining get_xsave_addr().  As xstate_bv
>> is previously validated, dest won't ever been NULL.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> albeit, as expressed before I would prefer ...
>
>>  void compress_xsave_states(struct vcpu *v, const void *src, unsigned int 
>> size)
>>  {
>>  struct xsave_struct *xsave = v->arch.xsave_area;
>> +void *dest;
>>  uint16_t comp_offsets[sizeof(xfeature_mask)*8];
>> -u64 xstate_bv = ((const struct xsave_struct *)src)->xsave_hdr.xstate_bv;
>> -u64 valid;
>> +u64 xstate_bv, valid;
>>  
>> -ASSERT(!xsave_area_compressed(src));
>> +BUG_ON(!v->arch.xcr0_accum);
>> +BUG_ON(size != xstate_ctxt_size(v->arch.xcr0_accum));
>> +BUG_ON(xsave_area_compressed(src));
> ... if at least the ASSERT() remained one.

Hmm fine.  At least that is only data corruption issue, not an buffer
boundary issue.

~Andrew

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

Re: [Xen-devel] [PATCH v2 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

[Andrew Cooper]

On 13/09/16 09:23, Jan Beulich wrote:
 On 12.09.16 at 18:21,  wrote:
>> Without checking the size input, the memcpy() for the uncompressed path might
>> read off the end of the vcpu's xsave_area.  Both callers pass the approprite
>> size, so hold them to it with a BUG_ON().
>>
>> The compressed path is currently dead code, but its attempt to avoid leaking
>> uninitalised data was incomplete.  Work around this by zeroing the whole rest
>> of the buffer before decompression.
>>
>> The loop skips all bits which aren't set in xstate_bv, meaning that the
>> memset() was dead code.  The logic is more obvious with get_xsave_addr()
>> expanded inline, allowing for quite a lot of simplification, including all 
>> the
>> NULL pointer logic.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Jan Beulich 
> with one suggestion:
>
>>  void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size)
>>  {
>>  struct xsave_struct *xsave = v->arch.xsave_area;
>> +const void *src;
> I think with the addition of this variable and the removal of the use of
> get_xsave_addr() "xsave" can now also be const.

So it can.  Done.

~Andrew

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

Re: [Xen-devel] [PATCH v3 16/38] arm/p2m: Add HVMOP_altp2m_set_domain_state

[Sergej Proskurin]

Hi Julien,


On 09/09/2016 07:14 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> +static int altp2m_init_helper(struct domain *d, unsigned int idx)
>> +{
>> +int rc;
>> +struct p2m_domain *p2m = d->arch.altp2m_p2m[idx];
>> +
>> +ASSERT(p2m == NULL);
>> +
>> +/* Allocate a new, zeroed altp2m view. */
>> +p2m = xzalloc(struct p2m_domain);
>> +if ( p2m == NULL)
>> +{
>> +rc = -ENOMEM;
>> +goto err;
>> +}
>
> This could be simplified with just return -ENOMEM.
>

True. I will do that.

>> +
>> +p2m->p2m_class = p2m_alternate;
>> +
>> +/* Initialize the new altp2m view. */
>> +rc = p2m_init_one(d, p2m);
>> +if ( rc )
>> +goto err;
>> +
>> +p2m->access_required = false;
>> +_atomic_set(>active_vcpus, 0);
>
> the p2m is initialized to 0, so both access_required and active_vcpus
> initialization is not necessary.
>

I will remove these initializations in the next patch.

>> +
>> +d->arch.altp2m_p2m[idx] = p2m;
>> +
>> +return rc;
>> +
>> +err:
>> +if ( p2m )
>> +xfree(p2m);
>
> xfree is able to handle NULL pointer.
>

Ok, thank you.

>> +
>> +d->arch.altp2m_p2m[idx] = NULL;
>> +
>> +return rc;
>> +}
>> +
>> +int altp2m_init_by_id(struct domain *d, unsigned int idx)
>> +{
>> +int rc = -EINVAL;
>> +
>> +if ( idx >= MAX_ALTP2M )
>> +return rc;
>> +
>> +altp2m_lock(d);
>> +
>> +if ( d->arch.altp2m_p2m[idx] == NULL )
>> +rc = altp2m_init_helper(d, idx);
>> +
>> +altp2m_unlock(d);
>> +
>> +return rc;
>> +}
>> +

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v3 15/18] bug/x86/arm: Align bug_frames sections.

[Jan Beulich]

>>> On 11.09.16 at 22:35,  wrote:
> Furthermore on x86 the bloat-o-meter detects that with this
> change:
> 
> [konrad@char xen]$ ~/linux/scripts/bloat-o-meter xen-syms xen-syms.align4
> add/remove: 0/0 grow/shrink: 3/14 up/down: 115/-1497 (-1382)
> function old new   delta
> mod_l1_entry14901587 +97
> p2m_switch_domain_altp2m_by_id   520 533 +13
> p2m_switch_vcpu_altp2m_by_id 453 458  +5
> machine_kexec263 261  -2
> hvm_do_IRQ_dpci  244 242  -2
> sh_page_fault__guest_4  82528192 -60
> sh_audit_gw 15291462 -67
> validate_gl3e337 264 -73
> validate_gl4e449 375 -74
> p2m_altp2m_lazy_copy 730 652 -78
> set_typed_p2m_entry 13461259 -87
> virt_to_xen_l2e  491 365-126
> sh_x86_emulate_write__guest_4443 288-155
> p2m_mem_access_check17331576-157
> sh_x86_emulate_cmpxchg__guest_4  512 349-163
> __get_gfn_type_access709 542-167
> map_pages_to_xen44304144-286
> Total: Before=1974033, After=1972651, chg -0.07%
> 
> We end up making the binary file a bit smaller.

I'm fine with the change, but I'm having a very hard time buying the
above: The change you do is to code used only in assembly files _and_
is not affecting .text (and I assume the sizes above are .text ones),
yet all the functions listed above live in C ones. I can't help thinking
that there must be something else going on, or that we had an actual
problem before this.

> --- a/xen/include/asm-x86/bug.h
> +++ b/xen/include/asm-x86/bug.h
> @@ -98,6 +98,7 @@ extern const struct bug_frame __start_bug_frames[],
>  .popsection
>  
>  .pushsection .bug_frames.\type, "a", @progbits
> +.p2align 2
>  .L\@bf:
>  .long (.L\@ud - .L\@bf) + \
> ((\line >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH)

This ought to be accompanied by removing the enforcing of alignment
in xen.lds.S.

Jan


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

Re: [Xen-devel] [PATCH v3 13/18] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

[Jan Beulich]

>>> On 11.09.16 at 22:35,  wrote:
> --- a/xen/include/asm-x86/cpufeature.h
> +++ b/xen/include/asm-x86/cpufeature.h
> @@ -34,6 +34,7 @@ XEN_CPUFEATURE(MFENCE_RDTSC,(FSCAPINTS+0)*32+ 9) /* 
> MFENCE synchronizes RDTS
>  
>  /* An alias of a feature we know is always going to be present. */
>  #define X86_FEATURE_ALWAYS  X86_FEATURE_LM
> +#define LIVEPATCH_FEATURE   X86_FEATURE_ALWAYS

Didn't an earlier patch introduce asm/livepatch.h? Such a #define
would better go there, if that file already exists.

Jan


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

Re: [Xen-devel] [PATCH v3 15/38] arm/p2m: Add altp2m table flushing routine

[Sergej Proskurin]

Hi Julien,


On 09/09/2016 07:02 PM, Julien Grall wrote:
> Hello Sergej,
>
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> The current implementation differentiates between flushing and
>> destroying altp2m views. This commit adds the function altp2m_flush,
>> which allows to release all of the alternate p2m views.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Pages in p2m->pages are not cleared in p2m_flush_table anymore.
>> VMID is freed in p2m_free_one.
>> Cosmetic fixes.
>>
>> v3: Changed the locking mechanism to "p2m_write_lock" inside the
>> function "altp2m_flush".
>>
>> Do not flush but rather teardown the altp2m in the function
>> "altp2m_flush".
>>
>> Exchanged the check "altp2m_vttbr[idx] == INVALID_VTTBR" for
>> "altp2m_p2m[idx] == NULL" in "altp2m_flush".
>> ---
>>  xen/arch/arm/altp2m.c| 31 +++
>>  xen/include/asm-arm/altp2m.h |  3 +++
>>  2 files changed, 34 insertions(+)
>>
>> diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
>> index 66a373a..02cffd7 100644
>> --- a/xen/arch/arm/altp2m.c
>> +++ b/xen/arch/arm/altp2m.c
>> @@ -34,6 +34,37 @@ int altp2m_init(struct domain *d)
>>  return 0;
>>  }
>>
>> +void altp2m_flush(struct domain *d)
>> +{
>> +unsigned int i;
>> +struct p2m_domain *p2m;
>> +
>> +/*
>> + * If altp2m is active, we are not allowed to flush altp2m[0].
>> This special
>> + * view is considered as the hostp2m as long as altp2m is active.
>> + */
>> +ASSERT(!altp2m_active(d));
>> +
>> +altp2m_lock(d);
>> +
>> +for ( i = 0; i < MAX_ALTP2M; i++ )
>> +{
>> +if ( d->arch.altp2m_p2m[i] == NULL )
>> +continue;
>> +
>> +p2m = d->arch.altp2m_p2m[i];
>> +
>> +p2m_write_lock(p2m);
>
> Why do you take the lock here? The p2m should not be used by anyone at
> that time.

Good point. I will not acquire the lock at this point. Thank you.

>
>> +p2m_teardown_one(p2m);
>
> You may want to add an ASSERT(!atomic_read(p2m->active_vcpus)) somewhere.

Ok.

>
>> +p2m_write_unlock(p2m);
>> +
>> +xfree(p2m);
>> +d->arch.altp2m_p2m[i] = NULL;
>> +}
>> +
>> +altp2m_unlock(d);
>> +}
>> +
>>  void altp2m_teardown(struct domain *d)
>>  {
>>  unsigned int i;
>> diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
>> index a156109..4c15b75 100644
>> --- a/xen/include/asm-arm/altp2m.h
>> +++ b/xen/include/asm-arm/altp2m.h
>> @@ -42,4 +42,7 @@ static inline uint16_t altp2m_vcpu_idx(const struct
>> vcpu *v)
>>  int altp2m_init(struct domain *d);
>>  void altp2m_teardown(struct domain *d);
>>
>> +/* Flush all the alternate p2m's for a domain. */
>> +void altp2m_flush(struct domain *d);
>> +
>>  #endif /* __ASM_ARM_ALTP2M_H */
>>

Best regards,
~Sergej

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

[Xen-devel] [xen-4.6-testing baseline-only test] 67702: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67702 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67702/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail REGR. vs. 67684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 67684
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67684
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 build-i386-rumprun5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-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-xl  13 saverestore-support-checkfail   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-libvirt-xsm 14 guest-saverestorefail   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-amd64-amd64-libvirt-xsm 12 migrate-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-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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  12 migrate-support-checkfail   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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  6b5bb502a93bcb7617ea1f3f5a8712f2b9f33d90
baseline version:
 xen  26352b6344ce5d5a2ee78e56ae631e156fbdce7f

Last test of basis67684  2016-09-09 21:16:49 Z3 days
Testing same since67702  2016-09-13 00:50:27 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 

Re: [Xen-devel] PC8 Residency on Broadwell hardware

[Andrew Cooper]

On 13/09/16 08:51, Jan Beulich wrote:
 On 12.09.16 at 19:28,  wrote:
> Please try to get quoting right - your response was rather hard to
> follow.
>
>> On Sep 12, 2016, at 2:00 AM, Jan Beulich 
>> > wrote:
>>
>> On 12.09.16 at 10:47, 
>> > wrote:
>> c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
>> MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).
> I think this was misleading: 79 == 0x4f. Andrew, can you confirm in
> your case please?

Very sorry for the confusion.  Yes, I was talking about model 0x4f.

>> Rereading the manual, it does indeed indicate that this MSR is available.
>>
>> However, experimentally it is not.  All Broadwell hardware XenServer has
>> (both SDPs and production systems) reliably take a #GP fault when trying
>> to read this MSR.  Haswell hardware appears fine (and indeed, was
>> reading that MSR before).
>>
>> Where did you find the info? I think you are talking about 
>> MSR_PKG_C8_RESIDENCY (630H).
> Yes.
>
>> The SDM says (35.13):
>>
>> "Processors with signatures 06_3DH and 06_47H support the MSR interfaces 
>> listed in Table 35-18, Table 35-19, Table 35-20, Table 35-23, Table 35-27, 
>> Table 35-28, Table 35-32, and Table 35-33.”
> Model 0x4f is what we're talking about, and table 35-36 has the information
> on MSR_PKG_C8_RESIDENCY (630H).

Correct.

~Andrew

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

Re: [Xen-devel] [PATCH v2 6/6] x86/xstate: Fix latent bugs in compress_xsave_states()

[Jan Beulich]

>>> On 12.09.16 at 18:21,  wrote:
> compress_xsave_states() mustn't read xstate_bv or xcomp_bv before first
> confirming that the input buffer is large enough.  It also doesn't cope with
> compressed input.  Make all of these problems the callers responsbility to
> ensure.
> 
> Simplify the decompression logic by inlining get_xsave_addr().  As xstate_bv
> is previously validated, dest won't ever been NULL.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
albeit, as expressed before I would prefer ...

>  void compress_xsave_states(struct vcpu *v, const void *src, unsigned int 
> size)
>  {
>  struct xsave_struct *xsave = v->arch.xsave_area;
> +void *dest;
>  uint16_t comp_offsets[sizeof(xfeature_mask)*8];
> -u64 xstate_bv = ((const struct xsave_struct *)src)->xsave_hdr.xstate_bv;
> -u64 valid;
> +u64 xstate_bv, valid;
>  
> -ASSERT(!xsave_area_compressed(src));
> +BUG_ON(!v->arch.xcr0_accum);
> +BUG_ON(size != xstate_ctxt_size(v->arch.xcr0_accum));
> +BUG_ON(xsave_area_compressed(src));

... if at least the ASSERT() remained one.

Jan


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

Re: [Xen-devel] [PATCH v2 4/6] x86/xstate: Fix latent bugs in expand_xsave_states()

[Jan Beulich]

>>> On 12.09.16 at 18:21,  wrote:
> Without checking the size input, the memcpy() for the uncompressed path might
> read off the end of the vcpu's xsave_area.  Both callers pass the approprite
> size, so hold them to it with a BUG_ON().
> 
> The compressed path is currently dead code, but its attempt to avoid leaking
> uninitalised data was incomplete.  Work around this by zeroing the whole rest
> of the buffer before decompression.
> 
> The loop skips all bits which aren't set in xstate_bv, meaning that the
> memset() was dead code.  The logic is more obvious with get_xsave_addr()
> expanded inline, allowing for quite a lot of simplification, including all the
> NULL pointer logic.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 
with one suggestion:

>  void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size)
>  {
>  struct xsave_struct *xsave = v->arch.xsave_area;
> +const void *src;

I think with the addition of this variable and the removal of the use of
get_xsave_addr() "xsave" can now also be const.

Jan


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

Re: [Xen-devel] PC8 Residency on Broadwell hardware

[Jan Beulich]

>>> On 12.09.16 at 19:28,  wrote:

Please try to get quoting right - your response was rather hard to
follow.

> On Sep 12, 2016, at 2:00 AM, Jan Beulich 
> > wrote:
> 
> On 12.09.16 at 10:47, 
> > wrote:
> c/s 350bc1a9d4 "x86: support newer Intel CPU models" changed the set of
> MSRs read by Xeon Broadwell hardware (specifically, model 79 / 0x47).

I think this was misleading: 79 == 0x4f. Andrew, can you confirm in
your case please?

> Rereading the manual, it does indeed indicate that this MSR is available.
> 
> However, experimentally it is not.  All Broadwell hardware XenServer has
> (both SDPs and production systems) reliably take a #GP fault when trying
> to read this MSR.  Haswell hardware appears fine (and indeed, was
> reading that MSR before).
> 
> Where did you find the info? I think you are talking about 
> MSR_PKG_C8_RESIDENCY (630H).

Yes.

> The SDM says (35.13):
> 
> "Processors with signatures 06_3DH and 06_47H support the MSR interfaces 
> listed in Table 35-18, Table 35-19, Table 35-20, Table 35-23, Table 35-27, 
> Table 35-28, Table 35-32, and Table 35-33.”

Model 0x4f is what we're talking about, and table 35-36 has the information
on MSR_PKG_C8_RESIDENCY (630H).

Jan

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

[Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan Tianyu]

On a machine with a mount of cpus, dump_timerq() lasts several seconds
which may exceed watchdog timeout and cause Xen hyperviosr reboot.
This patch is to disable watchdog when dump timer queues to fix the
issue.

Signed-off-by: Lan Tianyu 
---
 xen/common/timer.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/xen/common/timer.c b/xen/common/timer.c
index 29a60a9..2d9d828 100644
--- a/xen/common/timer.c
+++ b/xen/common/timer.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -524,6 +525,7 @@ static void dump_timerq(unsigned char key)
 s_time_t   now = NOW();
 inti, j;
 
+watchdog_disable();
 printk("Dumping timer queues:\n");
 
 for_each_online_cpu( i )
@@ -538,6 +540,8 @@ static void dump_timerq(unsigned char key)
 dump_timer(t, now);
 spin_unlock_irqrestore(>lock, flags);
 }
+
+watchdog_enable();
 }
 
 static void migrate_timers_from_cpu(unsigned int old_cpu)
-- 
1.7.1


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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Shannon Zhao]

On 2016/9/12 23:22, Julien Grall wrote:
> Hi Shannon,
> 
> On 02/09/16 03:55, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> The design of this feature is described as below.
>> Firstly, the toolstack (libxl) generates the ACPI tables according the
>> number of vcpus and gic controller.
>>
>> Then, it copies these ACPI tables to DomU non-RAM memory map space and
>> passes them to UEFI firmware through the "ARM multiboot" protocol.
>>
>> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
>> and installs these tables like the usual way and passes both ACPI and DT
>> information to the Xen DomU.
>>
>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
>> since it's enough now.
>>
>> This has been tested using guest kernel with the Dom0 ACPI support
>> patches which could be fetched from linux master or:
>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>
>>
>> The UEFI binary could be fetched from or built from edk2 master branch:
>> http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
>>
>> This series can be fetched from:
>> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v5
> 
> This branch is based on a fairly out of date xen. Do you have a branch
> rebased on the latest upstream + Boris ACPI v3?
> 
You can fetch the updated branch from:
https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v5_new

Thanks,
-- 
Shannon


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