[Xen-devel] [PATCH] x86/xen/64: Fix the reported SS and CS in SYSCALL

2017-08-14 Thread Andy Lutomirski
When I cleaned up the Xen SYSCALL entries, I inadvertently changed
the reported segment registers.  Before my patch, regs->ss was
__USER(32)_DS and regs->cs was __USER(32)_CS.  After the patch, they
are FLAT_USER_CS/DS(32).

This had a couple unfortunate effects.  It confused the
opportunistic fast return logic.  It also significantly increased
the risk of triggering a nasty glibc bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=21269

Update the Xen entry code to change it back.

Reported-by: Brian Gerst 
Fixes: 8a9949bc71a7 ("x86/xen/64: Rearrange the SYSCALL entries")
Signed-off-by: Andy Lutomirski 
---
 arch/x86/xen/xen-asm_64.S | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index a8a4f4c460a6..c5fee2680abc 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -88,6 +88,15 @@ RELOC(xen_sysret64, 1b+1)
 ENTRY(xen_syscall_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER_DS and __USER_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER_DS, 4*8(%rsp)
+   movq $__USER_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_64_after_hwframe
 ENDPROC(xen_syscall_target)
 
@@ -97,6 +106,15 @@ ENDPROC(xen_syscall_target)
 ENTRY(xen_syscall32_target)
popq %rcx
popq %r11
+
+   /*
+* Neither Xen nor the kernel really knows what the old SS and
+* CS were.  The kernel expects __USER32_DS and __USER32_CS, so
+* report those values even though Xen will guess its own values.
+*/
+   movq $__USER32_DS, 4*8(%rsp)
+   movq $__USER32_CS, 1*8(%rsp)
+
jmp entry_SYSCALL_compat_after_hwframe
 ENDPROC(xen_syscall32_target)
 
-- 
2.13.3


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


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

2017-08-14 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4ad5f597153c7cb20a968236c2c7d6ff01994350
baseline version:
 ovmf 0024172d909ec73a9ce9ffdfc9fdd4382080e110

Last test of basis71974  2017-08-14 18:17:16 Z0 days
Testing same since71975  2017-08-15 03:47:26 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Star Zeng 

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 4ad5f597153c7cb20a968236c2c7d6ff01994350
Author: Jiewen Yao 
Date:   Wed Aug 9 15:53:43 2017 +0800

IntelSiliconPkg/IntelVTdDxe: Improve performance.

This patch is to improve IOMMU performance.
All WBINVD is removed due to performance issue.
CLFLUSH by WriteBackDataCacheRange() is used to
only flush the context table or
second level page table if they are changed.

This patch also removed some unused functions.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Star Zeng 

commit 3ccf5a8a41b42fc5116fdc03bc2a273f7f3c5179
Author: Jiewen Yao 
Date:   Fri Aug 11 22:46:24 2017 +0800

IntelSiliconPkg/dsc: Add CacheMaintenanceLib.

It will be used by IntelVTdDxe.

Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Star Zeng 

commit 3cf737c74b0f2fa2d2c6a861343bde6fa2473a3f
Author: Star Zeng 
Date:   Mon Aug 7 15:28:46 2017 +0800

ShellPkg UefiDpLib: Init CustomCumulativeData.MinDur

Init CustomCumulativeData.MinDur to PERF_MAXDUR, otherwise the
MinDur displayed for custom cumulative data will be always 0,
but not the real shortest duration.

Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Cinnamon Shia 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

commit ce10f482f786283b160146bb7ba2d9770479c10c
Author: Star Zeng 
Date:   Mon Aug 7 15:28:21 2017 +0800

PerformancePkg DP: Init CustomCumulativeData.MinDur

Init CustomCumulativeData.MinDur to PERF_MAXDUR, otherwise the
MinDur displayed for custom cumulative data will be always 0,
but not the real shortest duration.

Cc: Liming Gao 
Cc: Cinnamon Shia 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

commit 9a701955a55d094e93c3613a3ae462660551d592
Author: Star Zeng 
Date:   Thu Aug 10 09:30:42 2017 +0800

MdeModulePkg DxeCore: Enhance "ConvertPages: Incompatible memory types"

When double free pages by FreePages() or allocate allocated pages by
AllocatePages() with AllocateAddress type, the code will print debug
message "ConvertPages: Incompatible memory types", but the debug
message is not very obvious for the error paths by FreePages() or
AllocatePages().

Refer https://lists.01.org/pipermail/edk2-devel/2017-August/013075.html
for the discussion.

This patch is to enhance the debug message for the error paths by
FreePages() or AllocatePages.

Cc: Liming Gao 

[Xen-devel] [patch] honour maxmem from config

2017-08-14 Thread James Dingwall
Hi,

>From xl.cfg(5):

maxmem=MBYTES
   Specifies the maximum amount of memory a guest can ever see.  The 
value of maxmem= must be equal or greater than memory=.

   In combination with memory= it will start the guest "pre-ballooned", 
if the values of memory= and maxmem= differ.

At present when creating (pv) domains with a configuration such as:

memory = 512
maxmem = 1024

The maximum memory of the guest will not go above 512 (this also shows in the 
maxmem column in xl top).  I expect that the vm will start with 512 and then be 
able to increase up to 1024 if there is memory available for xen to allocate 
and the guest is under memory pressure.  I have been carrying variations of 
this 
patch originally written by Wei Liu through 4.[345] and having just jumped to 
4.8 noted it is still a problem so thought I would raise this again.  With this 
applied everything is stable and working as expected - Xen 4.8.1 + Linux 4.1.43 
(dom0 and guest) with tmem enabled in Xen, dom0 and guest.

https://lists.xenproject.org/archives/html/xen-devel/2013-10/msg02228.html

Thanks,
James
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index d519c8d440..0b6d81e53a 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -416,7 +416,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 return ERROR_FAIL;
 }
 
-if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb + size) < 0) {
+if (xc_domain_setmaxmem(ctx->xch, domid, info->max_memkb + size) < 0) {
 LOGE(ERROR, "Couldn't set max memory");
 return ERROR_FAIL;
 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel


[Xen-devel] [xen-unstable test] 112632: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread osstest service owner
flight 112632 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112632/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 112544
 build-armhf-pvops 6 kernel-build   fail in 112608 REGR. vs. 112544

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112613 
pass in 112608
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 112613 pass 
in 112622
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112613 
pass in 112632
 test-amd64-i386-xl-qemut-debianhvm-amd64 17 guest-stop fail in 112613 pass in 
112632
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
112613

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 112613 REGR. vs. 
112544

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   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-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112544
 build-arm64   2 hosts-allocate  broken like 112544
 build-arm64-xsm   3 capture-logsbroken like 112544
 build-arm64-pvops 2 hosts-allocate  broken like 112544
 build-arm64-pvops 3 capture-logsbroken like 112544
 build-arm64   3 capture-logsbroken like 112544
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112544
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 112608 
blocked in 112544
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112608 
like 112544
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 112613 like 
112544
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112613 like 
112544
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 112613 like 
112544
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 112613 never 
pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 112613 never 
pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 112613 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 112613 
never pass
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 112613 never pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 112613 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 112613 
never pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112613 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 112613 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 112613 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 112613 never pass
 

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

2017-08-14 Thread osstest service owner
flight 112636 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112636/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4ad5f597153c7cb20a968236c2c7d6ff01994350
baseline version:
 ovmf 0024172d909ec73a9ce9ffdfc9fdd4382080e110

Last test of basis   112628  2017-08-14 07:47:27 Z0 days
Testing same since   112636  2017-08-14 18:17:22 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Star Zeng 

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=4ad5f597153c7cb20a968236c2c7d6ff01994350
+ . ./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 
4ad5f597153c7cb20a968236c2c7d6ff01994350
+ branch=ovmf
+ revision=4ad5f597153c7cb20a968236c2c7d6ff01994350
+ . ./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.9-testing
+ '[' x4ad5f597153c7cb20a968236c2c7d6ff01994350 = 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 XTF v3] Functional: Add a UMIP test

2017-08-14 Thread Boqun Feng (Intel)
Add a "umip" test for the User-Model Instruction Prevention. The test
simply tries to run sgdt/sidt/sldt/str/smsw in guest user-mode with
CR4_UMIP = 1.

Signed-off-by: Boqun Feng (Intel) 
---
v1 --> v2:
* add a new write_cr4_safe()
* use %pe for exception print
* refactor the code based on Andrew's guide and advice
v2 --> v3:
* add test_insns() to simplify test_main() logic
* make write_cr4_safe() return 0 for success.
* add UMIP activation test even if !cpu_has_umip

Test results:

* With UMIP patch:
** boot with hvm_fep: SUCCESS
** boot without hvm_fep: SKIP

* Without UMIP patch:
** boot with hvm_fep: SKIP
** boot without hvm_fep: SKIP

(illed implementation)
* With UMIP cpuid exposed but hvm_cr4_guest_valid_bits() didn't include 
X86_CR4_UMIP:
** boot with hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."
** boot without hvm_fep: FAILURE, due to "Fail: Unable to activate UMIP.."

* With UMIP cpuid not exposed but hvm_cr4_guest_valid_bits() included 
X86_CR4_UMIP:
** boot with hvm_fep: FAILURE, due to "UMIP unsupported, but setting CR4 
succeeded"
** boot without hvm_fep: FAILURE, due to "UMIP unsupported, but setting CR4 
succeeded"

 arch/x86/include/arch/lib.h |  13 +++
 docs/all-tests.dox  |   2 +
 tests/umip/Makefile |   9 ++
 tests/umip/main.c   | 214 
 4 files changed, 238 insertions(+)
 create mode 100644 tests/umip/Makefile
 create mode 100644 tests/umip/main.c

diff --git a/arch/x86/include/arch/lib.h b/arch/x86/include/arch/lib.h
index f608af9996f0..82eb7da600c4 100644
--- a/arch/x86/include/arch/lib.h
+++ b/arch/x86/include/arch/lib.h
@@ -340,6 +340,19 @@ static inline void write_cr4(unsigned long cr4)
 asm volatile ("mov %0, %%cr4" :: "r" (cr4));
 }
 
+static inline bool write_cr4_safe(unsigned long cr4)
+{
+exinfo_t fault = 0;
+
+asm volatile ("1: mov %1, %%cr4; 2:"
+  _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_edi)
+  : "+D" (fault)
+  : "r" (cr4),
+"X" (ex_record_fault_edi));
+
+return fault;
+}
+
 static inline void write_cr8(unsigned long cr8)
 {
 asm volatile ("mov %0, %%cr8" :: "r" (cr8));
diff --git a/docs/all-tests.dox b/docs/all-tests.dox
index c1b163a926cb..ef011007cf68 100644
--- a/docs/all-tests.dox
+++ b/docs/all-tests.dox
@@ -111,4 +111,6 @@ guest breakout.
 @section index-in-development In Development
 
 @subpage test-vvmx - Nested VT-x tests.
+
+@subpage test-umip - User-Mode Instruction Prevention
 */
diff --git a/tests/umip/Makefile b/tests/umip/Makefile
new file mode 100644
index ..0248c8b247a0
--- /dev/null
+++ b/tests/umip/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME  := umip
+CATEGORY  := functional
+TEST-ENVS := hvm32 hvm64
+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
diff --git a/tests/umip/main.c b/tests/umip/main.c
new file mode 100644
index ..76764c8b38f4
--- /dev/null
+++ b/tests/umip/main.c
@@ -0,0 +1,214 @@
+/**
+ * @file tests/umip/main.c
+ * @ref test-umip
+ *
+ * @page test-umip umip
+ *
+ * @todo Docs for test-umip
+ *
+ * @see tests/umip/main.c
+ */
+#include 
+#include 
+#include 
+
+const char test_title[] = "User-Mode Instruction Prevention Test";
+bool test_wants_user_mappings = true;
+
+static unsigned long stub_sgdt(unsigned long force)
+{
+exinfo_t fault = 0;
+desc_ptr tmp;
+
+asm volatile("test %[fep], %[fep];"
+ "jz 1f;"
+ _ASM_XEN_FEP
+ "1: sgdt %[tmp]; 2:"
+_ASM_EXTABLE_HANDLER(1b,2b, ex_record_fault_edi)
+   : "+D" (fault), [tmp] "=m" (tmp)
+: [fep] "q" (force),
+  "X" (ex_record_fault_edi));
+
+return fault;
+}
+static unsigned long stub_sidt(unsigned long force)
+{
+exinfo_t fault = 0;
+desc_ptr tmp;
+
+asm volatile("test %[fep], %[fep];"
+ "jz 1f;"
+ _ASM_XEN_FEP
+ "1: sidt %[tmp]; 2:"
+ _ASM_EXTABLE_HANDLER(1b,2b, ex_record_fault_edi)
+: "+D" (fault), [tmp] "=m" (tmp)
+ : [fep] "q" (force),
+  "X" (ex_record_fault_edi));
+
+return fault;
+}
+
+static unsigned long stub_sldt(unsigned long force)
+{
+exinfo_t fault = 0;
+unsigned int tmp;
+
+asm volatile("test %[fep], %[fep];"
+ "jz 1f;"
+ _ASM_XEN_FEP
+ "1: sldt %[tmp]; 2:"
+ _ASM_EXTABLE_HANDLER(1b,2b, ex_record_fault_edi)
+ : "+D" (fault), [tmp] "=r" (tmp)
+ : [fep] "q" (force),
+  "X" (ex_record_fault_edi));
+
+return fault;
+}
+
+static unsigned long stub_str(unsigned long force)
+{
+exinfo_t fault = 0;
+unsigned int tmp;
+
+asm volatile("test %[fep], %[fep];"
+ "jz 1f;"
+ 

Re: [Xen-devel] [PATCH V2 2/3] xen-pt: bind/unbind interrupt remapping format MSI

2017-08-14 Thread Lan Tianyu
Hi Anthony:

On 2017年08月12日 02:04, Anthony PERARD wrote:
> On Wed, Aug 09, 2017 at 04:51:21PM -0400, Lan Tianyu wrote:
>> From: Chao Gao 
>>
>> If a vIOMMU is exposed to guest, guest will configure the msi to remapping
>> format. The original code isn't suitable to the new format. A new pair
>> bind/unbind interfaces are added for this usage. This patch recognizes
>> this case and uses new interfaces to bind/unbind msi.
>>
>> Signed-off-by: Chao Gao 
>> Signed-off-by: Lan Tianyu 
> 
> Reviewed-by: Anthony PERARD 
> 
> That patch series can be applied once the Xen side patches are merged.
> 

Great. Thanks for your review.

-- 
Best regards
Tianyu Lan

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


Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

2017-08-14 Thread Michael S. Tsirkin
On Mon, Aug 14, 2017 at 05:45:02PM +0100, Anthony PERARD wrote:
> On Mon, Aug 14, 2017 at 06:53:14PM +0300, Michael S. Tsirkin wrote:
> > On Mon, Aug 14, 2017 at 03:55:50PM +0100, Anthony PERARD wrote:
> > > On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
> > > > On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> > > > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to 
> > > > > be
> > > > > set, but this was done only when ACPI tables are built which is not
> > > > > needed for a Xen guest. The need for the property starts with commit
> > > > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > > > 
> > > > > Set pci info before checking for the needs to build ACPI tables.
> > > > > 
> > > > > Reported-by: Sander Eikelenboom 
> > > > > Tested-by: Sander Eikelenboom 
> > > > > Signed-off-by: Anthony PERARD 
> > > > 
> > > > I am worried that Xen will come to depend on specific
> > > > assignment of bsel which isn't guaranteed. Thoughts on
> > > > how to avoid that?
> > > 
> > > Is it possible to have a different BSEL than 0 with PIIX ?
> > 
> > With PCI to PCI bridges, yes.
> > 
> > > Also, I don't known if having more than on PCI bus is going to work on
> > > Xen, there is nothing in our ACPI tables beyond _SB.PCI0, and nothing to
> > > use a different BSEL.
> > 
> > My worry is someone might decide to implement hotplug for pci to pci
> > bridges on Xen. If doing that, it's important to use the qemu supplied
> > acpi tables.
> 
> I can always add assert((xen_enable() && !bsel) || !xen_enable()) in
> acpi_set_bsel(), so if someone was going to make any change, he would
> find out about bsel quicker. But I don't see Xen using QEMU supplied
> ACPI tables anytime soon.

In that case I'd prefer assigning bsel 0 just for the root bus on xen.

-- 
MST

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


Re: [Xen-devel] [PATCH v3 10/13] xen/pvcalls: implement recvmsg

2017-08-14 Thread Boris Ostrovsky



On 07/31/2017 06:57 PM, Stefano Stabellini wrote:

Implement recvmsg by copying data from the "in" ring. If not enough data
is available and the recvmsg call is blocking, then wait on the
inflight_conn_req waitqueue. Take the active socket in_mutex so that
only one function can access the ring at any given time.

If no data is available on the ring, rather than returning immediately
or sleep-waiting, spin for up to 5000 cycles. This small optimization
turns out to improve performance and latency significantly.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
  drivers/xen/pvcalls-front.c | 102 
  drivers/xen/pvcalls-front.h |   4 ++
  2 files changed, 106 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 369acde..635a83a 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -105,6 +105,20 @@ static int pvcalls_front_write_todo(struct sock_mapping 
*map)
return size - pvcalls_queued(prod, cons, size);
  }
  
+static bool pvcalls_front_read_todo(struct sock_mapping *map)

+{
+   struct pvcalls_data_intf *intf = map->active.ring;
+   RING_IDX cons, prod;
+   int32_t error;
+
+   cons = intf->in_cons;
+   prod = intf->in_prod;
+   error = intf->in_error;
+   return (error != 0 ||
+   pvcalls_queued(prod, cons,
+  XEN_FLEX_RING_SIZE(intf->ring_order)) != 0);
+}
+
  static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
  {
struct xenbus_device *dev = dev_id;
@@ -434,6 +448,94 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
return tot_sent;
  }
  
+static int __read_ring(struct pvcalls_data_intf *intf,

+  struct pvcalls_data *data,
+  struct iov_iter *msg_iter,
+  size_t len, int flags)
+{
+   RING_IDX cons, prod, size, masked_prod, masked_cons;
+   RING_IDX array_size = XEN_FLEX_RING_SIZE(intf->ring_order);
+   int32_t error;
+
+   cons = intf->in_cons;
+   prod = intf->in_prod;
+   error = intf->in_error;
+   /* get pointers before reading from the ring */
+   virt_rmb();
+   if (error < 0)
+   return error;
+
+   size = pvcalls_queued(prod, cons, array_size);
+   masked_prod = pvcalls_mask(prod, array_size);
+   masked_cons = pvcalls_mask(cons, array_size);
+
+   if (size == 0)
+   return 0;
+
+   if (len > size)
+   len = size;
+
+   if (masked_prod > masked_cons) {
+   copy_to_iter(data->in + masked_cons, len, msg_iter);
+   } else {
+   if (len > (array_size - masked_cons)) {
+   copy_to_iter(data->in + masked_cons,
+array_size - masked_cons, msg_iter);
+   copy_to_iter(data->in,
+len - (array_size - masked_cons),
+msg_iter);
+   } else {
+   copy_to_iter(data->in + masked_cons, len, msg_iter);
+   }
+   }
+   /* read data from the ring before increasing the index */
+   virt_mb();
+   if (!(flags & MSG_PEEK))
+   intf->in_cons += len;
+
+   return len;
+}
+
+int pvcalls_front_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
+int flags)
+{
+   struct pvcalls_bedata *bedata;
+   int ret = -EAGAIN;


Not necessary to initialize.


+   struct sock_mapping *map;
+
+   if (!pvcalls_front_dev)
+   return -ENOTCONN;
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
+   if (!map)
+   return -ENOTSOCK;
+
+   if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
+   return -EOPNOTSUPP;
+
+   mutex_lock(>active.in_mutex);
+   if (len > XEN_FLEX_RING_SIZE(map->active.ring->ring_order))
+   len = XEN_FLEX_RING_SIZE(map->active.ring->ring_order);
+
+   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
+   wait_event_interruptible(map->active.inflight_conn_req,
+pvcalls_front_read_todo(map));
+   }
+   ret = __read_ring(map->active.ring, >active.data,
+ >msg_iter, len, flags);
+
+   if (ret > 0)
+   notify_remote_via_irq(map->active.irq);
+   if (ret == 0)
+   ret = -EAGAIN;
+   if (ret == -ENOTCONN)
+   ret = 0;
+
+   mutex_unlock(>active.in_mutex);
+   return ret;


Are errors converted by the caller? (I am asking because recvmsg can 
only return -1 for errors)


-boris


+}
+
  int pvcalls_front_bind(struct socket *sock, struct sockaddr *addr, int 
addr_len)
  {
   

Re: [Xen-devel] [PATCH v3 09/13] xen/pvcalls: implement sendmsg

2017-08-14 Thread Boris Ostrovsky



On 07/31/2017 06:57 PM, Stefano Stabellini wrote:

Send data to an active socket by copying data to the "out" ring. Take
the active socket out_mutex so that only one function can access the
ring at any given time.

If not enough room is available on the ring, rather than returning
immediately or sleep-waiting, spin for up to 5000 cycles. This small
optimization turns out to improve performance significantly.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
  drivers/xen/pvcalls-front.c | 109 
  drivers/xen/pvcalls-front.h |   3 ++
  2 files changed, 112 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index f83b910..369acde 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -29,6 +29,7 @@
  #define PVCALLS_INVALID_ID UINT_MAX
  #define PVCALLS_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
  #define PVCALLS_NR_REQ_PER_RING __CONST_RING_SIZE(xen_pvcalls, XEN_PAGE_SIZE)
+#define PVCALLS_FRONT_MAX_SPIN 5000
  
  struct pvcalls_bedata {

struct xen_pvcalls_front_ring ring;
@@ -88,6 +89,22 @@ static inline int get_request(struct pvcalls_bedata *bedata, 
int *req_id)
return 0;
  }
  
+static int pvcalls_front_write_todo(struct sock_mapping *map)

+{
+   struct pvcalls_data_intf *intf = map->active.ring;
+   RING_IDX cons, prod, size = XEN_FLEX_RING_SIZE(intf->ring_order);
+   int32_t error;
+
+   cons = intf->out_cons;
+   prod = intf->out_prod;
+   error = intf->out_error;
+   if (error == -ENOTCONN)
+   return 0;
+   if (error != 0)
+   return error;
+   return size - pvcalls_queued(prod, cons, size);


Do you ever look at actual return value except whether it's zero or not? 
Both here and in the poll patch you look for !=0 and never check for an 
error.



+}
+
  static irqreturn_t pvcalls_front_event_handler(int irq, void *dev_id)
  {
struct xenbus_device *dev = dev_id;
@@ -325,6 +342,98 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
return ret;
  }
  
+static int __write_ring(struct pvcalls_data_intf *intf,

+   struct pvcalls_data *data,
+   struct iov_iter *msg_iter,
+   size_t len)
+{
+   RING_IDX cons, prod, size, masked_prod, masked_cons;
+   RING_IDX array_size = XEN_FLEX_RING_SIZE(intf->ring_order);
+   int32_t error;
+
+   cons = intf->out_cons;
+   prod = intf->out_prod;
+   error = intf->out_error;
+   /* read indexes before continuing */
+   virt_mb();
+
+   if (error < 0)
+   return error;


This can be done before the barrier. (In fact, this can be done first 
thing, before cons and prod are read).



+
+   size = pvcalls_queued(prod, cons, array_size);
+   if (size >= array_size)
+   return 0;
+   if (len > array_size - size)
+   len = array_size - size;
+
+   masked_prod = pvcalls_mask(prod, array_size);
+   masked_cons = pvcalls_mask(cons, array_size);
+
+   if (masked_prod < masked_cons) {
+   copy_from_iter(data->out + masked_prod, len, msg_iter);
+   } else {
+   if (len > array_size - masked_prod) {
+   copy_from_iter(data->out + masked_prod,
+  array_size - masked_prod, msg_iter);
+   copy_from_iter(data->out,
+  len - (array_size - masked_prod),
+  msg_iter);
+   } else {
+   copy_from_iter(data->out + masked_prod, len, msg_iter);
+   }
+   }
+   /* write to ring before updating pointer */
+   virt_wmb();
+   intf->out_prod += len;
+
+   return len;


You are returning size_t. I actually was going to ask in one of the 
previous patches whether using int for sizes was correct. Unfortunately 
I can't remember which struct/function I was looking at ;-(


Of course, you are also possibly returning a (negative) error here.


+}
+
+int pvcalls_front_sendmsg(struct socket *sock, struct msghdr *msg,
+ size_t len)
+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   int sent = 0, tot_sent = 0;


'sent' doesn't need to be initialized.


+   int count = 0, flags;
+
+   if (!pvcalls_front_dev)
+   return -ENOTCONN;
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
+   if (!map)
+   return -ENOTSOCK;


IIRC the error value for sk_send_head being zero is inconsistent across 
patches.



+
+   flags = msg->msg_flags;
+   if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
+   return -EOPNOTSUPP;
+
+   mutex_lock(>active.out_mutex);
+   

Re: [Xen-devel] [PATCH v3 08/13] xen/pvcalls: implement accept command

2017-08-14 Thread Boris Ostrovsky



+
+ret = bedata->rsp[req_id].ret;


You can just return bedata->rsp[req_id].ret;


Or maybe not. The slot may get reused by the time you get to the end.

-boris



-boris


+/* read ret, then set this rsp slot to be reused */
+smp_mb();
+WRITE_ONCE(bedata->rsp[req_id].req_id, PVCALLS_INVALID_ID);
+WRITE_ONCE(map->passive.inflight_req_id, PVCALLS_INVALID_ID);
+return ret;
+}


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


Re: [Xen-devel] [PATCH v3 08/13] xen/pvcalls: implement accept command

2017-08-14 Thread Boris Ostrovsky



On 07/31/2017 06:57 PM, Stefano Stabellini wrote:

Introduce a waitqueue to allow only one outstanding accept command at
any given time and to implement polling on the passive socket. Introduce
a flags field to keep track of in-flight accept and poll commands.

Send PVCALLS_ACCEPT to the backend. Allocate a new active socket. Make
sure that only one accept command is executed at any given time by
setting PVCALLS_FLAG_ACCEPT_INFLIGHT and waiting on the
inflight_accept_req waitqueue.

Convert the new struct sock_mapping pointer into an uint64_t and use it
as id for the new socket to pass to the backend.

Check if the accept call is non-blocking: in that case after sending the
ACCEPT command to the backend store the sock_mapping pointer of the new
struct and the inflight req_id then return -EAGAIN (which will respond
only when there is something to accept). Next time accept is called,
we'll check if the ACCEPT command has been answered, if so we'll pick up
where we left off, otherwise we return -EAGAIN again.

Note that, differently from the other commands, we can use
wait_event_interruptible (instead of wait_event) in the case of accept
as we are able to track the req_id of the ACCEPT response that we are
waiting.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
  drivers/xen/pvcalls-front.c | 111 
  drivers/xen/pvcalls-front.h |   3 ++
  2 files changed, 114 insertions(+)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index b2757f5..f83b910 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -65,6 +65,16 @@ struct sock_mapping {
  #define PVCALLS_STATUS_BIND  1
  #define PVCALLS_STATUS_LISTEN2
uint8_t status;
+   /*
+* Internal state-machine flags.
+* Only one accept operation can be inflight for a socket.
+* Only one poll operation can be inflight for a given socket.
+*/
+#define PVCALLS_FLAG_ACCEPT_INFLIGHT 0
+   uint8_t flags;
+   uint32_t inflight_req_id;
+   struct sock_mapping *accept_map;
+   wait_queue_head_t inflight_accept_req;
} passive;
};
  };
@@ -414,6 +424,107 @@ int pvcalls_front_listen(struct socket *sock, int backlog)
return ret;
  }
  
+int pvcalls_front_accept(struct socket *sock, struct socket *newsock, int flags)

+{
+   struct pvcalls_bedata *bedata;
+   struct sock_mapping *map;
+   struct sock_mapping *map2 = NULL;
+   struct xen_pvcalls_request *req;
+   int notify, req_id, ret, evtchn, nonblock;
+
+   if (!pvcalls_front_dev)
+   return -ENOTCONN;
+   bedata = dev_get_drvdata(_front_dev->dev);
+
+   map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
+   if (!map)
+   return -ENOTSOCK;
+
+   if (map->passive.status != PVCALLS_STATUS_LISTEN)
+   return -EINVAL;
+
+   nonblock = flags & SOCK_NONBLOCK;
+   /*
+* Backend only supports 1 inflight accept request, will return
+* errors for the others
+*/
+   if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+(void *)>passive.flags)) {
+   req_id = READ_ONCE(map->passive.inflight_req_id);
+   if (req_id != PVCALLS_INVALID_ID &&
+   READ_ONCE(bedata->rsp[req_id].req_id) == req_id)
+   goto received;
+   if (nonblock)
+   return -EAGAIN;
+   if (wait_event_interruptible(map->passive.inflight_accept_req,
+   !test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
+ (void *)>passive.flags)))
+   return -EINTR;
+   }
+
+   spin_lock(>pvcallss_lock);
+   ret = get_request(bedata, _id);
+   if (ret < 0) {
+   spin_unlock(>pvcallss_lock);
+   return ret;
+   }   
+   map2 = kzalloc(sizeof(*map2), GFP_KERNEL);
+   if (map2 == NULL)
+   return -ENOMEM;
+   ret =  create_active(map2, );
+   if (ret < 0) {
+   kfree(map2);



In the connect patch create_active() frees maps2 (and I had some 
comments about it)




+   return -ENOMEM;


Both error paths need an unlock.


+   }
+   list_add_tail(>list, >socket_mappings);
+
+   req = RING_GET_REQUEST(>ring, req_id);
+   req->req_id = req_id;
+   req->cmd = PVCALLS_ACCEPT;
+   req->u.accept.id = (uint64_t) map;
+   req->u.accept.ref = map2->active.ref;
+   req->u.accept.id_new = (uint64_t) map2;
+   req->u.accept.evtchn = evtchn;
+   map->passive.accept_map = map2;
+
+   bedata->ring.req_prod_pvt++;
+   RING_PUSH_REQUESTS_AND_CHECK_NOTIFY(>ring, notify);
+   

[Xen-devel] [linux-next test] 112629: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread osstest service owner
flight 112629 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112629/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 112551
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 112551
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 112551
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 112551
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112551
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 112551
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 112551
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
112551
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112551
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 112551

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 112551

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112551
 build-arm64   2 hosts-allocate  broken like 112551
 build-arm64   3 capture-logsbroken like 112551
 build-arm64-pvops 2 hosts-allocate  broken like 112551
 build-arm64-xsm   3 capture-logsbroken like 112551
 build-arm64-pvops 3 capture-logsbroken like 112551
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112551
 test-amd64-amd64-examine  7 reboot   fail  like 112551
 test-amd64-amd64-pair10 xen-boot/src_hostfail  like 112551
 test-amd64-amd64-pair11 xen-boot/dst_hostfail  like 112551
 test-amd64-amd64-amd64-pvgrub  7 xen-boot fail like 112551
 test-amd64-amd64-rumprun-amd64  7 xen-bootfail like 112551
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112551
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112551
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112551
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112551
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112551
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 

Re: [Xen-devel] [stage1-xen PATCH v1] init: Add `glide.lock`

2017-08-14 Thread Stefano Stabellini
Thank you for the patch. Usually the description that you sent in the
previous email is written here.

I like the build.sh changes and I think introducing init/glide.yaml is a
great idea. But I don't think that introducing init/glide.lock is
necessary, is it? We could let glide generate it on the fly based on the
key versioning info already specified in glide.yaml.

For example, this patch already introduces:

  - package: github.com/containernetworking/cni
version: 0.3.0

to glide.yaml. Are there any other reasons for committing glide.lock to
the repository instead of generating it?


On Sat, 12 Aug 2017, Rajiv Ranganath wrote:
> Signed-off-by: Rajiv Ranganath 
> ---
>  build.sh|5 +--
>  init/glide.lock |   89 
> +++
>  init/glide.yaml |   23 ++
>  3 files changed, 114 insertions(+), 3 deletions(-)
>  create mode 100644 init/glide.lock
>  create mode 100644 init/glide.yaml
> 
> diff --git a/build.sh b/build.sh
> index ec56093..6c34890 100755
> --- a/build.sh
> +++ b/build.sh
> @@ -83,10 +83,9 @@ if [ -f stage1-xen.aci ]; then
>  fi
>  
>  # Build init
> -go get github.com/hashicorp/errwrap
>  cd init
> -glide init || true
> -glide up -v 
> +rm -rf vendor
> +glide install -v
>  cd ..
>  go build -o target/rootfs/init init/init.go
>  
> diff --git a/init/glide.lock b/init/glide.lock
> new file mode 100644
> index 000..f512bc7
> --- /dev/null
> +++ b/init/glide.lock
> @@ -0,0 +1,89 @@
> +hash: eb0d5fbb629911862615dfdc4dde5283949af890a06d3ff70662e507385bd14b
> +updated: 2017-08-12T09:56:42.779804672Z
> +imports:
> +- name: github.com/appc/spec
> +  version: 210e2995a04148739121566b71b7440512467cc2
> +  subpackages:
> +  - aci
> +  - pkg/device
> +  - pkg/tarheader
> +  - schema
> +  - schema/common
> +  - schema/types
> +  - schema/types/resource
> +- name: github.com/containernetworking/cni
> +  version: 5c3c17164270150467498a32c71436c7cd5501be
> +  subpackages:
> +  - pkg/ip
> +  - pkg/ns
> +  - pkg/types
> +  - pkg/utils
> +  - pkg/utils/sysctl
> +- name: github.com/coreos/go-iptables
> +  version: f2ede9c85e2fac4d72d5a9af0af59c0858d7a3bd
> +  subpackages:
> +  - iptables
> +- name: github.com/coreos/go-semver
> +  version: 1817cd4bea52af76542157eeabd74b057d1a199e
> +  subpackages:
> +  - semver
> +- name: github.com/coreos/go-systemd
> +  version: d2196463941895ee908e13531a23a39feb9e1243
> +  subpackages:
> +  - unit
> +- name: github.com/d2g/dhcp4
> +  version: fcbeb8a548ebd34b55134f2833c5b036a941aa82
> +- name: github.com/d2g/dhcp4client
> +  version: 8ca8fe2cad1770f068782377ec6be6733c01a96b
> +- name: github.com/hashicorp/errwrap
> +  version: 7554cd9344cec97297fa6649b055a8c98c2a1e55
> +- name: github.com/rkt/rkt
> +  version: 142050d1a558ab07f6eeddea55c0f51053a99b05
> +  subpackages:
> +  - common
> +  - common/cgroup
> +  - common/cgroup/v1
> +  - common/cgroup/v2
> +  - common/networking
> +  - networking/netinfo
> +  - networking/tuntap
> +  - pkg/acl
> +  - pkg/fileutil
> +  - pkg/flag
> +  - pkg/fs
> +  - pkg/group
> +  - pkg/log
> +  - pkg/mountinfo
> +  - pkg/passwd
> +  - pkg/sys
> +  - pkg/user
> +  - stage1/common
> +  - stage1/common/types
> +  - stage1/init/common
> +- name: github.com/spf13/pflag
> +  version: e57e3eeb33f795204c1ca35f56c44f83227c6e66
> +- name: github.com/sstabellini/rkt
> +  version: 8a57cb8b6682ed8fef054f57efef292781597fde
> +  subpackages:
> +  - networking
> +- name: github.com/syndtr/gocapability
> +  version: db04d3cc01c8b54962a58ec7e491717d06cfcc16
> +  subpackages:
> +  - capability
> +- name: github.com/vishvananda/netlink
> +  version: f5a6f697a596c788d474984a38a0ac4ba0719e93
> +  subpackages:
> +  - nl
> +- name: github.com/vishvananda/netns
> +  version: 86bef332bfc3b59b7624a600bd53009ce91a9829
> +- name: go4.org
> +  version: 034d17a462f7b2dcd1a4a73553ec5357ff6e6c6e
> +  subpackages:
> +  - errorutil
> +- name: golang.org/x/sys
> +  version: e42485b6e20ae7d2304ec72e535b103ed350cc02
> +  subpackages:
> +  - unix
> +- name: gopkg.in/inf.v0
> +  version: 3887ee99ecf07df5b447e9b00d9c0b2adaa9f3e4
> +testImports: []
> diff --git a/init/glide.yaml b/init/glide.yaml
> new file mode 100644
> index 000..3919338
> --- /dev/null
> +++ b/init/glide.yaml
> @@ -0,0 +1,23 @@
> +package: github.com/rkt/stage1-xen/init
> +import:
> +- package: github.com/appc/spec
> +  subpackages:
> +  - schema/types
> +- package: github.com/hashicorp/errwrap
> +- package: github.com/rkt/rkt
> +  subpackages:
> +  - common
> +  - common/networking
> +  - pkg/flag
> +  - pkg/log
> +  - pkg/sys
> +  - stage1/common
> +  - stage1/common/types
> +  - stage1/init/common
> +- package: github.com/sstabellini/rkt
> +  subpackages:
> +  - networking
> +- package: github.com/containernetworking/cni
> +  version: 0.3.0
> +- package: github.com/d2g/dhcp4
> +- package: github.com/d2g/dhcp4client
> 

___
Xen-devel mailing list

[Xen-devel] [qemu-mainline test] 112631: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread osstest service owner
flight 112631 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112631/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  5 host-ping-check-native   fail REGR. vs. 112610

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112610
 build-arm64-xsm   2 hosts-allocate  broken like 112610
 build-arm64-xsm   3 capture-logsbroken like 112610
 build-arm64   3 capture-logsbroken like 112610
 build-arm64-pvops 2 hosts-allocate  broken like 112610
 build-arm64-pvops 3 capture-logsbroken like 112610
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112603
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112610
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112610
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112610
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112610
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub968316069abd00feb7a3bc9f4e32ed6c227ea65
baseline version:
 qemuu9db6ffc76676731a25a5538ab71e8ca6ac234f80

Last test of basis   112610  2017-08-12 15:47:13 Z2 days
Testing same since   112631  2017-08-14 11:20:02 Z0 days1 attempts


People who touched revisions under test:
  Cornelia Huck 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  

Re: [Xen-devel] stage1-xen for Fedora

2017-08-14 Thread Stefano Stabellini
Sorry for the late reply, I am usually much faster replying to emails,
I have been caught in a personal issue.

On Tue, 8 Aug 2017, Rajiv Ranganath wrote:
> Hi Stefano,
> 
> On Wed, Aug 2, 2017 at 12:15 AM, Stefano Stabellini
>  wrote:
> 
> [...]
> 
> > The main thing that will be different is the list of dependencies you
> > need to install to build Xen. On Fedora it should be (I am using
> > Raisin[1] as a reference):
> 
> Thank you for the pointer to Raisin.
> 
> I have managed to build stage1-xen on Fedora. This project is very
> interesting. I have some questions regarding stage1-xen and containers
> on Xen.

Thank you, I am glad I could help! :-)


> 1. Is there a roadmap/design doc for containers primitives and container
> standards that Xen community is looking to support?
> 
> The only documentation that I could find were presentations by you.
> [1][2]

Not yet, the project is quite new, but we should definitely have one. On
my roadmap I have better support for all rkt commands, including for
example PoDs with multiple stage2s, and support for all rkt networking
modes.


> 2. Now that OCI 1.0 is out, are there any plans to create a Xen based
> OCI runtime? [3]
> 
> A Xen based OCI runtime that can work with containerd and cri-o would be
> very interesting to us.
> 
> I was wondering if you have thoughts on how xen-stage1 could be evolved
> to support rkt and also also a OCI runtime?

This is a very good question, I am glad you asked :-)

I would love to see more OCI runtimes supported, including containerd. I
started with rkt because it has a very nice and clean interface to the
stage1s. In other words, implementing stage1-xen for rkt is rather easy,
doing the same for Docker is possible but more work. I don't think the
difficulty would be on the stage1-xen side. The issue is that other OCI
runtimes would need more changes to be able to interface with something
like stage1-xen. Of course, I would be happy to see more OCI runtimes
supported and I would be happy to help.

Similarly, growing stage1-xen into its own OCI runtime would pull a
lot of code into the project that today we don't have to worry about.

In other words, I would be happy to take any contributions to stage1-xen
to expand OCI runtime support. However, I think it would be best to
focus on completing rkt support first.


> 3. Are there plans to use PVHv2 guests instead of PV guests?

Yes! I want stage1-xen to default to PVHv2 guests wherever possible
(all machines with VMX support).


> 4. In the presentation I noticed PV Calls for Networking. However when I
> did `rkt run ...`, it seems to use netback with vif-nat. How can I try
> PV calls for networking?
> 
> [...]

It's not yet upstream, but I have all the patches ready on my local
machine. I am just waiting for PVCalls to go upstream in Linux. PVCalls
will be very useful to implement the host networking mode of rkt.


> > Let me know if you find any issues!
> 
> Following are the issues that I ran into -
> 
> 1. `rkt rm ...` fails with `stage1/rootfs/gc` file not found error. I
> think because of this the Xen host gets populated with a lot of
> overlayfs mounts. I tried to manually clean up, but that failed too.

That is strage, I'll give it a look.


> 2. Upstream cni master seems to have reorganized its directory
> structure. So, I had to pin the version to 0.3 to get the build to work.
> I also had to manually get dhcp4 and dhcp4client packages. Perhaps we
> can add a glide.lock file to lock down the dependencies. I can send a
> patch for it.

Good idea, thank you.


> > I would be very happy to take a patch (or pull request) for
> > BUILDING.md to document how to do this on Fedora.
> 
> I have a somewhat "non-standard" setup for xen and qemu for Fedora. I'll
> briefly describe the setup.
> 
> Xen is booted using EFI. This required building a custom binutils
> package [4]. Both Xen and qemu are built with a non-standard prefix
> (/opt/xen-unstable and /opt/qemu-stable), with RPATHs appropriately
> adjusted.
> 
> Lastly I don't use systemd to manage Xen on Fedora. In the buildroot,
> Xen is explicitly configured using --disable-systemd. We have a version
> of runit package that we run under systemd. Runit then launches
> xenstore, xenconsole, dom0 qemu disk backend. We frequently toggle
> between upstart and systemd based distro, so using runit on both has
> been very helpful.
> 
> If this setup is okay you, I can open up the Fedora variant of our tools
> and packages and send patches to BUILDING.md.

I would prefer "standard" instructions for Fedora, but non-standard is
better than no instructions :-)  Please send a patch.


> Please let me know.
> 
> Thank you!
> 
> Best,
> Rajiv
> 
> [1]: 
> https://xendeveloperanddesignsummit2017.sched.com/event/AjGx/keynote-secure-containers-with-xen-and-coreos-rkt-stefano-stabellini-aporeto
> [2]: 
> https://docs.google.com/presentation/d/1dP_7myrUrtwQHnjgDtlMQkAxJNG6Se9SBl0tdaFIAYQ/edit?usp=sharing
> [3]: 
> 

[Xen-devel] [linux-linus test] 112626: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread osstest service owner
flight 112626 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112626/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-armhf-armhf-xl-vhd   6 xen-install  fail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 

Re: [Xen-devel] [PATCH v8 11/13] arm/mem_access: Add long-descriptor based gpt

2017-08-14 Thread Sergej Proskurin
Hi Julien,

On 08/14/2017 07:37 PM, Julien Grall wrote:
> Hi Sergej,
> 
> On 09/08/17 09:20, Sergej Proskurin wrote:
>> +/*
>> + * According to to ARM DDI 0487B.a J1-5927, we return an error if
>> the found
> 
> Please drop one of the 'to'. The rest looks good to me.
> 

Great, thanks. I will remove the second "to" in v9. Would that be an
Acked-by or shall I tag this patch with a Reviewed-by you?

Thanks,
~Sergej

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


Re: [Xen-devel] [PATCH 3/3] xen: remove not used trace functions

2017-08-14 Thread Steven Rostedt
On Fri, 4 Aug 2017 15:35:06 -0400
Boris Ostrovsky  wrote:

> On 08/04/2017 07:36 AM, Juergen Gross wrote:
> > There are some Xen specific trace functions defined in
> > include/trace/events/xen.h. Remove them.
> >
> > Signed-off-by: Juergen Gross   
> 
> (Again, adding Ingo and Steven)

Feel free to add:

Acked-by: Steven Rostedt (VMware) 

to both.

-- Steve

> 
> Reviewed-by: Boris Ostrovsky 
> 
> although I think "s/some Xen/some unused Xen/" in the commit message
> would make it clearer.
> 

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


Re: [Xen-devel] [PATCH 2/3] xen: remove unused function xen_set_domain_pte()

2017-08-14 Thread Steven Rostedt
On Fri, 4 Aug 2017 15:20:30 -0400
Boris Ostrovsky  wrote:

> On 08/04/2017 07:36 AM, Juergen Gross wrote:
> > The function xen_set_domain_pte() is used nowhere in the kernel.
> > Remove it.
> >
> > Signed-off-by: Juergen Gross   
> 
> Reviewed-by: Boris Ostrovsky 
> 
> (+ Ingo and Steven who are maintainers of include/trace/events/xen.h)

But the maintainers of where the tracepoints are located have final
say (in this case, the Xen maintainers). I like to be Cc'd to make sure
that the events are efficient and don't waste cpu unnecessary CPU
cycles or memory.

-- Steve

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


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

2017-08-14 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0024172d909ec73a9ce9ffdfc9fdd4382080e110
baseline version:
 ovmf 79de8c79cdef26e5578050b7f1a206745c6cff14

Last test of basis71973  2017-08-14 07:50:11 Z0 days
Testing same since71974  2017-08-14 18:17:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Hao Wu 
  Jiaxin Wu 
  Wu Jiaxin 

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 0024172d909ec73a9ce9ffdfc9fdd4382080e110
Author: Andrew Fish 
Date:   Mon Aug 7 11:26:05 2017 +0800

BaseTools: Fix Segmentation fault: 11 when build AppPkg with XCODE5

it is a bug in mtoc setting the size of the debug directory entry to
the size of the .debug section, not the size of the
EFI_IMAGE_DEBUG_DIRECTORY_ENTRY. It was causing a loop to iterate and
get bogus EFI_IMAGE_DEBUG_DIRECTORY_ENTRY data and pass that to
memset() and boom.

Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Andrew Fish 
Reviewed-by: Liming Gao 

commit 7b1dbd15ea00d09f5e8b1fe0f6c97f1eba0f7efe
Author: Jiaxin Wu 
Date:   Mon Jan 23 10:18:30 2017 +0800

NetworkPkg/HttpBootDxe: Update device path node to include DNS information

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 67e0bbd6c34942a238c8381d14aa984b30f27f0c
Author: Jiaxin Wu 
Date:   Tue Jan 24 11:51:01 2017 +0800

MdeModulePkg/UefiBootManagerLib: Support DNS device path description

This patch is to update UEFI Boot manager to support DNS device path
for HTTP(S) network boot.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit 9b9d0655c1547384c2b34cea94eab4b8b83bd1b9
Author: Jiaxin Wu 
Date:   Tue Jul 25 11:08:16 2017 +0800

MdePkg/UefiDevicePathLib: Add DevPathFromTextDns and DevPathToTextDns 
libraries

V3:
* Fix the bug in DevPathFromTextDns()

V2:
* Add no IP instance case check.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 

commit ecbabb7f8bf435c69bac97dee22899471294319b
Author: Jiaxin Wu 
Date:   Mon Jan 23 10:17:58 2017 +0800

MdePkg/DevicePath.h: Add DNS Device Path definition

This patch adds the DNS device path node definition.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

commit b92efc9fe5aebf4115e076c3ef44c82b21da4e20
Author: Hao Wu 
Date:   Tue Aug 8 16:34:43 2017 +0800

MdeModulePkg/EmmcDxe: Make sure no extra data is erased by EraseBlocks

V3 changes:
Add debug messages for new return 

[Xen-devel] [linux-4.9 test] 112627: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread osstest service owner
flight 112627 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112627/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   6 xen-buildfail REGR. vs. 112513

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112513
 build-arm64-pvops 3 capture-logsbroken like 112513
 build-arm64   2 hosts-allocate  broken like 112513
 build-arm64   3 capture-logsbroken like 112513
 build-arm64-xsm   2 hosts-allocate  broken like 112513
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112513
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 112497
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112497
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112513
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112513
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6da35f43acde8f718b53f6f05fc865bffa709fc5
baseline version:
 linuxdb397d9c6e66afdd34ae430172db122632b5f8a7

Last test of basis   112513  2017-08-07 20:19:27 Z6 days
Failing since112599  2017-08-11 16:18:32 Z3 days6 attempts
Testing same since   112616  2017-08-13 06:39:58 Z1 days3 attempts


Re: [Xen-devel] [xen-unstable test] 112618: regressions - trouble: blocked/broken/fail/pass

2017-08-14 Thread Julien Grall

Hi,

On 14/08/17 00:20, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 6 kernel-build   fail in 112608 REGR. vs. 112544


Something is a bit odd here. Why 112608 would affect this test?

Cheers,

--
Julien Grall

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


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

2017-08-14 Thread osstest service owner
flight 112628 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112628/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0024172d909ec73a9ce9ffdfc9fdd4382080e110
baseline version:
 ovmf 79de8c79cdef26e5578050b7f1a206745c6cff14

Last test of basis   112623  2017-08-14 00:47:13 Z0 days
Testing same since   112628  2017-08-14 07:47:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Fish 
  Hao Wu 
  Jiaxin Wu 
  Wu Jiaxin 

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=0024172d909ec73a9ce9ffdfc9fdd4382080e110
+ . ./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 
0024172d909ec73a9ce9ffdfc9fdd4382080e110
+ branch=ovmf
+ revision=0024172d909ec73a9ce9ffdfc9fdd4382080e110
+ . ./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.9-testing
+ '[' x0024172d909ec73a9ce9ffdfc9fdd4382080e110 = 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 v8 11/13] arm/mem_access: Add long-descriptor based gpt

2017-08-14 Thread Julien Grall

Hi Sergej,

On 09/08/17 09:20, Sergej Proskurin wrote:

+/*
+ * According to to ARM DDI 0487B.a J1-5927, we return an error if the found


Please drop one of the 'to'. The rest looks good to me.


+ * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the PTE
+ * maps a memory block at level 3 (PTE<1:0> == 01).
+ */
+if ( !lpae_is_page(pte, level) && !lpae_is_superpage(pte, level) )
+return -EFAULT;
+
+/* Make sure that the lower bits of the PTE's base address are zero. */
+mask = GENMASK_ULL(47, grainsizes[gran]);
+*ipa = (pfn_to_paddr(pte.walk.base) & mask) | (gva & masks[gran][level]);
+
+/*
+ * Set permissions so that the caller can check the flags by herself. Note
+ * that stage 1 translations also inherit attributes from the tables
+ * (ARM DDI 0487B.a J1-5928).
+ */
+if ( !pte.pt.ro && !ro_table )
+*perms |= GV2M_WRITE;
+if ( !pte.pt.xn && !xn_table )
+*perms |= GV2M_EXEC;
+
+return 0;
 }


Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v8 09/13] arm/guest_access: Rename vgic_access_guest_memory

2017-08-14 Thread Julien Grall

Hi Sergej,

On 09/08/17 09:20, Sergej Proskurin wrote:

This commit renames the function vgic_access_guest_memory to
access_guest_memory_by_ipa. As the function name suggests, the functions
expects an IPA as argument. All invocations of this function have been
adapted accordingly. Apart from that, we have adjusted all printk
messages for cleanup and to eliminate artefacts of the function's
previous location.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v6: We added this patch to our patch series.

v7: Renamed the function's argument ipa back to gpa.

Removed any mentioning of "vITS" in the function's printk messages
and adjusted the commit message accordingly.
---
 xen/arch/arm/guestcopy.c   | 10 +-
 xen/arch/arm/vgic-v3-its.c | 36 ++--
 xen/include/asm-arm/guest_access.h |  4 ++--
 3 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/guestcopy.c b/xen/arch/arm/guestcopy.c
index 938ffe2668..4ee07fcea3 100644
--- a/xen/arch/arm/guestcopy.c
+++ b/xen/arch/arm/guestcopy.c
@@ -123,8 +123,8 @@ unsigned long raw_copy_from_guest(void *to, const void 
__user *from, unsigned le
  * Temporarily map one physical guest page and copy data to or from it.
  * The data to be copied cannot cross a page boundary.
  */
-int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
- uint32_t size, bool is_write)
+int access_guest_memory_by_ipa(struct domain *d, paddr_t gpa, void *buf,
+   uint32_t size, bool is_write)
 {
 struct page_info *page;
 uint64_t offset = gpa & ~PAGE_MASK;  /* Offset within the mapped page */
@@ -134,7 +134,7 @@ int vgic_access_guest_memory(struct domain *d, paddr_t gpa, 
void *buf,
 /* Do not cross a page boundary. */
 if ( size > (PAGE_SIZE - offset) )
 {
-printk(XENLOG_G_ERR "d%d: vITS: memory access would cross page 
boundary\n",
+printk(XENLOG_G_ERR "d%d: guestcopy: memory access crosses page 
boundary.\n",
d->domain_id);
 return -EINVAL;
 }
@@ -142,7 +142,7 @@ int vgic_access_guest_memory(struct domain *d, paddr_t gpa, 
void *buf,
 page = get_page_from_gfn(d, paddr_to_pfn(gpa), , P2M_ALLOC);
 if ( !page )
 {
-printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
+printk(XENLOG_G_ERR "d%d: guestcopy: failed to get table entry.\n",
d->domain_id);
 return -EINVAL;
 }
@@ -150,7 +150,7 @@ int vgic_access_guest_memory(struct domain *d, paddr_t gpa, 
void *buf,
 if ( !p2m_is_ram(p2mt) )
 {
 put_page(page);
-printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
+printk(XENLOG_G_ERR "d%d: guestcopy: guest memory should be RAM.\n",
d->domain_id);
 return -EINVAL;
 }
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 1af6820cab..72a5c70656 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -131,9 +131,9 @@ static int its_set_collection(struct virt_its *its, 
uint16_t collid,
 if ( collid >= its->max_collections )
 return -ENOENT;

-return vgic_access_guest_memory(its->d,
-addr + collid * sizeof(coll_table_entry_t),
-_id, sizeof(vcpu_id), true);
+return access_guest_memory_by_ipa(its->d,
+  addr + collid * 
sizeof(coll_table_entry_t),
+  _id, sizeof(vcpu_id), true);
 }

 /* Must be called with the ITS lock held. */
@@ -149,9 +149,9 @@ static struct vcpu *get_vcpu_from_collection(struct 
virt_its *its,
 if ( collid >= its->max_collections )
 return NULL;

-ret = vgic_access_guest_memory(its->d,
-   addr + collid * sizeof(coll_table_entry_t),
-   _id, sizeof(coll_table_entry_t), 
false);
+ret = access_guest_memory_by_ipa(its->d,
+ addr + collid * 
sizeof(coll_table_entry_t),
+ _id, sizeof(coll_table_entry_t), 
false);
 if ( ret )
 return NULL;

@@ -171,9 +171,9 @@ static int its_set_itt_address(struct virt_its *its, 
uint32_t devid,
 if ( devid >= its->max_devices )
 return -ENOENT;

-return vgic_access_guest_memory(its->d,
-addr + devid * sizeof(dev_table_entry_t),
-_entry, sizeof(itt_entry), true);
+return access_guest_memory_by_ipa(its->d,
+  addr + devid * sizeof(dev_table_entry_t),
+  _entry, sizeof(itt_entry), true);
 }

 /*
@@ -189,9 +189,9 @@ 

Re: [Xen-devel] [PATCH] xen: lift hypercall_cancel_continuation to sched.h

2017-08-14 Thread Julien Grall

Hi Wei,

On 14/08/17 16:46, Wei Liu wrote:

The function is the same on both x86 and arm. Lift it to sched.h to
save a function call, make it take a pointer to vcpu to avoid
resolving current every time it gets called.

Take the chance to change its callers to only use one current in code.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Stefano Stabellini 
Cc: Julien Grall 


For ARM bits:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v3 3/3] arm: traps: handle SMC32 in check_conditional_instr()

2017-08-14 Thread Julien Grall

Hi Volodymyr,

On 14/08/17 18:15, Volodymyr Babchuk wrote:

On ARMv8 architecture we need to ensure that conditional check was passed
for a trapped SMC instruction that originates from AArch32 state
(ARM DDI 0487B.a page D7-2271).
Thus, we should not skip it while checking HSR.EC value.

For this type of exception special coding of HSR.ISS is used. There is
additional flag (CCKNOWNPASS) to be checked before performing standard
handling of CCVALID and COND fields.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/traps.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index eae2212..39791fc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1716,8 +1716,24 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 unsigned long cpsr, cpsr_cond;
 int cond;

+/*
+ * SMC32 instruction case is special. Under SMC32 we mean SMC
+ * instruction on ARMv7 or SMC instruction originating from
+ * AArch32 state on ARMv8.
+ * On ARMv7 it will be trapped only if it passed condition check
+ * (ARM DDI 0406C.c page B3-1431), but we need to check conditon


s/conditon/condition/


+ * flags on ARMv8 (ARM DDI 0487B.a page D7-2271).
+ * Ecoding for HSR.ISS on ARMv8 is backwards compatible with ARMv7:


s/Ecoding/Encoding/


+ * HSR.ISS is defined as UNK/SBZP on ARMv7 which means, that it
+ * will be read as 0. This includes CCKNOWNPASS field.
+ * If CCKNOWNPASS == 0 then this was an uncoditional instruction or


s/uncoditional/unconditional/


+ * it have passed conditional check (ARM DDI 0487B.a page D7-2272).


s/have/has/


+ */
+if (hsr.ec == HSR_EC_SMC32 && hsr.smc32.ccknownpass == 0)


Coding style:

if ( ... )


+return 1;
+
 /* Unconditional Exception classes */
-if ( hsr.ec == HSR_EC_UNKNOWN || hsr.ec >= 0x10 )
+if ( hsr.ec == HSR_EC_UNKNOWN || (hsr.ec >= 0x10 && hsr.ec != 
HSR_EC_SMC32))


Ditto.


 return 1;

 /* Check for valid condition in hsr */



Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v3 1/3] arm: processor: add new struct hsr_smc32 into hsr union

2017-08-14 Thread Julien Grall

Hi Volodymyr,

On 14/08/17 18:15, Volodymyr Babchuk wrote:

On ARMv8, one of conditional exceptions (SMC that originates
from AArch32 state) has extra field in HSR.ISS encoding:

CCKNOWNPASS, bit [19]
Indicates whether the instruction might have failed its condition
code check.
   0 - The instruction was unconditional, or was conditional and
   passed  its condition code check.
   1 - The instruction was conditional, and might have failed its
   condition code check.
(ARM DDI 0487B.a page D7-2272)

This is an instruction specific field, so better to add new structure
to union hsr. This structure describes ISS encoding for an exception
from SMC instruction executing in AArch32 state. But we define this
struct for both ARMv7 and ARMv8, because ARMv8 encoding is backwards
compatible with ARMv7.

Signed-off-by: Volodymyr Babchuk 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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


[Xen-devel] [PATCH v3 3/3] arm: traps: handle SMC32 in check_conditional_instr()

2017-08-14 Thread Volodymyr Babchuk
On ARMv8 architecture we need to ensure that conditional check was passed
for a trapped SMC instruction that originates from AArch32 state
(ARM DDI 0487B.a page D7-2271).
Thus, we should not skip it while checking HSR.EC value.

For this type of exception special coding of HSR.ISS is used. There is
additional flag (CCKNOWNPASS) to be checked before performing standard
handling of CCVALID and COND fields.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/traps.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index eae2212..39791fc 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1716,8 +1716,24 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 unsigned long cpsr, cpsr_cond;
 int cond;
 
+/*
+ * SMC32 instruction case is special. Under SMC32 we mean SMC
+ * instruction on ARMv7 or SMC instruction originating from
+ * AArch32 state on ARMv8.
+ * On ARMv7 it will be trapped only if it passed condition check
+ * (ARM DDI 0406C.c page B3-1431), but we need to check conditon
+ * flags on ARMv8 (ARM DDI 0487B.a page D7-2271).
+ * Ecoding for HSR.ISS on ARMv8 is backwards compatible with ARMv7:
+ * HSR.ISS is defined as UNK/SBZP on ARMv7 which means, that it
+ * will be read as 0. This includes CCKNOWNPASS field.
+ * If CCKNOWNPASS == 0 then this was an uncoditional instruction or
+ * it have passed conditional check (ARM DDI 0487B.a page D7-2272).
+ */
+if (hsr.ec == HSR_EC_SMC32 && hsr.smc32.ccknownpass == 0)
+return 1;
+
 /* Unconditional Exception classes */
-if ( hsr.ec == HSR_EC_UNKNOWN || hsr.ec >= 0x10 )
+if ( hsr.ec == HSR_EC_UNKNOWN || (hsr.ec >= 0x10 && hsr.ec != 
HSR_EC_SMC32))
 return 1;
 
 /* Check for valid condition in hsr */
-- 
2.7.4


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


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

2017-08-14 Thread osstest service owner
flight 112635 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112635/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112633
 build-arm64   2 hosts-allocate  broken like 112633
 build-arm64-pvops 3 capture-logsbroken like 112633
 build-arm64   3 capture-logsbroken like 112633
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  df8c142211b4559b136f377f58142214288fef8e
baseline version:
 xen  14c6cf41c79b8253690b40ee789110fe69fe39d3

Last test of basis   112633  2017-08-14 14:03:25 Z0 days
Testing same since   112635  2017-08-14 16:03:15 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Jan Beulich 
  Julien Grall 
  Wei Liu 

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



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=df8c142211b4559b136f377f58142214288fef8e
+ . ./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 
df8c142211b4559b136f377f58142214288fef8e
+ branch=xen-unstable-smoke
+ revision=df8c142211b4559b136f377f58142214288fef8e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xdf8c142211b4559b136f377f58142214288fef8e = 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
++ : 

[Xen-devel] [PATCH v3 1/3] arm: processor: add new struct hsr_smc32 into hsr union

2017-08-14 Thread Volodymyr Babchuk
On ARMv8, one of conditional exceptions (SMC that originates
from AArch32 state) has extra field in HSR.ISS encoding:

CCKNOWNPASS, bit [19]
Indicates whether the instruction might have failed its condition
code check.
   0 - The instruction was unconditional, or was conditional and
   passed  its condition code check.
   1 - The instruction was conditional, and might have failed its
   condition code check.
(ARM DDI 0487B.a page D7-2272)

This is an instruction specific field, so better to add new structure
to union hsr. This structure describes ISS encoding for an exception
from SMC instruction executing in AArch32 state. But we define this
struct for both ARMv7 and ARMv8, because ARMv8 encoding is backwards
compatible with ARMv7.

Signed-off-by: Volodymyr Babchuk 
---
 xen/include/asm-arm/processor.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1..926ae68 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -488,6 +488,23 @@ union hsr {
 unsigned long ec:6; /* Exception Class */
 } cp; /* HSR_EC_CP */
 
+/*
+ * This encoding is valid only for ARMv8 (ARM DDI 0487B.a, pages D7-2271 
and
+ * G6-4957). On ARMv7, encoding ISS for EC=0x13 is defined as UNK/SBZP
+ * (ARM DDI 0406C.c page B3-1431). UNK/SBZP means that hardware implements
+ * this field as Read-As-Zero. ARMv8 is backwards compatible with ARMv7:
+ * reading CCKNOWNPASS on ARMv7 will return 0, which means that condition
+ * check was passed or instruction was unconditional.
+ */
+struct hsr_smc32 {
+unsigned long res0:19;  /* Reserved */
+unsigned long ccknownpass:1; /* Instruction passed conditional check */
+unsigned long cc:4;/* Condition Code */
+unsigned long ccvalid:1;/* CC Valid */
+unsigned long len:1;   /* Instruction length */
+unsigned long ec:6;/* Exception Class */
+} smc32; /* HSR_EC_SMC32 */
+
 #ifdef CONFIG_ARM_64
 struct hsr_sysreg {
 unsigned long read:1;   /* Direction */
-- 
2.7.4


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


[Xen-devel] [PATCH v3 2/3] arm: traps: handle unknown exceptions in check_conditional_instr()

2017-08-14 Thread Volodymyr Babchuk
According to ARM architecture reference manual (ARM DDI 0487B.a page D7-2259,
ARM DDI 0406C.c page B3-1426), exception with unknown reason (HSR.EC == 0)
has no valid bits in HSR (apart from HSR.EC), so we can't check if that was
caused by conditional instruction. We need to assume that it is unconditional.

Signed-off-by: Volodymyr Babchuk 
Acked-by: Julien Grall 
---
 xen/arch/arm/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b..eae2212 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1717,7 +1717,7 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 int cond;
 
 /* Unconditional Exception classes */
-if ( hsr.ec >= 0x10 )
+if ( hsr.ec == HSR_EC_UNKNOWN || hsr.ec >= 0x10 )
 return 1;
 
 /* Check for valid condition in hsr */
-- 
2.7.4


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


[Xen-devel] [PATCH v3 0/3] arm: allign check_conditional_instr() with ARMv8

2017-08-14 Thread Volodymyr Babchuk
Hello all,

This is third version of series.

 * Dropped patch that renames hsr.iss to hsr.res0
 * Updated references to ARMv8 ARM (latest revision is used)
 * Added better explanation about ARMv7 and ARMv8 compatibility
 * No code changes. Only comments and commit messages.

Volodymyr Babchuk (3):
  arm: processor: add new struct hsr_smc32 into hsr union
  arm: traps: handle unknown exceptions in check_conditional_instr()
  arm: traps: handle SMC32 in check_conditional_instr()

 xen/arch/arm/traps.c| 18 +-
 xen/include/asm-arm/processor.h | 17 +
 2 files changed, 34 insertions(+), 1 deletion(-)

-- 
2.7.4


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


Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

2017-08-14 Thread Tim Deegan
At 18:21 +0200 on 14 Aug (1502734919), Dario Faggioli wrote:
> On Mon, 2017-08-14 at 14:54 +0100, Tim Deegan wrote:
> > At 15:24 +0200 on 14 Aug (1502724279), Dario Faggioli wrote:
> > > About the former... I'm not sure which check of rcp->cur you're
> > > referring to. I think it's the one in rcu_check_quiescent_state(),
> > > but
> > > then, I'm not sure where to actually put the barrier...
> > 
> > I mean whatever one causes the CPU to DTRT about the new grace
> > period.
> > AFAICT that's the one in __rcu_pending().  The important thing is
> > that
> > that read mustn't be allowed to happen before the write to the
> > idle_cpumask.
> >
> Interestingly enough, someone seems to have had a very similar
> discussion before:
> 
> https://lkml.org/lkml/2005/12/8/155
> 
> >   I'd be inclined to put the barrier right after the
> > cpumask_set_cpu() in rcu_idle_enter().
> > 
> And with conclusions similar to these: :-)
> 
> https://lkml.org/lkml/2005/12/8/308
> 
> I've no idea why they then didn't put an actual barrier in place. This
> thread mention s390's ordering, as at the time, this mechanism was only
> in used there, but they've not added one when making things general.
> 
> IAC, I'm fine putting down one. :-)

Sounds good to me. :)  I think it's required (even on s390!) but of
course there may be other barriers on those paths that happen to DTRT.
E.g. cpumask_set_cpu() itself is implicitly a mb() on x86, (but not,
AFAICT, on ARM).

Cheers,

Tim.

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


Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

2017-08-14 Thread Anthony PERARD
On Mon, Aug 14, 2017 at 06:53:14PM +0300, Michael S. Tsirkin wrote:
> On Mon, Aug 14, 2017 at 03:55:50PM +0100, Anthony PERARD wrote:
> > On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
> > > On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> > > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > > > set, but this was done only when ACPI tables are built which is not
> > > > needed for a Xen guest. The need for the property starts with commit
> > > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > > 
> > > > Set pci info before checking for the needs to build ACPI tables.
> > > > 
> > > > Reported-by: Sander Eikelenboom 
> > > > Tested-by: Sander Eikelenboom 
> > > > Signed-off-by: Anthony PERARD 
> > > 
> > > I am worried that Xen will come to depend on specific
> > > assignment of bsel which isn't guaranteed. Thoughts on
> > > how to avoid that?
> > 
> > Is it possible to have a different BSEL than 0 with PIIX ?
> 
> With PCI to PCI bridges, yes.
> 
> > Also, I don't known if having more than on PCI bus is going to work on
> > Xen, there is nothing in our ACPI tables beyond _SB.PCI0, and nothing to
> > use a different BSEL.
> 
> My worry is someone might decide to implement hotplug for pci to pci
> bridges on Xen. If doing that, it's important to use the qemu supplied
> acpi tables.

I can always add assert((xen_enable() && !bsel) || !xen_enable()) in
acpi_set_bsel(), so if someone was going to make any change, he would
find out about bsel quicker. But I don't see Xen using QEMU supplied
ACPI tables anytime soon.

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


Re: [Xen-devel] [PATCH 3/5] xen: RCU/x86/ARM: discount CPUs that were idle when grace period started.

2017-08-14 Thread Dario Faggioli
On Mon, 2017-08-14 at 14:54 +0100, Tim Deegan wrote:
> At 15:24 +0200 on 14 Aug (1502724279), Dario Faggioli wrote:
> > About the former... I'm not sure which check of rcp->cur you're
> > referring to. I think it's the one in rcu_check_quiescent_state(),
> > but
> > then, I'm not sure where to actually put the barrier...
> 
> I mean whatever one causes the CPU to DTRT about the new grace
> period.
> AFAICT that's the one in __rcu_pending().  The important thing is
> that
> that read mustn't be allowed to happen before the write to the
> idle_cpumask.
>
Interestingly enough, someone seems to have had a very similar
discussion before:

https://lkml.org/lkml/2005/12/8/155

>   I'd be inclined to put the barrier right after the
> cpumask_set_cpu() in rcu_idle_enter().
> 
And with conclusions similar to these: :-)

https://lkml.org/lkml/2005/12/8/308

I've no idea why they then didn't put an actual barrier in place. This
thread mention s390's ordering, as at the time, this mechanism was only
in used there, but they've not added one when making things general.

IAC, I'm fine putting down one. :-)

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

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


Re: [Xen-devel] [PATCH v5] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-14 Thread Tamas K Lengyel
On Tue, Aug 8, 2017 at 2:27 AM, Alexandru Isaila
 wrote:
>
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
>
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V4:
> - Changed function mane from xc_allow_guest_userspace_event
>   to xc_monitor_guest_userspace_event
> - Fixed guest_request_enabled check
> - Delete the guest_request_sync
> - Changed guest_request_userspace_event to
>   guest_request_userspace_enabled
> - Moved guest_request_userspace_enabled flag from sched.h to
>   domain.h
> ---
>  tools/libxc/include/xenctrl.h |  1 +
>  tools/libxc/xc_monitor.c  | 14 ++
>  xen/arch/x86/hvm/hypercall.c  |  5 +
>  xen/common/monitor.c  | 13 +
>  xen/include/asm-x86/domain.h  | 19 ++-
>  xen/include/public/domctl.h   | 21 +++--
>  6 files changed, 54 insertions(+), 19 deletions(-)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index bde8313..c72e12d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2022,6 +2022,7 @@ int xc_monitor_descriptor_access(xc_interface *xch, 
> domid_t domain_id,
>   bool enable);
>  int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
>   bool enable, bool sync);
> +int xc_monitor_guest_userspace_event(xc_interface *xch, domid_t domain_id, 
> bool enable);
>  int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
>  bool enable, bool sync);
>  int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
> diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
> index b44ce93..bd8cbcf 100644
> --- a/tools/libxc/xc_monitor.c
> +++ b/tools/libxc/xc_monitor.c
> @@ -161,6 +161,20 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
> domain_id, bool enable,
>  return do_domctl(xch, );
>  }
>
> +int xc_monitor_guest_userspace_event(xc_interface *xch, domid_t domain_id, 
> bool enable)
> +{
> +DECLARE_DOMCTL;
> +
> +domctl.cmd = XEN_DOMCTL_monitor_op;
> +domctl.domain = domain_id;
> +domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
> +: XEN_DOMCTL_MONITOR_OP_DISABLE;
> +domctl.u.monitor_op.event = 
> XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT;
> +
> +return do_domctl(xch, );
> +}
> +
> +
>  int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
>  bool enable)
>  {
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index e7238ce..5742dd1 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
>  /* Fallthrough to permission check. */
>  case 4:
>  case 2:
> +if ( currd->arch.monitor.guest_request_userspace_enabled &&
> +eax == __HYPERVISOR_hvm_op &&
> +(mode == 8 ? regs->rdi : regs->ebx) == 
> HVMOP_guest_request_vm_event )
> +break;
> +

So the CPL check happens after the monitor check, which means this
will trigger regardless if the hypercall is coming from userspace or
kernelspace. Since the monitor option specifically says userspace,
this should probably get moved into the block where CPL was checked.

>  if ( unlikely(hvm_get_cpl(curr)) )
>  {
>  default:
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 451f42f..080a405 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -79,6 +79,19 @@ int monitor_domctl(struct domain *d, struct 
> xen_domctl_monitor_op *mop)
>  break;
>  }
>
> +case XEN_DOMCTL_MONITOR_EVENT_GUEST_USERSPACE_EVENT:
> +{
> +bool old_status = d->arch.monitor.guest_request_userspace_enabled;
> +
> +if ( unlikely(old_status == requested_status) )
> +return -EEXIST;
> +
> +domain_pause(d);
> +d->arch.monitor.guest_request_userspace_enabled = requested_status;
> +domain_unpause(d);
> +break;
> +}
> +
>  default:
>  /* Give arch-side the chance to handle this event */
>  return arch_monitor_domctl_event(d, mop);
> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index c10522b..de02507 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -396,15 +396,16 @@ struct arch_domain
>
>  /* Arch-specific monitor options */

Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

2017-08-14 Thread Michael S. Tsirkin
On Mon, Aug 14, 2017 at 03:55:50PM +0100, Anthony PERARD wrote:
> On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
> > On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> > > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > > set, but this was done only when ACPI tables are built which is not
> > > needed for a Xen guest. The need for the property starts with commit
> > > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > > 
> > > Set pci info before checking for the needs to build ACPI tables.
> > > 
> > > Reported-by: Sander Eikelenboom 
> > > Tested-by: Sander Eikelenboom 
> > > Signed-off-by: Anthony PERARD 
> > 
> > I am worried that Xen will come to depend on specific
> > assignment of bsel which isn't guaranteed. Thoughts on
> > how to avoid that?
> 
> Is it possible to have a different BSEL than 0 with PIIX ?

With PCI to PCI bridges, yes.

> Also, I don't known if having more than on PCI bus is going to work on
> Xen, there is nothing in our ACPI tables beyond _SB.PCI0, and nothing to
> use a different BSEL.

My worry is someone might decide to implement hotplug for pci to pci
bridges on Xen. If doing that, it's important to use the qemu supplied
acpi tables.

> > > 
> > > ---
> > > In this patch rather than always calling acpi_set_pci_info() when
> > > acpi_setup() is called, we could check first for acpi_enabled? (which is
> > > true for Xen.)
> > 
> > Yes, please change it like this. Also, please add
> > a comment explainging what it does.
> 
> Will do.
> 
> -- 
> Anthony PERARD

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


[Xen-devel] [PATCH] xen: lift hypercall_cancel_continuation to sched.h

2017-08-14 Thread Wei Liu
The function is the same on both x86 and arm. Lift it to sched.h to
save a function call, make it take a pointer to vcpu to avoid
resolving current every time it gets called.

Take the chance to change its callers to only use one current in code.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/domain.c   | 5 -
 xen/arch/x86/hypercall.c| 5 -
 xen/arch/x86/x86_64/compat/mm.c | 5 +++--
 xen/common/multicall.c  | 7 ---
 xen/include/xen/sched.h | 6 +-
 5 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0ab5a..eeebbdb39a 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -365,11 +365,6 @@ void sync_vcpu_execstate(struct vcpu *v)
 __arg;  \
 })
 
-void hypercall_cancel_continuation(void)
-{
-current->hcall_preempted = false;
-}
-
 unsigned long hypercall_create_continuation(
 unsigned int op, const char *format, ...)
 {
diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
index e30181817a..90e88c1d2c 100644
--- a/xen/arch/x86/hypercall.c
+++ b/xen/arch/x86/hypercall.c
@@ -86,11 +86,6 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
 __arg;  \
 })
 
-void hypercall_cancel_continuation(void)
-{
-current->hcall_preempted = false;
-}
-
 unsigned long hypercall_create_continuation(
 unsigned int op, const char *format, ...)
 {
diff --git a/xen/arch/x86/x86_64/compat/mm.c b/xen/arch/x86/x86_64/compat/mm.c
index b737af1888..f3fc07c3a9 100644
--- a/xen/arch/x86/x86_64/compat/mm.c
+++ b/xen/arch/x86/x86_64/compat/mm.c
@@ -53,6 +53,7 @@ int compat_arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 compat_pfn_t mfn;
 unsigned int i;
 int rc = 0;
+struct vcpu *curr = current;
 
 switch ( cmd )
 {
@@ -124,7 +125,7 @@ int compat_arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( __copy_to_guest(arg, , 1) )
 {
 if ( rc == __HYPERVISOR_memory_op )
-hypercall_cancel_continuation();
+hypercall_cancel_continuation(curr);
 rc = -EFAULT;
 }
 
@@ -133,7 +134,7 @@ int compat_arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 case XENMEM_machphys_mapping:
 {
-struct domain *d = current->domain;
+struct domain *d = curr->domain;
 struct compat_machphys_mapping mapping = {
 .v_start = MACH2PHYS_COMPAT_VIRT_START(d),
 .v_end   = MACH2PHYS_COMPAT_VIRT_END,
diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index 7cbf857048..c7af4e0156 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -36,7 +36,8 @@ ret_t
 do_multicall(
 XEN_GUEST_HANDLE_PARAM(multicall_entry_t) call_list, uint32_t nr_calls)
 {
-struct mc_state *mcs = >mc_state;
+struct vcpu *curr = current;
+struct mc_state *mcs = >mc_state;
 uint32_t i;
 int  rc = 0;
 enum mc_disposition disp = mc_continue;
@@ -86,7 +87,7 @@ do_multicall(
 else if ( unlikely(__copy_field_to_guest(call_list, >call,
  result)) )
 rc = -EFAULT;
-else if ( current->hcall_preempted )
+else if ( curr->hcall_preempted )
 {
 /* Translate sub-call continuation to guest layout */
 xlat_multicall_entry(mcs);
@@ -95,7 +96,7 @@ do_multicall(
 if ( likely(!__copy_to_guest(call_list, >call, 1)) )
 goto preempted;
 else
-hypercall_cancel_continuation();
+hypercall_cancel_continuation(curr);
 rc = -EFAULT;
 }
 else
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6673b27d88..4b239452c8 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -705,7 +705,11 @@ extern void (*dead_idle) (void);
  */
 unsigned long hypercall_create_continuation(
 unsigned int op, const char *format, ...);
-void hypercall_cancel_continuation(void);
+
+static inline void hypercall_cancel_continuation(struct vcpu *v)
+{
+v->hcall_preempted = false;
+}
 
 /*
  * For long-running operations that must be in hypercall context, check
-- 
2.11.0


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


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

2017-08-14 Thread osstest service owner
flight 112633 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112633/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112630
 build-arm64   2 hosts-allocate  broken like 112630
 build-arm64-pvops 3 capture-logsbroken like 112630
 build-arm64   3 capture-logsbroken like 112630
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  14c6cf41c79b8253690b40ee789110fe69fe39d3
baseline version:
 xen  89fa95485e8a576fdaff955cdc4436165a6e9dce

Last test of basis   112630  2017-08-14 10:01:23 Z0 days
Testing same since   112633  2017-08-14 14:03:25 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=14c6cf41c79b8253690b40ee789110fe69fe39d3
+ . ./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 
14c6cf41c79b8253690b40ee789110fe69fe39d3
+ branch=xen-unstable-smoke
+ revision=14c6cf41c79b8253690b40ee789110fe69fe39d3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x14c6cf41c79b8253690b40ee789110fe69fe39d3 = 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
++ : 

Re: [Xen-devel] [PATCH v7 6/9] spinlock: Introduce spin_lock_cb()

2017-08-14 Thread Boris Ostrovsky
On 08/14/2017 10:42 AM, Julien Grall wrote:
>
>
> On 14/08/17 15:39, Boris Ostrovsky wrote:
>>

 +#define spin_lock_kick(l)   \
 +({  \to understand why
 you need a stronger one here
 +smp_mb();   \
>>>
>>> arch_lock_signal() has already a barrier for ARM. So we have a double
>>> barrier now.
>>>
>>> However, the barrier is slightly weaker (smp_wmb()). I am not sure why
>>> you need to use a stronger barrier here. What you care is the write to
>>> be done before signaling, read does not much matter. Did I miss
>>> anything?
>>
>> Yes, smp_wmb() should be sufficient.
>>
>> Should I then add arch_lock_signal_wmb() --- defined as
>> arch_lock_signal() for ARM and smp_wmb() for x86?
>
> I am not an x86 expert. Do you know why the barrier is not in
> arch_lock_signal() today?

Possibly because _spin_unlock() which is the only instance where
arch_lock_signal is used has arch_lock_release_barrier() (and
preempt_enable has one too). This guarantees that incremented ticket
head will be seen after all previous accesses have completed.



OTOH,

>
>>
>>
>> -boris
>>
>>>
>>> Cheers,
>>>
 +arch_lock_signal(); \
 +})
 +
  /* Ensure a lock is quiescent between two critical operations. */
  #define spin_barrier(l)   _spin_barrier(l)


>>>
>>
>


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


Re: [Xen-devel] [PATCH v2 48/52] xen: add hypercall for setting parameters at runtime

2017-08-14 Thread Daniel De Graaf

On 08/14/2017 03:08 AM, Juergen Gross wrote:

Add a sysctl hypercall to support setting parameters similar to
command line parameters, but at runtime. The parameters to set are
specified as a string, just like the boot parameters.


Acked-by: Daniel De Graaf 

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


Re: [Xen-devel] [PATCH v2 38/52] xen/xsm/flask/flask_op.c: let custom parameter parsing routines return errno

2017-08-14 Thread Daniel De Graaf

On 08/14/2017 03:08 AM, Juergen Gross wrote:

Modify the custom parameter parsing routines in:

xen/xsm/flask/flask_op.c

to indicate whether the parameter value was parsed successfully.


Acked-by: Daniel De Graaf 

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


Re: [Xen-devel] [PATCH for-2.10 1/2] hw/acpi: Call acpi_set_pci_info when no ACPI tables needed

2017-08-14 Thread Anthony PERARD
On Fri, Aug 11, 2017 at 08:18:28PM +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 11, 2017 at 04:11:37PM +0100, Anthony PERARD wrote:
> > To do PCI passthrough with Xen, the property acpi-pcihp-bsel needs to be
> > set, but this was done only when ACPI tables are built which is not
> > needed for a Xen guest. The need for the property starts with commit
> > "pc: pcihp: avoid adding ACPI_PCIHP_PROP_BSEL twice"
> > (f0c9d64a68b776374ec4732424a3e27753ce37b6).
> > 
> > Set pci info before checking for the needs to build ACPI tables.
> > 
> > Reported-by: Sander Eikelenboom 
> > Tested-by: Sander Eikelenboom 
> > Signed-off-by: Anthony PERARD 
> 
> I am worried that Xen will come to depend on specific
> assignment of bsel which isn't guaranteed. Thoughts on
> how to avoid that?

Is it possible to have a different BSEL than 0 with PIIX ?
Also, I don't known if having more than on PCI bus is going to work on
Xen, there is nothing in our ACPI tables beyond _SB.PCI0, and nothing to
use a different BSEL.

> > 
> > ---
> > In this patch rather than always calling acpi_set_pci_info() when
> > acpi_setup() is called, we could check first for acpi_enabled? (which is
> > true for Xen.)
> 
> Yes, please change it like this. Also, please add
> a comment explainging what it does.

Will do.

-- 
Anthony PERARD

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


Re: [Xen-devel] [PATCH v7 6/9] spinlock: Introduce spin_lock_cb()

2017-08-14 Thread Julien Grall



On 14/08/17 15:39, Boris Ostrovsky wrote:




+#define spin_lock_kick(l)   \
+({  \to understand why
you need a stronger one here
+smp_mb();   \


arch_lock_signal() has already a barrier for ARM. So we have a double
barrier now.

However, the barrier is slightly weaker (smp_wmb()). I am not sure why
you need to use a stronger barrier here. What you care is the write to
be done before signaling, read does not much matter. Did I miss anything?


Yes, smp_wmb() should be sufficient.

Should I then add arch_lock_signal_wmb() --- defined as
arch_lock_signal() for ARM and smp_wmb() for x86?


I am not an x86 expert. Do you know why the barrier is not in 
arch_lock_signal() today?





-boris



Cheers,


+arch_lock_signal(); \
+})
+
 /* Ensure a lock is quiescent between two critical operations. */
 #define spin_barrier(l)   _spin_barrier(l)








--
Julien Grall

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


Re: [Xen-devel] [PATCH v7 6/9] spinlock: Introduce spin_lock_cb()

2017-08-14 Thread Boris Ostrovsky

>>
>> +#define spin_lock_kick(l)   \
>> +({  \to understand why
>> you need a stronger one here
>> +smp_mb();   \
>
> arch_lock_signal() has already a barrier for ARM. So we have a double
> barrier now.
>
> However, the barrier is slightly weaker (smp_wmb()). I am not sure why
> you need to use a stronger barrier here. What you care is the write to
> be done before signaling, read does not much matter. Did I miss anything?

Yes, smp_wmb() should be sufficient.

Should I then add arch_lock_signal_wmb() --- defined as
arch_lock_signal() for ARM and smp_wmb() for x86?


-boris

>
> Cheers,
>
>> +arch_lock_signal(); \
>> +})
>> +
>>  /* Ensure a lock is quiescent between two critical operations. */
>>  #define spin_barrier(l)   _spin_barrier(l)
>>
>>
>


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


Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses

2017-08-14 Thread Jan Beulich
>>> On 14.08.17 at 16:23,  wrote:
> On 14/08/17 15:18, Jan Beulich wrote:
>> IOW the note needs to be present for a restriction to
>> be enforced, which in turn means the hypervisor first needs to
>> honor the note.
> 
> I don't think so. How would you get the note into already existing
> kernels having the restriction?

Well, we'd additionally need a guest config setting or some such.

>> Otherwise running a 4-level hypervisor on 5-level
>> capable hardware (with wider than 46-bit physical addresses)
>> would break Linux as well.
> 
> Right. OTOH on such a host bare metal 4-level Linux wouldn't run either
> (or only using less memory).
> 
> With Andrew's comment regarding grant v1 restricting _all_ current pv
> domains using this version to the first 16TB the complete discussion
> might be moot. So do we need an ELF note specifying whether a pv domain
> supports grant v2 in order to position it above 16TB? Or should this
> semantics be included in a kernel specifying its max physical address
> supported above 16TB?

First of all we'd need to enforce the 16Tb boundary in the
hypervisor. Then we could have a note relaxing this; whether
this is the note you propose or a separate one is secondary.

Jan


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


Re: [Xen-devel] [PATCH v2 22/52] xen/arch/x86/x86_64/mmconfig-shared.c: let custom parameter parsing routines return errno

2017-08-14 Thread Juergen Gross
On 14/08/17 15:40, Jan Beulich wrote:
 On 14.08.17 at 09:08,  wrote:
>> @@ -37,13 +37,24 @@ static void __init parse_mmcfg(char *s)
>>  if ( ss )
>>  *ss = '\0';
>>  
>> -if ( !parse_bool(s) )
>> +switch ( parse_bool(s) ) {
>> +case 0:
>>  pci_probe &= ~PCI_PROBE_MMCONF;
>> -else if ( !strcmp(s, "amd_fam10") || !strcmp(s, "amd-fam10") )
>> -pci_probe |= PCI_CHECK_ENABLE_AMD_MMCONF;
>> +break;
>> +case 1:
>> +break;
>> +default:
>> +if ( !strcmp(s, "amd_fam10") || !strcmp(s, "amd-fam10") )
>> +pci_probe |= PCI_CHECK_ENABLE_AMD_MMCONF;
>> +else
>> +return -EINVAL;
>> +break;
>> +}
>>  
>>  s = ss + 1;
>>  } while ( ss );
> 
> Same here (and wherever else I may have overlooked it) - you
> should not return out of loops.

Okay.


Juergen


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


Re: [Xen-devel] [PATCH v2 20/52] xen/arch/x86/shutdown.c: let custom parameter parsing routines return errno

2017-08-14 Thread Juergen Gross
On 14/08/17 15:39, Jan Beulich wrote:
 On 14.08.17 at 09:08,  wrote:
>> --- a/xen/arch/x86/shutdown.c
>> +++ b/xen/arch/x86/shutdown.c
>> @@ -51,7 +51,7 @@ static int reboot_mode;
>>   * efiUse the EFI reboot (if running under EFI)
>>   */
>>  static enum reboot_type reboot_type = BOOT_INVALID;
>> -static void __init set_reboot_type(char *str)
>> +static int __init set_reboot_type(char *str)
>>  {
>>  for ( ; ; )
>>  {
>> @@ -74,6 +74,8 @@ static void __init set_reboot_type(char *str)
>>  case 't':
>>  reboot_type = *str;
>>  break;
>> +default:
>> +return -EINVAL;
> 
> This alters behavior - you want to store -EINVAL in a local variable,
> but continue the loop.

Aah, yes. Okay.


Juergen



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


[Xen-devel] [PATCH v5 04/11] x86/physdev: enable PHYSDEVOP_pci_mmcfg_reserved for PVH Dom0

2017-08-14 Thread Roger Pau Monne
So that MMCFG regions not present in the MCFG ACPI table can be added
at run time by the hardware domain.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Change the hardware_domain check in hvm_physdev_op to a vpci check.
 - Only register the MMCFG area, but don't scan it.

Changes since v3:
 - New in this version.
---
 xen/arch/x86/hvm/hypercall.c | 4 
 xen/arch/x86/hvm/io.c| 7 +++
 xen/arch/x86/physdev.c   | 9 +
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index e7238ce293..369abfd262 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -89,6 +89,10 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( !has_pirq(curr->domain) )
 return -ENOSYS;
 break;
+case PHYSDEVOP_pci_mmcfg_reserved:
+if ( !has_vpci(curr->domain) )
+return -ENOSYS;
+break;
 }
 
 if ( !curr->hcall_compat )
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 2845dc5b48..93c3b21a47 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -524,10 +524,9 @@ static const struct hvm_mmio_ops vpci_mmcfg_ops = {
 .write = vpci_mmcfg_write,
 };
 
-int __hwdom_init register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
- unsigned int start_bus,
- unsigned int end_bus,
- unsigned int seg)
+int register_vpci_mmcfg_handler(struct domain *d, paddr_t addr,
+unsigned int start_bus, unsigned int end_bus,
+unsigned int seg)
 {
 struct hvm_mmcfg *mmcfg;
 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 0eb409758f..10e0a1ad79 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -559,6 +559,15 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) 
arg)
 
 ret = pci_mmcfg_reserved(info.address, info.segment,
  info.start_bus, info.end_bus, info.flags);
+if ( ret || !is_hvm_domain(currd) )
+break;
+
+/*
+ * For HVM (PVH) domains try to add the newly found MMCFG to the
+ * domain.
+ */
+ret = register_vpci_mmcfg_handler(currd, info.address, info.start_bus,
+  info.end_bus, info.segment);
 break;
 }
 
-- 
2.11.0 (Apple Git-81)


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


[Xen-devel] [PATCH v5 10/11] vpci: add a priority parameter to the vPCI register initializer

2017-08-14 Thread Roger Pau Monne
This is needed for MSI-X, since MSI-X will need to be initialized
before parsing the BARs, so that the header BAR handlers are aware of
the MSI-X related holes and make sure they are not mapped in order for
the trap handlers to work properly.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Add a middle priority and add the PCI header to it.

Changes since v3:
 - Add a numerial suffix to the section used to store the pointer to
   each initializer function, and sort them at link time.
---
 xen/arch/arm/xen.lds.S|  4 ++--
 xen/arch/x86/xen.lds.S|  4 ++--
 xen/drivers/vpci/header.c |  2 +-
 xen/drivers/vpci/msi.c|  2 +-
 xen/include/xen/vpci.h| 12 
 5 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 6690516ff1..781ea39ecc 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -43,7 +43,7 @@ SECTIONS
   .rodata : {
 #if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)
__start_vpci_array = .;
-   *(.rodata.vpci)
+   *(SORT(.rodata.vpci.*))
__end_vpci_array = .;
 #endif
 _srodata = .;  /* Read-only data */
@@ -138,7 +138,7 @@ SECTIONS
   .init.data : {
 #if defined(CONFIG_HAS_PCI) && !defined(CONFIG_LATE_HWDOM)
__start_vpci_array = .;
-   *(.init.rodata.vpci)
+   *(SORT(.init.rodata.vpci.*))
__end_vpci_array = .;
 #endif
*(.init.rodata)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index af1b30cb2b..4ed1fe5aff 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -78,7 +78,7 @@ SECTIONS
   .rodata : {
 #if defined(CONFIG_HAS_PCI) && defined(CONFIG_LATE_HWDOM)
__start_vpci_array = .;
-   *(.rodata.vpci)
+   *(SORT(.rodata.vpci.*))
__end_vpci_array = .;
 #endif
_srodata = .;
@@ -174,7 +174,7 @@ SECTIONS
   .init.data : {
 #if defined(CONFIG_HAS_PCI) && !defined(CONFIG_LATE_HWDOM)
__start_vpci_array = .;
-   *(.init.rodata.vpci)
+   *(SORT(.init.rodata.vpci.*))
__end_vpci_array = .;
 #endif
*(.init.rodata)
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 9b44c8441a..1533c36470 100644
--- a/xen/drivers/vpci/header.c
+++ b/xen/drivers/vpci/header.c
@@ -440,7 +440,7 @@ static int vpci_init_bars(struct pci_dev *pdev)
 return 0;
 }
 
-REGISTER_VPCI_INIT(vpci_init_bars);
+REGISTER_VPCI_INIT(vpci_init_bars, VPCI_PRIORITY_MIDDLE);
 
 /*
  * Local variables:
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index 1e36b9779a..181599241a 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -311,7 +311,7 @@ static int vpci_init_msi(struct pci_dev *pdev)
 return 0;
 }
 
-REGISTER_VPCI_INIT(vpci_init_msi);
+REGISTER_VPCI_INIT(vpci_init_msi, VPCI_PRIORITY_LOW);
 
 void vpci_dump_msi(void)
 {
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 21da73df16..66d8ae8b5f 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -34,14 +34,18 @@ typedef void vpci_write_t(struct pci_dev *pdev, unsigned 
int reg,
 typedef int vpci_register_init_t(struct pci_dev *dev);
 
 #ifdef CONFIG_LATE_HWDOM
-#define VPCI_SECTION ".rodata.vpci"
+#define VPCI_SECTION ".rodata.vpci."
 #else
-#define VPCI_SECTION ".init.rodata.vpci"
+#define VPCI_SECTION ".init.rodata.vpci."
 #endif
 
-#define REGISTER_VPCI_INIT(x)   \
+#define VPCI_PRIORITY_HIGH  "1"
+#define VPCI_PRIORITY_MIDDLE"5"
+#define VPCI_PRIORITY_LOW   "9"
+
+#define REGISTER_VPCI_INIT(x, p)\
   static vpci_register_init_t *const x##_entry  \
-   __used_section(VPCI_SECTION) = x
+   __used_section(VPCI_SECTION p) = x
 
 /* Add vPCI handlers to device. */
 int __must_check vpci_add_handlers(struct pci_dev *dev);
-- 
2.11.0 (Apple Git-81)


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


[Xen-devel] [PATCH v5 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space

2017-08-14 Thread Roger Pau Monne
This functionality is going to reside in vpci.c (and the corresponding
vpci.h header), and should be arch-agnostic. The handlers introduced
in this patch setup the basic functionality required in order to trap
accesses to the PCI config space, and allow decoding the address and
finding the corresponding handler that should handle the access
(although no handlers are implemented).

Note that the traps to the PCI IO ports registers (0xcf8/0xcfc) are
setup inside of a x86 HVM file, since that's not shared with other
arches.

A new XEN_X86_EMU_VPCI x86 domain flag is added in order to signal Xen
whether a domain should use the newly introduced vPCI handlers, this
is only enabled for PVH Dom0 at the moment.

A very simple user-space test is also provided, so that the basic
functionality of the vPCI traps can be asserted. This has been proven
quite helpful during development, since the logic to handle partial
accesses or accesses that expand across multiple registers is not
trivial.

The handlers for the registers are added to a linked list that's keep
sorted at all times. Both the read and write handlers support accesses
that expand across multiple emulated registers and contain gaps not
emulated.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v4:
* User-space test harness:
 - Do not redirect the output of the test.
 - Add main.c and emul.h as dependencies of the Makefile target.
 - Use the same rule to modify the vpci and list headers.
 - Remove underscores from local macro variables.
 - Add _check suffix to the test harness multiread function.
 - Change the value written by every different size in the multiwrite
   test.
 - Use { } to initialize the r16 and r20 arrays (instead of { 0 }).
 - Perform some of the read checks with the local variable directly.
 - Expand some comments.
 - Implement a dummy rwlock.
* Hypervisor code:
 - Guard the linker script changes with CONFIG_HAS_PCI.
 - Rename vpci_access_check to vpci_access_allowed and make it return
   bool.
 - Make hvm_pci_decode_addr return the register as return value.
 - Use ~3 instead of 0xfffc to remove the register offset when
   checking accesses to IO ports.
 - s/head/prev in vpci_add_register.
 - Add parentheses around & in vpci_add_register.
 - Fix register removal.
 - Change the BUGs in vpci_{read/write}_hw helpers to
   ASSERT_UNREACHABLE.
 - Make merge_result static and change the computation of the mask to
   avoid using a uint64_t.
 - Modify vpci_read to only read from hardware the not-emulated gaps.
 - Remove the vpci_val union and use a uint32_t instead.
 - Change handler read type to return a uint32_t instead of modifying
   a variable passed by reference.
 - Constify the data opaque parameter of read handlers.
 - Change the size parameter of the vpci_{read/write} functions to
   unsigned int.
 - Place the array of initialization handlers in init.rodata or
   .rodata depending on whether late-hwdom is enabled.
 - Remove the pci_devs lock, assume the Dom0 is well behaved and won't
   remove the device while trying to access it.
 - Change the recursive spinlock into a rw lock for performance
   reasons.

Changes since v3:
* User-space test harness:
 - Fix spaces in container_of macro.
 - Implement a dummy locking functions.
 - Remove 'current' macro make current a pointer to the statically
   allocated vpcu.
 - Remove unneeded parentheses in the pci_conf_readX macros.
 - Fix the name of the write test macro.
 - Remove the dummy EXPORT_SYMBOL macro (this was needed by the RB
   code only).
 - Import the max macro.
 - Test all possible read/write size combinations with all possible
   emulated register sizes.
 - Introduce a test for register removal.
* Hypervisor code:
 - Use a sorted list in order to store the config space handlers.
 - Remove some unneeded 'else' branches.
 - Make the IO port handlers always return X86EMUL_OKAY, and set the
   data to all 1's in case of read failure (write are simply ignored).
 - In hvm_select_ioreq_server reuse local variables when calling
   XEN_DMOP_PCI_SBDF.
 - Store the pointers to the initialization functions in the .rodata
   section.
 - Do not ignore the return value of xen_vpci_add_handlers in
   setup_one_hwdom_device.
 - Remove the vpci_init macro.
 - Do not hide the pointers inside of the vpci_{read/write}_t
   typedefs.
 - Rename priv_data to private in vpci_register.
 - Simplify checking for register overlap in vpci_register_cmp.
 - Check that the offset and the length match before removing a
   register in xen_vpci_remove_register.
 - Make vpci_read_hw return a value rather than storing it in a
   pointer passed by parameter.
 - Handler dispatcher functions vpci_{read/write} no longer return an
   error code, errors on reads/writes should be treated like hardware
  

[Xen-devel] [PATCH v5 08/11] vpci/bars: add handlers to map the BARs

2017-08-14 Thread Roger Pau Monne
Introduce a set of handlers that trap accesses to the PCI BARs and the command
register, in order to snoop BAR sizing and BAR relocation.

The command handler is used to detect changes to bit 2 (response to
memory space accesses), and maps/unmaps the BARs of the device into
the guest p2m. A rangeset is used in order to figure out which memory
to map/unmap. This makes it easier to keep track of the possible
overlaps with other BARs, and will also simplify MSI-X support, where
certain regions of a BAR might be used for the MSI-X table or PBA.

The BAR register handlers are used to detect attempts by the guest to size or
relocate the BARs.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v4:
 - Expand commit message to mention the reason behind the usage of
   rangesets.
 - Fix comment related to the inclusiveness of rangesets.
 - Fix off-by-one error in the calculation of the end of memory
   regions.
 - Store the state of the BAR (mapped/unmapped) in the vpci_bar
   enabled field, previously was only used by ROMs.
 - Fix double negation of return code.
 - Modify vpci_cmd_write so it has a single call to pci_conf_write16.
 - Print a warning when trying to write to the BAR with memory
   decoding enabled (and ignore the write).
 - Remove header_type local variable, it's used only once.
 - Move the read of the command register.
 - Restore previous command register value in the exit paths.
 - Only set address to INVALID_PADDR if the initial BAR value matches
~0 & PCI_BASE_ADDRESS_MEM_MASK.
 - Don't disable the enabled bit in the expansion ROM register, memory
   decoding is already disabled and takes precedence.
 - Don't use INVALID_PADDR, just set the initial BAR address to the
   value found in the hardware.
 - Introduce rom_enabled to store the status of the
   PCI_ROM_ADDRESS_ENABLE bit.
 - Reorder fields of the structure to prevent holes.

Changes since v3:
 - Propagate previous changes: drop xen_ prefix and use u8/u16/u32
   instead of the previous half_word/word/double_word.
 - Constify some of the paramerters.
 - s/VPCI_BAR_MEM/VPCI_BAR_MEM32/.
 - Simplify the number of fields stored for each BAR, a single address
   field is stored and contains the address of the BAR both on Xen and
   in the guest.
 - Allow the guest to move the BARs around in the physical memory map.
 - Add support for expansion ROM BARs.
 - Do not cache the value of the command register.
 - Remove a label used in vpci_cmd_write.
 - Fix the calculation of the sizing mask in vpci_bar_write.
 - Check the memory decode bit in order to decide if a BAR is
   positioned or not.
 - Disable memory decoding before sizing the BARs in Xen.
 - When mapping/unmapping BARs check if there's overlap between BARs,
   in order to avoid unmapping memory required by another BAR.
 - Introduce a macro to check whether a BAR is mappable or not.
 - Add a comment regarding the lack of support for SR-IOV.
 - Remove the usage of the GENMASK macro.

Changes since v2:
 - Detect unset BARs and allow the hardware domain to position them.
---
 xen/drivers/vpci/Makefile |   2 +-
 xen/drivers/vpci/header.c | 453 ++
 xen/include/xen/vpci.h|  29 +++
 3 files changed, 483 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/header.c

diff --git a/xen/drivers/vpci/Makefile b/xen/drivers/vpci/Makefile
index 840a906470..241467212f 100644
--- a/xen/drivers/vpci/Makefile
+++ b/xen/drivers/vpci/Makefile
@@ -1 +1 @@
-obj-y += vpci.o
+obj-y += vpci.o header.o
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
new file mode 100644
index 00..9b44c8441a
--- /dev/null
+++ b/xen/drivers/vpci/header.c
@@ -0,0 +1,453 @@
+/*
+ * Generic functionality for handling accesses to the PCI header from the
+ * configuration space.
+ *
+ * Copyright (C) 2017 Citrix Systems R
+ *
+ * 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 that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+#define MAPPABLE_BAR(x) \
+((x)->type == VPCI_BAR_MEM32 || (x)->type == 

Re: [Xen-devel] [PATCH v7 2/9] mm: Place unscrubbed pages at the end of pagelist

2017-08-14 Thread Boris Ostrovsky
On 08/14/2017 06:37 AM, Jan Beulich wrote:
 On 08.08.17 at 23:45,  wrote:
>> .. so that it's easy to find pages that need to be scrubbed (those pages are
>> now marked with _PGC_need_scrub bit).
>>
>> We keep track of the first unscrubbed page in a page buddy using first_dirty
>> field. For now it can have two values, 0 (whole buddy needs scrubbing) or
>> INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent 
>> patches
>> will allow scrubbing to be interrupted, resulting in first_dirty taking any
>> value.
>>
>> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Jan Beulich 
> with one remark:
>
>> --- a/xen/include/asm-x86/mm.h
>> +++ b/xen/include/asm-x86/mm.h
>> @@ -88,7 +88,15 @@ struct page_info
>>  /* Page is on a free list: ((count_info & PGC_count_mask) == 0). */
>>  struct {
>>  /* Do TLBs need flushing for safety before next page use? */
>> -bool_t need_tlbflush;
>> +bool need_tlbflush:1;
>> +
>> +/*
>> + * Index of the first *possibly* unscrubbed page in the buddy.
>> + * One more bit than maximum possible order to accommodate
>> + * INVALID_DIRTY_IDX.
>> + */
>> +#define INVALID_DIRTY_IDX ((1UL << (MAX_ORDER + 1)) - 1)
>> +unsigned long first_dirty:MAX_ORDER + 1;
>>  } free;
> I think generated code will be better with the two fields swapped:
> That way reading first_dirty won't involve a shift, and accessing a
> single bit doesn't require shifts at all on many architectures.

Ok, I will then keep need_tlbflush as the last field so the final struct
(as defined in patch 7) will look like

struct {
unsigned long first_dirty:MAX_ORDER + 1;
unsigned long scrub_state:2;
bool need_tlbflush:1;
};


-boris


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


[Xen-devel] [PATCH v5 06/11] pci: split code to size BARs from pci_add_device

2017-08-14 Thread Roger Pau Monne
So that it can be called from outside in order to get the size of regular PCI
BARs. This will be required in order to map the BARs from PCI devices into PVH
Dom0 p2m.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
Changes since v4:
 - Restore printing whether the BAR is from a vf.
 - Make the psize pointer parameter not optional.
 - s/u64/uint64_t.
 - Remove some unneeded parentheses.
 - Assert the return value is never 0.

Changes since v3:
 - Rename function to size BARs to pci_size_mem_bar.
 - Change the parameters passed to the function. Pass the position and
   whether the BAR is the last one, instead of the (base, max_bars,
   *index) tuple.
 - Make the function return the number of BARs consumed (1 for 32b, 2
   for 64b BARs).
 - Change the dprintk back to printk.
 - Do not log another error message in pci_add_device in case
   pci_size_mem_bar fails.
---
 xen/drivers/passthrough/pci.c | 91 +++
 xen/include/xen/pci.h |  3 ++
 2 files changed, 60 insertions(+), 34 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 54326cf0b8..948c227e01 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -592,6 +592,54 @@ static int iommu_add_device(struct pci_dev *pdev);
 static int iommu_enable_device(struct pci_dev *pdev);
 static int iommu_remove_device(struct pci_dev *pdev);
 
+int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot,
+ unsigned int func, unsigned int pos, bool last,
+ uint64_t *paddr, uint64_t *psize, bool vf)
+{
+uint32_t hi = 0, bar = pci_conf_read32(seg, bus, slot, func, pos);
+uint64_t addr, size;
+
+ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+pci_conf_write32(seg, bus, slot, func, pos, ~0);
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+if ( last )
+{
+printk(XENLOG_WARNING
+   "%sdevice %04x:%02x:%02x.%u with 64-bit %sBAR in last 
slot\n",
+   vf ? "SR-IOV " : "", seg, bus, slot, func,
+   vf ? "vf " : "");
+return -EINVAL;
+}
+hi = pci_conf_read32(seg, bus, slot, func, pos + 4);
+pci_conf_write32(seg, bus, slot, func, pos + 4, ~0);
+}
+size = pci_conf_read32(seg, bus, slot, func, pos) &
+   PCI_BASE_ADDRESS_MEM_MASK;
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+{
+size |= (uint64_t)pci_conf_read32(seg, bus, slot, func, pos + 4) << 32;
+pci_conf_write32(seg, bus, slot, func, pos + 4, hi);
+}
+else if ( size )
+size |= (uint64_t)~0 << 32;
+pci_conf_write32(seg, bus, slot, func, pos, bar);
+size = -size;
+addr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((uint64_t)hi << 32);
+
+if ( paddr )
+*paddr = addr;
+*psize = size;
+
+if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+ PCI_BASE_ADDRESS_MEM_TYPE_64 )
+return 2;
+
+return 1;
+}
+
 int pci_add_device(u16 seg, u8 bus, u8 devfn,
const struct pci_dev_info *info, nodeid_t node)
 {
@@ -652,11 +700,10 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 unsigned int i;
 
 BUILD_BUG_ON(ARRAY_SIZE(pdev->vf_rlen) != PCI_SRIOV_NUM_BARS);
-for ( i = 0; i < PCI_SRIOV_NUM_BARS; ++i )
+for ( i = 0; i < PCI_SRIOV_NUM_BARS; )
 {
 unsigned int idx = pos + PCI_SRIOV_BAR + i * 4;
 u32 bar = pci_conf_read32(seg, bus, slot, func, idx);
-u32 hi = 0;
 
 if ( (bar & PCI_BASE_ADDRESS_SPACE) ==
  PCI_BASE_ADDRESS_SPACE_IO )
@@ -667,38 +714,14 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
seg, bus, slot, func, i);
 continue;
 }
-pci_conf_write32(seg, bus, slot, func, idx, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
-{
-if ( i >= PCI_SRIOV_NUM_BARS )
-{
-printk(XENLOG_WARNING
-   "SR-IOV device %04x:%02x:%02x.%u with 64-bit"
-   " vf BAR in last slot\n",
-   seg, bus, slot, func);
-break;
-}
-hi = pci_conf_read32(seg, bus, slot, func, idx + 4);
-pci_conf_write32(seg, bus, slot, func, idx + 4, ~0);
-}
-pdev->vf_rlen[i] = pci_conf_read32(seg, bus, slot, func, idx) &
-   PCI_BASE_ADDRESS_MEM_MASK;
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
-   

[Xen-devel] [PATCH v5 00/11] vpci: PCI config space emulation

2017-08-14 Thread Roger Pau Monne
Hello,

The following series contain an implementation of handlers for the PCI
configuration space inside of Xen. This allows Xen to detect accesses
to the PCI configuration space and react accordingly.

Why is this needed? IMHO, there are two main points of doing all this
emulation inside of Xen, the first one is to prevent adding a bunch of
duplicated Xen PV specific code to each OS we want to support in PVH
mode. This just promotes Xen code duplication amongst OSes, which
leads to a higher maintainership burden.

The second reason would be that this code (or it's functionality to be
more precise) already exists in QEMU (and pciback to a degree), and
it's code that we already support and maintain. By moving it into the
hypervisor itself every guest type can make use of it, and should be
shared between them all. I know that the code in this series is not
yet suitable for DomU HVM guests in it's current state, but it should
be in due time.

As usual, each patch contains a changeset summary between versions,
I'm not going to copy the list of changes here.

Patch 1 introduces a function to decode a PCI IO port access into bdf
and register (which is shared with the ioreq code). Patch 2 implements
the generic handlers for accesses to the PCI configuration space
together with a minimal user-space test harness that I've used during
development. Currently a per-device linked list is used in order to
store the list of handlers, and they are sorted based on their offset
inside of the configuration space. Patch 2 also adds the x86 port IO
traps and wires them into the newly introduced vPCI dispatchers. Patch
3 and 4 adds handlers for the MMCFG areas (as found on the MMCFG ACPI
table). Patches 5, 6 and 7 are mostly code moment/refactoring in order
to implement support for BAR mapping in patch 8. Finally patches 9 and
11 add support for trapping accesses to the MSI and MSI-X capabilities
respectively, so that interrupts are properly setup on behalf of
Dom0.

The branch containing the patches can be found at:

git://xenbits.xen.org/people/royger/xen.git vpci_v5

Note that this is only safe to use for the hardware domain (that's
trusted), any non-trusted domain will need a lot more of traps before
it can freely access the PCI configuration space.

This series is based on top of my "x86/pvh: implement
iommu_inclusive_mapping for PVH Dom0" series.

Thanks, Roger.

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


[Xen-devel] [PATCH v5 11/11] vpci/msix: add MSI-X handlers

2017-08-14 Thread Roger Pau Monne
Add handlers for accesses to the MSI-X message control field on the
PCI configuration space, and traps for accesses to the memory region
that contains the MSI-X table and PBA. This traps detect attempts from
the guest to configure MSI-X interrupts and properly sets them up.

Note that accesses to the Table Offset, Table BIR, PBA Offset and PBA
BIR are not trapped by Xen at the moment.

Finally, turn the panic in the Dom0 PVH builder into a warning.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Remove parentheses around offsetof.
 - Add "being" to MSI-X enabling comment.
 - Use INVALID_PIRQ.
 - Add a simple sanity check to vpci_msix_arch_enable in order to
   detect wrong MSI-X entries more quickly.
 - Constify vpci_msix_arch_print entry argument.
 - s/cpu/fixed/ in vpci_msix_arch_print.
 - Dump the MSI-X info together with the MSI info.
 - Fix vpci_msix_control_write to take into account changes to the
   address and data fields when switching the function mask bit.
 - Only disable/enable the entries if the address or data fields have
   been updated.
 - Usew the BAR enable field to check if a BAR is mapped or not
   (instead of reading the command register for each device).
 - Fix error path in vpci_msix_read to set the return data to ~0.
 - Simplify mask usage in vpci_msix_write.
 - Cast data to uint64_t when shifting it 32 bits.
 - Fix writes to the table entry control register to take into account
   if the mask-all bit is set.
 - Add some comments to clarify the intended behavior of the code.
 - Align the PBA size to 64-bits.
 - Remove the error label in vpci_init_msix.
 - Try to compact the layout of the vpci_msix structure.
 - Remove the local table_bar and pba_bar variables from
   vpci_init_msix, they are used only once.

Changes since v3:
 - Propagate changes from previous versions: remove xen_ prefix, use
   the new fields in vpci_val and remove the return value from
   handlers.
 - Remove the usage of GENMASK.
 - Mave the arch-specific parts of the dump routine to the
   x86/hvm/vmsi.c dump handler.
 - Chain the MSI-X dump handler to the 'M' debug key.
 - Fix the header BAR mappings so that the MSI-X regions inside of
   BARs are unmapped from the domain p2m in order for the handlers to
   work properly.
 - Unconditionally trap and forward accesses to the PBA MSI-X area.
 - Simplify the conditionals in vpci_msix_control_write.
 - Fix vpci_msix_accept to use a bool type.
 - Allow all supported accesses as described in the spec to the MSI-X
   table.
 - Truncate the returned address when the access is a 32b read.
 - Always return X86EMUL_OKAY from the handlers, returning ~0 in the
   read case if the access is not supported, or ignoring writes.
 - Do not check that max_entries is != 0 in the init handler.
 - Use trylock in the dump handler.

Changes since v2:
 - Split out arch-specific code.

This patch has been tested with devices using both a single MSI-X
entry and multiple ones.
---
 xen/arch/x86/hvm/dom0_build.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   1 +
 xen/arch/x86/hvm/vmsi.c  | 138 ++-
 xen/drivers/vpci/Makefile|   2 +-
 xen/drivers/vpci/header.c|  81 +++
 xen/drivers/vpci/msi.c   |  25 +-
 xen/drivers/vpci/msix.c  | 478 +++
 xen/include/asm-x86/hvm/domain.h |   3 +
 xen/include/asm-x86/hvm/io.h |  19 ++
 xen/include/xen/vpci.h   |  39 
 10 files changed, 779 insertions(+), 9 deletions(-)
 create mode 100644 xen/drivers/vpci/msix.c

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index c65eb8503f..3deae7cb4a 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -1086,7 +1086,7 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 
 pvh_setup_mmcfg(d);
 
-panic("Building a PVHv2 Dom0 is not yet supported.");
+printk("WARNING: PVH is an experimental mode with limited 
functionality\n");
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3168973820..e27e86a514 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -584,6 +584,7 @@ int hvm_domain_initialise(struct domain *d, unsigned long 
domcr_flags,
 INIT_LIST_HEAD(>arch.hvm_domain.write_map.list);
 INIT_LIST_HEAD(>arch.hvm_domain.g2m_ioport_list);
 INIT_LIST_HEAD(>arch.hvm_domain.mmcfg_regions);
+INIT_LIST_HEAD(>arch.hvm_domain.msix_tables);
 
 rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
 if ( rc )
diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index aea088e290..5c41eea0fe 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -643,17 +643,15 @@ static unsigned int msi_flags(uint16_t data, uint64_t 
addr)
(trig_mode << GFLAGS_SHIFT_TRG_MODE);
 }
 
-void vpci_msi_arch_mask(struct 

[Xen-devel] [PATCH v5 09/11] vpci/msi: add MSI handlers

2017-08-14 Thread Roger Pau Monne
Add handlers for the MSI control, address, data and mask fields in
order to detect accesses to them and setup the interrupts as requested
by the guest.

Note that the pending register is not trapped, and the guest can
freely read/write to it.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v4:
 - Fix commit message.
 - Change the ASSERTs in vpci_msi_arch_mask into ifs.
 - Introduce INVALID_PIRQ.
 - Destroy the partially created bindings in case of failure in
   vpci_msi_arch_enable.
 - Just take the pcidevs lock once in vpci_msi_arch_disable.
 - Print an error message in case of failure of pt_irq_destroy_bind.
 - Make vpci_msi_arch_init return void.
 - Constify the arch parameter of vpci_msi_arch_print.
 - Use fixed instead of cpu for msi redirection.
 - Separate the header includes in vpci/msi.c between xen and asm.
 - Store the number of configured vectors even if MSI is not enabled
   and always return it in vpci_msi_control_read.
 - Fix/add comments in vpci_msi_control_write to clarify intended
   behavior.
 - Simplify usage of masks in vpci_msi_address_{upper_}write.
 - Add comment to vpci_msi_mask_{read/write}.
 - Don't use MASK_EXTR in vpci_msi_mask_write.
 - s/msi_offset/pos/ in vpci_init_msi.
 - Move control variable setup closer to it's usage.
 - Use d%d in vpci_dump_msi.
 - Fix printing of bitfield mask in vpci_dump_msi.
 - Fix definition of MSI_ADDR_REDIRECTION_MASK.
 - Shuffle the layout of vpci_msi to minimize gaps.
 - Remove the error label in vpci_init_msi.

Changes since v3:
 - Propagate changes from previous versions: drop xen_ prefix, drop
   return value from handlers, use the new vpci_val fields.
 - Use MASK_EXTR.
 - Remove the usage of GENMASK.
 - Add GFLAGS_SHIFT_DEST_ID and use it in msi_flags.
 - Add "arch" to the MSI arch specific functions.
 - Move the dumping of vPCI MSI information to dump_msi (key 'M').
 - Remove the guest_vectors field.
 - Allow the guest to change the number of active vectors without
   having to disable and enable MSI.
 - Check the number of active vectors when parsing the disable
   mask.
 - Remove the debug messages from vpci_init_msi.
 - Move the arch-specific part of the dump handler to x86/hvm/vmsi.c.
 - Use trylock in the dump handler to get the vpci lock.

Changes since v2:
 - Add an arch-specific abstraction layer. Note that this is only implemented
   for x86 currently.
 - Add a wrapper to detect MSI enabling for vPCI.

NB: I've only been able to test this with devices using a single MSI interrupt
and no mask register. I will try to find hardware that supports the mask
register and more than one vector, but I cannot make any promises.

If there are doubts about the untested parts we could always force Xen to
report no per-vector masking support and only 1 available vector, but I would
rather avoid doing it.
---
 xen/arch/x86/hvm/vmsi.c  | 156 ++
 xen/arch/x86/msi.c   |   3 +
 xen/drivers/vpci/Makefile|   2 +-
 xen/drivers/vpci/msi.c   | 368 +++
 xen/include/asm-x86/hvm/io.h |  18 +++
 xen/include/asm-x86/msi.h|   1 +
 xen/include/xen/hvm/irq.h|   2 +
 xen/include/xen/irq.h|   1 +
 xen/include/xen/vpci.h   |  27 
 9 files changed, 577 insertions(+), 1 deletion(-)
 create mode 100644 xen/drivers/vpci/msi.c

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index a36692c313..aea088e290 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -622,3 +622,159 @@ void msix_write_completion(struct vcpu *v)
 if ( msixtbl_write(v, ctrl_address, 4, 0) != X86EMUL_OKAY )
 gdprintk(XENLOG_WARNING, "MSI-X write completion failure\n");
 }
+
+static unsigned int msi_vector(uint16_t data)
+{
+return MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
+}
+
+static unsigned int msi_flags(uint16_t data, uint64_t addr)
+{
+unsigned int rh, dm, dest_id, deliv_mode, trig_mode;
+
+rh = MASK_EXTR(addr, MSI_ADDR_REDIRECTION_MASK);
+dm = MASK_EXTR(addr, MSI_ADDR_DESTMODE_MASK);
+dest_id = MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK);
+deliv_mode = MASK_EXTR(data, MSI_DATA_DELIVERY_MODE_MASK);
+trig_mode = MASK_EXTR(data, MSI_DATA_TRIGGER_MASK);
+
+return (dest_id << GFLAGS_SHIFT_DEST_ID) | (rh << GFLAGS_SHIFT_RH) |
+   (dm << GFLAGS_SHIFT_DM) | (deliv_mode << GFLAGS_SHIFT_DELIV_MODE) |
+   (trig_mode << GFLAGS_SHIFT_TRG_MODE);
+}
+
+void vpci_msi_arch_mask(struct vpci_arch_msi *arch, struct pci_dev *pdev,
+unsigned int entry, bool mask)
+{
+struct domain *d = pdev->domain;
+const struct pirq *pinfo;
+struct irq_desc *desc;
+unsigned long flags;
+int irq;
+
+ASSERT(arch->pirq >= 0);
+pinfo = pirq_info(d, arch->pirq + entry);
+if ( !pinfo )
+return;
+
+irq = pinfo->arch.irq;
+if ( irq >= 

[Xen-devel] [PATCH v5 07/11] pci: add support to size ROM BARs to pci_size_mem_bar

2017-08-14 Thread Roger Pau Monne
Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
Changes since v4:
 - New in this version.
---
 xen/drivers/passthrough/pci.c | 24 +---
 xen/include/xen/pci.h |  2 +-
 2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 948c227e01..33cb774d29 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -594,15 +594,18 @@ static int iommu_remove_device(struct pci_dev *pdev);
 
 int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot,
  unsigned int func, unsigned int pos, bool last,
- uint64_t *paddr, uint64_t *psize, bool vf)
+ uint64_t *paddr, uint64_t *psize, bool vf, bool rom)
 {
 uint32_t hi = 0, bar = pci_conf_read32(seg, bus, slot, func, pos);
 uint64_t addr, size;
+bool is64bits = !rom && (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
+PCI_BASE_ADDRESS_MEM_TYPE_64;
 
-ASSERT((bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
+ASSERT(!(rom && vf));
+ASSERT(rom ||
+   (bar & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY);
 pci_conf_write32(seg, bus, slot, func, pos, ~0);
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
+if ( is64bits )
 {
 if ( last )
 {
@@ -616,9 +619,8 @@ int pci_size_mem_bar(unsigned int seg, unsigned int bus, 
unsigned int slot,
 pci_conf_write32(seg, bus, slot, func, pos + 4, ~0);
 }
 size = pci_conf_read32(seg, bus, slot, func, pos) &
-   PCI_BASE_ADDRESS_MEM_MASK;
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
+   (rom ? PCI_ROM_ADDRESS_MASK : PCI_BASE_ADDRESS_MEM_MASK);
+if ( is64bits )
 {
 size |= (uint64_t)pci_conf_read32(seg, bus, slot, func, pos + 4) << 32;
 pci_conf_write32(seg, bus, slot, func, pos + 4, hi);
@@ -627,14 +629,14 @@ int pci_size_mem_bar(unsigned int seg, unsigned int bus, 
unsigned int slot,
 size |= (uint64_t)~0 << 32;
 pci_conf_write32(seg, bus, slot, func, pos, bar);
 size = -size;
-addr = (bar & PCI_BASE_ADDRESS_MEM_MASK) | ((uint64_t)hi << 32);
+addr = (bar & (rom ? PCI_ROM_ADDRESS_MASK : PCI_BASE_ADDRESS_MEM_MASK)) |
+   ((uint64_t)hi << 32);
 
 if ( paddr )
 *paddr = addr;
 *psize = size;
 
-if ( (bar & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
- PCI_BASE_ADDRESS_MEM_TYPE_64 )
+if ( is64bits )
 return 2;
 
 return 1;
@@ -716,7 +718,7 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
 }
 ret = pci_size_mem_bar(seg, bus, slot, func, idx,
i == PCI_SRIOV_NUM_BARS - 1, NULL,
-   >vf_rlen[i], true);
+   >vf_rlen[i], true, false);
 if ( ret < 0 )
 break;
 
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index b85e4fa8ad..72c901be66 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -166,7 +166,7 @@ const char *parse_pci_seg(const char *, unsigned int *seg, 
unsigned int *bus,
   unsigned int *dev, unsigned int *func, bool 
*def_seg);
 int pci_size_mem_bar(unsigned int seg, unsigned int bus, unsigned int slot,
  unsigned int func, unsigned int pos, bool last,
- uint64_t *addr, uint64_t *size, bool vf);
+ uint64_t *addr, uint64_t *size, bool vf, bool rom);
 
 
 bool_t pcie_aer_get_firmware_first(const struct pci_dev *);
-- 
2.11.0 (Apple Git-81)


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


[Xen-devel] [PATCH v5 01/11] x86/pci: introduce hvm_pci_decode_addr

2017-08-14 Thread Roger Pau Monne
And use it in the ioreq code to decode accesses to the PCI IO ports
into bus, slot, function and register values.

Signed-off-by: Roger Pau Monné 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - New in this version.
---
 xen/arch/x86/hvm/io.c| 19 +++
 xen/arch/x86/hvm/ioreq.c | 12 +---
 xen/include/asm-x86/hvm/io.h |  5 +
 3 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 214ab307c4..074cba89da 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -256,6 +256,25 @@ void register_g2m_portio_handler(struct domain *d)
 handler->ops = _portio_ops;
 }
 
+unsigned int hvm_pci_decode_addr(unsigned int cf8, unsigned int addr,
+ unsigned int *bus, unsigned int *slot,
+ unsigned int *func)
+{
+unsigned long bdf;
+
+ASSERT(CF8_ENABLED(cf8));
+
+bdf = CF8_BDF(cf8);
+*bus = PCI_BUS(bdf);
+*slot = PCI_SLOT(bdf);
+*func = PCI_FUNC(bdf);
+/*
+ * NB: the lower 2 bits of the register address are fetched from the
+ * offset into the 0xcfc register when reading/writing to it.
+ */
+return CF8_ADDR_LO(cf8) | (addr & 3);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index b2a8b0e986..752976d16d 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -1178,18 +1178,16 @@ struct hvm_ioreq_server *hvm_select_ioreq_server(struct 
domain *d,
  CF8_ENABLED(cf8) )
 {
 uint32_t sbdf, x86_fam;
+unsigned int bus, slot, func, reg;
+
+reg = hvm_pci_decode_addr(cf8, p->addr, , , );
 
 /* PCI config data cycle */
 
-sbdf = XEN_DMOP_PCI_SBDF(0,
- PCI_BUS(CF8_BDF(cf8)),
- PCI_SLOT(CF8_BDF(cf8)),
- PCI_FUNC(CF8_BDF(cf8)));
+sbdf = XEN_DMOP_PCI_SBDF(0, bus, slot, func);
 
 type = XEN_DMOP_IO_RANGE_PCI;
-addr = ((uint64_t)sbdf << 32) |
-   CF8_ADDR_LO(cf8) |
-   (p->addr & 3);
+addr = ((uint64_t)sbdf << 32) | reg;
 /* AMD extended configuration space access? */
 if ( CF8_ADDR_HI(cf8) &&
  d->arch.cpuid->x86_vendor == X86_VENDOR_AMD &&
diff --git a/xen/include/asm-x86/hvm/io.h b/xen/include/asm-x86/hvm/io.h
index 2484eb1c75..51659b6c7f 100644
--- a/xen/include/asm-x86/hvm/io.h
+++ b/xen/include/asm-x86/hvm/io.h
@@ -149,6 +149,11 @@ void stdvga_deinit(struct domain *d);
 
 extern void hvm_dpci_msi_eoi(struct domain *d, int vector);
 
+/* Decode a PCI port IO access into a bus/slot/func/reg. */
+unsigned int hvm_pci_decode_addr(unsigned int cf8, unsigned int addr,
+ unsigned int *bus, unsigned int *slot,
+ unsigned int *func);
+
 /*
  * HVM port IO handler that performs forwarding of guest IO ports into machine
  * IO ports.
-- 
2.11.0 (Apple Git-81)


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


[Xen-devel] [PATCH v5 05/11] mm: move modify_identity_mmio to global file and drop __init

2017-08-14 Thread Roger Pau Monne
And also allow it to do non-identity mappings by adding a new
parameter.

This function will be needed in order to map the BARs from PCI devices
into the Dom0 p2m (and is also used by the x86 Dom0 builder). While
there fix the function to use gfn_t and mfn_t instead of unsigned long
for memory addresses.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Guard the function with CONFIG_HAS_PCI only.
 - s/non-trival/non-negligible in the comment.
 - Change XENLOG_G_WARNING to XENLOG_WARNING like the original
   function.

Changes since v3:
 - Remove the dummy modify_identity_mmio helper in dom0_build.c
 - Try to make the comment in modify MMIO less scary.
 - Clarify commit message.
 - Only build the function for x86 or if there's PCI support.

Changes since v2:
 - Use mfn_t and gfn_t.
 - Remove stray newline.
---
 xen/arch/x86/hvm/dom0_build.c | 30 ++
 xen/common/memory.c   | 40 
 xen/include/xen/p2m-common.h  |  3 +++
 3 files changed, 45 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 04a8682d33..c65eb8503f 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -61,32 +61,6 @@ static struct acpi_madt_interrupt_override __initdata 
*intsrcovr;
 static unsigned int __initdata acpi_nmi_sources;
 static struct acpi_madt_nmi_source __initdata *nmisrc;
 
-static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
-   unsigned long nr_pages, const bool map)
-{
-int rc;
-
-for ( ; ; )
-{
-rc = (map ? map_mmio_regions : unmap_mmio_regions)
- (d, _gfn(pfn), nr_pages, _mfn(pfn));
-if ( rc == 0 )
-break;
-if ( rc < 0 )
-{
-printk(XENLOG_WARNING
-   "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
-   map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
-break;
-}
-nr_pages -= rc;
-pfn += rc;
-process_pending_softirqs();
-}
-
-return rc;
-}
-
 /* Populate a HVM memory range using the biggest possible order. */
 static int __init pvh_populate_memory_range(struct domain *d,
 unsigned long start,
@@ -397,7 +371,7 @@ static int __init pvh_setup_p2m(struct domain *d)
  * Memory below 1MB is identity mapped.
  * NB: this only makes sense when booted from legacy BIOS.
  */
-rc = modify_identity_mmio(d, 0, MB1_PAGES, true);
+rc = modify_mmio(d, _gfn(0), _mfn(0), MB1_PAGES, true);
 if ( rc )
 {
 printk("Failed to identity map low 1MB: %d\n", rc);
@@ -964,7 +938,7 @@ static int __init pvh_setup_acpi(struct domain *d, paddr_t 
start_info)
 nr_pages = PFN_UP((d->arch.e820[i].addr & ~PAGE_MASK) +
   d->arch.e820[i].size);
 
-rc = modify_identity_mmio(d, pfn, nr_pages, true);
+rc = modify_mmio(d, _gfn(pfn), _mfn(pfn), nr_pages, true);
 if ( rc )
 {
 printk("Failed to map ACPI region [%#lx, %#lx) into Dom0 memory 
map\n",
diff --git a/xen/common/memory.c b/xen/common/memory.c
index b2066db07e..86824edb09 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1465,6 +1465,46 @@ int prepare_ring_for_helper(
 return 0;
 }
 
+#if defined(CONFIG_HAS_PCI)
+int modify_mmio(struct domain *d, gfn_t gfn, mfn_t mfn, unsigned long nr_pages,
+bool map)
+{
+int rc;
+
+/*
+ * ATM this function should only be used by the hardware domain
+ * because it doesn't support preemption/continuation, and as such
+ * can take a non-negligible amount of time. Note that it periodically
+ * calls process_pending_softirqs in order to avoid stalling the system.
+ */
+ASSERT(is_hardware_domain(d));
+
+for ( ; ; )
+{
+rc = (map ? map_mmio_regions : unmap_mmio_regions)
+ (d, gfn, nr_pages, mfn);
+if ( rc == 0 )
+break;
+if ( rc < 0 )
+{
+printk(XENLOG_WARNING
+   "Failed to %smap [%" PRI_gfn ", %" PRI_gfn ") -> "
+   "[%" PRI_mfn ", %" PRI_mfn ") for d%d: %d\n",
+   map ? "" : "un", gfn_x(gfn), gfn_x(gfn_add(gfn, nr_pages)),
+   mfn_x(mfn), mfn_x(mfn_add(mfn, nr_pages)), d->domain_id,
+   rc);
+break;
+}
+nr_pages -= rc;
+mfn = mfn_add(mfn, rc);
+gfn = gfn_add(gfn, rc);
+process_pending_softirqs();
+}
+
+return rc;
+}
+#endif
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/p2m-common.h b/xen/include/xen/p2m-common.h
index 2b5696cf33..c2f9015ad8 100644
--- a/xen/include/xen/p2m-common.h
+++ b/xen/include/xen/p2m-common.h
@@ 

[Xen-devel] [PATCH v5 03/11] x86/mmcfg: add handlers for the PVH Dom0 MMCFG areas

2017-08-14 Thread Roger Pau Monne
Introduce a set of handlers for the accesses to the MMCFG areas. Those
areas are setup based on the contents of the hardware MMCFG tables,
and the list of handled MMCFG areas is stored inside of the hvm_domain
struct.

The read/writes are forwarded to the generic vpci handlers once the
address is decoded in order to obtain the device and register the
guest is trying to access.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
---
Changes since v4:
 - Change the attribute of pvh_setup_mmcfg to __hwdom_init.
 - Try to add as many MMCFG regions as possible, even if one fails to
   add.
 - Change some fields of the hvm_mmcfg struct: turn size into a
   unsigned int, segment into uint16_t and bus into uint8_t.
 - Convert some address parameters from unsigned long to paddr_t for
   consistency.
 - Make vpci_mmcfg_decode_addr return the decoded register in the
   return of the function.
 - Introduce a new macro to convert a MMCFG address into a BDF, and
   use it in vpci_mmcfg_decode_addr to clarify the logic.
 - In vpci_mmcfg_{read/write} unify the logic for 8B accesses and
   smaller ones.
 - Add the __hwdom_init attribute to register_vpci_mmcfg_handler.
 - Test that reg + size doesn't cross a device boundary.

Changes since v3:
 - Propagate changes from previous patches: drop xen_ prefix for vpci
   functions, pass slot and func instead of devfn and fix the error
   paths of the MMCFG handlers.
 - s/ecam/mmcfg/.
 - Move the destroy code to a separate function, so the hvm_mmcfg
   struct can be private to hvm/io.c.
 - Constify the return of vpci_mmcfg_find.
 - Use d instead of v->domain in vpci_mmcfg_accept.
 - Allow 8byte accesses to the mmcfg.

Changes since v1:
 - Added locking.
---
 xen/arch/x86/hvm/dom0_build.c|  22 +
 xen/arch/x86/hvm/hvm.c   |   3 +
 xen/arch/x86/hvm/io.c| 183 ++-
 xen/include/asm-x86/hvm/domain.h |   3 +
 xen/include/asm-x86/hvm/io.h |   7 ++
 xen/include/asm-x86/pci.h|   2 +
 6 files changed, 219 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index 0e7d06be95..04a8682d33 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include "../x86_64/mmconfig.h"
+
 /*
  * Have the TSS cover the ISA port range, which makes it
  * - 104 bytes base structure
@@ -1041,6 +1043,24 @@ static int __init pvh_setup_acpi(struct domain *d, 
paddr_t start_info)
 return 0;
 }
 
+static void __hwdom_init pvh_setup_mmcfg(struct domain *d)
+{
+unsigned int i;
+int rc;
+
+for ( i = 0; i < pci_mmcfg_config_num; i++ )
+{
+rc = register_vpci_mmcfg_handler(d, pci_mmcfg_config[i].address,
+ pci_mmcfg_config[i].start_bus_number,
+ pci_mmcfg_config[i].end_bus_number,
+ pci_mmcfg_config[i].pci_segment);
+if ( rc )
+printk("Unable to setup MMCFG handler at %#lx for segment %u\n",
+   pci_mmcfg_config[i].address,
+   pci_mmcfg_config[i].pci_segment);
+}
+}
+
 int __init dom0_construct_pvh(struct domain *d, const module_t *image,
   unsigned long image_headroom,
   module_t *initrd,
@@ -1090,6 +1110,8 @@ int __init dom0_construct_pvh(struct domain *d, const 
module_t *image,
 return rc;
 }
 
+pvh_setup_mmcfg(d);
+
 panic("Building a PVHv2 Dom0 is not yet supported.");
 return 0;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index cc73df8dc7..3168973820 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -583,6 +583,7 @@ int hvm_domain_initialise(struct domain *d, unsigned long 
domcr_flags,
 spin_lock_init(>arch.hvm_domain.write_map.lock);
 INIT_LIST_HEAD(>arch.hvm_domain.write_map.list);
 INIT_LIST_HEAD(>arch.hvm_domain.g2m_ioport_list);
+INIT_LIST_HEAD(>arch.hvm_domain.mmcfg_regions);
 
 rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
 if ( rc )
@@ -728,6 +729,8 @@ void hvm_domain_destroy(struct domain *d)
 list_del(>list);
 xfree(ioport);
 }
+
+destroy_vpci_mmcfg(>arch.hvm_domain.mmcfg_regions);
 }
 
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index c3b68eb257..2845dc5b48 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -280,7 +280,7 @@ unsigned int hvm_pci_decode_addr(unsigned int cf8, unsigned 
int addr,
 static bool vpci_access_allowed(unsigned int reg, unsigned int len)
 {
 /* Check access size. */
-if ( len != 1 && len != 2 && len != 4 )
+if ( len != 1 && len != 2 && len != 4 && len 

Re: [Xen-devel] [PATCH v2 03/52] xen/arch/arm/traps.c: let custom parameter parsing routines return errno

2017-08-14 Thread Julien Grall

Hi Juergen,

On 14/08/17 08:08, Juergen Gross wrote:

Modify the custom parameter parsing routines in:

xen/arch/arm/traps.c

to indicate whether the parameter value was parsed successfully.

Cc: Stefano Stabellini 
Cc: Julien Grall 
Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 02/52] xen/arch/arm/domain_build.c: let custom parameter parsing routines return errno

2017-08-14 Thread Julien Grall

Hi Juergen,

On 14/08/17 08:07, Juergen Gross wrote:

Modify the custom parameter parsing routines in:

xen/arch/arm/domain_build.c

to indicate whether the parameter value was parsed successfully.

Cc: Stefano Stabellini 
Cc: Julien Grall 
Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 01/52] xen/arch/arm/acpi/boot.c: let custom parameter parsing routines return errno

2017-08-14 Thread Julien Grall

Hi Juergen,

On 14/08/17 08:07, Juergen Gross wrote:

Modify the custom parameter parsing routines in:

xen/arch/arm/acpi/boot.c

to indicate whether the parameter value was parsed successfully.

Cc: Stefano Stabellini 
Cc: Julien Grall 
Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 19/52] xen/arch/x86/setup.c: let custom parameter parsing routines return errno

2017-08-14 Thread Juergen Gross
On 14/08/17 15:37, Jan Beulich wrote:
 On 14.08.17 at 09:08,  wrote:
>>  bool __read_mostly acpi_disabled;
>>  bool __initdata acpi_force;
>>  static char __initdata acpi_param[10] = "";
>> -static void __init parse_acpi_param(char *s)
>> +static int __init parse_acpi_param(char *s)
> 
> Again please take the opportunity and add the missing blank line
> ahead of the one you modify.

Okay.


Juergen

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


Re: [Xen-devel] [PATCH v2 18/52] xen/arch/x86/psr.c: let custom parameter parsing routines return errno

2017-08-14 Thread Juergen Gross
On 14/08/17 15:35, Jan Beulich wrote:
 On 14.08.17 at 09:08,  wrote:
>> --- a/xen/arch/x86/psr.c
>> +++ b/xen/arch/x86/psr.c
>> @@ -420,7 +420,7 @@ static const struct feat_props l2_cat_props = {
>>  };
>>  
>>  static void __init parse_psr_bool(char *s, char *value, char *feature,
>> -  unsigned int mask)
>> +  unsigned int mask, int *rc)
> 
> Please make the function return a value (perhaps bool) instead.

Okay.

> 
>> @@ -451,18 +455,28 @@ static void __init parse_psr_param(char *s)
>>  if ( val_str )
>>  *val_str++ = '\0';
>>  
>> -parse_psr_bool(s, val_str, "cmt", PSR_CMT);
>> -parse_psr_bool(s, val_str, "cat", PSR_CAT);
>> -parse_psr_bool(s, val_str, "cdp", PSR_CDP);
>> +parse_psr_bool(s, val_str, "cmt", PSR_CMT, );
>> +parse_psr_bool(s, val_str, "cat", PSR_CAT, );
>> +parse_psr_bool(s, val_str, "cdp", PSR_CDP, );
>>  
>>  if ( val_str && !strcmp(s, "rmid_max") )
>> -opt_rmid_max = simple_strtoul(val_str, NULL, 0);
>> +{
>> +opt_rmid_max = simple_strtoul(val_str, , 0);
>> +if ( *q )
>> +rc = -EINVAL;
>> +}
>>  
>>  if ( val_str && !strcmp(s, "cos_max") )
>> -opt_cos_max = simple_strtoul(val_str, NULL, 0);
>> +{
>> +opt_cos_max = simple_strtoul(val_str, , 0);
>> +if ( *q )
>> +rc = -EINVAL;
>> +}
>>  
>>  s = ss + 1;
>>  } while ( ss );
> 
> So if val_str didn't match any of the five strings you won't indicate
> an error here, which seems inconsistent.

Okay, I'll change it.


Juergen

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


[Xen-devel] [PATCH 27/27] xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one

2017-08-14 Thread Julien Grall
This will help to consolidate the page-table code and avoid different
path depending on the action to perform.

Signed-off-by: Julien Grall 

---

Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 

arch_livepatch_secure is now the same as on x86. It might be
possible to combine both, but I left that alone for now.
---
 xen/arch/arm/livepatch.c   |  6 +++---
 xen/arch/arm/mm.c  |  5 ++---
 xen/include/asm-arm/page.h | 11 ---
 3 files changed, 5 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3e53524365..279d52cc6c 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -146,15 +146,15 @@ int arch_livepatch_secure(const void *va, unsigned int 
pages, enum va_type type)
 switch ( type )
 {
 case LIVEPATCH_VA_RX:
-flags = PTE_RO; /* R set, NX clear */
+flags = PAGE_HYPERVISOR_RX;
 break;
 
 case LIVEPATCH_VA_RW:
-flags = PTE_NX; /* R clear, NX set */
+flags = PAGE_HYPERVISOR_RW;
 break;
 
 case LIVEPATCH_VA_RO:
-flags = PTE_NX | PTE_RO; /* R set, NX set */
+flags = PAGE_HYPERVISOR_RO;
 break;
 
 default:
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index fe0646002e..c2fd4baef9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1046,8 +1046,8 @@ static int create_xen_entries(enum xenmap_operation op,
 else
 {
 pte = *entry;
-pte.pt.ro = PTE_RO_MASK(flags);
-pte.pt.xn = PTE_NX_MASK(flags);
+pte.pt.ro = PAGE_RO_MASK(flags);
+pte.pt.xn = PAGE_XN_MASK(flags);
 if ( !pte.pt.ro && !pte.pt.xn )
 {
 printk("%s: Incorrect combination for addr=%lx\n",
@@ -1090,7 +1090,6 @@ int destroy_xen_mappings(unsigned long v, unsigned long e)
 
 int modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)
 {
-ASSERT((flags & (PTE_NX | PTE_RO)) == flags);
 return create_xen_entries(MODIFY, s, INVALID_MFN, (e - s) >> PAGE_SHIFT,
   flags);
 }
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 047220f86b..079097d429 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -91,17 +91,6 @@
 #define PAGE_HYPERVISOR_WC  (_PAGE_DEVICE|MT_NORMAL_NC)
 
 /*
- * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to be
- * used with modify_xen_mappings.
- */
-#define _PTE_NX_BIT 0U
-#define _PTE_RO_BIT 1U
-#define PTE_NX  (1U << _PTE_NX_BIT)
-#define PTE_RO  (1U << _PTE_RO_BIT)
-#define PTE_NX_MASK(x)  (((x) >> _PTE_NX_BIT) & 0x1U)
-#define PTE_RO_MASK(x)  (((x) >> _PTE_RO_BIT) & 0x1U)
-
-/*
  * Stage 2 Memory Type.
  *
  * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page
-- 
2.11.0


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


[Xen-devel] [PATCH 23/27] xen/arm: mm: Rename 'ai' into 'flags' in create_xen_entries

2017-08-14 Thread Julien Grall
The parameter 'ai' is used either for attribute index or for
permissions. Follow-up patch will rework that parameters to carry more
information. So rename the parameter to 'flags'.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index c0d5fda269..411fe02842 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -986,7 +986,7 @@ static int create_xen_entries(enum xenmap_operation op,
   unsigned long virt,
   mfn_t mfn,
   unsigned long nr_mfns,
-  unsigned int ai)
+  unsigned int flags)
 {
 int rc;
 unsigned long addr = virt, addr_end = addr + nr_mfns * PAGE_SIZE;
@@ -1021,7 +1021,7 @@ static int create_xen_entries(enum xenmap_operation op,
 }
 if ( op == RESERVE )
 break;
-pte = mfn_to_xen_entry(mfn, ai);
+pte = mfn_to_xen_entry(mfn, flags);
 pte.pt.table = 1;
 write_pte(entry, pte);
 break;
@@ -1038,8 +1038,8 @@ static int create_xen_entries(enum xenmap_operation op,
 else
 {
 pte = *entry;
-pte.pt.ro = PTE_RO_MASK(ai);
-pte.pt.xn = PTE_NX_MASK(ai);
+pte.pt.ro = PTE_RO_MASK(flags);
+pte.pt.xn = PTE_NX_MASK(flags);
 if ( !pte.pt.ro && !pte.pt.xn )
 {
 printk("%s: Incorrect combination for addr=%lx\n",
-- 
2.11.0


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


[Xen-devel] [PATCH 26/27] xen/arm: mm: Handling permission flags when adding a new mapping

2017-08-14 Thread Julien Grall
Currently, all the new mappings will be read-write non-executable. Allow the
caller to use other permissions.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index cd7bcf7aca..fe0646002e 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1022,6 +1022,14 @@ static int create_xen_entries(enum xenmap_operation op,
 if ( op == RESERVE )
 break;
 pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
+pte.pt.ro = PAGE_RO_MASK(flags);
+pte.pt.xn = PAGE_XN_MASK(flags);
+if (  !pte.pt.ro && !pte.pt.xn )
+{
+printk("%s: Incorrect combination for addr=%lx\n",
+   __func__, addr);
+return -EINVAL;
+}
 pte.pt.table = 1;
 write_pte(entry, pte);
 break;
-- 
2.11.0


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


[Xen-devel] [PATCH 14/27] xen/arm: traps: Improve logging for data/prefetch abort fault

2017-08-14 Thread Julien Grall
Walk the hypervisor page table for data/prefetch abort fault to help
diagnostics error in the page tables.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 819bdbc69e..dac4e54fa7 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2967,7 +2967,26 @@ asmlinkage void do_trap_hyp_sync(struct cpu_user_regs 
*regs)
 do_trap_brk(regs, hsr);
 break;
 #endif
+case HSR_EC_DATA_ABORT_CURR_EL:
+case HSR_EC_INSTR_ABORT_CURR_EL:
+{
+bool is_data = (hsr.ec == HSR_EC_DATA_ABORT_CURR_EL);
+const char *fault = (is_data) ? "Data Abort" : "Instruction Abort";
+
+printk("%s Trap. Syndrome=%#x\n", fault, hsr.iss);
+/*
+ * FAR may not be valid for a Synchronous External abort other
+ * than translation table walk.
+ */
+if ( hsr.xabt.fsc != FSC_SEA || !hsr.xabt.fnv )
+dump_hyp_walk(get_hfar(is_data));
+else
+printk("Invalid FAR, don't walk the hypervisor tables\n");
+
+do_unexpected_trap(fault, regs);
 
+break;
+}
 default:
 printk("Hypervisor Trap. HSR=0x%x EC=0x%x IL=%x 
Syndrome=0x%"PRIx32"\n",
hsr.bits, hsr.ec, hsr.len, hsr.iss);
-- 
2.11.0


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


[Xen-devel] [PATCH 21/27] xen/arm: mm: Rename and clarify AP[1] in the stage-1 page table

2017-08-14 Thread Julien Grall
The description of AP[1] in Xen is based on testing rather than the ARM
ARM.

Per the ARM ARM, on EL2 stage-1 page table, AP[1] is RES1 as the
translation regime applies to only one exception level (see D4.4.4 and
G4.6.1 in ARM DDI 0487B.a).

Update the comment and also rename the field to match the description in
the ARM ARM.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c  | 10 +-
 xen/include/asm-arm/lpae.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index ce1858fbf3..c0d5fda269 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -273,7 +273,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 .table = 0,   /* Set to 1 for links and 4k maps */
 .ai = attr,
 .ns = 1,  /* Hyp mode is in the non-secure world */
-.user = 1,/* See below */
+.up = 1,  /* See below */
 .ro = 0,  /* Assume read-write */
 .af = 1,  /* No need for access tracking */
 .ng = 1,  /* Makes TLB flushes easier */
@@ -282,10 +282,10 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 .avail = 0,   /* Reference count for domheap mapping */
 }};
 /*
- * Setting the User bit is strange, but the ATS1H[RW] instructions
- * don't seem to work otherwise, and since we never run on Xen
- * pagetables in User mode it's OK.  If this changes, remember
- * to update the hard-coded values in head.S too.
+ * For EL2 stage-1 page table, up (aka AP[1]) is RES1 as the translation
+ * regime applies to only one exception level (see D4.4.4 and G4.6.1
+ * in ARM DDI 0487B.a). If this changes, remember to update the
+ * hard-coded values in head.S too.
  */
 
 switch ( attr )
diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index a62b118630..9402434c1e 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -33,7 +33,7 @@ typedef struct __packed {
  */
 unsigned long ai:3; /* Attribute Index */
 unsigned long ns:1; /* Not-Secure */
-unsigned long user:1;   /* User-visible */
+unsigned long up:1; /* Unpriviledged access */
 unsigned long ro:1; /* Read-Only */
 unsigned long sh:2; /* Shareability */
 unsigned long af:1; /* Access Flag */
-- 
2.11.0


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


[Xen-devel] [PATCH 22/27] xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()

2017-08-14 Thread Julien Grall
We should consider the early boot period to end when we stop using the
boot allocator. This is inline with x86 and will be helpful to know
whether we should allocate memory from the boot allocator or xenheap.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/setup.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 277b566b88..46737a2eca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -757,6 +757,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 end_boot_allocator();
 
+/*
+ * The memory subsystem has been initialized, we can now switch from
+ * early_boot -> boot.
+ */
+system_state = SYS_STATE_boot;
+
 vm_init();
 
 if ( acpi_disabled )
@@ -779,8 +785,6 @@ void __init start_xen(unsigned long boot_phys_offset,
 console_init_preirq();
 console_init_ring();
 
-system_state = SYS_STATE_boot;
-
 processor_id();
 
 smp_init_cpus();
-- 
2.11.0


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


[Xen-devel] [PATCH 25/27] xen/arm: mm: Embed permission in the flags

2017-08-14 Thread Julien Grall
Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.

Add introduce a couple of new flags for the permissions (Non-eXecutable,
Read-Only) and also provides define that combine the memory attribute
and permission for common combination.

A follow-up patch will change modify_xen_mappings to use the new flags.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/page.h | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 1bf8e9d012..047220f86b 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -67,12 +67,28 @@
  * Layout of the flags used for updating the hypervisor page tables
  *
  * [0:2] Memory Attribute Index
+ * [3:4] Permission flags
  */
 #define PAGE_AI_MASK(x) ((x) & 0x7U)
 
-#define PAGE_HYPERVISOR (MT_NORMAL)
-#define PAGE_HYPERVISOR_NOCACHE (MT_DEVICE_nGnRE)
-#define PAGE_HYPERVISOR_WC  (MT_NORMAL_NC)
+#define _PAGE_XN_BIT3
+#define _PAGE_RO_BIT4
+#define _PAGE_XN(1U << _PAGE_XN_BIT)
+#define _PAGE_RO(1U << _PAGE_RO_BIT)
+#define PAGE_XN_MASK(x) (((x) >> _PAGE_XN_BIT) & 0x1U)
+#define PAGE_RO_MASK(x) (((x) >> _PAGE_RO_BIT) & 0x1U)
+
+/* Device memory will always be mapped read-write non-executable. */
+#define _PAGE_DEVICE_PAGE_XN
+#define _PAGE_NORMALMT_NORMAL
+
+#define PAGE_HYPERVISOR_RO  (_PAGE_NORMAL|_PAGE_RO|_PAGE_XN)
+#define PAGE_HYPERVISOR_RX  (_PAGE_NORMAL|_PAGE_RO)
+#define PAGE_HYPERVISOR_RW  (_PAGE_NORMAL|_PAGE_XN)
+
+#define PAGE_HYPERVISOR PAGE_HYPERVISOR_RW
+#define PAGE_HYPERVISOR_NOCACHE (_PAGE_DEVICE|MT_DEVICE_nGnRE)
+#define PAGE_HYPERVISOR_WC  (_PAGE_DEVICE|MT_NORMAL_NC)
 
 /*
  * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to be
-- 
2.11.0


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


[Xen-devel] [PATCH 06/27] xen/mm: Use __virt_to_mfn in map_domain_page instead of virt_to_mfn

2017-08-14 Thread Julien Grall
virt_to_mfn may by overridden by the source files, for improving locally
typesafe.

Therefore map_domain_page has to use __virt_to_mfn to prevent any
compilation issue in sources files that override the helper.

Signed-off-by: Julien Grall 
---

Cc: Stefano Stabellini 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/asm-arm/mm.h  | 3 ++-
 xen/include/xen/domain_page.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 28bdcc900e..71d7d36992 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -253,7 +253,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
unsigned int flags)
 
 /* Convert between Xen-heap virtual addresses and machine frame numbers. */
 #define __virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
-#define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
+#define __mfn_to_virt(mfn) (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
 
 /*
  * We define non-underscored wrappers for above conversion functions.
@@ -263,6 +263,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
unsigned int flags)
 #define mfn_to_page(mfn)__mfn_to_page(mfn)
 #define page_to_mfn(pg) __page_to_mfn(pg)
 #define virt_to_mfn(va) __virt_to_mfn(va)
+#define mfn_to_virt(mfn)__mfn_to_virt(mfn)
 
 /* Convert between Xen-heap virtual addresses and page-info structures. */
 static inline struct page_info *virt_to_page(const void *v)
diff --git a/xen/include/xen/domain_page.h b/xen/include/xen/domain_page.h
index 93f2a5aaf7..890bae5b9c 100644
--- a/xen/include/xen/domain_page.h
+++ b/xen/include/xen/domain_page.h
@@ -53,7 +53,7 @@ static inline void *__map_domain_page_global(const struct 
page_info *pg)
 
 #else /* !CONFIG_DOMAIN_PAGE */
 
-#define map_domain_page(mfn)mfn_to_virt(mfn_x(mfn))
+#define map_domain_page(mfn)__mfn_to_virt(mfn_x(mfn))
 #define __map_domain_page(pg)   page_to_virt(pg)
 #define unmap_domain_page(va)   ((void)(va))
 #define domain_page_map_to_mfn(va)  virt_to_mfn((unsigned long)(va))
-- 
2.11.0


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


[Xen-devel] [PATCH 20/27] xen/arm: page: Use ARMv8 naming to improve readability

2017-08-14 Thread Julien Grall
This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). Each
type will contain "NORMAL" or "DEVICE" to make clear whether each attribute
targets device or normal memory.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/kernel.c |  2 +-
 xen/arch/arm/mm.c | 28 +-
 xen/arch/arm/platforms/vexpress.c |  2 +-
 xen/drivers/video/arm_hdlcd.c |  2 +-
 xen/include/asm-arm/page.h| 42 +++
 5 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9c183f96da..a12baa86e7 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -54,7 +54,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len)
 s = paddr & (PAGE_SIZE-1);
 l = min(PAGE_SIZE - s, len);
 
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_BUFFERABLE);
+set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_NORMAL_NC);
 memcpy(dst, src + s, l);
 clean_dcache_va_range(dst, l);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 45974846a9..ce1858fbf3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -290,7 +290,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 
 switch ( attr )
 {
-case MT_BUFFERABLE:
+case MT_NORMAL_NC:
 /*
  * ARM ARM: Overlaying the shareability attribute (DDI
  * 0406C.b B3-1376 to 1377)
@@ -305,8 +305,8 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
  */
 e.pt.sh = LPAE_SH_OUTER;
 break;
-case MT_UNCACHED:
-case MT_DEV_SHARED:
+case MT_DEVICE_nGnRnE:
+case MT_DEVICE_nGnRE:
 /*
  * Shareability is ignored for non-Normal memory, Outer is as
  * good as anything.
@@ -369,7 +369,7 @@ static void __init create_mappings(lpae_t *second,
 
 count = nr_mfns / LPAE_ENTRIES;
 p = second + second_linear_offset(virt_offset);
-pte = mfn_to_xen_entry(_mfn(base_mfn), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(base_mfn), MT_NORMAL);
 if ( granularity == 16 * LPAE_ENTRIES )
 pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. */
 for ( i = 0; i < count; i++ )
@@ -422,7 +422,7 @@ void *map_domain_page(mfn_t mfn)
 else if ( map[slot].pt.avail == 0 )
 {
 /* Commandeer this 2MB slot */
-pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_NORMAL);
 pte.pt.avail = 1;
 write_pte(map + slot, pte);
 break;
@@ -543,7 +543,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 {
 paddr_t ma = va + phys_offset;
 
-return mfn_to_xen_entry(maddr_to_mfn(ma), MT_WRITEALLOC);
+return mfn_to_xen_entry(maddr_to_mfn(ma), MT_NORMAL);
 }
 
 /* Map the FDT in the early boot page table */
@@ -652,7 +652,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 /* Initialise xen second level entries ... */
 /* ... Xen's text etc */
 
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
 pte.pt.xn = 0;/* Contains our text mapping! */
 xen_second[second_table_offset(XEN_VIRT_START)] = pte;
 
@@ -669,7 +669,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 
 /* ... Boot Misc area for xen relocation */
 dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_NORMAL);
 /* Map the destination in xen_second. */
 xen_second[second_table_offset(dest_va)] = pte;
 /* Map the destination in boot_second. */
@@ -700,7 +700,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
 if ( !is_kernel(va) )
 break;
-pte = mfn_to_xen_entry(mfn, MT_WRITEALLOC);
+pte = mfn_to_xen_entry(mfn, MT_NORMAL);
 pte.pt.table = 1; /* 4k mappings always have this bit set */
 if ( is_kernel_text(va) || is_kernel_inittext(va) )
 {
@@ -771,7 +771,7 @@ int init_secondary_pagetables(int cpu)
 for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
 {
 pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
-   MT_WRITEALLOC);
+   MT_NORMAL);
 pte.pt.table = 1;
 write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
 }
@@ -869,13 +869,13 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 mfn_t first_mfn = alloc_boot_pages(1, 1);
 
 clear_page(mfn_to_virt(first_mfn));
-pte = mfn_to_xen_entry(first_mfn, MT_WRITEALLOC);
+pte 

[Xen-devel] [PATCH 19/27] xen/arm: page: Clean-up the definition of MAIRVAL

2017-08-14 Thread Julien Grall
Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
both hardcoded value. This makes quite difficult to understand the value
written in both registers.

Rework the definition by using value of each attribute shifted by their
associated index.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/page.h | 43 +--
 1 file changed, 25 insertions(+), 18 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index d7a048b64d..86b227c291 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -22,6 +22,21 @@
 #define LPAE_SH_INNER 0x3
 
 /*
+ * Attribute Indexes.
+ *
+ * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
+ * table entry. They are indexes into the bytes of the MAIR*
+ * registers, as defined above.
+ *
+ */
+#define MT_UNCACHED  0x0
+#define MT_BUFFERABLE0x1
+#define MT_WRITETHROUGH  0x2
+#define MT_WRITEBACK 0x3
+#define MT_DEV_SHARED0x4
+#define MT_WRITEALLOC0x7
+
+/*
  * LPAE Memory region attributes. Indexed by the AttrIndex bits of a
  * LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and MAIR1.
  *
@@ -35,26 +50,18 @@
  *   reserved 110
  *   MT_WRITEALLOC111      -- Write-back write-allocate
  *
- *   MT_DEV_WC001   (== BUFFERABLE)
  */
-#define MAIR0VAL 0xeeaa4400
-#define MAIR1VAL 0xff04
-#define MAIRVAL (MAIR0VAL|MAIR1VAL<<32)
+#define MAIR(attr, mt) (_AC(attr, ULL) << ((mt) * 8))
 
-/*
- * Attribute Indexes.
- *
- * These are valid in the AttrIndx[2:0] field of an LPAE stage 1 page
- * table entry. They are indexes into the bytes of the MAIR*
- * registers, as defined above.
- *
- */
-#define MT_UNCACHED  0x0
-#define MT_BUFFERABLE0x1
-#define MT_WRITETHROUGH  0x2
-#define MT_WRITEBACK 0x3
-#define MT_DEV_SHARED0x4
-#define MT_WRITEALLOC0x7
+#define MAIRVAL (MAIR(0x00, MT_UNCACHED) | \
+ MAIR(0x44, MT_BUFFERABLE)   | \
+ MAIR(0xaa, MT_WRITETHROUGH) | \
+ MAIR(0xee, MT_WRITEBACK)| \
+ MAIR(0x04, MT_DEV_SHARED)   | \
+ MAIR(0xff, MT_WRITEALLOC))
+
+#define MAIR0VAL (MAIRVAL & 0x)
+#define MAIR1VAL (MAIRVAL >> 32)
 
 #define PAGE_HYPERVISOR (MT_WRITEALLOC)
 #define PAGE_HYPERVISOR_NOCACHE (MT_DEV_SHARED)
-- 
2.11.0


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


[Xen-devel] [PATCH 24/27] xen/arm: page: Describe the layout of flags used to update page tables

2017-08-14 Thread Julien Grall
Currently, the flags used to update page tables (i.e PAGE_HYPERVISOR_*)
only contains the memory attribute index. Follow-up patches will add
more information in it.

At the same time introduce PAGE_AI_MASK to get the memory attribute
index easily.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c  | 2 +-
 xen/include/asm-arm/page.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 411fe02842..cd7bcf7aca 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1021,7 +1021,7 @@ static int create_xen_entries(enum xenmap_operation op,
 }
 if ( op == RESERVE )
 break;
-pte = mfn_to_xen_entry(mfn, flags);
+pte = mfn_to_xen_entry(mfn, PAGE_AI_MASK(flags));
 pte.pt.table = 1;
 write_pte(entry, pte);
 break;
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index d9dac92e73..1bf8e9d012 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -63,6 +63,13 @@
 #define MAIR0VAL (MAIRVAL & 0x)
 #define MAIR1VAL (MAIRVAL >> 32)
 
+/*
+ * Layout of the flags used for updating the hypervisor page tables
+ *
+ * [0:2] Memory Attribute Index
+ */
+#define PAGE_AI_MASK(x) ((x) & 0x7U)
+
 #define PAGE_HYPERVISOR (MT_NORMAL)
 #define PAGE_HYPERVISOR_NOCACHE (MT_DEVICE_nGnRE)
 #define PAGE_HYPERVISOR_WC  (MT_NORMAL_NC)
-- 
2.11.0


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


[Xen-devel] [PATCH 16/27] xen/arm: page: Remove unused attributes DEV_NONSHARED and DEV_CACHED

2017-08-14 Thread Julien Grall
They were imported from non-LPAE Linux, but Xen is LPAE only. It is time
to do some clean-up in the memory attribute and keep only what make
sense for Xen. Follow-up patch will do more clean-up.

Also, update the comment saying our attribute matches Linux.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/page.h | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index cef2f28914..465300c6e5 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -21,9 +21,9 @@
 #define LPAE_SH_OUTER 0x2
 #define LPAE_SH_INNER 0x3
 
-/* LPAE Memory region attributes, to match Linux's (non-LPAE) choices.
- * Indexed by the AttrIndex bits of a LPAE entry;
- * the 8-bit fields are packed little-endian into MAIR0 and MAIR1
+/*
+ * LPAE Memory region attributes. Indexed by the AttrIndex bits of a
+ * LPAE entry; the 8-bit fields are packed little-endian into MAIR0 and MAIR1.
  *
  * aiencoding
  *   UNCACHED  000      -- Strongly Ordered
@@ -35,9 +35,7 @@
  *   reserved  110
  *   WRITEALLOC111      -- Write-back write-allocate
  *
- *   DEV_NONSHARED 100   (== DEV_SHARED)
  *   DEV_WC001   (== BUFFERABLE)
- *   DEV_CACHED011   (== WRITEBACK)
  */
 #define MAIR0VAL 0xeeaa4400
 #define MAIR1VAL 0xff04
@@ -57,9 +55,7 @@
 #define WRITEBACK 0x3
 #define DEV_SHARED0x4
 #define WRITEALLOC0x7
-#define DEV_NONSHARED DEV_SHARED
 #define DEV_WCBUFFERABLE
-#define DEV_CACHEDWRITEBACK
 
 #define PAGE_HYPERVISOR (WRITEALLOC)
 #define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED)
-- 
2.11.0


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


[Xen-devel] [PATCH 18/27] xen/arm: page: Prefix memory types with MT_

2017-08-14 Thread Julien Grall
This will avoid confusion in the code when using them.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/kernel.c |  2 +-
 xen/arch/arm/mm.c | 28 +--
 xen/arch/arm/platforms/vexpress.c |  2 +-
 xen/drivers/video/arm_hdlcd.c |  2 +-
 xen/include/asm-arm/page.h| 40 +++
 5 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 7403ec0c0e..9c183f96da 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -54,7 +54,7 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned long 
len)
 s = paddr & (PAGE_SIZE-1);
 l = min(PAGE_SIZE - s, len);
 
-set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), BUFFERABLE);
+set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), MT_BUFFERABLE);
 memcpy(dst, src + s, l);
 clean_dcache_va_range(dst, l);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 349ac58ffe..45974846a9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -290,7 +290,7 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
 
 switch ( attr )
 {
-case BUFFERABLE:
+case MT_BUFFERABLE:
 /*
  * ARM ARM: Overlaying the shareability attribute (DDI
  * 0406C.b B3-1376 to 1377)
@@ -305,8 +305,8 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
attr)
  */
 e.pt.sh = LPAE_SH_OUTER;
 break;
-case UNCACHED:
-case DEV_SHARED:
+case MT_UNCACHED:
+case MT_DEV_SHARED:
 /*
  * Shareability is ignored for non-Normal memory, Outer is as
  * good as anything.
@@ -369,7 +369,7 @@ static void __init create_mappings(lpae_t *second,
 
 count = nr_mfns / LPAE_ENTRIES;
 p = second + second_linear_offset(virt_offset);
-pte = mfn_to_xen_entry(_mfn(base_mfn), WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(base_mfn), MT_WRITEALLOC);
 if ( granularity == 16 * LPAE_ENTRIES )
 pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. */
 for ( i = 0; i < count; i++ )
@@ -422,7 +422,7 @@ void *map_domain_page(mfn_t mfn)
 else if ( map[slot].pt.avail == 0 )
 {
 /* Commandeer this 2MB slot */
-pte = mfn_to_xen_entry(_mfn(slot_mfn), WRITEALLOC);
+pte = mfn_to_xen_entry(_mfn(slot_mfn), MT_WRITEALLOC);
 pte.pt.avail = 1;
 write_pte(map + slot, pte);
 break;
@@ -543,7 +543,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 {
 paddr_t ma = va + phys_offset;
 
-return mfn_to_xen_entry(maddr_to_mfn(ma), WRITEALLOC);
+return mfn_to_xen_entry(maddr_to_mfn(ma), MT_WRITEALLOC);
 }
 
 /* Map the FDT in the early boot page table */
@@ -652,7 +652,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 /* Initialise xen second level entries ... */
 /* ... Xen's text etc */
 
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
 pte.pt.xn = 0;/* Contains our text mapping! */
 xen_second[second_table_offset(XEN_VIRT_START)] = pte;
 
@@ -669,7 +669,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 
 /* ... Boot Misc area for xen relocation */
 dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), WRITEALLOC);
+pte = mfn_to_xen_entry(maddr_to_mfn(xen_paddr), MT_WRITEALLOC);
 /* Map the destination in xen_second. */
 xen_second[second_table_offset(dest_va)] = pte;
 /* Map the destination in boot_second. */
@@ -700,7 +700,7 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
 if ( !is_kernel(va) )
 break;
-pte = mfn_to_xen_entry(mfn, WRITEALLOC);
+pte = mfn_to_xen_entry(mfn, MT_WRITEALLOC);
 pte.pt.table = 1; /* 4k mappings always have this bit set */
 if ( is_kernel_text(va) || is_kernel_inittext(va) )
 {
@@ -771,7 +771,7 @@ int init_secondary_pagetables(int cpu)
 for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
 {
 pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
-   WRITEALLOC);
+   MT_WRITEALLOC);
 pte.pt.table = 1;
 write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], 
pte);
 }
@@ -869,13 +869,13 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 mfn_t first_mfn = alloc_boot_pages(1, 1);
 
 clear_page(mfn_to_virt(first_mfn));
-pte = mfn_to_xen_entry(first_mfn, WRITEALLOC);
+pte = mfn_to_xen_entry(first_mfn, MT_WRITEALLOC);
 pte.pt.table = 1;
 write_pte(p, pte);
 first = 

[Xen-devel] [PATCH 04/27] xen/mm: Move {G, M]FN <-> {G, M}ADDR helpers to common code

2017-08-14 Thread Julien Grall
Helpers to convert {G,M}FN to {G,M}ADDR and vice-versa were recently
introduced on ARM. However, they could be used in common code to
simplify a bit the code when using typesafes.

Signed-off-by: Julien Grall 
---

Cc: Stefano Stabellini 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/asm-arm/mm.h | 4 
 xen/include/xen/mm.h | 6 ++
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index ef84b72474..28bdcc900e 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -207,10 +207,6 @@ static inline void __iomem *ioremap_wc(paddr_t start, 
size_t len)
 #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
 #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
 #define paddr_to_pdx(pa)pfn_to_pdx(paddr_to_pfn(pa))
-#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
-#define gaddr_to_gfn(ga)_gfn(paddr_to_pfn(ga))
-#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
-#define maddr_to_mfn(ma)_mfn(paddr_to_pfn(ma))
 #define vmap_to_mfn(va) paddr_to_pfn(virt_to_maddr((vaddr_t)va))
 #define vmap_to_page(va)mfn_to_page(vmap_to_mfn(va))
 
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 503b92e4b0..eb0409d832 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -92,6 +92,9 @@ static inline bool_t mfn_eq(mfn_t x, mfn_t y)
 return mfn_x(x) == mfn_x(y);
 }
 
+#define maddr_to_mfn(maddr) _mfn(paddr_to_pfn(maddr))
+#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
+
 TYPE_SAFE(unsigned long, gfn);
 #define PRI_gfn  "05lx"
 #define INVALID_GFN  _gfn(~0UL)
@@ -130,6 +133,9 @@ static inline bool_t gfn_eq(gfn_t x, gfn_t y)
 return gfn_x(x) == gfn_x(y);
 }
 
+#define gaddr_to_gfn(gaddr) _gfn(paddr_to_pfn(gaddr))
+#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
+
 TYPE_SAFE(unsigned long, pfn);
 #define PRI_pfn  "05lx"
 #define INVALID_PFN  (~0UL)
-- 
2.11.0


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


[Xen-devel] [PATCH 17/27] xen/arm: page: Use directly BUFFERABLE and drop DEV_WC

2017-08-14 Thread Julien Grall
DEV_WC is only used for PAGE_HYPERVISOR_WC and does not bring much
improvement.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/page.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 465300c6e5..660e1779c5 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -55,11 +55,10 @@
 #define WRITEBACK 0x3
 #define DEV_SHARED0x4
 #define WRITEALLOC0x7
-#define DEV_WCBUFFERABLE
 
 #define PAGE_HYPERVISOR (WRITEALLOC)
 #define PAGE_HYPERVISOR_NOCACHE (DEV_SHARED)
-#define PAGE_HYPERVISOR_WC  (DEV_WC)
+#define PAGE_HYPERVISOR_WC  (BUFFERABLE)
 
 /*
  * Defines for changing the hypervisor PTE .ro and .nx bits. This is only to be
-- 
2.11.0


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


[Xen-devel] [PATCH 02/27] xen/x86: srat: Don't check alloc_boot_pages return

2017-08-14 Thread Julien Grall
alloc_boot_pages will panic if it is not possible to allocate. So the
check in the caller is pointless.

Signed-off-by: Julien Grall 
---

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/srat.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index cd1283e58c..95660a9bbc 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -194,11 +194,6 @@ void __init acpi_numa_slit_init(struct acpi_table_slit 
*slit)
return;
}
mfn = alloc_boot_pages(PFN_UP(slit->header.length), 1);
-   if (!mfn) {
-   printk(KERN_ERR "ACPI: Unable to allocate memory for "
-  "saving ACPI SLIT numa information.\n");
-   return;
-   }
acpi_slit = mfn_to_virt(mfn);
memcpy(acpi_slit, slit, slit->header.length);
 }
-- 
2.11.0


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


[Xen-devel] [PATCH 10/27] xen/arm: arm32: Don't define FAR_EL1

2017-08-14 Thread Julien Grall
Aliasing FAR_EL1 to IFAR is wrong because on ARMv8 FAR_EL1[31:0] is
architecturally mapped to DFAR and FAR_EL1[63:32] to DFAR.

As FAR_EL1 is not currently used in ARM32 code, remove it.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/cpregs.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 1889d7cbfb..9e138489f0 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -306,7 +306,6 @@
 #define DACR32_EL2  DACR
 #define ESR_EL1 DFSR
 #define ESR_EL2 HSR
-#define FAR_EL1 HIFAR
 #define HCR_EL2 HCR
 #define HPFAR_EL2   HPFAR
 #define HSTR_EL2HSTR
-- 
2.11.0


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


[Xen-devel] [PATCH 00/27] xen/arm: Memory subsystem clean-up

2017-08-14 Thread Julien Grall
Hi all,

This patch series contains clean-up for the ARM Memory subsystem in
preparation of reworking the page tables handling.

A branch with the patches can be found on xenbits:

https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
branch mm-cleanup-v1

Cheers,

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Ross Lagerwall 


Julien Grall (27):
  xen/x86: numa: Don't check alloc_boot_pages return
  xen/x86: srat: Don't check alloc_boot_pages return
  xen/x86: mm: Don't check alloc_boot_pages return
  xen/mm: Move {G,M]FN <-> {G,M}ADDR helpers to common code
  xen/mm: Use typesafe MFN for alloc_boot_pages return
  xen/mm: Use __virt_to_mfn in map_domain_page instead of virt_to_mfn
  xen/arm: mm: Redefine mfn_to_virt to use typesafe
  xen/arm: hsr_iabt: Document RES0 field
  xen/arm: traps: Don't define FAR_EL2 for ARM32
  xen/arm: arm32: Don't define FAR_EL1
  xen/arm: Add FnV field in hsr_*abt
  xen/arm: Introduce hsr_xabt to gather common bits between hsr_dabt and
  xen/arm: traps: Introduce a helper to read the hypersivor fault
register
  xen/arm: traps: Improve logging for data/prefetch abort fault
  xen/arm: Replace ioremap_attr(PAGE_HYPERVISOR_NOCACHE) call by
ioremap_nocache
  xen/arm: page: Remove unused attributes DEV_NONSHARED and DEV_CACHED
  xen/arm: page: Use directly BUFFERABLE and drop DEV_WC
  xen/arm: page: Prefix memory types with MT_
  xen/arm: page: Clean-up the definition of MAIRVAL
  xen/arm: page: Use ARMv8 naming to improve readability
  xen/arm: mm: Rename and clarify AP[1] in the stage-1 page table
  xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()
  xen/arm: mm: Rename 'ai' into 'flags' in create_xen_entries
  xen/arm: page: Describe the layout of flags used to update page tables
  xen/arm: mm: Embed permission in the flags
  xen/arm: mm: Handling permission flags when adding a new mapping
  xen/arm: mm: Use memory flags for modify_xen_mappings rather than
custom one

 xen/arch/arm/kernel.c |   2 +-
 xen/arch/arm/livepatch.c  |   6 +--
 xen/arch/arm/mm.c |  79 +-
 xen/arch/arm/platforms/exynos5.c  |   2 +-
 xen/arch/arm/platforms/omap5.c|   6 +--
 xen/arch/arm/platforms/vexpress.c |   2 +-
 xen/arch/arm/setup.c  |  12 +++--
 xen/arch/arm/traps.c  |  52 +---
 xen/arch/x86/mm.c |   8 +--
 xen/arch/x86/numa.c   |  10 +---
 xen/arch/x86/srat.c   |   7 +--
 xen/common/page_alloc.c   |   7 ++-
 xen/drivers/acpi/osl.c|   2 +-
 xen/drivers/video/arm_hdlcd.c |   2 +-
 xen/include/asm-arm/cpregs.h  |   2 -
 xen/include/asm-arm/lpae.h|   2 +-
 xen/include/asm-arm/mm.h  |   7 +--
 xen/include/asm-arm/page.h| 100 ++
 xen/include/asm-arm/processor.h   |  25 --
 xen/include/xen/domain_page.h |   2 +-
 xen/include/xen/mm.h  |   9 +++-
 21 files changed, 204 insertions(+), 140 deletions(-)

-- 
2.11.0


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


[Xen-devel] [PATCH 09/27] xen/arm: traps: Don't define FAR_EL2 for ARM32

2017-08-14 Thread Julien Grall
Aliasing FAR_EL2 to HIFAR makes the code confusing because on ARMv8
FAR_EL2[31:0] is architecturally mapped to HDFAR and FAR_EL2[63:32] to
FAR_EL2. See D7.2.30 in ARM DDI 0487B.a. Open-code the alias instead.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 8 +++-
 xen/include/asm-arm/cpregs.h | 1 -
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c07999b518..498d8c594a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2560,11 +2560,17 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
   const union hsr hsr)
 {
 int rc;
-register_t gva = READ_SYSREG(FAR_EL2);
+register_t gva;
 uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
 paddr_t gpa;
 mfn_t mfn;
 
+#ifdef CONFIG_ARM_32
+gva = READ_CP32(HIFAR);
+#else
+gva = READ_SYSREG64(FAR_EL2);
+#endif
+
 /*
  * If this bit has been set, it means that this instruction abort is caused
  * by a guest external abort. We can handle this instruction abort as guest
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index af45ec7a65..1889d7cbfb 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -307,7 +307,6 @@
 #define ESR_EL1 DFSR
 #define ESR_EL2 HSR
 #define FAR_EL1 HIFAR
-#define FAR_EL2 HIFAR
 #define HCR_EL2 HCR
 #define HPFAR_EL2   HPFAR
 #define HSTR_EL2HSTR
-- 
2.11.0


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


[Xen-devel] [PATCH 12/27] xen/arm: Introduce hsr_xabt to gather common bits between hsr_dabt and

2017-08-14 Thread Julien Grall
This will allow to consolidate some part of the data abort and prefetch
abort handling in a single function later on.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/processor.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 3ef606c554..9964348189 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -537,6 +537,19 @@ union hsr {
 unsigned long ec:6;/* Exception Class */
 } dabt; /* HSR_EC_DATA_ABORT_* */
 
+/* Contain the common bits between DABT and IABT */
+struct hsr_xabt {
+unsigned long fsc:6;/* Fault status code */
+unsigned long pad1:1;
+unsigned long s1ptw:1;  /* Stage 2 fault during stage 1 translation */
+unsigned long pad2:1;
+unsigned long eat:1;/* External abort type */
+unsigned long fnv:1;/* FAR not Valid */
+unsigned long pad3:14;
+unsigned long len:1;/* Instruction length */
+unsigned long ec:6; /* Exception Class */
+} xabt;
+
 #ifdef CONFIG_ARM_64
 struct hsr_brk {
 unsigned long comment:16;   /* Comment */
-- 
2.11.0


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


[Xen-devel] [PATCH 11/27] xen/arm: Add FnV field in hsr_*abt

2017-08-14 Thread Julien Grall
FnV (FAR not Valid) bit was introduced by ARMv8 in both AArch32 and
AArch64 (See D7-2275, D7-2277, G6-4958, G6-4962 in ARM DDI 0487B.a).

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/processor.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 51645f08c0..3ef606c554 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -509,7 +509,8 @@ union hsr {
 unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
 unsigned long res1:1;  /* RES0 */
 unsigned long eat:1;   /* External abort type */
-unsigned long res2:15;
+unsigned long fnv:1;   /* FAR not Valid */
+unsigned long res2:14;
 unsigned long len:1;   /* Instruction length */
 unsigned long ec:6;/* Exception Class */
 } iabt; /* HSR_EC_INSTR_ABORT_* */
@@ -520,10 +521,11 @@ union hsr {
 unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
 unsigned long cache:1; /* Cache Maintenance */
 unsigned long eat:1;   /* External Abort Type */
+unsigned long fnv:1;   /* FAR not Valid */
 #ifdef CONFIG_ARM_32
-unsigned long sbzp0:6;
+unsigned long sbzp0:5;
 #else
-unsigned long sbzp0:4;
+unsigned long sbzp0:3;
 unsigned long ar:1;/* Acquire Release */
 unsigned long sf:1;/* Sixty Four bit register */
 #endif
-- 
2.11.0


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


[Xen-devel] [PATCH 07/27] xen/arm: mm: Redefine mfn_to_virt to use typesafe

2017-08-14 Thread Julien Grall
This add a bit more safety in the memory subsystem code.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b3def63ed7..349ac58ffe 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -47,6 +47,8 @@ struct domain *dom_xen, *dom_io, *dom_cow;
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+#undef mfn_to_virt
+#define mfn_to_virt(mfn) __mfn_to_virt(mfn_x(mfn))
 
 /* Static start-of-day pagetables that we use before the allocators
  * are up. These are used by all CPUs during bringup before switching
@@ -837,7 +839,7 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
  * Virtual address aligned to previous 1GB to match physical
  * address alignment done above.
  */
-vaddr = (vaddr_t)mfn_to_virt(base_mfn) & FIRST_MASK;
+vaddr = (vaddr_t)__mfn_to_virt(base_mfn) & FIRST_MASK;
 
 while ( mfn < end_mfn )
 {
@@ -849,7 +851,7 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 /* mfn_to_virt is not valid on the 1st 1st mfn, since it
  * is not within the xenheap. */
 first = slot == xenheap_first_first_slot ?
-xenheap_first_first : mfn_to_virt(p->pt.base);
+xenheap_first_first : __mfn_to_virt(p->pt.base);
 }
 else if ( xenheap_first_first_slot == -1)
 {
@@ -866,11 +868,11 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 {
 mfn_t first_mfn = alloc_boot_pages(1, 1);
 
-clear_page(mfn_to_virt(mfn_x(first_mfn)));
+clear_page(mfn_to_virt(first_mfn));
 pte = mfn_to_xen_entry(first_mfn, WRITEALLOC);
 pte.pt.table = 1;
 write_pte(p, pte);
-first = mfn_to_virt(mfn_x(first_mfn));
+first = mfn_to_virt(first_mfn);
 }
 
 pte = mfn_to_xen_entry(_mfn(mfn), WRITEALLOC);
@@ -909,10 +911,10 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
 /* Compute the number of second level pages. */
 nr_second = ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;
 second_base = alloc_boot_pages(nr_second, 1);
-second = mfn_to_virt(mfn_x(second_base));
+second = mfn_to_virt(second_base);
 for ( i = 0; i < nr_second; i++ )
 {
-clear_page(mfn_to_virt(mfn_x(mfn_add(second_base, i;
+clear_page(mfn_to_virt(mfn_add(second_base, i)));
 pte = mfn_to_xen_entry(mfn_add(second_base, i), WRITEALLOC);
 pte.pt.table = 1;
 write_pte(_first[first_table_offset(FRAMETABLE_VIRT_START)+i], 
pte);
@@ -1005,7 +1007,7 @@ static int create_xen_entries(enum xenmap_operation op,
 
 BUG_ON(!lpae_valid(*entry));
 
-third = mfn_to_virt(entry->pt.base);
+third = __mfn_to_virt(entry->pt.base);
 entry = [third_table_offset(addr)];
 
 switch ( op ) {
-- 
2.11.0


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


[Xen-devel] [PATCH 13/27] xen/arm: traps: Introduce a helper to read the hypersivor fault register

2017-08-14 Thread Julien Grall
While ARM32 has 2 distinct registers for the hypervisor fault register
(one for prefetch abort, the other for data abort), AArch64 has only
one.

Currently, the logic is open-code but a follow-up patch will require to
read it too. So move the logic in a separate helper and use it instead
of open-coding it.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/traps.c | 35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 498d8c594a..819bdbc69e 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2530,6 +2530,28 @@ done:
 if (first) unmap_domain_page(first);
 }
 
+/*
+ * Return the value of the hypervisor fault address register.
+ *
+ * On ARM32, the register will be different depending whether the
+ * fault is a prefetch abort or data abort.
+ */
+static inline vaddr_t get_hfar(bool is_data)
+{
+vaddr_t gva;
+
+#ifdef CONFIG_ARM_32
+if ( is_data )
+gva = READ_CP32(HDFAR);
+else
+gva = READ_CP32(HIFAR);
+#else
+gva =  READ_SYSREG(FAR_EL2);
+#endif
+
+return gva;
+}
+
 static inline paddr_t get_faulting_ipa(vaddr_t gva)
 {
 register_t hpfar = READ_SYSREG(HPFAR_EL2);
@@ -2565,11 +2587,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 paddr_t gpa;
 mfn_t mfn;
 
-#ifdef CONFIG_ARM_32
-gva = READ_CP32(HIFAR);
-#else
-gva = READ_SYSREG64(FAR_EL2);
-#endif
+gva = get_hfar(false /* is_data */);
 
 /*
  * If this bit has been set, it means that this instruction abort is caused
@@ -2711,11 +2729,8 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 return __do_trap_serror(regs, true);
 
 info.dabt = dabt;
-#ifdef CONFIG_ARM_32
-info.gva = READ_CP32(HDFAR);
-#else
-info.gva = READ_SYSREG64(FAR_EL2);
-#endif
+
+info.gva = get_hfar(true /* is_data */);
 
 if ( hpfar_is_valid(dabt.s1ptw, fsc) )
 info.gpa = get_faulting_ipa(info.gva);
-- 
2.11.0


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


[Xen-devel] [PATCH 08/27] xen/arm: hsr_iabt: Document RES0 field

2017-08-14 Thread Julien Grall
Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/processor.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index ab5225fa6c..51645f08c0 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -505,9 +505,9 @@ union hsr {
 
 struct hsr_iabt {
 unsigned long ifsc:6;  /* Instruction fault status code */
-unsigned long res0:1;
+unsigned long res0:1;  /* RES0 */
 unsigned long s1ptw:1; /* Stage 2 fault during stage 1 translation */
-unsigned long res1:1;
+unsigned long res1:1;  /* RES0 */
 unsigned long eat:1;   /* External abort type */
 unsigned long res2:15;
 unsigned long len:1;   /* Instruction length */
-- 
2.11.0


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


[Xen-devel] [PATCH 15/27] xen/arm: Replace ioremap_attr(PAGE_HYPERVISOR_NOCACHE) call by ioremap_nocache

2017-08-14 Thread Julien Grall
ioremap_cache is a wrapper of ioremap_attr(...).

Signed-off-by: Julien Grall 
---
 xen/arch/arm/platforms/exynos5.c | 2 +-
 xen/arch/arm/platforms/omap5.c   | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index 2ae5fa66e0..95d6581d33 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -62,7 +62,7 @@ static int exynos5_init_time(void)
 dprintk(XENLOG_INFO, "mct_base_addr: %016llx size: %016llx\n",
 mct_base_addr, size);
 
-mct = ioremap_attr(mct_base_addr, size, PAGE_HYPERVISOR_NOCACHE);
+mct = ioremap_nocache(mct_base_addr, size);
 if ( !mct )
 {
 dprintk(XENLOG_ERR, "Unable to map MCT\n");
diff --git a/xen/arch/arm/platforms/omap5.c b/xen/arch/arm/platforms/omap5.c
index 1e1f9fa970..7dbba95756 100644
--- a/xen/arch/arm/platforms/omap5.c
+++ b/xen/arch/arm/platforms/omap5.c
@@ -51,8 +51,7 @@ static int omap5_init_time(void)
 unsigned int sys_clksel;
 unsigned int num, den, frac1, frac2;
 
-ckgen_prm_base = ioremap_attr(OMAP5_CKGEN_PRM_BASE,
-  0x20, PAGE_HYPERVISOR_NOCACHE);
+ckgen_prm_base = ioremap_nocache(OMAP5_CKGEN_PRM_BASE, 0x20);
 if ( !ckgen_prm_base )
 {
 dprintk(XENLOG_ERR, "%s: PRM_BASE ioremap failed\n", __func__);
@@ -64,8 +63,7 @@ static int omap5_init_time(void)
 
 iounmap(ckgen_prm_base);
 
-rt_ct_base = ioremap_attr(REALTIME_COUNTER_BASE,
-  0x20, PAGE_HYPERVISOR_NOCACHE);
+rt_ct_base = ioremap_nocache(REALTIME_COUNTER_BASE, 0x20);
 if ( !rt_ct_base )
 {
 dprintk(XENLOG_ERR, "%s: REALTIME_COUNTER_BASE ioremap failed\n", 
__func__);
-- 
2.11.0


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


[Xen-devel] [PATCH 05/27] xen/mm: Use typesafe MFN for alloc_boot_pages return

2017-08-14 Thread Julien Grall
At the moment, most of the callers will have to use mfn_x. However
follow-up patches will remove some of them by propagating the typesafe a
bit further.

Signed-off-by: Julien Grall 
---

Cc: Stefano Stabellini 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/arm/mm.c   | 26 ++
 xen/arch/arm/setup.c|  4 ++--
 xen/arch/x86/mm.c   |  4 ++--
 xen/arch/x86/numa.c |  2 +-
 xen/arch/x86/srat.c |  2 +-
 xen/common/page_alloc.c |  7 +++
 xen/drivers/acpi/osl.c  |  2 +-
 xen/include/xen/mm.h|  3 +--
 8 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index a810a056d7..b3def63ed7 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -864,13 +864,13 @@ void __init setup_xenheap_mappings(unsigned long base_mfn,
 }
 else
 {
-unsigned long first_mfn = alloc_boot_pages(1, 1);
+mfn_t first_mfn = alloc_boot_pages(1, 1);
 
-clear_page(mfn_to_virt(first_mfn));
-pte = mfn_to_xen_entry(_mfn(first_mfn), WRITEALLOC);
+clear_page(mfn_to_virt(mfn_x(first_mfn)));
+pte = mfn_to_xen_entry(first_mfn, WRITEALLOC);
 pte.pt.table = 1;
 write_pte(p, pte);
-first = mfn_to_virt(first_mfn);
+first = mfn_to_virt(mfn_x(first_mfn));
 }
 
 pte = mfn_to_xen_entry(_mfn(mfn), WRITEALLOC);
@@ -891,11 +891,12 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
 unsigned long nr_pages = (pe - ps) >> PAGE_SHIFT;
 unsigned long nr_pdxs = pfn_to_pdx(nr_pages);
 unsigned long frametable_size = nr_pdxs * sizeof(struct page_info);
-unsigned long base_mfn;
+mfn_t base_mfn;
 const unsigned long mapping_size = frametable_size < MB(32) ? MB(2) : 
MB(32);
 #ifdef CONFIG_ARM_64
 lpae_t *second, pte;
-unsigned long nr_second, second_base;
+unsigned long nr_second;
+mfn_t second_base;
 int i;
 #endif
 
@@ -908,18 +909,19 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
 /* Compute the number of second level pages. */
 nr_second = ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;
 second_base = alloc_boot_pages(nr_second, 1);
-second = mfn_to_virt(second_base);
+second = mfn_to_virt(mfn_x(second_base));
 for ( i = 0; i < nr_second; i++ )
 {
-clear_page(mfn_to_virt(second_base + i));
-pte = mfn_to_xen_entry(_mfn(second_base + i), WRITEALLOC);
+clear_page(mfn_to_virt(mfn_x(mfn_add(second_base, i;
+pte = mfn_to_xen_entry(mfn_add(second_base, i), WRITEALLOC);
 pte.pt.table = 1;
 write_pte(_first[first_table_offset(FRAMETABLE_VIRT_START)+i], 
pte);
 }
-create_mappings(second, 0, base_mfn, frametable_size >> PAGE_SHIFT, 
mapping_size);
+create_mappings(second, 0, mfn_x(base_mfn), frametable_size >> PAGE_SHIFT,
+mapping_size);
 #else
-create_mappings(xen_second, FRAMETABLE_VIRT_START,
-base_mfn, frametable_size >> PAGE_SHIFT, mapping_size);
+create_mappings(xen_second, FRAMETABLE_VIRT_START, mfn_x(base_mfn),
+frametable_size >> PAGE_SHIFT, mapping_size);
 #endif
 
 memset(_table[0], 0, nr_pdxs * sizeof(struct page_info));
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3b34855668..277b566b88 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -561,7 +561,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 init_boot_pages(pfn_to_paddr(boot_mfn_start), pfn_to_paddr(boot_mfn_end));
 
 /* Copy the DTB. */
-fdt = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+fdt = mfn_to_virt(mfn_x(alloc_boot_pages(dtb_pages, 1)));
 copy_from_paddr(fdt, dtb_paddr, dtb_size);
 device_tree_flattened = fdt;
 
@@ -671,7 +671,7 @@ static void __init setup_mm(unsigned long dtb_paddr, size_t 
dtb_size)
 dtb_pages = (dtb_size + PAGE_SIZE-1) >> PAGE_SHIFT;
 
 /* Copy the DTB. */
-fdt = mfn_to_virt(alloc_boot_pages(dtb_pages, 1));
+fdt = mfn_to_virt(mfn_x(alloc_boot_pages(dtb_pages, 1)));
 copy_from_paddr(fdt, dtb_paddr, dtb_size);
 device_tree_flattened = fdt;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 66e337109d..dc54ebf2e6 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -200,7 +200,7 @@ static void __init init_frametable_chunk(void *start, void 
*end)
  */
 while ( step && s + (step << PAGE_SHIFT) > e + (4 << PAGE_SHIFT) )
 step >>= PAGETABLE_ORDER;
-mfn = alloc_boot_pages(step, step);
+mfn = mfn_x(alloc_boot_pages(step, step));
 

[Xen-devel] [PATCH 01/27] xen/x86: numa: Don't check alloc_boot_pages return

2017-08-14 Thread Julien Grall
alloc_boot_pages will panic if it is not possible to allocate. So the
check in the caller is pointless.

Signed-off-by: Julien Grall 
---

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/numa.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index d45196fafc..ffeba6e180 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -101,14 +101,6 @@ static int __init allocate_cachealigned_memnodemap(void)
 unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
 unsigned long mfn = alloc_boot_pages(size, 1);
 
-if ( !mfn )
-{
-printk(KERN_ERR
-   "NUMA: Unable to allocate Memory to Node hash map\n");
-memnodemapsize = 0;
-return -1;
-}
-
 memnodemap = mfn_to_virt(mfn);
 mfn <<= PAGE_SHIFT;
 size <<= PAGE_SHIFT;
-- 
2.11.0


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


[Xen-devel] [PATCH 03/27] xen/x86: mm: Don't check alloc_boot_pages return

2017-08-14 Thread Julien Grall
The only way alloc_boot_pages will return 0 is during the error case.
Although, Xen will panic in the error path. So the check in the caller
is pointless.

Looking at the loop, my understanding is it will try to allocate in
smaller chunk if a bigger chunk fail. Given that alloc_boot_pages can
never check, the loop seems unecessary.

Signed-off-by: Julien Grall 

---

Cc: Jan Beulich 
Cc: Andrew Cooper 

I haven't tested this code, only build test it. I can't see how
alloc_boot_pages would return 0 other than the error path.
---
 xen/arch/x86/mm.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f53ca43554..66e337109d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -200,11 +200,7 @@ static void __init init_frametable_chunk(void *start, void 
*end)
  */
 while ( step && s + (step << PAGE_SHIFT) > e + (4 << PAGE_SHIFT) )
 step >>= PAGETABLE_ORDER;
-do {
-mfn = alloc_boot_pages(step, step);
-} while ( !mfn && (step >>= PAGETABLE_ORDER) );
-if ( !mfn )
-panic("Not enough memory for frame table");
+mfn = alloc_boot_pages(step, step);
 map_pages_to_xen(s, mfn, step, PAGE_HYPERVISOR);
 }
 
-- 
2.11.0


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


Re: [Xen-devel] [PATCH] include/public: add new elf note for support of huge physical addresses

2017-08-14 Thread Juergen Gross
On 14/08/17 15:18, Jan Beulich wrote:
 On 14.08.17 at 14:21,  wrote:
>> On 14/08/17 13:40, Jan Beulich wrote:
>> On 14.08.17 at 13:05,  wrote:
 On 14/08/17 12:48, Jan Beulich wrote:
 On 14.08.17 at 12:35,  wrote:
>> On 14/08/17 12:29, Jan Beulich wrote:
>> On 14.08.17 at 12:21,  wrote:
 Current pv guests will only see physical addresses up to 46 bits wide.
 In order to be able to run on a host supporting 5 level paging and to
 make use of any possible memory page there, physical addresses with up
 to 52 bits have to be supported.
>>>
>>> Is this a Xen shortcoming or a Linux one (I assume the latter)?
>>
>> It is a shortcoming of the Xen pv interface.
>
> Please be more precise: Where in the interface to we have a
> restriction to 46 bits?

 We have no definition that the mfn width in a pte can be larger than
 the pfn width for a given architecture (in this case a 4 level paging
 64 bit x86 host).

 So Xen has to assume a guest not telling otherwise has to be limited
 to mfns not exceeding 4 level hosts maximum addresses.
>>>
>>> The number of page table levels affects only virtual address
>>> width. Physical addresses can architecturally be 52 bits wide,
>>> and what CPUID extended leaf 8 provides is what limits
>>> physical address width.
>>
>> Yes.
>>
>> OTOH up to now there have been no x86 platforms supporting more than
>> 46 bits physical address width (at least AFAIK), and this limit is
>> explicitly specified for all current processors.
> 
> As said, AMD CPUs support 48 bits (and actually have hypertransport
> stuff sitting at the top end, just not RAM extending that far).
> 
 Or would you like to not limit current pv guests to the lower 64TB and
 risk them crashing, just because they interpreted the lack of any
 specific mfn width definition in another way as you do?
>>>
>>> Again - you saying "current pv guests" rather than "current
>>> Linux PV guests" makes me assume you've found some
>>> limitation in the PV ABI. Yet so far you didn't point out where
>>> that is, which then again makes me assume you're talking
>>> about a Linux limitation.
>>
>> Yes, I am talking of Linux here.
>>
>> And no, you are wrong that I haven't pointed out where the limitation
>> is: I have said that the PV ABI nowhere states that MFNs can be wider
>> than any current processor's PFNs.
> 
> Why would it need to? The relevant limits are imposed by CPUID
> output. There's no PV ABI aspect here.
> 
>> So when being pedantic you are right: the Linux kernel is violating
>> the specification by not being able to run on a processor specifying
>> physical address width to be 52 bits via CPUID.
>>
>> OTOH as there hasn't been any such processor up to now this was no
>> problem for Linux.
>>
>> We could say, of course, this is a problem of Linux which should be
>> fixed. I think this wouldn't be a wise thing to do: we don't want to
>> do finger pointing at Linux, but we want a smooth user's experience
>> with Xen. So we need some kind of interface to handle the current
>> situation that no Linux kernel up to 4.13 will be able to make use of
>> physical host memory above 64TB. Again: I don't think we want to let
>> those kernel's just crash and tell the users its Linux' fault, they
>> should either use a new kernel or KVM.
> 
> That's all fine, just that I'd expect you to make the hypervisor at
> once honor the new note. Before accepting the addition to the
> ABI, I'd at least like to see sketched out how the resulting
> restriction would be enforced by the hypervisor. With the way
> we do this for 32-bit guests I don't expect this to be entirely
> straightforward.

The minimal implementation would be to allocate memory for the guest
like today, then free all memory above the boundary the guest can
handle, and issue a message in case there was some memory freed. This
would tell the user what happened and why his guest wasn't started
or has less memory than intended. This would be much better than
random crashs at random times.

 This can be easily compared to the support of 5 level paging in the
 kernel happening right now: When the 5 level paging machines are
 available in the future you won't be limited to a rather recent kernel,
 but you can use one already being part of some distribution.
>>>
>>> Yes and no. Since we don't mean to introduce 5-level PV guests,
>>> we're not adding respective MMU ops anyway. If we would, it
>>> would still seem strange to introduced, say, MMUEXT_PIN_L5_TABLE
>>> without also implementing it. But yes, it would be possible, just
>>> that other than here there really would not be a need for the
>>> hypervisor to do anything for it as long as it doesn't itself know
>>> of 5 page table levels.
>>
>> The patch I'm thinking of would just avoid masking away MFN bits as
>> it is done today. 

Re: [Xen-devel] [PATCH v2 43/52] xen/arch/x86/io_apic.c: remove custom_param() error messages

2017-08-14 Thread Jan Beulich
>>> On 14.08.17 at 09:08,  wrote:
> With _cmdline_parse() now issuing error messages in case of illegal
> parameters signalled by parsing functions specified in custom_param()
> the message issued by setup_ioapic_ack() can be removed.
> 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



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


Re: [Xen-devel] [PATCH v2 41/52] xen/arch/x86/cpu/mcheck/mce.c: remove custom_param() error messages

2017-08-14 Thread Jan Beulich
>>> On 14.08.17 at 09:08,  wrote:
> With _cmdline_parse() now issuing error messages in case of illegal
> parameters signalled by parsing functions specified in custom_param()
> the message issued by mce_set_verbosity() can be removed.
> 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



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


Re: [Xen-devel] [PATCH v2 40/52] xen/arch/x86/apic.c: remove custom_param() error messages

2017-08-14 Thread Jan Beulich
>>> On 14.08.17 at 09:08,  wrote:
> With _cmdline_parse() now issuing error messages in case of illegal
> parameters signalled by parsing functions specified in custom_param()
> the message issued by apic_set_verbosity() can be removed.
> 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



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


  1   2   3   >