[Xen-devel] [xen-4.10-testing test] 128108: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-libvirt 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-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-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-amd64-xl-qemuu-win7-amd64 17 guest-stop 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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  0c1d5b68e27da167a51c2ea828636c14ff5c017b
baseline version:
 xen  4266e4c7d343af4ef36adf62fcf5f3236432387a

Last test of basis   127761  2018-09-18 08:16:44 Z9 days
Testing same since   128055  2018-09-25 14:06:26 Z2 days2 attempts


People who touched revisions under test:
  Jan Beulich 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 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  a8c7e309d1fec898a2731b6e0f63d66c509c7233
baseline version:
 xen  89faccfd35dde2cc1e2e2452ada0c978caaf4862

Last test of basis   128135  2018-09-27 11:00:42 Z0 days
Testing same since   128152  2018-09-28 00:00:44 Z0 days1 attempts


People who touched revisions under test:
  Andrii Anisov 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   89faccfd35..a8c7e309d1  a8c7e309d1fec898a2731b6e0f63d66c509c7233 -> smoke

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail in 128054 pass in 128105
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 128054 pass in 128105
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 128054
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail pass in 128054

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 128054 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 128054 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-pair  1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
128054 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 128054 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 128054 n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
128054 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 
128054 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 128054 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
128054 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 128054 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 128054 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 128054 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 127753
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 128054 
like 127753
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 128054 
like 127753
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 128054 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 128054 
never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127606
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 127606
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 127692
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 127692
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 127753
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 127753
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 127753
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 127753
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 127753
 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   

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

[osstest service owner]

flight 128101 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128101/

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. 128022
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
128022
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 128022
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 128022
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 128022
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 128022
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128022
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128022
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128022
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
128022
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
128022
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-qemuu-nested-amd  7 xen-bootfail REGR. vs. 128022
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-pvhv2-amd  7 xen-bootfail REGR. vs. 128022
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 128022
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 128022
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 128022
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 128022
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128022
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 128022
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 128022
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128022
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128022
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 128022
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 128022
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 128022
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 128022
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 128022
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 128022
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 128022
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 128022
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
128022
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 128022

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qcow2 7 xen-boot fail  like 128022
 test-amd64-amd64-xl-rtds  7 xen-boot

Re: [Xen-devel] [PATCH v2] arm/traps: coding style fixes

[Stefano Stabellini]

On Tue, 11 Sep 2018, Andrii Anisov wrote:
> From: Andrii Anisov 
> 
> Signed-off-by: Andrii Anisov 


Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 9ae64ae..7bfdda8 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -244,7 +244,8 @@ static register_t *select_user_reg(struct cpu_user_regs 
> *regs, int reg)
>   */
>  #define REGOFFS(R) offsetof(struct cpu_user_regs, R)
>  
> -switch ( reg ) {
> +switch ( reg )
> +{
>  case 0 ... 7: /* Unbanked registers */
>  BUILD_BUG_ON(REGOFFS(r0) + 7*sizeof(register_t) != REGOFFS(r7));
>  return >r0 + reg;
> @@ -422,7 +423,7 @@ static vaddr_t exception_handler32(vaddr_t offset)
>  {
>  uint32_t sctlr = READ_SYSREG32(SCTLR_EL1);
>  
> -if (sctlr & SCTLR_V)
> +if ( sctlr & SCTLR_V )
>  return 0x + offset;
>  else /* always have security exceptions */
>  return READ_SYSREG(VBAR_EL1) + offset;
> @@ -1340,7 +1341,7 @@ static void do_trap_brk(struct cpu_user_regs *regs, 
> const union hsr hsr)
>   */
>  BUG_ON(!hyp_mode(regs));
>  
> -switch (hsr.brk.comment)
> +switch ( hsr.brk.comment )
>  {
>  case BRK_BUG_FRAME_IMM:
>  if ( do_bug_frame(regs, regs->pc) )
> @@ -1429,7 +1430,9 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
> unsigned int code)
>  {
>  uint32_t reg;
>  uint32_t domid = current->domain->domain_id;
> -switch ( code ) {
> +
> +switch ( code )
> +{
>  case 0xe0 ... 0xef:
>  reg = code - 0xe0;
>  printk("DOM%d: R%d = 0x%"PRIregister" at 0x%"PRIvaddr"\n",
> @@ -1823,8 +1826,8 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
> offset, mfn_to_maddr(mfn), second[offset]);
>  
>  done:
> -if (second) unmap_domain_page(second);
> -if (first) unmap_domain_page(first);
> +if ( second ) unmap_domain_page(second);
> +if ( first ) unmap_domain_page(first);
>  }
>  
>  /*
> @@ -2071,7 +2074,8 @@ void do_trap_guest_sync(struct cpu_user_regs *regs)
>  
>  enter_hypervisor_head(regs);
>  
> -switch (hsr.ec) {
> +switch ( hsr.ec )
> +{
>  case HSR_EC_WFI_WFE:
>  /*
>   * HCR_EL2.TWI, HCR_EL2.TWE
> @@ -2270,7 +2274,8 @@ void leave_hypervisor_tail(void)
>  while (1)
>  {
>  local_irq_disable();
> -if (!softirq_pending(smp_processor_id())) {
> +if ( !softirq_pending(smp_processor_id()) )
> +{
>  vgic_sync_to_lrs();
>  
>  /*
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH 2/3] xen/arm: vgic-v3: Don't create empty re-distributor regions

[Stefano Stabellini]

On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/25/2018 09:38 PM, Stefano Stabellini wrote:
> > On Tue, 4 Sep 2018, Julien Grall wrote:
> > > At the moment, Xen is assuming the hardware domain will have the same
> > > number of re-distributor regions as the host. However, as the
> > > number of CPUs or the stride (e.g on GICv4) may be different we end up
> > > exposing regions which does not contain any re-distributors.
> > > 
> > > When booting, Linux will go through all the re-distributor region to
> > > check whether a property (e.g vPLIs) is available accross all the
> > > re-distributors. This will result to a data abort on empty regions
> > > because there are no underlying re-distributor.
> > > 
> > > So we need to limit the number of regions exposed to the hardware
> > > domain. The code reworked to only expose the minimun number of regions
> > > required by the hardware domain. It is assumed the regions will be
> > > populated starting from the first one.
> > 
> > I have a question: given that it is possible for a rdist_region to cover
> > more than 1 cpu, could we get into troubles if the last rdist_region of
> > the hardware_domain covers 2 cpus, but actually dom0 only has 1 vcpu?
> > get_vcpu_from_rdist would return NULL and vgic_v3_rdistr_mmio_read/write
> > would return 0.
> > This case seems to be handled correctly but I wanted to
> > double check.
> 
> 0 means a data abort will be injected into the guest. However, the guest
> should never touch that because the last valid re-distributor of the regions
> will have GICR_TYPER.Last set.
> 
> So the guest OS will stop looking for more re-distributors in that region.

OK


> >  >
> > I think we also need to fix vgic_v3_rdist_count? Today it just returns
> > vgic_v3_hw.nr_rdist_regions for dom0. It would be bad if we left it
> > unfixed? If we do that, we might be able to get rid of the modifications
> > to vgic_v3_real_domain_init.
> 
> We don't want to fix vgic_v3_rdist_count. The helper returns the maximum
> re-distributors regions.

We don't want to or we can't? Because it looks like we would want to fix
vgic_v3_rdist_count if we could, right? It is called from domain
specific initialization functions, so theoretically it should return
domain specific vgic information, not physical information.


> This is used to compute the number of IO handlers and
> allocating the array storing the regions.
> 
> I am pretty sure you will say we will waste memory. However, at the moment,
> we need to know the number of IO handlers much before we know the number of
> vCPUs. For the array, we would need to go through the regions twice (regions
> may not be the same size so we can't infer easily the number needed). Overall,
> the amount of memory used is the same as today (so not really a waste per-se).
> 
> It might be possible to limit that once we reworked the common code to know
> the number of vCPUs earlier on (see discussion on patch #1).

Yeah, this is nasty, but it is clear that until we rework the code to
set d->max_vcpus earlier it won't get fixed. Nothing we can do here.

So, I think ideally we would want to fix vgic_v3_rdist_count, but today
we can't. Maybe we could rename vgic_v3_rdist_count to
vgic_v3_hw_rdist_count, and add a short TODO comment somewhere in the
file?

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

Re: [Xen-devel] [PATCH 1/3] [not-for-unstable] xen/arm: vgic-v3: Delay the initialization of the domain information

[Stefano Stabellini]

On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/25/2018 09:45 PM, Stefano Stabellini wrote:
> > On Tue, 4 Sep 2018, Andrew Cooper wrote:
> > > On 04/09/18 20:35, Julien Grall wrote:
> > > > Hi,
> > > > 
> > > > On 09/04/2018 08:21 PM, Julien Grall wrote:
> > > > > A follow-up patch will require to know the number of vCPUs when
> > > > > initializating the vGICv3 domain structure. However this information
> > > > > is
> > > > > not available at domain creation. This is only known once
> > > > > XEN_DOMCTL_max_vpus is called for that domain.
> > > > > 
> > > > > In order to get the max vCPUs around, delay the domain part of the
> > > > > vGIC
> > > > > v3 initialization until the first vCPU of the domain is initialized.
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > > 
> > > > > ---
> > > > > 
> > > > > Cc: Andrew Cooper 
> > > > > 
> > > > > This is nasty but I can't find a better way for Xen 4.11 and older.
> > > > > This
> > > > > is not necessary for unstable as the number of vCPUs is known at
> > > > > domain
> > > > > creation.
> > > > > 
> > > > > Andrew, I have CCed you to know whether you have a better idea where
> > > > > to
> > > > > place this call on Xen 4.11 and older.
> > > > 
> > > > I just noticed that d->max_vcpus is initialized after
> > > > arch_domain_create. So without this patch on Xen 4.12, it will not work.
> > > > 
> > > > This is getting nastier because arch_domain_init is the one initialize
> > > > the value returned by dom0_max_vcpus. So I am not entirely sure what
> > > > to do here.
> > > 
> > > The positioning after arch_domain_create() is unfortunate, but I
> > > couldn’t manage better with ARM's current behaviour and Jan's insistence
> > > that the allocation of d->vcpu was common.  I'd prefer if the dependency
> > > could be broken and the allocation moved earlier.
> > > 
> > > One option might be to have an arch_check_domainconfig() (or similar?)
> > > which is called very early on and can sanity check the values, including
> > > cross-checking the vgic and max_vcpus settings?  It could even be
> > > responsible for mutating XEN_DOMCTL_CONFIG_GIC_NATIVE into the correct
> > > real value.
> > > 
> > > As for your patch here, its a gross hack, but its probably the best
> > > which can be done.
> > 
> > *Sighs*
> > If that is what we have to do, it is as ugly as hell, but that is what
> > we'll do.
> 
> This is the best we can do with the current code base. I think it would be
> worth reworking the code to make it nicer. I will add it in my TODO list.
> 
> > 
> > My only suggestion to marginally improve it would be instead of:
> > 
> > > +if ( v->vcpu_id == 0 )
> > > +{
> > > +rc = vgic_v3_real_domain_init(d);
> > > +if ( rc )
> > > +return rc;
> > > +}
> > 
> > to check on d->arch.vgic.rdist_regions instead:
> > 
> >if ( d->arch.vgic.rdist_regions == NULL )
> >{
> >   // initialize domain
> 
> I would prefer to keep v->vcpu_id == 0 just in case we end up to re-order the
> allocation in the future.

I was suggesting to check on (rdist_regions == NULL) exactly for
potential re-ordering, in case in the future we end up calling
vcpu_vgic_init differently and somehow vcpu_init(vcpu1) is done before
before vcpu_init(vcpu0). Ideally we would like a way to check that
vgic_v3_real_domain_init has been called before and I thought
rdist_regions == NULL could do just that...___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 3/6] xen/arm: add SMC wrapper that is compatible with SMCCC v1.0

[Stefano Stabellini]

On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/26/2018 12:50 AM, Stefano Stabellini wrote:
> > On Tue, 25 Sep 2018, Julien Grall wrote:
> > > From: Volodymyr Babchuk 
> > > 
> > > Existing SMC wrapper call_smc() allows only 4 parameters and
> > > returns only one value. This is enough for existing
> > > use in PSCI code, but TEE mediator will need a call that is
> > > fully compatible with ARM SMCCC v1.0.
> > > 
> > > This patch adds a wrapper for both arm32 and arm64. In the case of
> > > arm32, the wrapper is just an alias to the ARM SMCCC v1.1 as the
> > > convention is the same.
> > > 
> > > CC: "Edgar E. Iglesias" 
> > > Signed-off-by: Volodymyr Babchuk 
> > > [julien: Rework the wrapper to make it closer to SMCC 1.1 wrapper]
> > > Signed-off-by: Julien Grall 
> > 
> > I have been struggling to find the old doc for SMCCC v1.0, all the
> > references have been updated to v1.1 online now. Do you have a link?
> 
> Are you sure? All the references are still to v1.0 (DEN 0028B). See [1].

The lack of version in the doc confused me.


> > > diff --git a/xen/arch/arm/arm64/smc.S b/xen/arch/arm/arm64/smc.S
> > > new file mode 100644
> > > index 00..b0752be57e
> > > --- /dev/null
> > > +++ b/xen/arch/arm/arm64/smc.S
> > > @@ -0,0 +1,32 @@
> > > +/*
> > > + * xen/arch/arm/arm64/smc.S
> > > + *
> > > + * Wrapper for Secure Monitors Calls
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify
> > > + * it under the terms of the GNU General Public License as published by
> > > + * the Free Software Foundation; either version 2 of the License.
> > > + *
> > > + * This program is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > > + * GNU General Public License for more details.
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +/*
> > > + * void __arm_smccc_1_0_smc(register_t a0, register_t a1, register_t a2,
> > > + *  register_t a3, register_t a4, register_t a5,
> > > + *  register_t a6, register_t a7,
> > > + *  struct arm_smccc_res *res)
> > > + */
> > > +ENTRY(__arm_smccc_1_0_smc)
> > > +smc #0
> > > +ldr x4, [sp]
> > > +cbz x4, 1f  /* No need to store the result */
> > > +stp x0, x1, [x4, #SMCCC_RES_a0]
> > > +stp x2, x3, [x4, #SMCCC_RES_a2]
> > > +1:
> > > +ret
> > 
> > As I mentioned, I couldn't find the doc, but it looks like the Linux
> > implementation always copies back the results
> > (arch/arm64/kernel/smccc-call.S)? Shouldn't we zero x0-x3 at least?
> Could you provide more details on what looks wrong?
> 
> The results are copied in the array res using stp instructions. The only
> difference with Linux implementation is we don't handle quirk.

The only difference is that in this implementation we handle `res' being
NULL, which I think is a good idea:

Reviewed-by: Stefano Stabellini 

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

[Xen-devel] [ovmf baseline-only test] 75305: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75305 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75305/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm  broken
 build-i386   broken
 build-amd64-pvopsbroken
 build-i386-xsm   broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 build-amd64   4 host-install(4)   broken baseline untested
 build-amd64-xsm   4 host-install(4)   broken baseline untested
 build-i386-pvops  4 host-install(4)   broken baseline untested
 build-i3864 host-install(4)   broken baseline untested
 build-amd64-pvops 4 host-install(4)   broken baseline untested
 build-i386-xsm4 host-install(4)   broken baseline untested

version targeted for testing:
 ovmf 6a147d6dae733f3a1d5ddf9af9adce5fb8504a53
baseline version:
 ovmf 447b08b3d2a3e04a9fccda68c72a2ff62d8197e9

Last test of basis75299  2018-09-27 00:50:12 Z0 days
Testing same since75305  2018-09-27 18:20:23 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  bob.c.f...@intel.com 
  BobCF 
  Eric Dong 
  Laszlo Ersek 
  Liming Gao 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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.xensource.com/osstest/logs

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

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-amd64 host-install(4)
broken-step build-amd64-xsm host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-i386 host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-i386-xsm host-install(4)

Push not applicable.

(No revision log; it would be 470 lines long.)

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

Re: [Xen-devel] [PATCH v2 6/6] xen/arm: Replace call_smc with arm_smccc_smc

[Stefano Stabellini]

On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/26/2018 12:57 AM, Stefano Stabellini wrote:
> > On Tue, 25 Sep 2018, Julien Grall wrote:
> > > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> > > index 941eec921b..02737e6caa 100644
> > > --- a/xen/arch/arm/psci.c
> > > +++ b/xen/arch/arm/psci.c
> > > @@ -42,42 +42,53 @@ uint32_t smccc_ver;
> > > static uint32_t psci_cpu_on_nr;
> > >   +#define PSCI_RET(res)   ((int32_t)(res).a0)
> > > +
> > >   int call_psci_cpu_on(int cpu)
> > >   {
> > > -return call_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
> > > __pa(init_secondary), 0);
> > > +struct arm_smccc_res res;
> > > +
> > > +arm_smccc_smc(psci_cpu_on_nr, cpu_logical_map(cpu),
> > > __pa(init_secondary),
> > > +  );
> > > +
> > > +return (int32_t)res.a0;
> > >   }
> > 
> > Can't we use PSCI_RET(res) here?
> 
> I missed that one. I will update it.
> 
> > 
> > Also in general, should we care about the type mismatch int32_t vs. int
> > which is the return type of this function?
> 
> The only issue I could see is if sizeof(int) < sizeof(int32_t). If that
> happen, then psci.c would be our least concern as we always assume int would
> at least 32-bit wide.
> 
> I would prefer to keep the return of the function int and casting the result
> with (int32_t). The latter is helpful to know what is the size of the result
> (a0 is 64-bit).

It is a good idea to keep the cast. I don't have a strong opinion on
whether the functions should return int or int32_t. The only question is
whether we want to cast to (int32_t) or to (int). I would prefer to cast
to the same type of the return of the function. So if we keep int as
return type, then casting to (int). However, given that in practice it
makes no difference, I can ack the patch in any case.

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

Re: [Xen-devel] [PATCH v2 4/6] xen/arm: cpufeature: Add helper to check constant caps

[Stefano Stabellini]

On Wed, 26 Sep 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 09/26/2018 05:53 PM, Stefano Stabellini wrote:
> > On Tue, 25 Sep 2018, Julien Grall wrote:
> > > Some capababilities are set right during boot and will never change
> > > afterwards. At the moment, the function cpu_have_caps will check whether
> > > the cap is enabled from the memory.
> > > 
> > > It is possible to avoid the load from the memory by using an
> > > ALTERNATIVE. With that the check is just reduced to 1 instruction.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > I enjoyed reading the patch :-)  But I don't think it is worth going
> > into this extreme level of optimization. test_bit is efficient enough,
> > right? What do you think we need to use alternatives just to check one
> > bit?
> 
> We already have an helper using test_bit (see cpus_have_cap). However test_bit
> requires to load the word from the memory. This is an overhead when the
> decision never change after boot.
> 
> One load may be insignificant by itself (thought may have a cache miss), but
> if you are in hotpath this is a win in long term.
> 
> The mechanism is very similar to static key but for the poor (I don't have
> much time to implement better for now). We already use similar construction on
> other places (see CHECK_WORKAROUND_HELPER).

I like the mechanism and the little ALTERNATIVE trick.  I can see it
could very useful in some cases. It is just that it is a bit of a waste
to use it on SMCCC virtualization -- SMCCC calls cannot be done often
enough for this to make a difference.

But who am I to complain when you make things faster? :-)

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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Sander Eikelenboom]

On 27/09/18 23:48, Boris Ostrovsky wrote:
> On 9/27/18 5:37 PM, Jens Axboe wrote:
>> On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
>>> On 27/09/18 21:06, Boris Ostrovsky wrote:
 On 9/27/18 2:56 PM, Jens Axboe wrote:
> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>> On 27/09/18 16:26, Jens Axboe wrote:
>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
 On 22/09/18 21:55, Boris Ostrovsky wrote:
> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> added support for purging persistent grants when they are not in use. 
> As
> part of the purge, the grants were removed from the grant buffer, This
> eventually causes the buffer to become empty, with BUG_ON triggered in
> get_free_grant(). This can be observed even on an idle system, within
> 20-30 minutes.
>
> We should keep the grants in the buffer when purging, and only free 
> the
> grant ref.
>
> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> Signed-off-by: Boris Ostrovsky 
 Reviewed-by: Juergen Gross 
>>> Since Konrad is out, I'm going to queue this up for 4.19.
>>>
>> Hi Boris/Juergen.
>>
>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch 
>> from Boris pulled on top. 
>> Unfortunately it made a VM hang (probably because it's rootFS is 
>> shuffled from under it's feet 
 What do you mean by "rootFS is shuffled from under it's feet " ?
>>> Assumption that block-front getting borked and either a kernel crash or 
>>> rootfs becoming mounted readonly. Didn't (try) to check though.
>>>
>> and it gave these in dom0 dmesg:
>>
>> [ 9251.696090] xen-blkback: requesting a grant already in use
>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the 
>> tree
>> [ 9251.715781] xen-blkback: requesting a grant already in use
>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the 
>> tree
>> [ 9251.735698] xen-blkback: requesting a grant already in use
>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the 
>> tree
>>
>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
>> persistent grants
>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
>> persistent grants
>>
>>
>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>> tried to fix.
>>
>> If you can come up with a debug patch i can give that a spin tomorrow
>> evening or in the weekend, so we are hopefully still in time for the
>> 4.19 release.
> At this late in the game, might make more sense to simply revert the
> buggy commit.  Especially since what is currently out there doesn't fix
> the issue for you.
>>> Don't know if Boris or Juergen have a hunch about the issue, if not
>>> perhaps a revert is the best.
>> Anyone? Unless I hear otherwise, I'll revert the series tomorrow.
> 
> Juergen may have something to say by tomorrow, but from my perspective,
> given that we are coming up on rc6 --- yes.
> 
> I looked at the patches again and didn't see anything obvious.
> 
> -boris

Could also be that what i hit is a latent bug, 
that is not caused by these patches but merely got uncovered by them.

xl dmesg also shows quite some:
(XEN) [2018-09-24 03:15:46.847] grant_table.c:1755:d14v0 Expanding d14 
grant table from 19 to 20 frames
(XEN) [2018-09-24 03:15:46.849] grant_table.c:1755:d14v0 Expanding d14 
grant table from 20 to 21 frames
(and has done that for ages on my box not leading to any direct problems to my 
knowledge)

I don't know if there could be related and something around the (persistent) 
grants for block devices could be leaking under some conditions?

--
Sander


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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Boris Ostrovsky]

On 9/27/18 5:37 PM, Jens Axboe wrote:
> On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
>> On 27/09/18 21:06, Boris Ostrovsky wrote:
>>> On 9/27/18 2:56 PM, Jens Axboe wrote:
 On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
> On 27/09/18 16:26, Jens Axboe wrote:
>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
 Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
 added support for purging persistent grants when they are not in use. 
 As
 part of the purge, the grants were removed from the grant buffer, This
 eventually causes the buffer to become empty, with BUG_ON triggered in
 get_free_grant(). This can be observed even on an idle system, within
 20-30 minutes.

 We should keep the grants in the buffer when purging, and only free the
 grant ref.

 Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
 Signed-off-by: Boris Ostrovsky 
>>> Reviewed-by: Juergen Gross 
>> Since Konrad is out, I'm going to queue this up for 4.19.
>>
> Hi Boris/Juergen.
>
> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch 
> from Boris pulled on top. 
> Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
> from under it's feet 
>>> What do you mean by "rootFS is shuffled from under it's feet " ?
>> Assumption that block-front getting borked and either a kernel crash or 
>> rootfs becoming mounted readonly. Didn't (try) to check though.
>>
> and it gave these in dom0 dmesg:
>
> [ 9251.696090] xen-blkback: requesting a grant already in use
> [ 9251.705861] xen-blkback: trying to add a gref that's already in the 
> tree
> [ 9251.715781] xen-blkback: requesting a grant already in use
> [ 9251.725756] xen-blkback: trying to add a gref that's already in the 
> tree
> [ 9251.735698] xen-blkback: requesting a grant already in use
> [ 9251.745573] xen-blkback: trying to add a gref that's already in the 
> tree
>
> The VM was a HVM with 4 vcpu's and 2 phy disks:
> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
> persistent grants
> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
> persistent grants
>
>
> Currently i have been running 4.19-rc5 with xen-next on top and commit
> a46b53672b2c reverted, for a couple of days. That seems to run stable
> for me (since it's a small box so i'm not hit by what a46b53672b2c
> tried to fix.
>
> If you can come up with a debug patch i can give that a spin tomorrow
> evening or in the weekend, so we are hopefully still in time for the
> 4.19 release.
 At this late in the game, might make more sense to simply revert the
 buggy commit.  Especially since what is currently out there doesn't fix
 the issue for you.
>> Don't know if Boris or Juergen have a hunch about the issue, if not
>> perhaps a revert is the best.
> Anyone? Unless I hear otherwise, I'll revert the series tomorrow.

Juergen may have something to say by tomorrow, but from my perspective,
given that we are coming up on rc6 --- yes.

I looked at the patches again and didn't see anything obvious.

-boris



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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Jens Axboe]

On 9/27/18 2:33 PM, Sander Eikelenboom wrote:
> On 27/09/18 21:06, Boris Ostrovsky wrote:
>> On 9/27/18 2:56 PM, Jens Axboe wrote:
>>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
 On 27/09/18 16:26, Jens Axboe wrote:
> On 9/27/18 1:12 AM, Juergen Gross wrote:
>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>> added support for purging persistent grants when they are not in use. As
>>> part of the purge, the grants were removed from the grant buffer, This
>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>> get_free_grant(). This can be observed even on an idle system, within
>>> 20-30 minutes.
>>>
>>> We should keep the grants in the buffer when purging, and only free the
>>> grant ref.
>>>
>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>> Signed-off-by: Boris Ostrovsky 
>> Reviewed-by: Juergen Gross 
> Since Konrad is out, I'm going to queue this up for 4.19.
>
 Hi Boris/Juergen.

 Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch 
 from Boris pulled on top. 
 Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
 from under it's feet 
>>
>> What do you mean by "rootFS is shuffled from under it's feet " ?
> 
> Assumption that block-front getting borked and either a kernel crash or 
> rootfs becoming mounted readonly. Didn't (try) to check though.
> 
 and it gave these in dom0 dmesg:

 [ 9251.696090] xen-blkback: requesting a grant already in use
 [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
 [ 9251.715781] xen-blkback: requesting a grant already in use
 [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
 [ 9251.735698] xen-blkback: requesting a grant already in use
 [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree

 The VM was a HVM with 4 vcpu's and 2 phy disks:
 xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
 persistent grants
 xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
 persistent grants


 Currently i have been running 4.19-rc5 with xen-next on top and commit
 a46b53672b2c reverted, for a couple of days. That seems to run stable
 for me (since it's a small box so i'm not hit by what a46b53672b2c
 tried to fix.

 If you can come up with a debug patch i can give that a spin tomorrow
 evening or in the weekend, so we are hopefully still in time for the
 4.19 release.
>>> At this late in the game, might make more sense to simply revert the
>>> buggy commit.  Especially since what is currently out there doesn't fix
>>> the issue for you.
>
> Don't know if Boris or Juergen have a hunch about the issue, if not
> perhaps a revert is the best.

Anyone? Unless I hear otherwise, I'll revert the series tomorrow.

-- 
Jens Axboe


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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Sander Eikelenboom]

On 27/09/18 21:06, Boris Ostrovsky wrote:
> On 9/27/18 2:56 PM, Jens Axboe wrote:
>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>> On 27/09/18 16:26, Jens Axboe wrote:
 On 9/27/18 1:12 AM, Juergen Gross wrote:
> On 22/09/18 21:55, Boris Ostrovsky wrote:
>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> added support for purging persistent grants when they are not in use. As
>> part of the purge, the grants were removed from the grant buffer, This
>> eventually causes the buffer to become empty, with BUG_ON triggered in
>> get_free_grant(). This can be observed even on an idle system, within
>> 20-30 minutes.
>>
>> We should keep the grants in the buffer when purging, and only free the
>> grant ref.
>>
>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Juergen Gross 
 Since Konrad is out, I'm going to queue this up for 4.19.

>>> Hi Boris/Juergen.
>>>
>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch 
>>> from Boris pulled on top. 
>>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
>>> from under it's feet 
> 
> What do you mean by "rootFS is shuffled from under it's feet " ?

Assumption that block-front getting borked and either a kernel crash or rootfs 
becoming mounted readonly. Didn't (try) to check though.

>>> and it gave these in dom0 dmesg:
>>>
>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>>
>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
>>> persistent grants
>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
>>> persistent grants
>>>
>>>
>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>> tried to fix.
>>>
>>> If you can come up with a debug patch i can give that a spin tomorrow
>>> evening or in the weekend, so we are hopefully still in time for the
>>> 4.19 release.
>> At this late in the game, might make more sense to simply revert the
>> buggy commit.  Especially since what is currently out there doesn't fix
>> the issue for you.
Don't know if Boris or Juergen have a hunch about the issue, if not perhaps a 
revert is the best. 

> If decision is to revert then I think the whole series needs to be
> reverted.
> 
> -boris
> 

For Boris and Juergen:
Would it make sense to have an "xen-next" branch in the xen-tip tree that is:
- based on the previous stable kernel
- and has the for-linus branches for the upcoming kernel release on top;
- and has the pathes for net(-next) and block changes on top (since these don't 
go via the tree but only via mailing-list patches);
  (which are scattered, difficult to track and use for automated testing)
- and dependency patches for the above if necessary to be able to build.

So there is one branch that can be used to test ALL pending kernel related Xen 
patches and which could be used in OSStest without as
many potential false alarms as linux-next will have ?

--
Sander

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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Jens Axboe]

On 9/27/18 1:06 PM, Boris Ostrovsky wrote:
> On 9/27/18 2:56 PM, Jens Axboe wrote:
>> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>>> On 27/09/18 16:26, Jens Axboe wrote:
 On 9/27/18 1:12 AM, Juergen Gross wrote:
> On 22/09/18 21:55, Boris Ostrovsky wrote:
>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> added support for purging persistent grants when they are not in use. As
>> part of the purge, the grants were removed from the grant buffer, This
>> eventually causes the buffer to become empty, with BUG_ON triggered in
>> get_free_grant(). This can be observed even on an idle system, within
>> 20-30 minutes.
>>
>> We should keep the grants in the buffer when purging, and only free the
>> grant ref.
>>
>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> Signed-off-by: Boris Ostrovsky 
> Reviewed-by: Juergen Gross 
 Since Konrad is out, I'm going to queue this up for 4.19.

>>> Hi Boris/Juergen.
>>>
>>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch 
>>> from Boris pulled on top. 
>>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
>>> from under it's feet 
> 
> What do you mean by "rootFS is shuffled from under it's feet " ?
> 
>>> and it gave these in dom0 dmesg:
>>>
>>> [ 9251.696090] xen-blkback: requesting a grant already in use
>>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.715781] xen-blkback: requesting a grant already in use
>>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>>> [ 9251.735698] xen-blkback: requesting a grant already in use
>>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>>
>>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
>>> persistent grants
>>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
>>> persistent grants
>>>
>>>
>>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>>> tried to fix.
>>>
>>> If you can come up with a debug patch i can give that a spin tomorrow
>>> evening or in the weekend, so we are hopefully still in time for the
>>> 4.19 release.
>> At this late in the game, might make more sense to simply revert the
>> buggy commit.  Especially since what is currently out there doesn't fix
>> the issue for you.
> 
> If decision is to revert then I think the whole series needs to be
> reverted.

Yes, definitely.

-- 
Jens Axboe


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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Boris Ostrovsky]

On 9/27/18 2:56 PM, Jens Axboe wrote:
> On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
>> On 27/09/18 16:26, Jens Axboe wrote:
>>> On 9/27/18 1:12 AM, Juergen Gross wrote:
 On 22/09/18 21:55, Boris Ostrovsky wrote:
> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> added support for purging persistent grants when they are not in use. As
> part of the purge, the grants were removed from the grant buffer, This
> eventually causes the buffer to become empty, with BUG_ON triggered in
> get_free_grant(). This can be observed even on an idle system, within
> 20-30 minutes.
>
> We should keep the grants in the buffer when purging, and only free the
> grant ref.
>
> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> Signed-off-by: Boris Ostrovsky 
 Reviewed-by: Juergen Gross 
>>> Since Konrad is out, I'm going to queue this up for 4.19.
>>>
>> Hi Boris/Juergen.
>>
>> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch from 
>> Boris pulled on top. 
>> Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
>> from under it's feet 

What do you mean by "rootFS is shuffled from under it's feet " ?

>> and it gave these in dom0 dmesg:
>>
>> [ 9251.696090] xen-blkback: requesting a grant already in use
>> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
>> [ 9251.715781] xen-blkback: requesting a grant already in use
>> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
>> [ 9251.735698] xen-blkback: requesting a grant already in use
>> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
>>
>> The VM was a HVM with 4 vcpu's and 2 phy disks:
>> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
>> persistent grants
>> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
>> persistent grants
>>
>>
>> Currently i have been running 4.19-rc5 with xen-next on top and commit
>> a46b53672b2c reverted, for a couple of days. That seems to run stable
>> for me (since it's a small box so i'm not hit by what a46b53672b2c
>> tried to fix.
>>
>> If you can come up with a debug patch i can give that a spin tomorrow
>> evening or in the weekend, so we are hopefully still in time for the
>> 4.19 release.
> At this late in the game, might make more sense to simply revert the
> buggy commit.  Especially since what is currently out there doesn't fix
> the issue for you.

If decision is to revert then I think the whole series needs to be
reverted.

-boris


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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Jens Axboe]

On 9/27/18 12:52 PM, Sander Eikelenboom wrote:
> On 27/09/18 16:26, Jens Axboe wrote:
>> On 9/27/18 1:12 AM, Juergen Gross wrote:
>>> On 22/09/18 21:55, Boris Ostrovsky wrote:
 Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
 added support for purging persistent grants when they are not in use. As
 part of the purge, the grants were removed from the grant buffer, This
 eventually causes the buffer to become empty, with BUG_ON triggered in
 get_free_grant(). This can be observed even on an idle system, within
 20-30 minutes.

 We should keep the grants in the buffer when purging, and only free the
 grant ref.

 Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
 Signed-off-by: Boris Ostrovsky 
>>>
>>> Reviewed-by: Juergen Gross 
>>
>> Since Konrad is out, I'm going to queue this up for 4.19.
>>
> 
> Hi Boris/Juergen.
> 
> Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch from 
> Boris pulled on top. 
> Unfortunately it made a VM hang (probably because it's rootFS is shuffled 
> from under it's feet 
> and it gave these in dom0 dmesg:
> 
> [ 9251.696090] xen-blkback: requesting a grant already in use
> [ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
> [ 9251.715781] xen-blkback: requesting a grant already in use
> [ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
> [ 9251.735698] xen-blkback: requesting a grant already in use
> [ 9251.745573] xen-blkback: trying to add a gref that's already in the tree
> 
> The VM was a HVM with 4 vcpu's and 2 phy disks:
> xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
> persistent grants
> xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
> persistent grants
> 
> 
> Currently i have been running 4.19-rc5 with xen-next on top and commit
> a46b53672b2c reverted, for a couple of days. That seems to run stable
> for me (since it's a small box so i'm not hit by what a46b53672b2c
> tried to fix.
> 
> If you can come up with a debug patch i can give that a spin tomorrow
> evening or in the weekend, so we are hopefully still in time for the
> 4.19 release.

At this late in the game, might make more sense to simply revert the
buggy commit.  Especially since what is currently out there doesn't fix
the issue for you.

-- 
Jens Axboe


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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Sander Eikelenboom]

On 27/09/18 16:26, Jens Axboe wrote:
> On 9/27/18 1:12 AM, Juergen Gross wrote:
>> On 22/09/18 21:55, Boris Ostrovsky wrote:
>>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>> added support for purging persistent grants when they are not in use. As
>>> part of the purge, the grants were removed from the grant buffer, This
>>> eventually causes the buffer to become empty, with BUG_ON triggered in
>>> get_free_grant(). This can be observed even on an idle system, within
>>> 20-30 minutes.
>>>
>>> We should keep the grants in the buffer when purging, and only free the
>>> grant ref.
>>>
>>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>>> Signed-off-by: Boris Ostrovsky 
>>
>> Reviewed-by: Juergen Gross 
> 
> Since Konrad is out, I'm going to queue this up for 4.19.
> 

Hi Boris/Juergen.

Last week i tested a linux-4.19-rc4 kernel with xen-next and this patch from 
Boris pulled on top. 
Unfortunately it made a VM hang (probably because it's rootFS is shuffled from 
under it's feet 
and it gave these in dom0 dmesg:

[ 9251.696090] xen-blkback: requesting a grant already in use
[ 9251.705861] xen-blkback: trying to add a gref that's already in the tree
[ 9251.715781] xen-blkback: requesting a grant already in use
[ 9251.725756] xen-blkback: trying to add a gref that's already in the tree
[ 9251.735698] xen-blkback: requesting a grant already in use
[ 9251.745573] xen-blkback: trying to add a gref that's already in the tree

The VM was a HVM with 4 vcpu's and 2 phy disks:
xen-blkback: backend/vbd/14/768: using 4 queues, protocol 1 (x86_64-abi) 
persistent grants
xen-blkback: backend/vbd/14/832: using 4 queues, protocol 1 (x86_64-abi) 
persistent grants


Currently i have been running 4.19-rc5 with xen-next on top and commit 
a46b53672b2c reverted,
for a couple of days. That seems to run stable for me (since it's a small box 
so i'm not hit
by what a46b53672b2c tried to fix.

If you can come up with a debug patch i can give that a spin tomorrow evening 
or in the weekend,
so we are hopefully still in time for the 4.19 release.

--
Sander

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

Re: [Xen-devel] Backports to stable trees

[Andrew Cooper]

On 27/09/18 15:36, Andrew Cooper wrote:
> Hello,
>
> Please can the following patches be considered for stable.
>
> 18cd4997d26b - x86/efi: move the logic to detect PE build support
> 93249f7fc17c - x86/efi: split compiler vs linker support
>
> CentOS and RHEL 7.x GCC's are capable of compiling xen.gz with EFI
> support, but LD doesn't have i386pep support.  Without a bodge to the
> build system (and several downstreams have borrowed by XenServer bodge),
> making a EFI-capable xen.gz isn't possible with the default toolchain.
>
> These patches resolve the issue.

In addition, it looks like:

328ca55b7bd4 - x86/shutdown: use ACPI reboot method for Dell PowerEdge R540
7626edeaca97 - x86/hvm/emulate: make sure rep I/O emulation does not
cross GFN boundaries

are general bugfix candidates for backport.

~Andrew

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6a147d6dae733f3a1d5ddf9af9adce5fb8504a53
baseline version:
 ovmf 447b08b3d2a3e04a9fccda68c72a2ff62d8197e9

Last test of basis   128098  2018-09-26 07:11:44 Z1 days
Testing same since   128119  2018-09-27 00:40:44 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  bob.c.f...@intel.com 
  BobCF 
  Eric Dong 
  Laszlo Ersek 
  Liming Gao 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   447b08b3d2..6a147d6dae  6a147d6dae733f3a1d5ddf9af9adce5fb8504a53 -> 
xen-tested-master

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

Re: [Xen-devel] null scheduler bug

[Dario Faggioli]

On Thu, 2018-09-27 at 16:09 +0100, Julien Grall wrote:
> Hi Dario,
> 
Hi,

> On 09/27/2018 03:32 PM, Dario Faggioli wrote:
> > On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
> > > 
> In one of your e-mail, you wrote:
> 
> "Well, our implementation of RCU requires that, from time to time,
> the
> various physical CPUs of your box become idle, or get an interrupt,
> or
> go executing inside Xen (for hypercalls, vmexits, etc). In fact, a
> CPU
> going through Xen is what allow us to tell that it reached a so-
> called
> 'quiescent state', which in turns is necessary for declaring a so-
> called 'RCU grace period' over."
> 
> I don't quite agree with you on the definition of "quiescent state" 
> here. 
>
Hehe... I was trying to be both quick and accurate. It's more than
possible that I failed. :-)

> To take the domain example, we want to wait until all the CPU has 
> stopped using the pointer (an hypercall could race put_domain). 
>
I'm not sure what you mean with "an hypercall could race put_domain".
What we want is to wait until all the CPUs that are involved in the
grace period, have gone through rcupdate.c:cpu_quiet(), or have become
idle.

Receiving an interrupt, or experiencing a context switch, or even going
idle, it's "just" how it happens that these CPUs have their chance to
go through cpu_quiet(). It is in this sense that I meant that those
events are used as markers of a quiescent state.

And "wfi=native" (in particular in combination with the null scheduler,
but I guess also with other ones, at least to a certain extent) makes
figuring out the "or have become idle" part tricky. That is the problem
here, isn't it?

> That 
> pointer will not be in-use if the CPU is in kernel-mode/user-mode or
> in 
> the idle loop. Am I correct?
> 
Right.

So, we want that all the CPUs that were in Xen to have either left Xen
at least once or, if they're still there and have never left, that must
be because they've become idle.

And currently we treat all the CPUs that have not told the RCU
subsystem that they're idle (via rcu_idle_enter()) as busy, without
distinguishing between the ones that are busy in Xen from the one which
are busy in guest (kernel or user) mode.

> So I am wondering whether we could:
>   - Mark any CPU in kernel-mode/user-mode quiet
>
Right. We'd need something like a rcu_guest_enter()/rcu_guest_exit()
(or a rcu_xen_exit()/rcu_xen_enter()), which works for all combination
of arches and guest types.

It looks to me too that this would help in this case, as the vCPU that
stays in guest mode because of wfi=idle would be counted as quiet, and
we won't have to wait for it.

>   - Raise a RCU_SOFTIRQ in call_rcu?
> 
Mmm... what would be the point of this?

> With that solution, it may even be possible to avoid the timer in
> the 
> idle loop.
> 
Not sure. The timer is there to deal with the case when a CPU which has
a callback queued wants to go idle. It may have quiesced already, but
if there are others which have not, either:
1) we let it go idle, but then the callback will run only when it 
   wakes up from idle which, without the timer, could be far ahead in 
   time;
2) we don't let it go idle, but we waste resources;
3) we let it go idle and keep the timer. :-)

But anyway, even if it would not let us get rid of the timer, it seems
like it could be nicer than any other approaches. I accept
help/suggestions about the "let's intercept guest-Xen and Xen-guest
transitions, and track that inside RCU code.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


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

[Xen-devel] [linux-4.14 test] 128097: regressions - FAIL

[osstest service owner]

flight 128097 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128097/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
127877

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   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-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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-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:
 linux2cc4d365363b1fb681b8231adcf4a8f80082506c
baseline version:
 linux1244bbb3e92135d247e2dddfa6fe5e3e171a9635

Last test of basis   127877  2018-09-21 09:23:06 Z6 days
Testing same since   128097  2018-09-26 07:11:31 Z1 days1 attempts


People who touched revisions under test:
  Aaron Brown 
  Aaron Knister 
  Alan Stern 
  Alexander Duyck 
  Alexander Usyskin 
  Alexandre Belloni 
  Andrea Parri 
  Andreas Gruenbacher 
  Andreas Kemnade 
  Andrew Jones 
  Andy Gross 
  Andy Shevchenko 
  Anna Schumaker 
  Anton Vasilyev 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Bartlomiej Zolnierkiewicz 
  Ben Hutchings 
  Ben Skeggs 
  Benjamin Poirier 
  Bhushan Shah 
  Bin Yang 
  Bob Peterson 
  Boris Brezillon 
  Boris Ostrovsky 
  Brian Masney 
  Casey Schaufler 
  Chris Wilson 
  Christian König 
  

Re: [Xen-devel] [PATCH] x86: assert MBI is large enough in pvh-boot.c

[Wei Liu]

On Wed, Sep 26, 2018 at 12:05:05PM +0100, Andrew Cooper wrote:
> On 26/09/18 12:00, Wei Liu wrote:
> > The relocation code in __start_xen requires one extra element in the
> > MBI structure. By the looks of it the temporary MBI array is already
> > large enough. Add an assertion to catch any issue in the future.
> >
> > Signed-off-by: Wei Liu 
> 
> While this is all well and good, the ASSERT() never actually gets out
> onto the console.  This is because, when a failure occurs, the console
> hasn't been configured yet.
> 
> For development purposes I use:
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index e48039d..64febfa 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -91,7 +91,7 @@ static uint32_t conringc, conringp;
>  static int __read_mostly sercon_handle = -1;
>  
>  #ifdef CONFIG_X86
> -static bool __read_mostly opt_console_xen; /* console=xen */
> +static bool __read_mostly opt_console_xen = true; /* console=xen */
>  #endif
>  
>  static DEFINE_SPINLOCK(console_lock);
> 
> which gets the details out into the L0 log.
> 
> As an addendum, might it be worth having opt_console_xen be tristate,
> and enabled by the start of the PVH path, so log messages before the
> command line is parsed end up being emitted?

This is fine by me.

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH] x86: assert MBI is large enough in pvh-boot.c

[Wei Liu]

On Wed, Sep 26, 2018 at 06:07:30AM -0600, Jan Beulich wrote:
> >>> On 26.09.18 at 13:00,  wrote:
> > --- a/xen/arch/x86/guest/pvh-boot.c
> > +++ b/xen/arch/x86/guest/pvh-boot.c
> > @@ -44,6 +44,13 @@ static void __init convert_pvh_info(void)
> >  
> >  ASSERT(pvh_info->magic == XEN_HVM_START_MAGIC_VALUE);
> >  
> > +/*
> > + * Temporary MBI array needs to be at least one element bigger than
> > + * required. The extra element is used to aid relocation. See
> > + * arch/x86/setup.c:__start_xen().
> > + */
> > +ASSERT(ARRAY_SIZE(pvh_mbi_mods) > pvh_info->nr_modules);
> 
> Are ASSERT()s (also the other one in context) actually the right thing
> here? I think we'd better panic(): That'll also cover release builds and
> is imo more appropriate for data coming from the outside.

Okay.

Wei.

> 
> Jan
> 
> 

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

Re: [Xen-devel] [PATCH v12 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

[Jan Beulich]

>>> On 27.09.18 at 16:33,  wrote:
> v12:
>  - Fix two mis-uses of iommu_hap_pt_share().

I had hoped that with my reply to v11 you would have gone through
all uses, not just the ones your series adds or modifies. At the very
least the one in iommu_construct() is bogus too, as PV domains also
make it there.

Perhaps in the end we're better off adding is_hvm_domain() right to
hap_enabled(). Patch just sent.

> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -1426,8 +1426,13 @@ int memory_add(unsigned long spfn, unsigned long epfn, 
> unsigned int pxm)
>  if ( ret )
>  goto destroy_m2p;
>  
> -if ( iommu_enabled && !iommu_hwdom_passthrough &&
> - !need_iommu(hardware_domain) )
> +/*
> + * If hardware domain has IOMMU mappings but page tables are not
> + * shared, and are not being kept in sync (which is the case when
> + * in strict mode) then newly added memory needs to be mapped here.
> + */
> +if ( has_iommu_pt(hardware_domain) &&
> + !iommu_hap_pt_share && !iommu_hwdom_strict )

Why not !iommu_use_hap_pt()? Irrespective of HAP and sharing being
available, the hardware domain may not use HAP and/or sharing. Also
the use of a the global variable here renders the PV case wrong in at
least one of the possible combinations.

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -1416,10 +1416,9 @@ static int assign_device(struct domain *d, u16 seg, u8 
> bus, u8 devfn, u32 flag)
>  
>  /* Prevent device assign if mem paging or mem sharing have been 
>   * enabled for this domain */
> -if ( unlikely(!need_iommu(d) &&
> -(d->arch.hvm.mem_sharing_enabled ||
> - vm_event_check_ring(d->vm_event_paging) ||
> - p2m_get_hostp2m(d)->global_logdirty)) )
> +if ( unlikely(d->arch.hvm.mem_sharing_enabled ||
> +  vm_event_check_ring(d->vm_event_paging) ||
> +  p2m_get_hostp2m(d)->global_logdirty) )
>  return -EXDEV;

While as per v11 I'm in full agreement with this removal, I think it needs
calling out in the description.

Jan



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

Re: [Xen-devel] [PATCH] x86: hap_enabled() is HVM-only

[Andrew Cooper]

On 27/09/18 16:30, Jan Beulich wrote:
> There at least two cases where the field so far got accessed for PV
> guests as well: One is in iommu_construct(), via iommu_use_hap_pt(),
> and the other is
> arch_domain_create()
> -> paging_domain_init()
>-> p2m_init()
>   -> p2m_init_hostp2m()
>  -> p2m_init_one()
> -> p2m_initialise()
> It just so happens that the field currently lives in struct hvm_domain
> at an offset larger than sizeof(struct pv_domain).
>
> Signed-off-by: Jan Beulich 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86: hap_enabled() is HVM-only

[Jan Beulich]

There at least two cases where the field so far got accessed for PV
guests as well: One is in iommu_construct(), via iommu_use_hap_pt(),
and the other is
arch_domain_create()
-> paging_domain_init()
   -> p2m_init()
  -> p2m_init_hostp2m()
 -> p2m_init_one()
-> p2m_initialise()
It just so happens that the field currently lives in struct hvm_domain
at an offset larger than sizeof(struct pv_domain).

Signed-off-by: Jan Beulich 

--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -195,7 +195,7 @@ struct hvm_domain {
 };
 
 #ifdef CONFIG_HVM
-#define hap_enabled(d)  ((d)->arch.hvm.hap_enabled)
+#define hap_enabled(d)  (is_hvm_domain(d) && (d)->arch.hvm.hap_enabled)
 #else
 #define hap_enabled(d)  ({(void)(d); false;})
 #endif



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

Re: [Xen-devel] null scheduler bug

[Julien Grall]

Hi Dario,

On 09/27/2018 03:32 PM, Dario Faggioli wrote:

On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:

Hi,
I applied patch and vwfi=native and everything works fine, I can
create and destroy guest domain as many times as I want.


Ok, now that we know it works, what do you guys prefer?

Stefano? Julien? I know it's not strictly an ARM-only issue, but I'm
asking you because ARM is where it shows-up/harm the most.

I personally would be ok with:
- doing a patch adding qhimark, qlowmark and blimit boot command line
   parameters;
- doing a patch (similar to this one) forcing the parameters to a
   specific state (and printing a warning about that), if wfi=native is
   used.

Thoughts?


I know I first suggested this but I have been thinking about it and 
trying to find a different approach. With NULL scheduler, you end up 
partitioning your platform. I think may have have Xen to be there just 
for handling hypercall, emulation and guest interrupt. So I would like 
to avoid adding an interrupt when possible.


In one of your e-mail, you wrote:

"Well, our implementation of RCU requires that, from time to time, the
various physical CPUs of your box become idle, or get an interrupt, or
go executing inside Xen (for hypercalls, vmexits, etc). In fact, a CPU
going through Xen is what allow us to tell that it reached a so-called
'quiescent state', which in turns is necessary for declaring a so-
called 'RCU grace period' over."

I don't quite agree with you on the definition of "quiescent state" 
here. To take the domain example, we want to wait until all the CPU has 
stopped using the pointer (an hypercall could race put_domain). That 
pointer will not be in-use if the CPU is in kernel-mode/user-mode or in 
the idle loop. Am I correct?


So I am wondering whether we could:
- Mark any CPU in kernel-mode/user-mode quiet
- Raise a RCU_SOFTIRQ in call_rcu?

With that solution, it may even be possible to avoid the timer in the 
idle loop.


Cheers,

--
Julien Grall

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

[Xen-devel] Backports to stable trees

[Andrew Cooper]

Hello,

Please can the following patches be considered for stable.

18cd4997d26b - x86/efi: move the logic to detect PE build support
93249f7fc17c - x86/efi: split compiler vs linker support

CentOS and RHEL 7.x GCC's are capable of compiling xen.gz with EFI
support, but LD doesn't have i386pep support.  Without a bodge to the
build system (and several downstreams have borrowed by XenServer bodge),
making a EFI-capable xen.gz isn't possible with the default toolchain.

These patches resolve the issue.

~Andrew

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

[Xen-devel] [PATCH v12 5/9] memory: add check_get_page_from_gfn() as a wrapper...

[Paul Durrant]

...for some uses of get_page_from_gfn().

There are many occurrences of the following pattern in the code:

q =  ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, , q);

if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);

p2m_mem_paging_populate(d, gfn);
return <-EAGAIN or equivalent>;
}

if ( (q & P2M_UNSHARE) && p2m_is_shared(p2mt) )
{
if ( page )
put_page(page);

return <-EAGAIN or equivalent>;
}

if ( !page )
return <-EINVAL or equivalent>;

There are some small differences between the exact way the occurrences
are coded but the desired semantic is the same.

This patch introduces a new common implementation of this code in
check_get_page_from_gfn() and then converts the various open-coded patterns
into calls to this new function.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monne 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v11:
 - Forward declare p2m_type_t in p2m-common.h to allow the duplicate
   declarations of check_get_page_from_gfn() to be removed, and hence add
   Jan's R-b.

v10:
 - Expand commit comment to point out the reason for the duplicate
   declarations of check_get_page_from_gfn().

v9:
 - Defer P2M type checks (beyond shared or paging) to the caller.

v7:
 - Fix ARM build by introducing p2m_is_readonly() predicate.
 - Re-name get_paged_frame() -> check_get_page_from_gfn().
 - Adjust default cases of callers switch-ing on return value.

v3:
 - Addressed comments from George.

v2:
 - New in v2.
---
 xen/arch/x86/hvm/emulate.c   | 25 +++---
 xen/arch/x86/hvm/hvm.c   | 14 +
 xen/common/grant_table.c | 32 ++---
 xen/common/memory.c  | 49 +++-
 xen/include/asm-arm/p2m.h|  4 ++--
 xen/include/asm-x86/p2m.h|  5 ++---
 xen/include/xen/p2m-common.h |  6 ++
 7 files changed, 77 insertions(+), 58 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index a577685dc6..480840b202 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -356,22 +356,21 @@ static int hvmemul_acquire_page(unsigned long gmfn, 
struct page_info **page)
 struct domain *curr_d = current->domain;
 p2m_type_t p2mt;
 
-*page = get_page_from_gfn(curr_d, gmfn, , P2M_UNSHARE);
-
-if ( *page == NULL )
-return X86EMUL_UNHANDLEABLE;
-
-if ( p2m_is_paging(p2mt) )
+switch ( check_get_page_from_gfn(curr_d, _gfn(gmfn), false, ,
+ page) )
 {
-put_page(*page);
-p2m_mem_paging_populate(curr_d, gmfn);
-return X86EMUL_RETRY;
-}
+case 0:
+break;
 
-if ( p2m_is_shared(p2mt) )
-{
-put_page(*page);
+case -EAGAIN:
 return X86EMUL_RETRY;
+
+default:
+ASSERT_UNREACHABLE();
+/* Fallthrough */
+
+case -EINVAL:
+return X86EMUL_UNHANDLEABLE;
 }
 
 /* This code should not be reached if the gmfn is not RAM */
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 9a490ef68c..8fb4f2e7d8 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2536,20 +2536,8 @@ static void *_hvm_map_guest_frame(unsigned long gfn, 
bool_t permanent,
 struct page_info *page;
 struct domain *d = current->domain;
 
-page = get_page_from_gfn(d, gfn, ,
- writable ? P2M_UNSHARE : P2M_ALLOC);
-if ( (p2m_is_shared(p2mt) && writable) || !page )
-{
-if ( page )
-put_page(page);
-return NULL;
-}
-if ( p2m_is_paging(p2mt) )
-{
-put_page(page);
-p2m_mem_paging_populate(d, gfn);
+if ( check_get_page_from_gfn(d, _gfn(gfn), !writable, , ) )
 return NULL;
-}
 
 if ( writable )
 {
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 0f0b7b1a49..3604a8812c 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -374,25 +374,23 @@ static int get_paged_frame(unsigned long gfn, mfn_t *mfn,
struct page_info **page, bool readonly,
struct domain *rd)
 {
-int rc = GNTST_okay;
 p2m_type_t p2mt;
+int rc;
 
-*mfn = INVALID_MFN;
-*page = get_page_from_gfn(rd, gfn, ,
-  readonly ? P2M_ALLOC : P2M_UNSHARE);
-if ( !*page )
+rc = check_get_page_from_gfn(rd, _gfn(gfn), readonly, , page);
+switch ( rc )
 {
-#ifdef P2M_SHARED_TYPES
-if ( p2m_is_shared(p2mt) )
-return GNTST_eagain;
-#endif
-#ifdef P2M_PAGES_TYPES
-if ( p2m_is_paging(p2mt) )
-{
-p2m_mem_paging_populate(rd, gfn);
-return GNTST_eagain;
-}
-#endif
+case 0:
+   

[Xen-devel] [PATCH v12 6/9] vtd: add missing check for shared EPT...

[Paul Durrant]

...in intel_iommu_unmap_page().

This patch also includes some non-functional modifications in
intel_iommu_map_page().

Signed-off-by: Paul Durrant 
Acked-by: Kevin Tian 
---
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: George Dunlap 

v8:
 - New in v8. (Split from the next patch in the series as requested by
   Kevin).
---
 xen/drivers/passthrough/vtd/iommu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 80264c6cc0..5b66ede599 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1773,7 +1773,7 @@ static int __must_check intel_iommu_map_page(struct 
domain *d,
  unsigned int flags)
 {
 struct domain_iommu *hd = dom_iommu(d);
-struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
+struct dma_pte *page, *pte, old, new = {};
 u64 pg_maddr;
 int rc = 0;
 
@@ -1788,14 +1788,16 @@ static int __must_check intel_iommu_map_page(struct 
domain *d,
 spin_lock(>arch.mapping_lock);
 
 pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), 1);
-if ( pg_maddr == 0 )
+if ( !pg_maddr )
 {
 spin_unlock(>arch.mapping_lock);
 return -ENOMEM;
 }
+
 page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
-pte = page + (dfn_x(dfn) & LEVEL_MASK);
+pte = [dfn_x(dfn) & LEVEL_MASK];
 old = *pte;
+
 dma_set_pte_addr(new, mfn_to_maddr(mfn));
 dma_set_pte_prot(new,
  ((flags & IOMMUF_readable) ? DMA_PTE_READ  : 0) |
@@ -1811,6 +1813,7 @@ static int __must_check intel_iommu_map_page(struct 
domain *d,
 unmap_vtd_domain_page(page);
 return 0;
 }
+
 *pte = new;
 
 iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
@@ -1826,6 +1829,10 @@ static int __must_check intel_iommu_map_page(struct 
domain *d,
 static int __must_check intel_iommu_unmap_page(struct domain *d,
dfn_t dfn)
 {
+/* Do nothing if VT-d shares EPT page table */
+if ( iommu_use_hap_pt(d) )
+return 0;
+
 /* Do nothing if hardware domain and iommu supports pass thru. */
 if ( iommu_hwdom_passthrough && is_hardware_domain(d) )
 return 0;
-- 
2.11.0


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

[Xen-devel] [PATCH v12 2/9] iommu: make use of type-safe DFN and MFN in exported functions

[Paul Durrant]

This patch modifies the declaration of the entry points to the IOMMU
sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.

Signed-off-by: Paul Durrant 
Reviewed-by: Wei Liu 
Reviewed-by: Kevin Tian 
Reviewed-by: Roger Pau Monne 
Acked-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Tim Deegan 
Cc: Jun Nakajima 
Cc: George Dunlap 

v9:
 - Re-base.

v7:
 - Re-base and re-name BFN -> DFN.
 - Added Jan's A-b since re-naming was purely mechanical.

v6:
 - Re-base.

v3:
 - Removed most of the uses of an intermediate 'frame' variable.

v2:
 - Addressed comments from Jan.
 - Use intermediate 'frame' variable to avoid directly encapsulating
   mfn or gfn values as dfns.
---
 xen/arch/arm/p2m.c|  3 ++-
 xen/arch/x86/mm.c | 10 
 xen/arch/x86/mm/p2m-ept.c | 10 +---
 xen/arch/x86/mm/p2m-pt.c  | 45 ---
 xen/arch/x86/mm/p2m.c | 16 -
 xen/arch/x86/x86_64/mm.c  |  5 ++--
 xen/common/grant_table.c  | 12 +-
 xen/common/memory.c   |  4 ++--
 xen/drivers/passthrough/iommu.c   | 25 ++-
 xen/drivers/passthrough/vtd/x86/vtd.c |  1 -
 xen/drivers/passthrough/x86/iommu.c   |  3 ++-
 xen/include/xen/iommu.h   | 14 +++
 12 files changed, 85 insertions(+), 63 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1364e5960a..0db12b01f1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -957,7 +957,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 
 if ( need_iommu(p2m->domain) &&
  (lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
-rc = iommu_iotlb_flush(p2m->domain, gfn_x(sgfn), 1UL << page_order);
+rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
+   1UL << page_order);
 else
 rc = 0;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index af1440d578..6f281ad7d5 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2788,14 +2788,14 @@ static int _get_page_type(struct page_info *page, 
unsigned long type,
 struct domain *d = page_get_owner(page);
 if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
 {
-gfn_t gfn = _gfn(mfn_to_gmfn(d, mfn_x(page_to_mfn(page;
+mfn_t mfn = page_to_mfn(page);
 
 if ( (x & PGT_type_mask) == PGT_writable_page )
-iommu_ret = iommu_unmap_page(d, gfn_x(gfn));
+iommu_ret = iommu_unmap_page(d, _dfn(mfn_x(mfn)));
 else if ( type == PGT_writable_page )
-iommu_ret = iommu_map_page(d, gfn_x(gfn),
-   mfn_x(page_to_mfn(page)),
-   IOMMUF_readable|IOMMUF_writable);
+iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
+   IOMMUF_readable |
+   IOMMUF_writable);
 }
 }
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 1ff4f14ae4..9a3a90e9e6 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -870,15 +870,19 @@ out:
 rc = iommu_pte_flush(d, gfn, _entry->epte, order, 
vtd_pte_present);
 else
 {
+dfn_t dfn = _dfn(gfn);
+
 if ( iommu_flags )
 for ( i = 0; i < (1 << order); i++ )
 {
-rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
iommu_flags);
+rc = iommu_map_page(d, dfn_add(dfn, i),
+mfn_add(mfn, i), iommu_flags);
 if ( unlikely(rc) )
 {
 while ( i-- )
 /* If statement to satisfy __must_check. */
-if ( iommu_unmap_page(p2m->domain, gfn + i) )
+if ( iommu_unmap_page(p2m->domain,
+  dfn_add(dfn, i)) )
 continue;
 
 break;
@@ -887,7 +891,7 @@ out:
 else
 for ( i = 0; i < (1 << order); i++ )
 {
-ret = iommu_unmap_page(d, gfn + i);
+ret = iommu_unmap_page(d, dfn_add(dfn, i));
 if ( !rc )
 rc = ret;
 }
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index b8c5d2ed26..881e9e87b8 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -687,29 +687,36 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
mfn_t mfn,
 if ( iommu_old_flags )
 

[Xen-devel] [PATCH v12 3/9] iommu: push use of type-safe DFN and MFN into iommu_ops

[Paul Durrant]

This patch modifies the methods in struct iommu_ops to use type-safe DFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.

Signed-off-by: Paul Durrant 
Reviewed-by: Wei Liu 
Reviewed-by: Kevin Tian 
Reviewed-by: Roger Pau Monne 
Acked-by: Jan Beulich 
---
Cc: Suravee Suthikulpanit 
Cc: Andrew Cooper 
Cc: George Dunlap 

v9:
 - Re-base.

v7:
 - Re-base and re-name BFN -> DFN.
 - Added Jan's A-b since re-naming was purely mechanical.

v6:
 - Re-base.

v3:
 - Remove some use of intermediate 'frame' variables.

v2:
 - Addressed comments from Jan.
 - Extend use of intermediate 'frame' variable to avoid directly
   encapsulating gfn values as bfns (now dfns) or vice versa.
---
 xen/drivers/passthrough/amd/iommu_map.c   | 46 ---
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  2 +-
 xen/drivers/passthrough/arm/smmu.c| 16 +-
 xen/drivers/passthrough/iommu.c   |  9 +++---
 xen/drivers/passthrough/vtd/iommu.c   | 26 +++
 xen/drivers/passthrough/x86/iommu.c   |  2 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  8 ++---
 xen/include/xen/iommu.h   | 13 +---
 8 files changed, 67 insertions(+), 55 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 61ade71850..c89c54fdb6 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -631,7 +631,7 @@ static int update_paging_mode(struct domain *d, unsigned 
long dfn)
 return 0;
 }
 
-int amd_iommu_map_page(struct domain *d, unsigned long dfn, unsigned long mfn,
+int amd_iommu_map_page(struct domain *d, dfn_t dfn, mfn_t mfn,
unsigned int flags)
 {
 bool_t need_flush = 0;
@@ -651,7 +651,8 @@ int amd_iommu_map_page(struct domain *d, unsigned long dfn, 
unsigned long mfn,
 if ( rc )
 {
 spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Root table alloc failed, dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
 domain_crash(d);
 return rc;
 }
@@ -660,25 +661,27 @@ int amd_iommu_map_page(struct domain *d, unsigned long 
dfn, unsigned long mfn,
  * we might need a deeper page table for wider dfn now */
 if ( is_hvm_domain(d) )
 {
-if ( update_paging_mode(d, dfn) )
+if ( update_paging_mode(d, dfn_x(dfn)) )
 {
 spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Update page mode failed dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Update page mode failed dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
 domain_crash(d);
 return -EFAULT;
 }
 }
 
-if ( iommu_pde_from_dfn(d, dfn, pt_mfn) || (pt_mfn[1] == 0) )
+if ( iommu_pde_from_dfn(d, dfn_x(dfn), pt_mfn) || (pt_mfn[1] == 0) )
 {
 spin_unlock(>arch.mapping_lock);
-AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %lx\n", dfn);
+AMD_IOMMU_DEBUG("Invalid IO pagetable entry dfn = %"PRI_dfn"\n",
+dfn_x(dfn));
 domain_crash(d);
 return -EFAULT;
 }
 
 /* Install 4k mapping first */
-need_flush = set_iommu_pte_present(pt_mfn[1], dfn, mfn,
+need_flush = set_iommu_pte_present(pt_mfn[1], dfn_x(dfn), mfn_x(mfn),
IOMMU_PAGING_MODE_LEVEL_1,
!!(flags & IOMMUF_writable),
!!(flags & IOMMUF_readable));
@@ -690,7 +693,7 @@ int amd_iommu_map_page(struct domain *d, unsigned long dfn, 
unsigned long mfn,
 /* 4K mapping for PV guests never changes, 
  * no need to flush if we trust non-present bits */
 if ( is_hvm_domain(d) )
-amd_iommu_flush_pages(d, dfn, 0);
+amd_iommu_flush_pages(d, dfn_x(dfn), 0);
 
 for ( merge_level = IOMMU_PAGING_MODE_LEVEL_2;
   merge_level <= hd->arch.paging_mode; merge_level++ )
@@ -698,15 +701,16 @@ int amd_iommu_map_page(struct domain *d, unsigned long 
dfn, unsigned long mfn,
 if ( pt_mfn[merge_level] == 0 )
 break;
 if ( !iommu_update_pde_count(d, pt_mfn[merge_level],
- dfn, mfn, merge_level) )
+ dfn_x(dfn), mfn_x(mfn), merge_level) )
 break;
 
-if ( iommu_merge_pages(d, pt_mfn[merge_level], dfn,
+if ( iommu_merge_pages(d, pt_mfn[merge_level], dfn_x(dfn),
flags, merge_level) )
 {
 spin_unlock(>arch.mapping_lock);
 AMD_IOMMU_DEBUG("Merge iommu page failed at level %d, "
-"dfn = %lx mfn = %lx\n", merge_level, dfn, mfn);
+"dfn = %"PRI_dfn" mfn = %"PRI_mfn"\n",
+merge_level, 

[Xen-devel] [PATCH v12 4/9] iommu: don't domain_crash() inside iommu_map/unmap_page()

[Paul Durrant]

This patch removes the implicit domain_crash() from iommu_map(),
unmap_page() and iommu_iotlb_flush() and turns them into straightforward
wrappers that check the existence of the relevant iommu_op and call
through to it. This makes them usable by PV IOMMU code to be delivered in
future patches.
This patch adds a helper macro, domu_crash(), that will only invoke
domain_crash() if the domain is not the hardware domain and modifies
callers of iommu_map(), unmap_page() and iommu_iotlb_flush() to use this
should an operation fail.

NOTE: This patch includes one bit of clean-up in set_identity_p2m_entry()
  replacing use of p2m->domain with the domain pointer passed into the
  function.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Reviewed-by: Kevin Tian 
Reviewed-by: Roger Pau Monne 
---
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Jun Nakajima 
Cc: George Dunlap 

v7:
 - Re-base and re-name BFN -> DFN.
 - Move domu_crash() outside double locked region in grant_table.c.
 - Added Jan's R-b.

v6:
 - Introduce domu_crash() (idea suggested by Kevin, name suggested by Jan)
   to crash non-hardware domains.
 - Dropped Wei's and George's R-b because of change.

v2:
 - New in v2.
---
 xen/arch/arm/p2m.c  |  4 
 xen/arch/x86/mm.c   |  3 +++
 xen/arch/x86/mm/p2m-ept.c   |  3 +++
 xen/arch/x86/mm/p2m-pt.c|  3 +++
 xen/arch/x86/mm/p2m.c   | 22 ++
 xen/common/grant_table.c|  4 
 xen/common/memory.c |  3 +++
 xen/drivers/passthrough/iommu.c | 12 
 xen/drivers/passthrough/x86/iommu.c |  4 
 xen/include/xen/sched.h |  5 +
 10 files changed, 47 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 0db12b01f1..1c79ff7ade 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -957,8 +957,12 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 
 if ( need_iommu(p2m->domain) &&
  (lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
+{
 rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
1UL << page_order);
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
+}
 else
 rc = 0;
 
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 6f281ad7d5..b713764c11 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -2796,6 +2796,9 @@ static int _get_page_type(struct page_info *page, 
unsigned long type,
 iommu_ret = iommu_map_page(d, _dfn(mfn_x(mfn)), mfn,
IOMMUF_readable |
IOMMUF_writable);
+
+if ( unlikely(iommu_ret) )
+domu_crash(d);
 }
 }
 
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 9a3a90e9e6..af7674f7e1 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -895,6 +895,9 @@ out:
 if ( !rc )
 rc = ret;
 }
+
+if ( unlikely(rc) )
+domu_crash(d);
 }
 }
 
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 881e9e87b8..607046f31b 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -717,6 +717,9 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 rc = ret;
 }
 }
+
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
 }
 
 /*
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 801b629b95..537add65bb 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -724,6 +724,9 @@ p2m_remove_page(struct p2m_domain *p2m, unsigned long 
gfn_l, unsigned long mfn,
 if ( !rc )
 rc = ret;
 }
+
+if ( unlikely(rc) )
+domu_crash(p2m->domain);
 }
 
 return rc;
@@ -789,6 +792,7 @@ guest_physmap_add_entry(struct domain *d, gfn_t gfn, mfn_t 
mfn,
 if ( iommu_unmap_page(d, dfn_add(dfn, i)) )
 continue;
 
+domu_crash(d);
 return rc;
 }
 }
@@ -1157,12 +1161,17 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
long gfn_l,
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int ret;
 
-if ( !paging_mode_translate(p2m->domain) )
+if ( !paging_mode_translate(d) )
 {
 if ( !need_iommu(d) )
 return 0;
-return iommu_map_page(d, _dfn(gfn_l), _mfn(gfn_l),
-  IOMMUF_readable | IOMMUF_writable);
+
+ret = iommu_map_page(d, _dfn(gfn_l), _mfn(gfn_l),
+ IOMMUF_readable | IOMMUF_writable);
+if ( unlikely(ret) )
+ 

[Xen-devel] [PATCH v12 1/9] iommu: introduce the concept of DFN...

[Paul Durrant]

...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU
(rather than the MMU) and hence used for DMA address translation.

This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number
or address relate to a device rather than the CPU.

The parts that are not purely cosmetic are:

 - the introduction of a type-safe declaration of dfn_t and definition of
   INVALID_DFN to make the substitution of gfn_x(INVALID_GFN) mechanical.
 - the introduction of __dfn_to_daddr and __daddr_to_dfn (and type-safe
   variants without the leading __) with some use of the former.

Subsequent patches will convert code to make use of type-safe DFNs.

Signed-off-by: Paul Durrant 
Acked-by: Jan Beulich 
Reviewed-by: Kevin Tian 
---
Cc: Wei Liu 
Cc: Suravee Suthikulpanit 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v9:
 - Re-word comment in mm.h.
 - Move definitions relating to daddr into asm-x86/iommu.h since these are
   not used by any ARM IOMMU implementation.
 - Fix __daddr_to_dfn() to properly parenthesize and remove cast.

v8:
 - Correct definition of INVALID_DFN.
 - Don't use _AC in definition of IOMMU_PAGE_SIZE.

v7:
 - Re-name BFN -> DFN as requested by Jan.
 - Dropped Wei's R-b because of name change.

v6:
 - Dropped changes to 'mfn' section in xen/mm.h as suggested by Kevin.

v3:
 - Get rid of intermediate 'frame' variables again.

v2:
 - Addressed comments from Jan.
---
 xen/drivers/passthrough/amd/iommu_cmd.c | 18 +++
 xen/drivers/passthrough/amd/iommu_map.c | 78 ++---
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  2 +-
 xen/drivers/passthrough/arm/smmu.c  | 16 +++---
 xen/drivers/passthrough/iommu.c | 28 +--
 xen/drivers/passthrough/vtd/iommu.c | 30 +--
 xen/include/asm-x86/iommu.h | 12 +
 xen/include/xen/iommu.h | 26 +++---
 xen/include/xen/mm.h|  5 ++
 9 files changed, 123 insertions(+), 92 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_cmd.c 
b/xen/drivers/passthrough/amd/iommu_cmd.c
index 08247fa354..d4d071e53e 100644
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -284,7 +284,7 @@ void invalidate_iommu_all(struct amd_iommu *iommu)
 }
 
 void amd_iommu_flush_iotlb(u8 devfn, const struct pci_dev *pdev,
-   uint64_t gaddr, unsigned int order)
+   daddr_t daddr, unsigned int order)
 {
 unsigned long flags;
 struct amd_iommu *iommu;
@@ -315,12 +315,12 @@ void amd_iommu_flush_iotlb(u8 devfn, const struct pci_dev 
*pdev,
 
 /* send INVALIDATE_IOTLB_PAGES command */
 spin_lock_irqsave(>lock, flags);
-invalidate_iotlb_pages(iommu, maxpend, 0, queueid, gaddr, req_id, order);
+invalidate_iotlb_pages(iommu, maxpend, 0, queueid, daddr, req_id, order);
 flush_command_buffer(iommu);
 spin_unlock_irqrestore(>lock, flags);
 }
 
-static void amd_iommu_flush_all_iotlbs(struct domain *d, uint64_t gaddr,
+static void amd_iommu_flush_all_iotlbs(struct domain *d, daddr_t daddr,
unsigned int order)
 {
 struct pci_dev *pdev;
@@ -333,7 +333,7 @@ static void amd_iommu_flush_all_iotlbs(struct domain *d, 
uint64_t gaddr,
 u8 devfn = pdev->devfn;
 
 do {
-amd_iommu_flush_iotlb(devfn, pdev, gaddr, order);
+amd_iommu_flush_iotlb(devfn, pdev, daddr, order);
 devfn += pdev->phantom_stride;
 } while ( devfn != pdev->devfn &&
   PCI_SLOT(devfn) == PCI_SLOT(pdev->devfn) );
@@ -342,7 +342,7 @@ static void amd_iommu_flush_all_iotlbs(struct domain *d, 
uint64_t gaddr,
 
 /* Flush iommu cache after p2m changes. */
 static void _amd_iommu_flush_pages(struct domain *d,
-   uint64_t gaddr, unsigned int order)
+   daddr_t daddr, unsigned int order)
 {
 unsigned long flags;
 struct amd_iommu *iommu;
@@ -352,13 +352,13 @@ static void _amd_iommu_flush_pages(struct domain *d,
 for_each_amd_iommu ( iommu )
 {
 spin_lock_irqsave(>lock, flags);
-invalidate_iommu_pages(iommu, gaddr, dom_id, order);
+invalidate_iommu_pages(iommu, daddr, dom_id, order);
 flush_command_buffer(iommu);
 spin_unlock_irqrestore(>lock, flags);
 }
 
 if ( ats_enabled )
-amd_iommu_flush_all_iotlbs(d, gaddr, order);
+amd_iommu_flush_all_iotlbs(d, daddr, order);
 }
 
 void amd_iommu_flush_all_pages(struct domain *d)
@@ -367,9 +367,9 @@ void amd_iommu_flush_all_pages(struct domain *d)
 }
 
 void amd_iommu_flush_pages(struct domain *d,
-   unsigned long gfn, unsigned int order)
+   unsigned long dfn, unsigned int order)
 {
-_amd_iommu_flush_pages(d, (uint64_t) gfn << PAGE_SHIFT, order);
+

[Xen-devel] [PATCH v12 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

[Paul Durrant]

The name 'need_iommu()' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
represents a tri-state value (not a boolean as might be expected) where
-1 means 'IOMMU mappings being set up' and 1 means 'IOMMU mappings have
been fully set up'.

Two different meanings are also inferred from the macro it in various
places in the code:

- Some callers want to test whether a domain has IOMMU mappings at all
- Some callers want to test whether they need to synchronize the domain's
  P2M and IOMMU mappings

This patch replaces the 'need_iommu' tri-state value with a defined
enumeration and adds a boolean flag 'need_sync' to separate these meanings,
and places both of these in struct domain_iommu, rather than directly in
struct domain.
This patch also creates two new boolean macros:

- 'has_iommu_pt()' evaluates to true if a domain has IOMMU mappings, even
  if they are still under construction.
- 'need_iommu_pt_sync()' evaluates to true if a domain requires explicit
  synchronization of the P2M and IOMMU mappings.

All callers of need_iommu() are then modified to use the macro appropriate
to what they are trying to test.

NOTE: There are some callers of need_iommu() that strictly operate on
  the hardware domain. In some of these case a more global flag is
  used instead.

Signed-off-by: Paul Durrant 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Tamas K Lengyel 
Cc: George Dunlap 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 

v12:
 - Fix two mis-uses of iommu_hap_pt_share().
 - Remove one use has_iommu_pt() check in passthrough/pci.c

v11:
 - Pulled in from v6 of the full PV-IOMMU series.
 _ Changed the condition being tested in memory_add() to be more self-
   explanatory but also added a comment to explain the circumstances
   under which iommu_map_page() needs to be called.
 - Get rid of #ifdef CONFIG_HAS_PASSTHROUGH in memory.c since the if
   clauses within will never be executed unless the option is defined
   (since has_iommu_pt() will always be false otherwise). Also flushing
   should be done regardless of whether the IOMMU is sharing page tables
   or not.

v6:
 - Deal with need_iommu being tri-state.
 - Change the name of 'sync_iommu_pt' to 'need_iommu_pt_sync' and make
   sure it is set as soon as the mappings are under construction.
 - Not adding Razvan's A-b because of change.

v4:
 - New in v4.
---
 xen/arch/arm/p2m.c  |  2 +-
 xen/arch/x86/hvm/mtrr.c |  4 ++--
 xen/arch/x86/mm.c   |  2 +-
 xen/arch/x86/mm/mem_sharing.c   |  2 +-
 xen/arch/x86/mm/p2m-ept.c   |  2 +-
 xen/arch/x86/mm/p2m-pt.c|  2 +-
 xen/arch/x86/mm/p2m.c   |  8 +++
 xen/arch/x86/mm/paging.c|  2 +-
 xen/arch/x86/x86_64/mm.c|  9 +--
 xen/common/memory.c | 10 +++-
 xen/common/vm_event.c   |  2 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c |  2 +-
 xen/drivers/passthrough/device_tree.c   | 21 
 xen/drivers/passthrough/iommu.c | 37 ++---
 xen/drivers/passthrough/pci.c   | 11 -
 xen/drivers/passthrough/x86/iommu.c |  2 --
 xen/include/asm-arm/grant_table.h   |  2 +-
 xen/include/asm-arm/iommu.h |  2 +-
 xen/include/asm-x86/grant_table.h   |  2 +-
 xen/include/asm-x86/iommu.h |  2 +-
 xen/include/xen/iommu.h | 17 +
 xen/include/xen/sched.h |  9 ---
 22 files changed, 92 insertions(+), 60 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1c79ff7ade..a0bec7c95c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -955,7 +955,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 if ( lpae_is_valid(orig_pte) && entry->p2m.base != orig_pte.p2m.base )
 p2m_free_entry(p2m, orig_pte, level);
 
-if ( need_iommu(p2m->domain) &&
+if ( need_iommu_pt_sync(p2m->domain) &&
  (lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
 {
 rc = iommu_iotlb_flush(p2m->domain, _dfn(gfn_x(sgfn)),
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 4f2f195f7d..b8fa340d5a 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -783,7 +783,7 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, 
hvm_load_mtrr_msr, 1,
 
 void memory_type_changed(struct domain *d)
 {
-if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
+if ( has_iommu_pt(d) && d->vcpu && d->vcpu[0] )
 {
 p2m_memory_type_changed(d);
 flush_all(FLUSH_CACHE);
@@ -831,7 +831,7 @@ int 

[Xen-devel] [PATCH v12 8/9] mm / iommu: include need_iommu() test in iommu_use_hap_pt()

[Paul Durrant]

The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.

Signed-off-by: Paul Durrant 
Reviewed-by: Kevin Tian 
---
Cc: Jun Nakajima 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v11:
 - Pulled in from v6 of the full PV-IOMMU series.

v4:
 - New in v4.
---
 xen/arch/x86/mm/p2m-ept.c   | 6 +++---
 xen/arch/x86/mm/p2m-pt.c| 6 +++---
 xen/arch/x86/mm/p2m.c   | 2 +-
 xen/drivers/passthrough/iommu.c | 2 +-
 xen/include/asm-arm/iommu.h | 2 +-
 xen/include/asm-x86/iommu.h | 5 +++--
 6 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index af7674f7e1..f0d93856f2 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -863,12 +863,12 @@ out:
 ept_sync_domain(p2m);
 
 /* For host p2m, may need to change VT-d page table.*/
-if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
+if ( rc == 0 && p2m_is_hostp2m(p2m) &&
  need_modify_vtd_table )
 {
-if ( iommu_hap_pt_share )
+if ( iommu_use_hap_pt(d) )
 rc = iommu_pte_flush(d, gfn, _entry->epte, order, 
vtd_pte_present);
-else
+else if ( need_iommu(d) )
 {
 dfn_t dfn = _dfn(gfn);
 
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 607046f31b..6b30337f62 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -677,8 +677,8 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
  && (gfn + (1UL << page_order) - 1 > p2m->max_mapped_pfn) )
 p2m->max_mapped_pfn = gfn + (1UL << page_order) - 1;
 
-if ( iommu_enabled && need_iommu(p2m->domain) &&
- (iommu_old_flags != iommu_pte_flags || old_mfn != mfn_x(mfn)) )
+if ( iommu_enabled && (iommu_old_flags != iommu_pte_flags ||
+   old_mfn != mfn_x(mfn)) )
 {
 ASSERT(rc == 0);
 
@@ -687,7 +687,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, mfn_t 
mfn,
 if ( iommu_old_flags )
 amd_iommu_flush_pages(p2m->domain, gfn, page_order);
 }
-else
+else if ( need_iommu(p2m->domain) )
 {
 dfn_t dfn = _dfn(gfn);
 
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 537add65bb..97bb3feacc 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -2091,7 +2091,7 @@ static unsigned int mmio_order(const struct domain *d,
  * - exclude PV guests, should execution reach this code for such.
  * So be careful when altering this.
  */
-if ( !need_iommu(d) || !iommu_use_hap_pt(d) ||
+if ( !iommu_use_hap_pt(d) ||
  (start_fn & ((1UL << PAGE_ORDER_2M) - 1)) || !(nr >> PAGE_ORDER_2M) )
 return PAGE_ORDER_4K;
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 9cb1793144..ea7ccbace7 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -475,7 +475,7 @@ int iommu_do_domctl(
 
 void iommu_share_p2m_table(struct domain* d)
 {
-if ( iommu_enabled && iommu_use_hap_pt(d) )
+if ( iommu_use_hap_pt(d) )
 iommu_get_ops()->share_p2m(d);
 }
 
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 57d9b1e14a..8d1506c6f7 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -21,7 +21,7 @@ struct arch_iommu
 };
 
 /* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) (1)
+#define iommu_use_hap_pt(d) (need_iommu(d))
 
 const struct iommu_ops *iommu_get_ops(void);
 void __init iommu_set_ops(const struct iommu_ops *ops);
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 0ed4a9e86d..7c3187c8ec 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -89,8 +89,9 @@ static inline int iommu_hardware_setup(void)
 return -ENODEV;
 }
 
-/* Does this domain have a P2M table we can use as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) (hap_enabled(d) && iommu_hap_pt_share)
+/* Are we using the domain P2M table as its IOMMU pagetable? */
+#define iommu_use_hap_pt(d) \
+(hap_enabled(d) && need_iommu(d) && iommu_hap_pt_share)
 
 void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg, unsigned 
int value);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
-- 
2.11.0


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

[Xen-devel] [PATCH v12 0/9] paravirtual IOMMU pre-requisites and clean-up

[Paul Durrant]

This series contains pre-requisites and clean-up needed for paravirtual
IOMMU support.

I have separated these patches to avoid further delaying their application
whilst I re-work the implementation of paravirtual IOMMU after review of
v6 of the series. Several of them already have all necessary acks.

v12:
 - Only patch #9 changed.

v11:
 - Pull in two more patches from v6.

Paul Durrant (9):
  iommu: introduce the concept of DFN...
  iommu: make use of type-safe DFN and MFN in exported functions
  iommu: push use of type-safe DFN and MFN into iommu_ops
  iommu: don't domain_crash() inside iommu_map/unmap_page()
  memory: add check_get_page_from_gfn() as a wrapper...
  vtd: add missing check for shared EPT...
  vtd: add lookup_page method to iommu_ops
  mm / iommu: include need_iommu() test in iommu_use_hap_pt()
  mm / iommu: split need_iommu() into has_iommu_pt() and
need_iommu_pt_sync()

 xen/arch/arm/p2m.c|  9 ++-
 xen/arch/x86/hvm/emulate.c| 25 
 xen/arch/x86/hvm/hvm.c| 14 +---
 xen/arch/x86/hvm/mtrr.c   |  4 +-
 xen/arch/x86/mm.c | 15 +++--
 xen/arch/x86/mm/mem_sharing.c |  2 +-
 xen/arch/x86/mm/p2m-ept.c | 19 --
 xen/arch/x86/mm/p2m-pt.c  | 52 +--
 xen/arch/x86/mm/p2m.c | 42 
 xen/arch/x86/mm/paging.c  |  2 +-
 xen/arch/x86/x86_64/mm.c  | 14 ++--
 xen/common/grant_table.c  | 48 +++---
 xen/common/memory.c   | 66 +--
 xen/common/vm_event.c |  2 +-
 xen/drivers/passthrough/amd/iommu_cmd.c   | 18 +++---
 xen/drivers/passthrough/amd/iommu_map.c   | 88 +
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  6 +-
 xen/drivers/passthrough/arm/smmu.c| 20 +++---
 xen/drivers/passthrough/device_tree.c | 21 +++---
 xen/drivers/passthrough/iommu.c   | 92 ---
 xen/drivers/passthrough/pci.c | 11 ++--
 xen/drivers/passthrough/vtd/iommu.c   | 88 +++--
 xen/drivers/passthrough/vtd/iommu.h   |  3 +
 xen/drivers/passthrough/vtd/x86/vtd.c |  1 -
 xen/drivers/passthrough/x86/iommu.c   | 11 ++--
 xen/include/asm-arm/grant_table.h |  2 +-
 xen/include/asm-arm/iommu.h   |  2 +-
 xen/include/asm-arm/p2m.h |  4 +-
 xen/include/asm-x86/grant_table.h |  2 +-
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  8 +--
 xen/include/asm-x86/iommu.h   | 17 -
 xen/include/asm-x86/p2m.h |  5 +-
 xen/include/xen/iommu.h   | 68 +---
 xen/include/xen/mm.h  |  5 ++
 xen/include/xen/p2m-common.h  |  6 ++
 xen/include/xen/sched.h   | 14 ++--
 36 files changed, 513 insertions(+), 293 deletions(-)
---
Cc: Andrew Cooper 
Cc: Brian Woods 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tamas K Lengyel 
Cc: Tim Deegan 
Cc: Wei Liu 
-- 
2.11.0


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

[Xen-devel] [PATCH v12 7/9] vtd: add lookup_page method to iommu_ops

[Paul Durrant]

This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified DFN along with a wrapper function
in generic IOMMU code to call the implementation if it exists.

NOTE: This patch only adds a Xen-internal interface. This will be used by
  a subsequent patch.
  Another subsequent patch will add similar functionality for AMD
  IOMMUs.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Reviewed-by: Kevin Tian 
---
Cc: Wei Liu 
Cc: George Dunlap 

v11:
 - Fold in patch to change failure semantics (already ack-ed by Kevin).

v10:
 - Adjust the locking comment.

v9:
 - Add comment about locking in xen/iommu.h.

v8:
 - Remove clean-up as this is now done by a prior patch.
 - Make intel_iommu_lookup_page() return dfn value if using shared EPT
   or iommu_passthrough is set, as requested by Kevin.

v7:
 - Re-base and re-name BFN -> DFN.
 - Add missing checks for shared EPT and iommu_passthrough.
 - Remove unnecessary initializers and use array-style dereference.
 - Drop Wei's R-b because of code churn.

v3:
 - Addressed comments from George.

v2:
 - Addressed some comments from Jan.
---
 xen/drivers/passthrough/iommu.c | 11 ++
 xen/drivers/passthrough/vtd/iommu.c | 41 +
 xen/drivers/passthrough/vtd/iommu.h |  3 +++
 xen/include/xen/iommu.h | 10 +
 4 files changed, 65 insertions(+)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 4486b16109..9cb1793144 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -327,6 +327,17 @@ int iommu_unmap_page(struct domain *d, dfn_t dfn)
 return rc;
 }
 
+int iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
+  unsigned int *flags)
+{
+const struct domain_iommu *hd = dom_iommu(d);
+
+if ( !iommu_enabled || !hd->platform_ops )
+return -EOPNOTSUPP;
+
+return hd->platform_ops->lookup_page(d, dfn, mfn, flags);
+}
+
 static void iommu_free_pagetables(unsigned long unused)
 {
 do {
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 5b66ede599..1e861b696d 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1840,6 +1840,46 @@ static int __must_check intel_iommu_unmap_page(struct 
domain *d,
 return dma_pte_clear_one(d, dfn_to_daddr(dfn));
 }
 
+static int intel_iommu_lookup_page(struct domain *d, dfn_t dfn, mfn_t *mfn,
+   unsigned int *flags)
+{
+struct domain_iommu *hd = dom_iommu(d);
+struct dma_pte *page, val;
+u64 pg_maddr;
+
+/*
+ * If VT-d shares EPT page table or if the domain is the hardware
+ * domain and iommu_passthrough is set then pass back the dfn.
+ */
+if ( iommu_use_hap_pt(d) ||
+ (iommu_hwdom_passthrough && is_hardware_domain(d)) )
+return -EOPNOTSUPP;
+
+spin_lock(>arch.mapping_lock);
+
+pg_maddr = addr_to_dma_page_maddr(d, dfn_to_daddr(dfn), 0);
+if ( !pg_maddr )
+{
+spin_unlock(>arch.mapping_lock);
+return -ENOMEM;
+}
+
+page = map_vtd_domain_page(pg_maddr);
+val = page[dfn_x(dfn) & LEVEL_MASK];
+
+unmap_vtd_domain_page(page);
+spin_unlock(>arch.mapping_lock);
+
+if ( !dma_pte_present(val) )
+return -ENOENT;
+
+*mfn = maddr_to_mfn(dma_pte_addr(val));
+*flags = dma_pte_read(val) ? IOMMUF_readable : 0;
+*flags |= dma_pte_write(val) ? IOMMUF_writable : 0;
+
+return 0;
+}
+
 int iommu_pte_flush(struct domain *d, uint64_t dfn, uint64_t *pte,
 int order, int present)
 {
@@ -2665,6 +2705,7 @@ const struct iommu_ops intel_iommu_ops = {
 .teardown = iommu_domain_teardown,
 .map_page = intel_iommu_map_page,
 .unmap_page = intel_iommu_unmap_page,
+.lookup_page = intel_iommu_lookup_page,
 .free_page_table = iommu_free_page_table,
 .reassign_device = reassign_device_ownership,
 .get_device_group_id = intel_iommu_group_id,
diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 72c1a2e3cd..47bdfcb5ea 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -272,6 +272,9 @@ struct dma_pte {
 #define dma_set_pte_prot(p, prot) do { \
 (p).val = ((p).val & ~DMA_PTE_PROT) | ((prot) & DMA_PTE_PROT); \
 } while (0)
+#define dma_pte_prot(p) ((p).val & DMA_PTE_PROT)
+#define dma_pte_read(p) (dma_pte_prot(p) & DMA_PTE_READ)
+#define dma_pte_write(p) (dma_pte_prot(p) & DMA_PTE_WRITE)
 #define dma_pte_addr(p) ((p).val & PADDR_MASK & PAGE_MASK_4K)
 #define dma_set_pte_addr(p, addr) do {\
 (p).val |= ((addr) & PAGE_MASK_4K); } while (0)
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 7313957c81..9ae8321bb4 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -92,6 +92,8 @@ void iommu_teardown(struct domain *d);
 

Re: [Xen-devel] null scheduler bug

[Dario Faggioli]

On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
> Hi,
> I applied patch and vwfi=native and everything works fine, I can
> create and destroy guest domain as many times as I want.
> 
Ok, now that we know it works, what do you guys prefer?

Stefano? Julien? I know it's not strictly an ARM-only issue, but I'm
asking you because ARM is where it shows-up/harm the most.

I personally would be ok with:
- doing a patch adding qhimark, qlowmark and blimit boot command line 
  parameters;
- doing a patch (similar to this one) forcing the parameters to a 
  specific state (and printing a warning about that), if wfi=native is 
  used.

Thoughts?

Oh, and I'm adding Juergen in case we consider this relevant for the
release (and in case we want to add a Jira issue, which I don't think I
can do).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


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

[Xen-devel] [qemu-mainline baseline-only test] 75302: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75302 qemu-mainline real [real]
http://osstest.xensource.com/osstest/logs/75302/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  broken
 build-i386   broken
 build-armhf-pvopsbroken
 build-i386-xsm   broken
 build-amd64-xsm  broken
 build-amd64-pvopsbroken
 build-i386-pvops broken
 build-armhf  broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvshim1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Jens Axboe]

On 9/27/18 1:12 AM, Juergen Gross wrote:
> On 22/09/18 21:55, Boris Ostrovsky wrote:
>> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> added support for purging persistent grants when they are not in use. As
>> part of the purge, the grants were removed from the grant buffer, This
>> eventually causes the buffer to become empty, with BUG_ON triggered in
>> get_free_grant(). This can be observed even on an idle system, within
>> 20-30 minutes.
>>
>> We should keep the grants in the buffer when purging, and only free the
>> grant ref.
>>
>> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
>> Signed-off-by: Boris Ostrovsky 
> 
> Reviewed-by: Juergen Gross 

Since Konrad is out, I'm going to queue this up for 4.19.

-- 
Jens Axboe


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

Re: [Xen-devel] null scheduler bug

[Dario Faggioli]

On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
> Hi,
> I applied patch and vwfi=native and everything works fine, I can
> create and destroy guest domain as many times as I want.
> 
> I have to ask, will this patch have any impact on performance (I will
> test it later, but I just need your opinions)?
>
Well, with a question like this, the only possible answer is "depends".
:-)

Basically, there is a little bit of overhead to be expected, with this
patch applied, every time that call_rcu() is invoked, inside Xen. Now,
you can look at when that happens, and you'll notice that this
basically never happen in an hot-path.

In your case, there is at least one call in the domain destruction
path. You can try to measure whether actually destroying the domain
takes more time _with_ "wfi=native" (plus this patch) as compared to
how long it takes _without_ "wfi=native" (and also without this patch).
I don't think you'll be able to appreciate any significant difference.

The point is more, I think, whether "wfi=native" helps your use case.
Have you measure that? I mean, have you checked what is the difference
in performance (or latency, or whatever you're interested in) between
the "wfi=native" case and the default?
If you have, and "wfi=native" helps, then you also need something like
this patch, or domain destruction won't work (in fact, I call the fact
that it takes 'around 7 seconds', not working). If "wfi=native" does
not help your use case, then you're better off not using neither it nor
this patch.

> And what this patch exactly do? I need to fully understand it because
> I need to document it in my master thesis which will be finished soon
> thanks to you people :D
> 
Have you heard about RCU? It's a very clever synchronization solution,
widely used in the Linux kernel. Xen has that too, but we use an old
version of the Linux code, and we don't use it that much.

This is, IMO, some good introductory material, but, really, just google
"RCU" or "RCU linux", and you'll hit tons of articles and docs:
https://lwn.net/Articles/262464/

Well, our implementation of RCU requires that, from time to time, the
various physical CPUs of your box become idle, or get an interrupt, or
go executing inside Xen (for hypercalls, vmexits, etc). In fact, a CPU
going through Xen is what allow us to tell that it reached a so-called
'quiescent state', which in turns is necessary for declaring a so-
called 'RCU grace period' over.

Usually, as soon as a guest (or dom0) vCPU become idle, the pCPU on
which it was running does go through Xen, to figure out whether or not
there is another vCPU, from the same or from another guest, to be run.
If not, the pCPU stays idle, but it stays idle _in_Xen_, and that is
good for RCU quiescence and grace period tracking.

Now, with the combination of "sched=null" and "wfi=native", when the
guest (or dom0) vCPU becomes idle, we _stay_in_the_guest_, until
something (typically an interrupt) comes. This means that the vCPU in
question never let Xen's RCU know that he has gone through a quiescent
state, and grace periods risk lasting very long, if not forever.

In fact, the reason why everything was working again with a printk()
was, as Julien noted, that an interrupt was being injected. Check the
old discussion on xen-devel about the RCU bug that I linked to in one
of my first messages in this thread to even more insights.

https://www.mail-archive.com/xen-devel@lists.xen.org/msg105388.html

https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg02770.html

https://lists.xen.org/archives/html/xen-devel/2017-09/msg01855.html
https://lists.xen.org/archives/html/xen-devel/2017-09/msg03515.html
https://lists.xenproject.org/archives/html/xen-devel/2017-09/msg01855.html

Setting the qhimark, qlowmark and blimit to the values you see in the
patch, partially defeats the purpose of RCU, as the update of the data
structure is not deferred to some future point in time, but it is
basically always performed synchronously with the modification, and
that's why I dislike just doing it all the time, and I prefer limiting
to doing it when we're using "wfi=native".

For some more details about the meaning of the qhimark, qlowmark and
blimit values, check these:
https://www.systutorials.com/linux-kernels/132439/patch-rcu-batch-tuning-linux-2-6-16/
https://lwn.net/Articles/166647/

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 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  89faccfd35dde2cc1e2e2452ada0c978caaf4862
baseline version:
 xen  c759fb5bc303411e70322948a6ced81b6219ad3a

Last test of basis   128100  2018-09-26 09:00:41 Z1 days
Testing same since   128135  2018-09-27 11:00:42 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Christian Lindig 
  Daniel Kiper 
  Yang Qian 
  Yang Qian 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   c759fb5bc3..89faccfd35  89faccfd35dde2cc1e2e2452ada0c978caaf4862 -> smoke

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

[Xen-devel] [linux-4.9 test] 128095: tolerable FAIL - PUSHED

[osstest service owner]

flight 128095 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128095/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127931
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 127931
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 127931
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 127931
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 127931
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-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-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 14 saverestore-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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6ceccdf5ca9e8a41a581e059e9a98f17e14e99c4
baseline version:
 linux70915e25e1cff60c32e79e5b02e9559c1ed7bab2

Last test of basis   127931  2018-09-22 11:21:47 Z5 days
Testing same since   128095  2018-09-26 06:42:23 Z1 days1 attempts


People who touched revisions under test:
  Aaron Brown 
  Aaron Knister 
  Alan Stern 
  Alexander Duyck 
  Alexander Usyskin 
  Alexandre Belloni 
  Andreas Gruenbacher 
  Andreas Kemnade 
  Andy Gross 
  Andy Shevchenko 
  Anna Schumaker 
  Anton Vasilyev 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  

Re: [Xen-devel] null scheduler bug

[Milan Boberic]

Hi,
I applied patch and vwfi=native and everything works fine, I can
create and destroy guest domain as many times as I want.

I have to ask, will this patch have any impact on performance (I will
test it later, but I just need your opinions)?
And what this patch exactly do? I need to fully understand it because
I need to document it in my master thesis which will be finished soon
thanks to you people :D

Thank you for taking your time to make this patch, best regards!
On Thu, Sep 27, 2018 at 11:51 AM Dario Faggioli  wrote:
>
> On Tue, 2018-09-25 at 19:49 +0200, Dario Faggioli wrote:
> > [Adding a few people to the Cc-list. See below...]
> > On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote:
> > > On 09/25/2018 10:02 AM, Dario Faggioli wrote:
> > > > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> > > > >
> > My knowledge of RCU themselves would need refreshing, though. I
> > managed
> > to getbecome reasonably familiar with how the implementation we
> > imported works back then, when working on the said issue, but I guess
> > I
> > better go check the code again.
> >
> > I'm Cc-ing the people that have reviewed the patches and helping with
> > the idle timer problem, in case anyone has bright ideas out of the
> > top
> > of his head.
> >
> > Perhaps we should "just" get away from using RCU for domain
> > destruction
> > (but I'm just tossing the idea around, without much consideration
> > about
> > whether it's the right solution, or about how hard/feasible it really
> > is).
> >
> > Or maybe we can still use the timer, in some special way, if we have
> > wfi=native (or equivalent)...
> >
> So, I've had a look (but only a quick one).
>
> If we want to do something specific within the domain destruction path,
> we can add an rcu_barrier() there (I mean in domain_destroy()).
> However, that does not feel right either. Also, how can we be sure that
> the CPU never going through idle (as far as Xen knows, at least), isn't
> going to be problem for other RCU calls as well?
>
> Another thing that we can do is to act on the parameters that control
> the threshold which decides when a quiescent state is forced. This was
> basically what Julien was suggesting, but I still would avoid to do
> that always.
>
> So, basically, in this hackish patch attached, I added a new boot
> command line argument, called rcu_force_quiesc. If set to true,
> thresholds are set so that quiescence is always forced at each
> invocation of call_rcu(). And even if the new param is not explicitly
> specified, I do tweak the threshold when "wfi=native" is.
>
> Milan, can you apply this patch, add "wfi=native" again, and re-test?
> If it works, we'll decide what to do next.
>
> E.g., we can expose the RCU threshold via the appropriate set of boot
> time parameters --like Linux, from where this code comes, did/does--
> and document how they should be set, if one wants to use "wfi=native".
>
> Thanks and Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Software Engineer @ SUSE https://www.suse.com/

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

Re: [Xen-devel] [PATCH v11 9/9] mm / iommu: split need_iommu() into has_iommu_pt() and need_iommu_pt_sync()

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 25 September 2018 11:37
> To: Paul Durrant 
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Julien Grall ;
> Andrew Cooper ; Wei Liu ;
> George Dunlap ; Ian Jackson
> ; Jun Nakajima ; Kevin
> Tian ; Stefano Stabellini ;
> xen-devel ; Konrad Rzeszutek Wilk
> ; Tamas K Lengyel ; Tim
> (Xen.org) 
> Subject: Re: [PATCH v11 9/9] mm / iommu: split need_iommu() into
> has_iommu_pt() and need_iommu_pt_sync()
> 
> >>> On 21.09.18 at 12:56,  wrote:
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -783,7 +783,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr,
> hvm_load_mtrr_msr, 1,
> >
> >  void memory_type_changed(struct domain *d)
> >  {
> > -if ( need_iommu(d) && d->vcpu && d->vcpu[0] )
> > +if ( (has_iommu_pt(d) || iommu_use_hap_pt(d)) &&
> > + d->vcpu && d->vcpu[0] )
> >  {
> >  p2m_memory_type_changed(d);
> >  flush_all(FLUSH_CACHE);
> > @@ -831,7 +832,7 @@ int epte_get_entry_emt(struct domain *d, unsigned
> long gfn, mfn_t mfn,
> >  return MTRR_TYPE_UNCACHABLE;
> >  }
> >
> > -if ( !need_iommu(d) && !cache_flush_permitted(d) )
> > +if ( !has_iommu_pt(d) && !cache_flush_permitted(d) )
> >  {
> >  *ipat = 1;
> >  return MTRR_TYPE_WRBACK;
> 
> Considering how closely the two functions are related I'm struggling to
> understand why the conditions are no longer the inverse of one another.
> With iommu_use_hap_pt() including a has_iommu_pt() check I think the
> former can and should be simplified.

Ok.

> 
> > --- a/xen/arch/x86/x86_64/mm.c
> > +++ b/xen/arch/x86/x86_64/mm.c
> > @@ -1426,8 +1426,13 @@ int memory_add(unsigned long spfn, unsigned long
> epfn, unsigned int pxm)
> >  if ( ret )
> >  goto destroy_m2p;
> >
> > -if ( iommu_enabled && !iommu_hwdom_passthrough &&
> > - !need_iommu(hardware_domain) )
> > +/*
> > + * If hardware domain has IOMMU mappings but page tables are not
> > + * shared, and are not being kept in sync (which is the case when
> > + * in strict mode) then newly added memory needs to be mapped here.
> > + */
> > +if ( has_iommu_pt(hardware_domain) &&
> > + !iommu_use_hap_pt(hardware_domain) && !iommu_hwdom_strict )
> 
> iommu_use_hap_pt() includes a hap_enabled() check, but that is valid
> to be used on HVM domains only. It looks like there are other similar
> improper uses elsewhere - all new and pre-existing uses need auditing.
> 

Yes... I will check.

> > --- a/xen/drivers/passthrough/pci.c
> > +++ b/xen/drivers/passthrough/pci.c
> > @@ -1416,7 +1416,7 @@ static int assign_device(struct domain *d, u16
> seg, u8 bus, u8 devfn, u32 flag)
> >
> >  /* Prevent device assign if mem paging or mem sharing have been
> >   * enabled for this domain */
> > -if ( unlikely(!need_iommu(d) &&
> > +if ( unlikely(!has_iommu_pt(d) &&
> >  (d->arch.hvm.mem_sharing_enabled ||
> >   vm_event_check_ring(d->vm_event_paging) ||
> >   p2m_get_hostp2m(d)->global_logdirty)) )
> 
> This need_iommu() check looks rather unmotivated to me - wouldn't
> you better delete it instead of finding a suitable replacement?

Yes, it's not clear why need_iommu() is here. I can only guess it's to avoid 
re-checking the second clause once the domain has pagetables, but nothing in 
the second clause seems to be computationally expensive.

  Paul

> 
> Jan
> 


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

[Xen-devel] [PATCH] amd-iommu: get rid of pointless IOMMU_PAGING_MODE_LEVEL_X definitions

[Paul Durrant]

The levels are absolute numbers such that IOMMU_PAGING_MODE_LEVEL_X
evaluates to X (for the valid range of 0 - 7) so simply use numbers in
the code.

No functional change.

NOTE: This patch also adds emacs boilerplate to amd-iommu-defs.h

Signed-off-by: Paul Durrant 
---
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
---
 xen/drivers/passthrough/amd/iommu_map.c  | 26 +++---
 xen/drivers/passthrough/amd/pci_amd_iommu.c  |  4 +---
 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h | 21 +++--
 3 files changed, 23 insertions(+), 28 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 9fa5cd3bd3..ecd55d0573 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -40,7 +40,7 @@ void clear_iommu_pte_present(unsigned long l1_mfn, unsigned 
long gfn)
 u64 *table, *pte;
 
 table = map_domain_page(_mfn(l1_mfn));
-pte = table + pfn_to_pde_idx(gfn, IOMMU_PAGING_MODE_LEVEL_1);
+pte = table + pfn_to_pde_idx(gfn, 1);
 *pte = 0;
 unmap_domain_page(table);
 }
@@ -84,7 +84,7 @@ static bool_t set_iommu_pde_present(u32 *pde, unsigned long 
next_mfn,
 /* FC bit should be enabled in PTE, this helps to solve potential
  * issues with ATS devices
  */
-if ( next_level == IOMMU_PAGING_MODE_LEVEL_0 )
+if ( next_level == 0 )
 set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
  IOMMU_PTE_FC_MASK, IOMMU_PTE_FC_SHIFT, );
 pde[1] = entry;
@@ -116,8 +116,7 @@ static bool_t set_iommu_pte_present(unsigned long pt_mfn, 
unsigned long gfn,
 
 pde = (u32*)(table + pfn_to_pde_idx(gfn, pde_level));
 
-need_flush = set_iommu_pde_present(pde, next_mfn, 
-   IOMMU_PAGING_MODE_LEVEL_0, iw, ir);
+need_flush = set_iommu_pde_present(pde, next_mfn, 0, iw, ir);
 unmap_domain_page(table);
 return need_flush;
 }
@@ -419,8 +418,7 @@ static int iommu_merge_pages(struct domain *d, unsigned 
long pt_mfn,
 }
 
 /* setup super page mapping, next level = 0 */
-set_iommu_pde_present((u32*)pde, first_mfn,
-  IOMMU_PAGING_MODE_LEVEL_0,
+set_iommu_pde_present((u32*)pde, first_mfn, 0,
   !!(flags & IOMMUF_writable),
   !!(flags & IOMMUF_readable));
 
@@ -447,18 +445,17 @@ static int iommu_pde_from_gfn(struct domain *d, unsigned 
long pfn,
 table = hd->arch.root_table;
 level = hd->arch.paging_mode;
 
-BUG_ON( table == NULL || level < IOMMU_PAGING_MODE_LEVEL_1 || 
-level > IOMMU_PAGING_MODE_LEVEL_6 );
+BUG_ON( table == NULL || level < 1 || level > 6 );
 
 next_table_mfn = mfn_x(page_to_mfn(table));
 
-if ( level == IOMMU_PAGING_MODE_LEVEL_1 )
+if ( level == 1 )
 {
 pt_mfn[level] = next_table_mfn;
 return 0;
 }
 
-while ( level > IOMMU_PAGING_MODE_LEVEL_1 )
+while ( level > 1 )
 {
 unsigned int next_level = level - 1;
 pt_mfn[level] = next_table_mfn;
@@ -676,8 +673,7 @@ int amd_iommu_map_page(struct domain *d, unsigned long gfn, 
unsigned long mfn,
 }
 
 /* Install 4k mapping first */
-need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn, 
-   IOMMU_PAGING_MODE_LEVEL_1,
+need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn, 1,
!!(flags & IOMMUF_writable),
!!(flags & IOMMUF_readable));
 
@@ -690,8 +686,8 @@ int amd_iommu_map_page(struct domain *d, unsigned long gfn, 
unsigned long mfn,
 if ( is_hvm_domain(d) )
 amd_iommu_flush_pages(d, gfn, 0);
 
-for ( merge_level = IOMMU_PAGING_MODE_LEVEL_2;
-  merge_level <= hd->arch.paging_mode; merge_level++ )
+for ( merge_level = 2; merge_level <= hd->arch.paging_mode;
+  merge_level++ )
 {
 if ( pt_mfn[merge_level] == 0 )
 break;
@@ -808,7 +804,7 @@ void amd_iommu_share_p2m(struct domain *d)
 hd->arch.root_table = p2m_table;
 
 /* When sharing p2m with iommu, paging mode = 4 */
-hd->arch.paging_mode = IOMMU_PAGING_MODE_LEVEL_4;
+hd->arch.paging_mode = 4;
 AMD_IOMMU_DEBUG("Share p2m table with iommu: p2m table = %#lx\n",
 mfn_x(pgd_mfn));
 }
diff --git a/xen/drivers/passthrough/amd/pci_amd_iommu.c 
b/xen/drivers/passthrough/amd/pci_amd_iommu.c
index 80d9ae6561..030debb775 100644
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -240,9 +240,7 @@ static int amd_iommu_domain_init(struct domain *d)
 
 /* For pv and dom0, stick with get_paging_mode(max_page)
  * For HVM dom0, use 2 level page table at first */
-hd->arch.paging_mode = is_hvm_domain(d) ?
-  IOMMU_PAGING_MODE_LEVEL_2 :
-  get_paging_mode(max_page);
+

Re: [Xen-devel] [PATCH] x86/mwait-idle: Tweak reporting when MONITOR is not available

[Jan Beulich]

>>> On 27.09.18 at 13:12,  wrote:
> Currently, booting Xen as a PVH guest yields:
> 
>   (d10) (XEN) mwait-idle: does not run on family 6 model 60
> 
> which is inaccurate.
> 
> The problem is the lack of monitor, rather than the family/model.  Combine the
> two CPUID checks and skip the list search in the case that is is going to fail
> for feature reasons.
> 
> Signed-off-by: Andrew Cooper 

For the specific case here and at this point in time, the change is acceptable,
so feel free to use
Acked-by: Jan Beulich 
However,

> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -1113,17 +1113,17 @@ static void __init mwait_idle_state_table_update(void)
>  static int __init mwait_idle_probe(void)
>  {
>   unsigned int eax, ebx, ecx;
> - const struct x86_cpu_id *id = x86_match_cpu(intel_idle_ids);
> + const struct x86_cpu_id *id;
>  
> - if (!id) {
> + if (!cpu_has_monitor || boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
> + return -ENODEV;
> +
> + if (!(id = x86_match_cpu(intel_idle_ids))) {
>   pr_debug(PREFIX "does not run on family %d model %d\n",
>boot_cpu_data.x86, boot_cpu_data.x86_model);
>   return -ENODEV;
>   }

... the cpu_has_monitor check is (here) redundant with what intel_idle_ids[]
says, and in the more general case (including possibly here, going forward)
there might be entries in such a table with differing feature flag requests.
Therefore I would prefer if the redundancy was not introduced (also to
avoid others [blindly] cloning this code), and instead the log message be
made less misleading in the PVH case. The moving ahead of the CPUID level
check, otoh, is fine with me (but won't help your case at all afaict), since
new (future) feature dependencies are rather unlikely to be towards lower
levels.

Jan



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

Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

[Isaila Alexandru]

On Thu, 2018-09-27 at 12:25 +0100, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather
> where
> the fault originated.  The npfec.kind value is always valid, and
> should thus be propagated, regardless of whether gla_valid is set or
> not.
> 
> In particular, gla_valid will never be set on AMD systems; but
> npfec.kind will still be valid and should still be propagated.
> 
> Signed-off-by: Alexandru Isaila 
> Signed-off-by: George Dunlap 

Reviewed-by: Alexandru Isaila 


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

Re: [Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

[Andrew Cooper]

On 27/09/18 12:25, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated.  The npfec.kind value is always valid, and
> should thus be propagated, regardless of whether gla_valid is set or
> not.
>
> In particular, gla_valid will never be set on AMD systems; but
> npfec.kind will still be valid and should still be propagated.
>
> Signed-off-by: Alexandru Isaila 
> Signed-off-by: George Dunlap 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] mem_access: Fix npfec.kind propagation

[George Dunlap]

The name of the "with_gla" flag is confusing; it has nothing to do
with the existence or lack thereof of a faulting GLA, but rather where
the fault originated.  The npfec.kind value is always valid, and
should thus be propagated, regardless of whether gla_valid is set or
not.

In particular, gla_valid will never be set on AMD systems; but
npfec.kind will still be valid and should still be propagated.

Signed-off-by: Alexandru Isaila 
Signed-off-by: George Dunlap 
---
Changes since RFC:
- Use switch() rather than a series of if's
- Adjust spacing

CC: Andrew Cooper 
CC: Jan Beulich 
CC: Tim Deegan 
CC: Tamas K Lengyel 
CC: Razvan Cojocaru 
---
 xen/arch/x86/mm/mem_access.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index d9e64fcbb9..99232045a9 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -228,16 +228,24 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 req->reason = VM_EVENT_REASON_MEM_ACCESS;
 req->u.mem_access.gfn = gfn_x(gfn);
 req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
+
 if ( npfec.gla_valid )
 {
 req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
 req->u.mem_access.gla = gla;
+}
 
-if ( npfec.kind == npfec_kind_with_gla )
-req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
-else if ( npfec.kind == npfec_kind_in_gpt )
-req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
+switch ( npfec.kind )
+{
+case npfec_kind_with_gla:
+req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
+break;
+case npfec_kind_in_gpt:
+req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
+default:
+break;
 }
+
 req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
 req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
 req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
-- 
2.19.0


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

[Xen-devel] [PATCH] x86/mwait-idle: Tweak reporting when MONITOR is not available

[Andrew Cooper]

Currently, booting Xen as a PVH guest yields:

  (d10) (XEN) mwait-idle: does not run on family 6 model 60

which is inaccurate.

The problem is the lack of monitor, rather than the family/model.  Combine the
two CPUID checks and skip the list search in the case that is is going to fail
for feature reasons.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/cpu/mwait-idle.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 77fc3dd..e3b5334 100644
--- a/xen/arch/x86/cpu/mwait-idle.c
+++ b/xen/arch/x86/cpu/mwait-idle.c
@@ -1113,17 +1113,17 @@ static void __init mwait_idle_state_table_update(void)
 static int __init mwait_idle_probe(void)
 {
unsigned int eax, ebx, ecx;
-   const struct x86_cpu_id *id = x86_match_cpu(intel_idle_ids);
+   const struct x86_cpu_id *id;
 
-   if (!id) {
+   if (!cpu_has_monitor || boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
+   return -ENODEV;
+
+   if (!(id = x86_match_cpu(intel_idle_ids))) {
pr_debug(PREFIX "does not run on family %d model %d\n",
 boot_cpu_data.x86, boot_cpu_data.x86_model);
return -ENODEV;
}
 
-   if (boot_cpu_data.cpuid_level < CPUID_MWAIT_LEAF)
-   return -ENODEV;
-
cpuid(CPUID_MWAIT_LEAF, , , , _substates);
 
if (!(ecx & CPUID5_ECX_EXTENSIONS_SUPPORTED) ||
-- 
2.1.4


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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Juergen Gross]

On 27/09/2018 12:35, Omkar Bolla wrote:
> Hi,
> 
> Sorry, I forgot, I used code from github chapter [2] from that link, and
> I just changed name "mydevice"  to "vdevb"

Okay.

> 
>> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
>> are not sufficient to write the needed entries.
> Where I have to provide access rights, i.e from Kernel code or from from
> command line in domain-0 or modify in xen source?

I guess you have your frontend already loaded when running the
script creating the Xenstore entries?

This would explain the problem: as soon as the entries are written
the frontend will react. At this point the access rights are not setup
properly, this is done a little bit later in the script.

Possible solutions are to either load the frontend driver only after
setting up the Xenstore entries, or to pause the domain while doing
so and unpause it afterwards (or start the domain paused, create the
Xenstore entries, and unpause the domain).

The really correct way to do it would be to setup Xenstore in a single
transaction (write all the entries and set access rights).

> Any thing that I have to do/change in xenbits xen-4.8 sources code, to
> add new PV device?

Only if you want to include domain config file entries for your device.

> 
>> Did you modify Xen tools (xl/libxl) for adding the new device type?
> No, is it needed to modify some thing in xl/libxl for adding new device
> type?

This was just a question to learn how Xenstore is being initialized
in your scenario.

> 
>> If not you need to setup the Xenstore nodes manually.
> Setup manually Xenstore means, using commands?

Yes, like your script does.


Juergen

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

Re: [Xen-devel] IOREQ server on Arm

[Julien Grall]

Hi Paul,

Thank you for your help understanding the resource code.

On 09/27/2018 11:46 AM, Paul Durrant wrote:

If the DM domain is not PV then currently it must be the hardware domain to be 
able to map resources. Hence we trust it not to descrease_reservation IOREQ 
pages.


Can you point me to check in the code? The only check I found is:

!(xmar.flags & XENMEM_rsrc_acq_caller_owned) && !is_hardware_domain(d)

But this is still allowing to map some of the resources in a DM domain.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

[Paul Durrant]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 27 September 2018 11:38
> To: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Cc: Isaila Alexandru ; Jan Beulich
> ; Tim (Xen.org) ; Tamas K Lengyel
> ; Paul Durrant ;
> Razvan Cojocaru ; Suravee Suthikulpanit
> ; Brian Woods ; Boris
> Ostrovsky 
> Subject: Re: [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT
> 
> On 09/26/2018 06:22 PM, Andrew Cooper wrote:
> > On 26/09/18 17:47, George Dunlap wrote:
> >> From: Isaila Alexandru 
> >>
> >> This patch adds access control for NPT mode.
> >>
> >> There aren’t enough extra bits to store the access rights in the NPT
> p2m
> >> table, so we add a radix tree to store extra information.
> >
> > I'm sorry to re-open this argument, but why?
> >
> > ISTR there being some argument based on pagetable sharing with the
> > IOMMU, but that doesn't work at the moment and can't reasonably be made
> > to work.  For one, attempting to use pt sharing will break as soon as
> > you try and DMA to a mapped grant.
> >
> > I'm disinclined to let a broken vestigial feature get in the way of real
> > improvements.
> >
> > Beyond that, an NPT PTE has basically the same number of software
> > available bits as an EPT PTE.
> >
> > Am I missing anything?
> 
> Wow -- looks like IOMMU/p2m sharing has been disabled unconditionally
> since 2014.  If nobody has complained since then, that seems like a good
> enough reason to me to rip it out.
> 
> Suravee / Brian / Boris -- any opinions?
> 
> The main reason to go with the 'extra bits' solution rather than the
> 'rip out iommu/p2m sharing' solution is because people have been
> prognosticating for years that we would be running out of bits and need
> more at some point in the future.  I thought Paul, for instance, might
> have a use for the extra bits.  But I'm happy to wait until such time as
> we need it and then fish this patch out of the mail archives.
> 

The main angle I had was to have a more generic page-to-type mapping such that 
it would be suitable to allow steering of accesses to certain pages to distinct 
IOREQ servers.

  Paul

>  -George
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] IOREQ server on Arm

[Paul Durrant]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 27 September 2018 11:31
> To: Paul Durrant ; 'Jan Beulich'
> 
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel 
> Subject: Re: IOREQ server on Arm
> 
> Hi Paul,
> 
> On 09/27/2018 11:16 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Julien Grall [mailto:julien.gr...@arm.com]
> >> Sent: 27 September 2018 10:42
> >> To: Paul Durrant ; 'Jan Beulich'
> >> 
> >> Cc: Andrew Cooper ; Roger Pau Monne
> >> ; Stefano Stabellini ;
> xen-
> >> devel 
> >> Subject: Re: IOREQ server on Arm
> >>
> >> Hi Paul,
> >>
> >> On 09/27/2018 09:38 AM, Paul Durrant wrote:
>  -Original Message-
>  From: Julien Grall [mailto:julien.gr...@arm.com]
>  Sent: 26 September 2018 22:32
>  To: Paul Durrant ; 'Jan Beulich'
>  
>  Cc: Andrew Cooper ; Roger Pau Monne
>  ; Stefano Stabellini ;
> >> xen-
>  devel 
>  Subject: Re: IOREQ server on Arm
> 
>  Hi Paul,
> 
>  On 09/26/2018 01:01 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 26 September 2018 12:57
> >> To: Paul Durrant 
> >> Cc: Julien Grall ; Andrew Cooper
> >> ; Roger Pau Monne
> ;
> >> Stefano Stabellini ; xen-devel  >> de...@lists.xenproject.org>
> >> Subject: RE: IOREQ server on Arm
> >>
> > On 26.09.18 at 13:02,  wrote:
> >>> --- a/xen/common/memory.c
> >>> +++ b/xen/common/memory.c
> >>> @@ -1105,8 +1105,11 @@ static int acquire_resource(
> >>>
> >>> for ( i = 0; !rc && i < xmar.nr_frames; i++ )
> >>> {
> >>> -rc = set_foreign_p2m_entry(currd, gfn_list[i],
> >>> -   _mfn(mfn_list[i]));
> >>> +rc = (xmar.flags & XENMEM_rsrc_acq_caller_owned) ?
> >>> +guest_physmap_add_entry(currd, gfn_list[i],
> >>> +_mfn(mfn_list[i]), 0,
> >> p2m_ram_rw) :
> >>> +set_foreign_p2m_entry(currd, gfn_list[i],
> >>> +  _mfn(mfn_list[i]));
> >>> /* rc should be -EIO for any iteration other than
> the
>  first
> >> */
> >>> if ( rc && i )
> >>> rc = -EIO;
> >>>
> >>> But the guest_physmap_add_entry() is problematic as it will IOMMU
> >> map
> >> pages
> >>> as well, which is probably not wanted.
> >>
> >> Yeah, I'd prefer if we avoided establishing IOMMU mappings here.
> >> How about transforming set_foreign_p2m_entry() into
> >> set_special_p2m_entry(), with a type passed in?
> >>
> >
> > That sounds like it might work.
> >
> > Julien, do you want page types to distinguish caller-owned resources
>  from normal RAM are you ok with p2m_ram_rw even though it could be
> >> subject
>  of another domain's foreign map?
> 
>  Based on your previous e-mail, I would be fine with that on Arm.
> 
>  This brings me to the next question. Do you expect
> >> set_special_p2m_entry
>  to take a reference on the page?
> 
>  If not, we may run into some troubles because AFAICT you can map
> twice
>  the ioreq page in a guest but reference will only be taken on the
>  allocation.
> 
>  However, the unmap path will always drop a reference when removing
> the
>  page. This is because Xen at the moment, reference will not be taken
> on
>  mapping but allocation (we assume a page could not be mapped twice in
> a
>  guest).
> 
>  Foreign mapping on Arm are a bit special because we get a reference
> on
>  mapping them and will drop it when the mapping disappear. So we would
>  not have any problem there.
> 
>  Any thoughts?
> >>>
> >>> Well, as Jan says, on x86 we don't reference count in the P2M so
> >> multiple mappings should not be an issue AFAICT.
> >>
> >> I understand that you don't have reference count in the P2M (that's the
> >> same on Arm today except for foreign mapping). But I think I can list
> at
> >> least 2 major issues with the design today. Let me give an example
> based
> >> on my understanding.
> >>
> >> 1. DM requests to map the IOREQ page
> >>a) page allocated (one reference)
> >>b) get reference (will be dropped when the IOREQ server is
> >> destroyed)
> >>
> >> 2. DM requests to map the IOREQ page (second time)
> >>No reference taken
> >>
> >> 3. DM unmap the IOREQ page
> >> 4. DM unmap the IOREQ page
> >>
> >> AFAIU, 3. 4. would be done through XENMEM_remove_from_physmap. So no
> >> reference dropped there. While the reference 1.b) will be dropped in
> >> hvm_free_ioreq_mfn. AFAICT 1.a) would be kept until the domain die.
> This
> >> would result to Xen memory exhaustion in long term. Did I miss
> anything?
> >>
> 

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

[George Dunlap]

On 09/26/2018 06:22 PM, Andrew Cooper wrote:
> On 26/09/18 17:47, George Dunlap wrote:
>> From: Isaila Alexandru 
>>
>> This patch adds access control for NPT mode.
>>
>> There aren’t enough extra bits to store the access rights in the NPT p2m
>> table, so we add a radix tree to store extra information.
> 
> I'm sorry to re-open this argument, but why?
> 
> ISTR there being some argument based on pagetable sharing with the
> IOMMU, but that doesn't work at the moment and can't reasonably be made
> to work.  For one, attempting to use pt sharing will break as soon as
> you try and DMA to a mapped grant.
> 
> I'm disinclined to let a broken vestigial feature get in the way of real
> improvements.
> 
> Beyond that, an NPT PTE has basically the same number of software
> available bits as an EPT PTE.
> 
> Am I missing anything?

Wow -- looks like IOMMU/p2m sharing has been disabled unconditionally
since 2014.  If nobody has complained since then, that seems like a good
enough reason to me to rip it out.

Suravee / Brian / Boris -- any opinions?

The main reason to go with the 'extra bits' solution rather than the
'rip out iommu/p2m sharing' solution is because people have been
prognosticating for years that we would be running out of bits and need
more at some point in the future.  I thought Paul, for instance, might
have a use for the extra bits.  But I'm happy to wait until such time as
we need it and then fish this patch out of the mail archives.

 -George

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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Omkar Bolla]

Hi,

Sorry, I forgot, I used code from github chapter [2] from that link, and
I just changed name "mydevice"  to "vdevb"

> Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> are not sufficient to write the needed entries.
Where I have to provide access rights, i.e from Kernel code or from from
command line in domain-0 or modify in xen source?
Any thing that I have to do/change in xenbits xen-4.8 sources code, to add
new PV device?

> Did you modify Xen tools (xl/libxl) for adding the new device type?
No, is it needed to modify some thing in xl/libxl for adding new device
type?

> If not you need to setup the Xenstore nodes manually.
Setup manually Xenstore means, using commands?

Thanks,
Omkar B




On Thu, Sep 27, 2018 at 3:50 PM Oleksandr Andrushchenko <
oleksandr_andrushche...@epam.com> wrote:

> On 09/27/2018 01:16 PM, Juergen Gross wrote:
> > On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:
> >> Hi,
> >> On 09/27/2018 12:39 PM, Lars Kurth wrote:
> >>> Adding a few people who have recently been working on PV drivers, as
> >>> well as Julien
> >>> Lars
> >>>
>  On 27 Sep 2018, at 06:44, Omkar Bolla
>    > wrote:
> 
>  Hi,
> 
>  I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
>  platform(ARMv8) and using Xen-4.8 stable release. Here I want to
>  create a PV frontend and backend to share memory between Domain-0 and
>  Domain-U.
> 
> 
> 
>  I used below link to create frontend and backend,
>  https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
> >> The link above has another link to github [1] with 2 chapters. And it
> >> looks like you have
> >> already modified the sources ("mydevice" -> "vdevb" at least).
> >> So, what are the sources you are using?
> >>
> >> You could probably take a look at the relatively small vkbd frontend
> >> driver [2]
> >> to get some hints.
>  But I am facing below errors while adding device vdevb to xenstore.
>  Below errors I am getting from xenbus_switch_state().
>  vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
>  writing new state)
> > Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
> > are not sufficient to write the needed entries.
> >
> > Did you modify Xen tools (xl/libxl) for adding the new device type?
> > If not you need to setup the Xenstore nodes manually.
> There is a script [1] which comes with the example implementation,
> so I believe Omkar uses it with "mydevice" -> "vdevb" change
> >
> >
> > Juergen
> [1]
>
> https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh
>

-- 






This
message contains confidential information and is intended only 
for the
individual(s) named. If you are not the intended
recipient, you are 
notified that disclosing, copying, distributing or taking any
action in 
reliance on the contents of this mail and attached file/s is strictly

prohibited. Please notify the
sender immediately and delete this e-mail 
from your system. E-mail transmission
cannot be guaranteed to be secured or 
error-free as information could be
intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain
viruses. The sender therefore does 
not accept liability for any errors or
omissions in the contents of this 
message, which arise as a result of e-mail
transmission.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Julien Grall]

Hi,

On 09/27/2018 11:20 AM, Oleksandr Andrushchenko wrote:

On 09/27/2018 01:16 PM, Juergen Gross wrote:

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:

Adding a few people who have recently been working on PV drivers, as
well as Julien
Lars


On 27 Sep 2018, at 06:44, Omkar Bolla
mailto:omkar.bo...@pathpartnertech.com>> wrote:

Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
platform(ARMv8) and using Xen-4.8 stable release. Here I want to
create a PV frontend and backend to share memory between Domain-0 and
Domain-U.


Do you need to share the buffer dynamically? If not, you may want to 
have a look at "Allow setting up shared memory areas between VMs from xl 
config files" [2]. We aim to merge it in the next Xen release.


Cheers,

[2] https://lists.xen.org/archives/html/xen-devel/2018-08/msg00883.html

--
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH v3] ts-xen-build-prep: install libgnutls28-dev for libvirt build

[Ian Jackson]

Wei Liu writes ("[OSSTEST PATCH v3] ts-xen-build-prep: install libgnutls28-dev 
for libvirt build"):
> d54ecf31b2 placed the build dependency in a wrong file. This patch
> adds the dependency to the right file. Add a runtime dependency in
> libvirt.pm.

Thanks, acked again and pushed.  Let's see how it goes this time...
Also, I did a tiny style change (as a separate
commit).

Ian.

From ad7f0784d0cc057e0826ff6a6a1142067f8e3da5 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Thu, 27 Sep 2018 11:29:23 +0100
Subject: [OSSTEST PATCH] libvirt.pm: Drop some unneeded parens (no functional
 change0

Signed-off-by: Ian Jackson 
---
 Osstest/Toolstack/libvirt.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 7ebeaf66..e817f5b4 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -30,8 +30,8 @@ sub new {
 my $nl_lib = "libnl-3-200";
 my $libgnutls = "libgnutls30";
 
-$nl_lib = "libnl1" if ($ho->{Suite} =~ m/wheezy/);
-$libgnutls = "libgnutls-deb0-28" if ($ho->{Suite} =~ m/jessie/);
+$nl_lib = "libnl1" if $ho->{Suite} =~ m/wheezy/;
+$libgnutls = "libgnutls-deb0-28" if $ho->{Suite} =~ m/jessie/;
 push(@extra_packages, $nl_lib);
 push(@extra_packages, $libgnutls);
 return bless { Name => "libvirt",
-- 
2.11.0


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

Re: [Xen-devel] IOREQ server on Arm

[Julien Grall]

Hi Paul,

On 09/27/2018 11:16 AM, Paul Durrant wrote:

-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 27 September 2018 10:42
To: Paul Durrant ; 'Jan Beulich'

Cc: Andrew Cooper ; Roger Pau Monne
; Stefano Stabellini ; xen-
devel 
Subject: Re: IOREQ server on Arm

Hi Paul,

On 09/27/2018 09:38 AM, Paul Durrant wrote:

-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 26 September 2018 22:32
To: Paul Durrant ; 'Jan Beulich'

Cc: Andrew Cooper ; Roger Pau Monne
; Stefano Stabellini ;

xen-

devel 
Subject: Re: IOREQ server on Arm

Hi Paul,

On 09/26/2018 01:01 PM, Paul Durrant wrote:

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 26 September 2018 12:57
To: Paul Durrant 
Cc: Julien Grall ; Andrew Cooper
; Roger Pau Monne ;
Stefano Stabellini ; xen-devel 
Subject: RE: IOREQ server on Arm


On 26.09.18 at 13:02,  wrote:

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1105,8 +1105,11 @@ static int acquire_resource(

for ( i = 0; !rc && i < xmar.nr_frames; i++ )
{
-rc = set_foreign_p2m_entry(currd, gfn_list[i],
-   _mfn(mfn_list[i]));
+rc = (xmar.flags & XENMEM_rsrc_acq_caller_owned) ?
+guest_physmap_add_entry(currd, gfn_list[i],
+_mfn(mfn_list[i]), 0,

p2m_ram_rw) :

+set_foreign_p2m_entry(currd, gfn_list[i],
+  _mfn(mfn_list[i]));
/* rc should be -EIO for any iteration other than the

first

*/

if ( rc && i )
rc = -EIO;

But the guest_physmap_add_entry() is problematic as it will IOMMU

map

pages

as well, which is probably not wanted.


Yeah, I'd prefer if we avoided establishing IOMMU mappings here.
How about transforming set_foreign_p2m_entry() into
set_special_p2m_entry(), with a type passed in?



That sounds like it might work.

Julien, do you want page types to distinguish caller-owned resources

from normal RAM are you ok with p2m_ram_rw even though it could be

subject

of another domain's foreign map?

Based on your previous e-mail, I would be fine with that on Arm.

This brings me to the next question. Do you expect

set_special_p2m_entry

to take a reference on the page?

If not, we may run into some troubles because AFAICT you can map twice
the ioreq page in a guest but reference will only be taken on the
allocation.

However, the unmap path will always drop a reference when removing the
page. This is because Xen at the moment, reference will not be taken on
mapping but allocation (we assume a page could not be mapped twice in a
guest).

Foreign mapping on Arm are a bit special because we get a reference on
mapping them and will drop it when the mapping disappear. So we would
not have any problem there.

Any thoughts?


Well, as Jan says, on x86 we don't reference count in the P2M so

multiple mappings should not be an issue AFAICT.

I understand that you don't have reference count in the P2M (that's the
same on Arm today except for foreign mapping). But I think I can list at
least 2 major issues with the design today. Let me give an example based
on my understanding.

1. DM requests to map the IOREQ page
a) page allocated (one reference)
b) get reference (will be dropped when the IOREQ server is
destroyed)

2. DM requests to map the IOREQ page (second time)
No reference taken

3. DM unmap the IOREQ page
4. DM unmap the IOREQ page

AFAIU, 3. 4. would be done through XENMEM_remove_from_physmap. So no
reference dropped there. While the reference 1.b) will be dropped in
hvm_free_ioreq_mfn. AFAICT 1.a) would be kept until the domain die. This
would result to Xen memory exhaustion in long term. Did I miss anything?



1.a) would be kept until the IOREQ server is destroyed, which will happen 
either at domain destruction *or* when the DM destroys it.


Argh, I mixed get_page_type and get_page(). Sorry for the noise.




But, I think there are another way for badly written guest to remove the
page. It looks like you can use XENMEM_decrease_reservation as the page
belongs to the guest. So a reference would be dropped by 3. and 4.



How so? The pages don't belong to the guest; they belong the the DM domain. 
They never appear in guest P2M so how can the guest decrease_reservation them? 
Are you worried about the DM domain doing a decrease reservation?


By guest I meant DM domain.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

[Daniel Kiper]

On Thu, Sep 27, 2018 at 11:19:24AM +0100, Andrew Cooper wrote:
> On 27/09/18 11:10, Daniel Kiper wrote:
> > On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote:
> >> On 27/09/18 11:05, Daniel Kiper wrote:
> >>> Commit 9589927 (x86/mb2: avoid Xen image when looking for
> >>> module/crashkernel position) fixed relocation issues for
> >>> Multiboot2 protocol. Unfortunately it missed to allocate
> >>> module slot for Xen image placement in early boot path.
> >>> So, let's fix it right now.
> >>>
> >>> Reported-by: Wei Liu 
> >>> Signed-off-by: Daniel Kiper 
> >> Acked-by: Andrew Cooper 
> > Wow!!! The quickest review which I have got ever! Less than 2 mins... :-)))
>
> Obvious patch is obvious.  No point letting it languish.

Yep, though even in that case it counts...

Daniel

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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Oleksandr Andrushchenko]

On 09/27/2018 01:16 PM, Juergen Gross wrote:

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:

Adding a few people who have recently been working on PV drivers, as
well as Julien
Lars


On 27 Sep 2018, at 06:44, Omkar Bolla
mailto:omkar.bo...@pathpartnertech.com>> wrote:

Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
platform(ARMv8) and using Xen-4.8 stable release. Here I want to
create a PV frontend and backend to share memory between Domain-0 and
Domain-U.



I used below link to create frontend and backend,
https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/

The link above has another link to github [1] with 2 chapters. And it
looks like you have
already modified the sources ("mydevice" -> "vdevb" at least).
So, what are the sources you are using?

You could probably take a look at the relatively small vkbd frontend
driver [2]
to get some hints.

But I am facing below errors while adding device vdevb to xenstore.
Below errors I am getting from xenbus_switch_state().
vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
writing new state)

Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
are not sufficient to write the needed entries.

Did you modify Xen tools (xl/libxl) for adding the new device type?
If not you need to setup the Xenstore nodes manually.

There is a script [1] which comes with the example implementation,
so I believe Omkar uses it with "mydevice" -> "vdevb" change



Juergen
[1] 
https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh


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

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

[Andrew Cooper]

On 27/09/18 11:10, Daniel Kiper wrote:
> On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote:
>> On 27/09/18 11:05, Daniel Kiper wrote:
>>> Commit 9589927 (x86/mb2: avoid Xen image when looking for
>>> module/crashkernel position) fixed relocation issues for
>>> Multiboot2 protocol. Unfortunately it missed to allocate
>>> module slot for Xen image placement in early boot path.
>>> So, let's fix it right now.
>>>
>>> Reported-by: Wei Liu 
>>> Signed-off-by: Daniel Kiper 
>> Acked-by: Andrew Cooper 
> Wow!!! The quickest review which I have got ever! Less than 2 mins... :-)))

Obvious patch is obvious.  No point letting it languish.

~Andrew

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

Re: [Xen-devel] [Xen-users] XSM/Flask iomem

[George Dunlap]

[Moving to xen-devel]

Daniel,

Any comments on this one?

 -George
On Wed, Sep 26, 2018 at 12:41 PM  wrote:
>
> Hi,
>
> I just noticed from a bad behaviour of my installation and the 
> security_iterate_iomem_sids
> function that the iomem ranges have to be sorted in the device_contexts file.
> The flask load policy takes iomem ranges declaration as it comes but the sid 
> attribution
> and check function expects the list of iomem ocontexts to be sorted.
> My file didn't comply with this statement which ended to use the default 
> iomem sid instead
> of computing one before checking the permission.
>
> This doesn't seem to be documented anywhere in the xen release 4.11.0.
>
> Thanks.
>
> Nicolas
> 1
>
>
> ___
> Xen-users mailing list
> xen-us...@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-users

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

Re: [Xen-devel] IOREQ server on Arm

[Paul Durrant]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 27 September 2018 10:42
> To: Paul Durrant ; 'Jan Beulich'
> 
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel 
> Subject: Re: IOREQ server on Arm
> 
> Hi Paul,
> 
> On 09/27/2018 09:38 AM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Julien Grall [mailto:julien.gr...@arm.com]
> >> Sent: 26 September 2018 22:32
> >> To: Paul Durrant ; 'Jan Beulich'
> >> 
> >> Cc: Andrew Cooper ; Roger Pau Monne
> >> ; Stefano Stabellini ;
> xen-
> >> devel 
> >> Subject: Re: IOREQ server on Arm
> >>
> >> Hi Paul,
> >>
> >> On 09/26/2018 01:01 PM, Paul Durrant wrote:
>  -Original Message-
>  From: Jan Beulich [mailto:jbeul...@suse.com]
>  Sent: 26 September 2018 12:57
>  To: Paul Durrant 
>  Cc: Julien Grall ; Andrew Cooper
>  ; Roger Pau Monne ;
>  Stefano Stabellini ; xen-devel   de...@lists.xenproject.org>
>  Subject: RE: IOREQ server on Arm
> 
> >>> On 26.09.18 at 13:02,  wrote:
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -1105,8 +1105,11 @@ static int acquire_resource(
> >
> >for ( i = 0; !rc && i < xmar.nr_frames; i++ )
> >{
> > -rc = set_foreign_p2m_entry(currd, gfn_list[i],
> > -   _mfn(mfn_list[i]));
> > +rc = (xmar.flags & XENMEM_rsrc_acq_caller_owned) ?
> > +guest_physmap_add_entry(currd, gfn_list[i],
> > +_mfn(mfn_list[i]), 0,
>  p2m_ram_rw) :
> > +set_foreign_p2m_entry(currd, gfn_list[i],
> > +  _mfn(mfn_list[i]));
> >/* rc should be -EIO for any iteration other than the
> >> first
>  */
> >if ( rc && i )
> >rc = -EIO;
> >
> > But the guest_physmap_add_entry() is problematic as it will IOMMU
> map
>  pages
> > as well, which is probably not wanted.
> 
>  Yeah, I'd prefer if we avoided establishing IOMMU mappings here.
>  How about transforming set_foreign_p2m_entry() into
>  set_special_p2m_entry(), with a type passed in?
> 
> >>>
> >>> That sounds like it might work.
> >>>
> >>> Julien, do you want page types to distinguish caller-owned resources
> >> from normal RAM are you ok with p2m_ram_rw even though it could be
> subject
> >> of another domain's foreign map?
> >>
> >> Based on your previous e-mail, I would be fine with that on Arm.
> >>
> >> This brings me to the next question. Do you expect
> set_special_p2m_entry
> >> to take a reference on the page?
> >>
> >> If not, we may run into some troubles because AFAICT you can map twice
> >> the ioreq page in a guest but reference will only be taken on the
> >> allocation.
> >>
> >> However, the unmap path will always drop a reference when removing the
> >> page. This is because Xen at the moment, reference will not be taken on
> >> mapping but allocation (we assume a page could not be mapped twice in a
> >> guest).
> >>
> >> Foreign mapping on Arm are a bit special because we get a reference on
> >> mapping them and will drop it when the mapping disappear. So we would
> >> not have any problem there.
> >>
> >> Any thoughts?
> >
> > Well, as Jan says, on x86 we don't reference count in the P2M so
> multiple mappings should not be an issue AFAICT.
> 
> I understand that you don't have reference count in the P2M (that's the
> same on Arm today except for foreign mapping). But I think I can list at
> least 2 major issues with the design today. Let me give an example based
> on my understanding.
> 
>1. DM requests to map the IOREQ page
>   a) page allocated (one reference)
>   b) get reference (will be dropped when the IOREQ server is
> destroyed)
> 
>2. DM requests to map the IOREQ page (second time)
>   No reference taken
> 
>3. DM unmap the IOREQ page
>4. DM unmap the IOREQ page
> 
> AFAIU, 3. 4. would be done through XENMEM_remove_from_physmap. So no
> reference dropped there. While the reference 1.b) will be dropped in
> hvm_free_ioreq_mfn. AFAICT 1.a) would be kept until the domain die. This
> would result to Xen memory exhaustion in long term. Did I miss anything?
> 

1.a) would be kept until the IOREQ server is destroyed, which will happen 
either at domain destruction *or* when the DM destroys it.

> But, I think there are another way for badly written guest to remove the
> page. It looks like you can use XENMEM_decrease_reservation as the page
> belongs to the guest. So a reference would be dropped by 3. and 4.
> 

How so? The pages don't belong to the guest; they belong the the DM domain. 
They never appear in guest P2M so how can the guest decrease_reservation them? 
Are you worried about the DM domain doing a decrease reservation?

  Paul

> While 3. will drop the 

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Juergen Gross]

On 27/09/2018 12:07, Oleksandr Andrushchenko wrote:
> Hi,
> On 09/27/2018 12:39 PM, Lars Kurth wrote:
>> Adding a few people who have recently been working on PV drivers, as
>> well as Julien
>> Lars
>>
>>> On 27 Sep 2018, at 06:44, Omkar Bolla
>>> >> > wrote:
>>>
>>> Hi,
>>>
>>> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960
>>> platform(ARMv8) and using Xen-4.8 stable release. Here I want to
>>> create a PV frontend and backend to share memory between Domain-0 and
>>> Domain-U.
>>>
>>>
>>>
>>> I used below link to create frontend and backend,
>>> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
> The link above has another link to github [1] with 2 chapters. And it
> looks like you have
> already modified the sources ("mydevice" -> "vdevb" at least).
> So, what are the sources you are using?
> 
> You could probably take a look at the relatively small vkbd frontend
> driver [2]
> to get some hints.
>>>
>>> But I am facing below errors while adding device vdevb to xenstore.
>>> Below errors I am getting from xenbus_switch_state().
>>> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13
>>> writing new state)

Error 13 is EACCESS. I guess the access rights of the Xenstore nodes
are not sufficient to write the needed entries.

Did you modify Xen tools (xl/libxl) for adding the new device type?
If not you need to setup the Xenstore nodes manually.


Juergen

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

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

[Christian Lindig]

> On 27 Sep 2018, at 11:15, Andrew Cooper  wrote:
> 
> On 27/09/18 11:11, Christian Lindig wrote:
>> 
>>> On 27 Sep 2018, at 09:59, Andrew Cooper  wrote:
>>> 
>>> On 27/09/18 08:53, Yang Qian wrote:
 1. Add a common bind virq function
 2. Reduce the stub code of `bind_dom_exc_virq`
 
 Signed-off-by: Yang Qian 
>>> CC'ing the relevant maintainers.
>>> 
>>> Reviewed-by: Andrew Cooper  (forwarding my
>>> internal review of this patch)
>> There is a discussion about caml_{leave,enter}_blocking_section required for 
>> this to work in a thread context that is not yet addressed in the patch.
> 
> Right, but that is just a performance issue is it not?  We hold the GC
> lock longer than we need to.
> 
> i.e. AFACIT, that is a good followup patch, but doesn't invalidate this one?
> 
> ~Andrew

You are correct. It does not invalidate this patch.

— Christian
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

[Andrew Cooper]

On 27/09/18 11:11, Christian Lindig wrote:
>
>> On 27 Sep 2018, at 09:59, Andrew Cooper  wrote:
>>
>> On 27/09/18 08:53, Yang Qian wrote:
>>> 1. Add a common bind virq function
>>> 2. Reduce the stub code of `bind_dom_exc_virq`
>>>
>>> Signed-off-by: Yang Qian 
>> CC'ing the relevant maintainers.
>>
>> Reviewed-by: Andrew Cooper  (forwarding my
>> internal review of this patch)
> There is a discussion about caml_{leave,enter}_blocking_section required for 
> this to work in a thread context that is not yet addressed in the patch.

Right, but that is just a performance issue is it not?  We hold the GC
lock longer than we need to.

i.e. AFACIT, that is a good followup patch, but doesn't invalidate this one?

~Andrew

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

[Xen-devel] [distros-debian-wheezy test] 75301: trouble: blocked/broken

[Platform Team regression test user]

flight 75301 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/75301/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 build-armhf   4 host-install(4)  broken like 75255
 build-armhf-pvops 4 host-install(4)  broken like 75255
 build-amd64-pvops 4 host-install(4)  broken like 75255
 build-amd64   4 host-install(4)  broken like 75255
 build-i3864 host-install(4)  broken like 75255
 build-i386-pvops  4 host-install(4)  broken like 75255

baseline version:
 flight   75255

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



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.xensource.com/osstest/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

[Christian Lindig]

> On 27 Sep 2018, at 09:59, Andrew Cooper  wrote:
> 
> On 27/09/18 08:53, Yang Qian wrote:
>> 1. Add a common bind virq function
>> 2. Reduce the stub code of `bind_dom_exc_virq`
>> 
>> Signed-off-by: Yang Qian 
> 
> CC'ing the relevant maintainers.
> 
> Reviewed-by: Andrew Cooper  (forwarding my
> internal review of this patch)

There is a discussion about caml_{leave,enter}_blocking_section required for 
this to work in a thread context that is not yet addressed in the patch.

Acked-by: Christian Lindig 
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

[Daniel Kiper]

On Thu, Sep 27, 2018 at 11:06:24AM +0100, Andrew Cooper wrote:
> On 27/09/18 11:05, Daniel Kiper wrote:
> > Commit 9589927 (x86/mb2: avoid Xen image when looking for
> > module/crashkernel position) fixed relocation issues for
> > Multiboot2 protocol. Unfortunately it missed to allocate
> > module slot for Xen image placement in early boot path.
> > So, let's fix it right now.
> >
> > Reported-by: Wei Liu 
> > Signed-off-by: Daniel Kiper 
>
> Acked-by: Andrew Cooper 

Wow!!! The quickest review which I have got ever! Less than 2 mins... :-)))

Thanks,

Daniel

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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Oleksandr Andrushchenko]

Hi,
On 09/27/2018 12:39 PM, Lars Kurth wrote:
Adding a few people who have recently been working on PV drivers, as 
well as Julien

Lars

On 27 Sep 2018, at 06:44, Omkar Bolla 
> wrote:


Hi,

I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 
platform(ARMv8) and using Xen-4.8 stable release. Here I want to 
create a PV frontend and backend to share memory between Domain-0 and 
Domain-U.




I used below link to create frontend and backend,
https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/
The link above has another link to github [1] with 2 chapters. And it 
looks like you have

already modified the sources ("mydevice" -> "vdevb" at least).
So, what are the sources you are using?

You could probably take a look at the relatively small vkbd frontend 
driver [2]

to get some hints.


But I am facing below errors while adding device vdevb to xenstore.
Below errors I am getting from xenbus_switch_state().
vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 
writing new state)


If the sources are known then we would need the full scenario which 
leads to the failure.
Could you please also add some debug logs into every function of the 
driver so we see what

and when happens on both backend and frontend sides?

Please suggest me, How to create PV drivers.

I would go with any existing driver in the kernel as an example

Thanks,
Omkar B

This message contains confidential information and is intended only 
for the individual(s) named.If you are not the intended recipient, 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this mail and attached file/s 
is strictly prohibited. Please notify the sender immediately and 
delete this e-mail from your system. E-mail transmission cannot be 
guaranteed to be secured or error-free as information could be 
intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message, which 
arise as a result of e-mail transmission.


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




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

[1] https://github.com/badboy/xen-split-driver-example
[2] 
https://elixir.bootlin.com/linux/latest/source/drivers/input/misc/xen-kbdfront.c
[3] 
https://github.com/badboy/xen-split-driver-example/blob/master/chapter02/activate.sh


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

Re: [Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

[Andrew Cooper]

On 27/09/18 11:05, Daniel Kiper wrote:
> Commit 9589927 (x86/mb2: avoid Xen image when looking for
> module/crashkernel position) fixed relocation issues for
> Multiboot2 protocol. Unfortunately it missed to allocate
> module slot for Xen image placement in early boot path.
> So, let's fix it right now.
>
> Reported-by: Wei Liu 
> Signed-off-by: Daniel Kiper 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH 1/1] x86/boot: Allocate one extra module slot for Xen image placement

[Daniel Kiper]

Commit 9589927 (x86/mb2: avoid Xen image when looking for
module/crashkernel position) fixed relocation issues for
Multiboot2 protocol. Unfortunately it missed to allocate
module slot for Xen image placement in early boot path.
So, let's fix it right now.

Reported-by: Wei Liu 
Signed-off-by: Daniel Kiper 
---
 xen/arch/x86/boot/reloc.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/boot/reloc.c b/xen/arch/x86/boot/reloc.c
index a56ec77..4f4039b 100644
--- a/xen/arch/x86/boot/reloc.c
+++ b/xen/arch/x86/boot/reloc.c
@@ -177,7 +177,12 @@ static multiboot_info_t *mbi2_reloc(u32 mbi_in)
 if ( mbi_out->mods_count )
 {
 mbi_out->flags |= MBI_MODULES;
-mbi_out->mods_addr = alloc_mem(mbi_out->mods_count * 
sizeof(*mbi_out_mods));
+/*
+ * We have to allocate one more module slot here. At some point
+ * __start_xen() may put Xen image placement into it.
+ */
+mbi_out->mods_addr = alloc_mem((mbi_out->mods_count + 1) *
+   sizeof(*mbi_out_mods));
 mbi_out_mods = _p(mbi_out->mods_addr);
 }
 
-- 
1.7.10.4


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

Re: [Xen-devel] null scheduler bug

[Dario Faggioli]

On Tue, 2018-09-25 at 19:49 +0200, Dario Faggioli wrote:
> [Adding a few people to the Cc-list. See below...]
> On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote:
> > On 09/25/2018 10:02 AM, Dario Faggioli wrote:
> > > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> > > > 
> My knowledge of RCU themselves would need refreshing, though. I
> managed
> to getbecome reasonably familiar with how the implementation we
> imported works back then, when working on the said issue, but I guess
> I
> better go check the code again.
> 
> I'm Cc-ing the people that have reviewed the patches and helping with
> the idle timer problem, in case anyone has bright ideas out of the
> top
> of his head.
> 
> Perhaps we should "just" get away from using RCU for domain
> destruction
> (but I'm just tossing the idea around, without much consideration
> about
> whether it's the right solution, or about how hard/feasible it really
> is).
> 
> Or maybe we can still use the timer, in some special way, if we have
> wfi=native (or equivalent)...
> 
So, I've had a look (but only a quick one).

If we want to do something specific within the domain destruction path,
we can add an rcu_barrier() there (I mean in domain_destroy()).
However, that does not feel right either. Also, how can we be sure that
the CPU never going through idle (as far as Xen knows, at least), isn't
going to be problem for other RCU calls as well?

Another thing that we can do is to act on the parameters that control
the threshold which decides when a quiescent state is forced. This was
basically what Julien was suggesting, but I still would avoid to do
that always.

So, basically, in this hackish patch attached, I added a new boot
command line argument, called rcu_force_quiesc. If set to true,
thresholds are set so that quiescence is always forced at each
invocation of call_rcu(). And even if the new param is not explicitly
specified, I do tweak the threshold when "wfi=native" is.

Milan, can you apply this patch, add "wfi=native" again, and re-test?
If it works, we'll decide what to do next.

E.g., we can expose the RCU threshold via the appropriate set of boot
time parameters --like Linux, from where this code comes, did/does--
and document how they should be set, if one wants to use "wfi=native".

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/
commit 0d2beb3d4125d65c415860d66974db9a5532ac84
Author: Dario Faggioli 
Date:   Wed Sep 26 11:47:06 2018 +0200

xen: RCU: bootparam to force quiescence at every call.

Signed-off-by: Dario Faggioli 

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0f4b1f2a5d..536eb17017 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -110,7 +110,10 @@ static enum {
 static int __init parse_vwfi(const char *s)
 {
 	if ( !strcmp(s, "native") )
+	{
+		rcu_always_quiesc = true;
 		vwfi = NATIVE;
+	}
 	else
 		vwfi = TRAP;
 
diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c
index 3517790913..219dd2884f 100644
--- a/xen/common/rcupdate.c
+++ b/xen/common/rcupdate.c
@@ -140,6 +140,9 @@ static int qhimark = 1;
 static int qlowmark = 100;
 static int rsinterval = 1000;
 
+bool rcu_always_quiesc = false;
+boolean_param("rcu_force_quiesc", rcu_always_quiesc);
+
 struct rcu_barrier_data {
 struct rcu_head head;
 atomic_t *cpu_count;
@@ -562,6 +565,13 @@ static void rcu_init_percpu_data(int cpu, struct rcu_ctrlblk *rcp,
 rdp->quiescbatch = rcp->completed;
 rdp->qs_pending = 0;
 rdp->cpu = cpu;
+if ( rcu_always_quiesc )
+{
+blimit = INT_MAX;
+qhimark = 0;
+qlowmark = 0;
+//rsinterval = 0;
+}
 rdp->blimit = blimit;
 init_timer(>idle_timer, rcu_idle_timer_handler, rdp, cpu);
 }
diff --git a/xen/include/xen/rcupdate.h b/xen/include/xen/rcupdate.h
index 3402eb5caf..274a01acf6 100644
--- a/xen/include/xen/rcupdate.h
+++ b/xen/include/xen/rcupdate.h
@@ -56,6 +56,8 @@ struct rcu_head {
 } while (0)
 
 
+extern bool rcu_always_quiesc;
+
 int rcu_pending(int cpu);
 int rcu_needs_cpu(int cpu);
 


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

Re: [Xen-devel] IOREQ server on Arm

[Julien Grall]

Hi Paul,

On 09/27/2018 09:38 AM, Paul Durrant wrote:

-Original Message-
From: Julien Grall [mailto:julien.gr...@arm.com]
Sent: 26 September 2018 22:32
To: Paul Durrant ; 'Jan Beulich'

Cc: Andrew Cooper ; Roger Pau Monne
; Stefano Stabellini ; xen-
devel 
Subject: Re: IOREQ server on Arm

Hi Paul,

On 09/26/2018 01:01 PM, Paul Durrant wrote:

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com]
Sent: 26 September 2018 12:57
To: Paul Durrant 
Cc: Julien Grall ; Andrew Cooper
; Roger Pau Monne ;
Stefano Stabellini ; xen-devel 
Subject: RE: IOREQ server on Arm


On 26.09.18 at 13:02,  wrote:

--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1105,8 +1105,11 @@ static int acquire_resource(

   for ( i = 0; !rc && i < xmar.nr_frames; i++ )
   {
-rc = set_foreign_p2m_entry(currd, gfn_list[i],
-   _mfn(mfn_list[i]));
+rc = (xmar.flags & XENMEM_rsrc_acq_caller_owned) ?
+guest_physmap_add_entry(currd, gfn_list[i],
+_mfn(mfn_list[i]), 0,

p2m_ram_rw) :

+set_foreign_p2m_entry(currd, gfn_list[i],
+  _mfn(mfn_list[i]));
   /* rc should be -EIO for any iteration other than the

first

*/

   if ( rc && i )
   rc = -EIO;

But the guest_physmap_add_entry() is problematic as it will IOMMU map

pages

as well, which is probably not wanted.


Yeah, I'd prefer if we avoided establishing IOMMU mappings here.
How about transforming set_foreign_p2m_entry() into
set_special_p2m_entry(), with a type passed in?



That sounds like it might work.

Julien, do you want page types to distinguish caller-owned resources

from normal RAM are you ok with p2m_ram_rw even though it could be subject
of another domain's foreign map?

Based on your previous e-mail, I would be fine with that on Arm.

This brings me to the next question. Do you expect set_special_p2m_entry
to take a reference on the page?

If not, we may run into some troubles because AFAICT you can map twice
the ioreq page in a guest but reference will only be taken on the
allocation.

However, the unmap path will always drop a reference when removing the
page. This is because Xen at the moment, reference will not be taken on
mapping but allocation (we assume a page could not be mapped twice in a
guest).

Foreign mapping on Arm are a bit special because we get a reference on
mapping them and will drop it when the mapping disappear. So we would
not have any problem there.

Any thoughts?


Well, as Jan says, on x86 we don't reference count in the P2M so multiple 
mappings should not be an issue AFAICT.


I understand that you don't have reference count in the P2M (that's the 
same on Arm today except for foreign mapping). But I think I can list at 
least 2 major issues with the design today. Let me give an example based 
on my understanding.


  1. DM requests to map the IOREQ page
a) page allocated (one reference)
b) get reference (will be dropped when the IOREQ server is destroyed)

  2. DM requests to map the IOREQ page (second time)
No reference taken

  3. DM unmap the IOREQ page
  4. DM unmap the IOREQ page

AFAIU, 3. 4. would be done through XENMEM_remove_from_physmap. So no 
reference dropped there. While the reference 1.b) will be dropped in 
hvm_free_ioreq_mfn. AFAICT 1.a) would be kept until the domain die. This 
would result to Xen memory exhaustion in long term. Did I miss anything?


But, I think there are another way for badly written guest to remove the 
page. It looks like you can use XENMEM_decrease_reservation as the page 
belongs to the guest. So a reference would be dropped by 3. and 4.


While 3. will drop the reference drop by 1.a), 4. may drop the reference 
from 1.b) and releasing the page for good. Although the page will still 
be associated with the IOREQ server until it has been effectively 
destroyed. Did I miss anything in the code?



It sounds like resource mapping should be treated the same way as foreign 
mapping (albeit with a non-foreign domid) such that the reference acquisition 
occurs at map time.


If my understanding is correct then yes it would be much safer to get 
reference here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen PV: Sample new PV driver for buffer sharing between domains

[Lars Kurth]

Adding a few people who have recently been working on PV drivers, as well as 
Julien
Lars

> On 27 Sep 2018, at 06:44, Omkar Bolla  wrote:
> 
> Hi,
> 
> I am using Debian as Domain-0 and Debian as Domain-U on Hikey960 
> platform(ARMv8) and using Xen-4.8 stable release. Here I want to create a PV 
> frontend and backend to share memory between Domain-0 and Domain-U. 
> 
> 
> 
> I used below link to create frontend and backend,
> https://fnordig.de/2016/12/02/xen-a-backend-frontend-driver-example/ 
> 
> 
> But I am facing below errors while adding device vdevb to xenstore. 
> Below errors I am getting from xenbus_switch_state().
> vdevb vdevb-0: failed to write error node for device/vdevb/0 (13 writing new 
> state)
> 
> Please suggest me, How to create PV drivers.
> 
> Thanks,
> Omkar B
> 
> This message contains confidential information and is intended only for the 
> individual(s) named. If you are not the intended recipient, you are notified 
> that disclosing, copying, distributing or taking any action in reliance on 
> the contents of this mail and attached file/s is strictly prohibited. Please 
> notify the sender immediately and delete this e-mail from your system. E-mail 
> transmission cannot be guaranteed to be secured or error-free as information 
> could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, 
> or contain viruses. The sender therefore does not accept liability for any 
> errors or omissions in the contents of this message, which arise as a result 
> of e-mail transmission.
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [RFC PATCH 2/2] x86/mm: Add mem access rights to NPT

[Isaila Alexandru]

On Wed, 2018-09-26 at 17:47 +0100, George Dunlap wrote:
> From: Isaila Alexandru 
> 
> This patch adds access control for NPT mode.
> 
> There aren’t enough extra bits to store the access rights in the NPT
> p2m
> table, so we add a radix tree to store extra information.
> 
> For efficiency:
>  - Only allocate this radix tree when we first store "non-default"
>extra information
> 
>  - Remove entires which match the default extra information rather
>than continuing to store them
> 
>  - For superpages, only store an entry for the first gfn in the
>superpage.  Use the order of the p2m entry being read to determine
>the proper place to look in the radix table.
> 
> Modify p2m_type_to_flags() to accept and interpret an access value,
> parallel to the ept code.
> 
> Add a set_default_access() method to the p2m-pt and p2m-ept versions
> of the p2m rather than setting it directly, to deal with different
> default permitted access values.
> 
> Signed-off-by: Alexandru Isaila 
> Signed-off-by: George Dunlap 
> ---
> NB, this is compile-tested only.

I've tested this with xen-access and it works as expected
> 
> diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
> index 3c42e21906..2e6b1e75e4 100644
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -20,6 +20,7 @@
>   */
>  
>  #include 
> +#include 

Is this intended?

Regards,
Alex



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

[Xen-devel] [PATCH v3 6/6] memory-hotplug.txt: Add some details about locking internals

[David Hildenbrand]

Let's document the magic a bit, especially why device_hotplug_lock is
required when adding/removing memory and how it all play together with
requests to online/offline memory from user space.

Cc: Jonathan Corbet 
Cc: Michal Hocko 
Cc: Andrew Morton 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rashmica Gupta 
Signed-off-by: David Hildenbrand 
---
 Documentation/memory-hotplug.txt | 42 +++-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 7f49ebf3ddb2..ce4faa5530fa 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -3,7 +3,7 @@ Memory Hotplug
 ==
 
 :Created:  Jul 28 2007
-:Updated: Add description of notifier of memory hotplug:   Oct 11 2007
+:Updated: Add some details about locking internals:Aug 20 2018
 
 This document is about memory hotplug including how-to-use and current status.
 Because Memory Hotplug is still under development, contents of this text will
@@ -495,6 +495,46 @@ further processing of the notification queue.
 
 NOTIFY_STOP stops further processing of the notification queue.
 
+
+Locking Internals
+=
+
+When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
+the device_hotplug_lock should be held to:
+
+- synchronize against online/offline requests (e.g. via sysfs). This way, 
memory
+  block devices can only be accessed (.online/.state attributes) by user
+  space once memory has been fully added. And when removing memory, we
+  know nobody is in critical sections.
+- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
+
+Especially, there is a possible lock inversion that is avoided using
+device_hotplug_lock when adding memory and user space tries to online that
+memory faster than expected:
+
+- device_online() will first take the device_lock(), followed by
+  mem_hotplug_lock
+- add_memory_resource() will first take the mem_hotplug_lock, followed by
+  the device_lock() (while creating the devices, during bus_add_device()).
+
+As the device is visible to user space before taking the device_lock(), this
+can result in a lock inversion.
+
+onlining/offlining of memory should be done via device_online()/
+device_offline() - to make sure it is properly synchronized to actions
+via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
+
+When adding/removing/onlining/offlining memory or adding/removing
+heterogeneous/device memory, we should always hold the mem_hotplug_lock in
+write mode to serialise memory hotplug (e.g. access to global/zone
+variables).
+
+In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
+mode allows for a quite efficient get_online_mems/put_online_mems
+implementation, so code accessing memory can protect from that memory
+vanishing.
+
+
 Future Work
 ===
 
-- 
2.17.1


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

[Xen-devel] [PATCH v3 3/6] mm/memory_hotplug: fix online/offline_pages called w.o. mem_hotplug_lock

[David Hildenbrand]

There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
fix concurrent memory hot-add deadlock"), which tried to fix a possible
lock inversion reported and discussed in [1] due to the two locks
a) device_lock()
b) mem_hotplug_lock

While add_memory() first takes b), followed by a) during
bus_probe_device(), onlining of memory from user space first took a),
followed by b), exposing a possible deadlock.

In [1], and it was decided to not make use of device_hotplug_lock, but
rather to enforce a locking order.

The problems I spotted related to this:

1. Memory block device attributes: While .state first calls
   mem_hotplug_begin() and the calls device_online() - which takes
   device_lock() - .online does no longer call mem_hotplug_begin(), so
   effectively calls online_pages() without mem_hotplug_lock.

2. device_online() should be called under device_hotplug_lock, however
   onlining memory during add_memory() does not take care of that.

In addition, I think there is also something wrong about the locking in

3. arch/powerpc/platforms/powernv/memtrace.c calls offline_pages()
   without locks. This was introduced after 30467e0b3be. And skimming over
   the code, I assume it could need some more care in regards to locking
   (e.g. device_online() called without device_hotplug_lock. This will
   be addressed in the following patches.

Now that we hold the device_hotplug_lock when
- adding memory (e.g. via add_memory()/add_memory_resource())
- removing memory (e.g. via remove_memory())
- device_online()/device_offline()

We can move mem_hotplug_lock usage back into
online_pages()/offline_pages().

Why is mem_hotplug_lock still needed? Essentially to make
get_online_mems()/put_online_mems() be very fast (relying on
device_hotplug_lock would be very slow), and to serialize against
addition of memory that does not create memory block devices (hmm).

[1] http://driverdev.linuxdriverproject.org/pipermail/ driverdev-devel/
2015-February/065324.html

This patch is partly based on a patch by Vitaly Kuznetsov.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Rashmica Gupta 
Cc: Michael Neuling 
Cc: Balbir Singh 
Cc: Kate Stewart 
Cc: Thomas Gleixner 
Cc: Philippe Ombredanne 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Pavel Tatashin 
Cc: Vlastimil Babka 
Cc: Dan Williams 
Cc: Oscar Salvador 
Cc: YASUAKI ISHIMATSU 
Cc: Mathieu Malaterre 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rashmica Gupta 
Signed-off-by: David Hildenbrand 
---
 drivers/base/memory.c | 13 +
 mm/memory_hotplug.c   | 28 
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 40cac122ec73..0e5985682642 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -228,7 +228,6 @@ static bool pages_correctly_probed(unsigned long start_pfn)
 /*
  * MEMORY_HOTPLUG depends on SPARSEMEM in mm/Kconfig, so it is
  * OK to have direct references to sparsemem variables in here.
- * Must already be protected by mem_hotplug_begin().
  */
 static int
 memory_block_action(unsigned long phys_index, unsigned long action, int 
online_type)
@@ -294,7 +293,6 @@ static int memory_subsys_online(struct device *dev)
if (mem->online_type < 0)
mem->online_type = MMOP_ONLINE_KEEP;
 
-   /* Already under protection of mem_hotplug_begin() */
ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
 
/* clear online_type */
@@ -341,19 +339,11 @@ store_mem_state(struct device *dev,
goto err;
}
 
-   /*
-* Memory hotplug needs to hold mem_hotplug_begin() for probe to find
-* the correct memory block to online before doing device_online(dev),
-* which will take dev->mutex.  Take the lock early to prevent an
-* inversion, memory_subsys_online() callbacks will be implemented by
-* assuming it's already protected.
-*/
-   mem_hotplug_begin();
-
switch (online_type) {
case MMOP_ONLINE_KERNEL:
case MMOP_ONLINE_MOVABLE:
case MMOP_ONLINE_KEEP:
+   /* mem->online_type is protected by device_hotplug_lock */
mem->online_type = online_type;
ret = device_online(>dev);
break;
@@ -364,7 +354,6 @@ store_mem_state(struct device *dev,
ret = -EINVAL; /* should never happen */
}
 
-   mem_hotplug_done();
 err:
unlock_device_hotplug();
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index affb03e0dfef..d4c7e42e46f3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -860,7 +860,6 @@ static struct zone * __meminit move_pfn_range(int 
online_type, int nid,
  

[Xen-devel] [PATCH v3 5/6] powerpc/powernv: hold device_hotplug_lock when calling memtrace_offline_pages()

[David Hildenbrand]

Let's perform all checking + offlining + removing under
device_hotplug_lock, so nobody can mess with these devices via
sysfs concurrently.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Rashmica Gupta 
Cc: Balbir Singh 
Cc: Michael Neuling 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rashmica Gupta 
Acked-by: Balbir Singh 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/platforms/powernv/memtrace.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c 
b/arch/powerpc/platforms/powernv/memtrace.c
index fdd48f1a39f7..84d038ed3882 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -70,6 +70,7 @@ static int change_memblock_state(struct memory_block *mem, 
void *arg)
return 0;
 }
 
+/* called with device_hotplug_lock held */
 static bool memtrace_offline_pages(u32 nid, u64 start_pfn, u64 nr_pages)
 {
u64 end_pfn = start_pfn + nr_pages - 1;
@@ -110,6 +111,7 @@ static u64 memtrace_alloc_node(u32 nid, u64 size)
/* Trace memory needs to be aligned to the size */
end_pfn = round_down(end_pfn - nr_pages, nr_pages);
 
+   lock_device_hotplug();
for (base_pfn = end_pfn; base_pfn > start_pfn; base_pfn -= nr_pages) {
if (memtrace_offline_pages(nid, base_pfn, nr_pages) == true) {
/*
@@ -118,7 +120,6 @@ static u64 memtrace_alloc_node(u32 nid, u64 size)
 * we never try to remove memory that spans two iomem
 * resources.
 */
-   lock_device_hotplug();
end_pfn = base_pfn + nr_pages;
for (pfn = base_pfn; pfn < end_pfn; pfn += bytes>> 
PAGE_SHIFT) {
__remove_memory(nid, pfn << PAGE_SHIFT, bytes);
@@ -127,6 +128,7 @@ static u64 memtrace_alloc_node(u32 nid, u64 size)
return base_pfn << PAGE_SHIFT;
}
}
+   unlock_device_hotplug();
 
return 0;
 }
-- 
2.17.1


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

[Xen-devel] [PATCH v3 4/6] powerpc/powernv: hold device_hotplug_lock when calling device_online()

[David Hildenbrand]

device_online() should be called with device_hotplug_lock() held.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Rashmica Gupta 
Cc: Balbir Singh 
Cc: Michael Neuling 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rashmica Gupta 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/platforms/powernv/memtrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c 
b/arch/powerpc/platforms/powernv/memtrace.c
index 773623f6bfb1..fdd48f1a39f7 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -242,9 +242,11 @@ static int memtrace_online(void)
 * we need to online the memory ourselves.
 */
if (!memhp_auto_online) {
+   lock_device_hotplug();
walk_memory_range(PFN_DOWN(ent->start),
  PFN_UP(ent->start + ent->size - 1),
  NULL, online_mem_block);
+   unlock_device_hotplug();
}
 
/*
-- 
2.17.1


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

[Xen-devel] [PATCH v3 0/6] mm: online/offline_pages called w.o. mem_hotplug_lock

[David Hildenbrand]

@Andrew, Only patch #5 changed (see change notes below). Thanks!


Reading through the code and studying how mem_hotplug_lock is to be used,
I noticed that there are two places where we can end up calling
device_online()/device_offline() - online_pages()/offline_pages() without
the mem_hotplug_lock. And there are other places where we call
device_online()/device_offline() without the device_hotplug_lock.

While e.g.
echo "online" > /sys/devices/system/memory/memory9/state
is fine, e.g.
echo 1 > /sys/devices/system/memory/memory9/online
Will not take the mem_hotplug_lock. However the device_lock() and
device_hotplug_lock.

E.g. via memory_probe_store(), we can end up calling
add_memory()->online_pages() without the device_hotplug_lock. So we can
have concurrent callers in online_pages(). We e.g. touch in online_pages()
basically unprotected zone->present_pages then.

Looks like there is a longer history to that (see Patch #2 for details),
and fixing it to work the way it was intended is not really possible. We
would e.g. have to take the mem_hotplug_lock in device/base/core.c, which
sounds wrong.

Summary: We had a lock inversion on mem_hotplug_lock and device_lock().
More details can be found in patch 3 and patch 6.

I propose the general rules (documentation added in patch 6):

1. add_memory/add_memory_resource() must only be called with
   device_hotplug_lock.
2. remove_memory() must only be called with device_hotplug_lock. This is
   already documented and holds for all callers.
3. device_online()/device_offline() must only be called with
   device_hotplug_lock. This is already documented and true for now in core
   code. Other callers (related to memory hotplug) have to be fixed up.
4. mem_hotplug_lock is taken inside of add_memory/remove_memory/
   online_pages/offline_pages.

To me, this looks way cleaner than what we have right now (and easier to
verify). And looking at the documentation of remove_memory, using
lock_device_hotplug also for add_memory() feels natural.


v2 -> v3:
- Take device_hotplug_lock outside of loop in patch #5
- Added Ack to patch #5

v1 -> v2:
- Upstream changes in powerpc/powernv code required modifications to
  patch #1, #4 and #5.
- Minor patch description changes.
- Added more locking details in patch #6.
- Added rb's

RFCv2 -> v1:
- Dropped an unnecessary _ref from remove_memory() in patch #1
- Minor patch description fixes.
- Added rb's

RFC -> RFCv2:
- Don't export device_hotplug_lock, provide proper remove_memory/add_memory
  wrappers.
- Split up the patches a bit.
- Try to improve powernv memtrace locking
- Add some documentation for locking that matches my knowledg

David Hildenbrand (6):
  mm/memory_hotplug: make remove_memory() take the device_hotplug_lock
  mm/memory_hotplug: make add_memory() take the device_hotplug_lock
  mm/memory_hotplug: fix online/offline_pages called w.o.
mem_hotplug_lock
  powerpc/powernv: hold device_hotplug_lock when calling device_online()
  powerpc/powernv: hold device_hotplug_lock when calling
memtrace_offline_pages()
  memory-hotplug.txt: Add some details about locking internals

 Documentation/memory-hotplug.txt  | 42 -
 arch/powerpc/platforms/powernv/memtrace.c |  8 ++-
 .../platforms/pseries/hotplug-memory.c|  8 +--
 drivers/acpi/acpi_memhotplug.c|  4 +-
 drivers/base/memory.c | 22 +++
 drivers/xen/balloon.c |  3 +
 include/linux/memory_hotplug.h|  4 +-
 mm/memory_hotplug.c   | 59 +++
 8 files changed, 114 insertions(+), 36 deletions(-)

-- 
2.17.1


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

[Xen-devel] [PATCH v3 2/6] mm/memory_hotplug: make add_memory() take the device_hotplug_lock

[David Hildenbrand]

add_memory() currently does not take the device_hotplug_lock, however
is aleady called under the lock from
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
to synchronize against CPU hot-remove and similar.

In general, we should hold the device_hotplug_lock when adding memory
to synchronize against online/offline request (e.g. from user space) -
which already resulted in lock inversions due to device_lock() and
mem_hotplug_lock - see 30467e0b3be ("mm, hotplug: fix concurrent memory
hot-add deadlock"). add_memory()/add_memory_resource() will create memory
block devices, so this really feels like the right thing to do.

Holding the device_hotplug_lock makes sure that a memory block device
can really only be accessed (e.g. via .online/.state) from user space,
once the memory has been fully added to the system.

The lock is not held yet in
drivers/xen/balloon.c
arch/powerpc/platforms/powernv/memtrace.c
drivers/s390/char/sclp_cmd.c
drivers/hv/hv_balloon.c
So, let's either use the locked variants or take the lock.

Don't export add_memory_resource(), as it once was exported to be used
by XEN, which is never built as a module. If somebody requires it, we
also have to export a locked variant (as device_hotplug_lock is never
exported).

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Greg Kroah-Hartman 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Cc: Nathan Fontenot 
Cc: John Allen 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Joonsoo Kim 
Cc: Vlastimil Babka 
Cc: Oscar Salvador 
Cc: Mathieu Malaterre 
Cc: Pavel Tatashin 
Cc: YASUAKI ISHIMATSU 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Rashmica Gupta 
Signed-off-by: David Hildenbrand 
---
 .../platforms/pseries/hotplug-memory.c|  2 +-
 drivers/acpi/acpi_memhotplug.c|  2 +-
 drivers/base/memory.c |  9 ++--
 drivers/xen/balloon.c |  3 +++
 include/linux/memory_hotplug.h|  1 +
 mm/memory_hotplug.c   | 22 ---
 6 files changed, 32 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index dd0264c43f3e..d26a771d985e 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -673,7 +673,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
nid = memory_add_physaddr_to_nid(lmb->base_addr);
 
/* Add the memory */
-   rc = add_memory(nid, lmb->base_addr, block_sz);
+   rc = __add_memory(nid, lmb->base_addr, block_sz);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 811148415993..8fe0960ea572 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -228,7 +228,7 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
 
-   result = add_memory(node, info->start_addr, info->length);
+   result = __add_memory(node, info->start_addr, info->length);
 
/*
 * If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 817320c7c4c1..40cac122ec73 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -519,15 +519,20 @@ memory_probe_store(struct device *dev, struct 
device_attribute *attr,
if (phys_addr & ((pages_per_block << PAGE_SHIFT) - 1))
return -EINVAL;
 
+   ret = lock_device_hotplug_sysfs();
+   if (ret)
+   goto out;
+
nid = memory_add_physaddr_to_nid(phys_addr);
-   ret = add_memory(nid, phys_addr,
-MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+   ret = __add_memory(nid, phys_addr,
+  MIN_MEMORY_BLOCK_SIZE * sections_per_block);
 
if (ret)
goto out;
 
ret = count;
 out:
+   unlock_device_hotplug();
return ret;
 }
 
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index a3f5cbfcd4a1..fdfc64f5acea 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -395,7 +395,10 @@ static enum bp_state reserve_additional_memory(void)
 * callers drop the mutex before trying again.
 */
mutex_unlock(_mutex);
+   /* add_memory_resource() requires the device_hotplug lock */
+   lock_device_hotplug();
rc = add_memory_resource(nid, resource, memhp_auto_online);
+   unlock_device_hotplug();
mutex_lock(_mutex);
 
if (rc) {
diff --git a/include/linux/memory_hotplug.h 

[Xen-devel] [PATCH v3 1/6] mm/memory_hotplug: make remove_memory() take the device_hotplug_lock

[David Hildenbrand]

remove_memory() is exported right now but requires the
device_hotplug_lock, which is not exported. So let's provide a variant
that takes the lock and only export that one.

The lock is already held in
arch/powerpc/platforms/pseries/hotplug-memory.c
drivers/acpi/acpi_memhotplug.c
arch/powerpc/platforms/powernv/memtrace.c

Apart from that, there are not other users in the tree.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
Cc: Rashmica Gupta 
Cc: Michael Neuling 
Cc: Balbir Singh 
Cc: Nathan Fontenot 
Cc: John Allen 
Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Dan Williams 
Cc: Joonsoo Kim 
Cc: Vlastimil Babka 
Cc: Pavel Tatashin 
Cc: Greg Kroah-Hartman 
Cc: Oscar Salvador 
Cc: YASUAKI ISHIMATSU 
Cc: Mathieu Malaterre 
Reviewed-by: Pavel Tatashin 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Rashmica Gupta 
Signed-off-by: David Hildenbrand 
---
 arch/powerpc/platforms/powernv/memtrace.c   | 2 +-
 arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++---
 drivers/acpi/acpi_memhotplug.c  | 2 +-
 include/linux/memory_hotplug.h  | 3 ++-
 mm/memory_hotplug.c | 9 -
 5 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/memtrace.c 
b/arch/powerpc/platforms/powernv/memtrace.c
index a29fdf8a2e56..773623f6bfb1 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -121,7 +121,7 @@ static u64 memtrace_alloc_node(u32 nid, u64 size)
lock_device_hotplug();
end_pfn = base_pfn + nr_pages;
for (pfn = base_pfn; pfn < end_pfn; pfn += bytes>> 
PAGE_SHIFT) {
-   remove_memory(nid, pfn << PAGE_SHIFT, bytes);
+   __remove_memory(nid, pfn << PAGE_SHIFT, bytes);
}
unlock_device_hotplug();
return base_pfn << PAGE_SHIFT;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c 
b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 9a15d39995e5..dd0264c43f3e 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -305,7 +305,7 @@ static int pseries_remove_memblock(unsigned long base, 
unsigned int memblock_siz
nid = memory_add_physaddr_to_nid(base);
 
for (i = 0; i < sections_per_block; i++) {
-   remove_memory(nid, base, MIN_MEMORY_BLOCK_SIZE);
+   __remove_memory(nid, base, MIN_MEMORY_BLOCK_SIZE);
base += MIN_MEMORY_BLOCK_SIZE;
}
 
@@ -394,7 +394,7 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)
block_sz = pseries_memory_block_size();
nid = memory_add_physaddr_to_nid(lmb->base_addr);
 
-   remove_memory(nid, lmb->base_addr, block_sz);
+   __remove_memory(nid, lmb->base_addr, block_sz);
 
/* Update memory regions for memory remove */
memblock_remove(lmb->base_addr, block_sz);
@@ -681,7 +681,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
 
rc = dlpar_online_lmb(lmb);
if (rc) {
-   remove_memory(nid, lmb->base_addr, block_sz);
+   __remove_memory(nid, lmb->base_addr, block_sz);
invalidate_lmb_associativity_index(lmb);
} else {
lmb->flags |= DRCONF_MEM_ASSIGNED;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 6b0d3ef7309c..811148415993 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -282,7 +282,7 @@ static void acpi_memory_remove_memory(struct 
acpi_memory_device *mem_device)
nid = memory_add_physaddr_to_nid(info->start_addr);
 
acpi_unbind_memory_blocks(info);
-   remove_memory(nid, info->start_addr, info->length);
+   __remove_memory(nid, info->start_addr, info->length);
list_del(>list);
kfree(info);
}
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 34a28227068d..1f096852f479 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -301,6 +301,7 @@ extern bool is_mem_section_removable(unsigned long pfn, 
unsigned long nr_pages);
 extern void try_offline_node(int nid);
 extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
 extern void remove_memory(int nid, u64 start, u64 size);
+extern void __remove_memory(int nid, u64 start, u64 size);
 
 #else
 static inline bool is_mem_section_removable(unsigned long pfn,
@@ -317,6 +318,7 @@ static inline int offline_pages(unsigned long start_pfn, 
unsigned long nr_pages)
 }
 
 static inline void remove_memory(int nid, u64 start, u64 size) {}
+static inline void __remove_memory(int nid, u64 start, u64 size) {}
 #endif /* 

Re: [Xen-devel] Xen PPC64

[Lars Kurth]

Tamara,
Have a look at this thread: https://xen.markmail.org/thread/vuk7atnyqfq52epp 

That will answer some but not all of your questions: 
https://markmail.org/message/cizu54474lvuus6k 
 gives an indication of size and 
elapsed time required
Regards
Lars

> On 27 Sep 2018, at 08:07, Tamara B. Elizondo  wrote:
> 
> Hello,
> 
> I would like to fund a port of Xen to the PPC64 architecture, more specially 
> POWER9, in little endian and big endian mode.
> 
> Anyone with the required competence can provide me with an idea of the delay 
> and funds required for this?
> 
> I am pushing this forward to enable Qubes OS compatibility on the Talos II 
> Desktop POWER9 platform. (https://raptorcs.com)
> 
> Thank you
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

[Andrew Cooper]

On 27/09/18 08:53, Yang Qian wrote:
> 1. Add a common bind virq function
> 2. Reduce the stub code of `bind_dom_exc_virq`
>
> Signed-off-by: Yang Qian 

CC'ing the relevant maintainers.

Reviewed-by: Andrew Cooper  (forwarding my
internal review of this patch)

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

Re: [Xen-devel] [RFC PATCH 1/2] mem_access: Fix npfec.kind propagation

[George Dunlap]

On 09/27/2018 08:04 AM, Jan Beulich wrote:
 On 26.09.18 at 19:00,  wrote:
>> On 26/09/18 17:47, George Dunlap wrote:
>>> --- a/xen/arch/x86/mm/mem_access.c
>>> +++ b/xen/arch/x86/mm/mem_access.c
>>> @@ -232,12 +232,12 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned long 
>>> gla,
>>>  {
>>>  req->u.mem_access.flags |= MEM_ACCESS_GLA_VALID;
>>>  req->u.mem_access.gla = gla;
>>> -
>>> -if ( npfec.kind == npfec_kind_with_gla )
>>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>>> -else if ( npfec.kind == npfec_kind_in_gpt )
>>> -req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>>>  }
>>> +
>>> +if ( npfec.kind == npfec_kind_with_gla )
>>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA;
>>> +else if ( npfec.kind == npfec_kind_in_gpt )
>>> +req->u.mem_access.flags |= MEM_ACCESS_FAULT_IN_GPT;
>>
>> Nit.  Newline here please, as it is not logically related with the block
>> below.
> 
> And, despite it being just two comparisons, perhaps better to
> make it a switch() at the same time?

Sure -- this is logically separate from the follow-up patch, so I'll
re-send it as a singleton with the comments.

 -George

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

Re: [Xen-devel] IOREQ server on Arm

[Paul Durrant]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 26 September 2018 22:32
> To: Paul Durrant ; 'Jan Beulich'
> 
> Cc: Andrew Cooper ; Roger Pau Monne
> ; Stefano Stabellini ; xen-
> devel 
> Subject: Re: IOREQ server on Arm
> 
> Hi Paul,
> 
> On 09/26/2018 01:01 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 26 September 2018 12:57
> >> To: Paul Durrant 
> >> Cc: Julien Grall ; Andrew Cooper
> >> ; Roger Pau Monne ;
> >> Stefano Stabellini ; xen-devel  >> de...@lists.xenproject.org>
> >> Subject: RE: IOREQ server on Arm
> >>
> > On 26.09.18 at 13:02,  wrote:
> >>> --- a/xen/common/memory.c
> >>> +++ b/xen/common/memory.c
> >>> @@ -1105,8 +1105,11 @@ static int acquire_resource(
> >>>
> >>>   for ( i = 0; !rc && i < xmar.nr_frames; i++ )
> >>>   {
> >>> -rc = set_foreign_p2m_entry(currd, gfn_list[i],
> >>> -   _mfn(mfn_list[i]));
> >>> +rc = (xmar.flags & XENMEM_rsrc_acq_caller_owned) ?
> >>> +guest_physmap_add_entry(currd, gfn_list[i],
> >>> +_mfn(mfn_list[i]), 0,
> >> p2m_ram_rw) :
> >>> +set_foreign_p2m_entry(currd, gfn_list[i],
> >>> +  _mfn(mfn_list[i]));
> >>>   /* rc should be -EIO for any iteration other than the
> first
> >> */
> >>>   if ( rc && i )
> >>>   rc = -EIO;
> >>>
> >>> But the guest_physmap_add_entry() is problematic as it will IOMMU map
> >> pages
> >>> as well, which is probably not wanted.
> >>
> >> Yeah, I'd prefer if we avoided establishing IOMMU mappings here.
> >> How about transforming set_foreign_p2m_entry() into
> >> set_special_p2m_entry(), with a type passed in?
> >>
> >
> > That sounds like it might work.
> >
> > Julien, do you want page types to distinguish caller-owned resources
> from normal RAM are you ok with p2m_ram_rw even though it could be subject
> of another domain's foreign map?
> 
> Based on your previous e-mail, I would be fine with that on Arm.
> 
> This brings me to the next question. Do you expect set_special_p2m_entry
> to take a reference on the page?
> 
> If not, we may run into some troubles because AFAICT you can map twice
> the ioreq page in a guest but reference will only be taken on the
> allocation.
> 
> However, the unmap path will always drop a reference when removing the
> page. This is because Xen at the moment, reference will not be taken on
> mapping but allocation (we assume a page could not be mapped twice in a
> guest).
> 
> Foreign mapping on Arm are a bit special because we get a reference on
> mapping them and will drop it when the mapping disappear. So we would
> not have any problem there.
> 
> Any thoughts?

Well, as Jan says, on x86 we don't reference count in the P2M so multiple 
mappings should not be an issue AFAICT. It sounds like resource mapping should 
be treated the same way as foreign mapping (albeit with a non-foreign domid) 
such that the reference acquisition occurs at map time.

  Paul

> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 128049
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128049
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 128049
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128049
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 128049
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-armhf-armhf-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-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   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-libvirt-raw 12 migrate-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-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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 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-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail 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:
 qemuuc5e4e49258e9b89cb34c085a419dd9f862935c48
baseline version:
 qemuu5b9000b52fba08a567f8efaa4aa56233b5f2a081

Last test of basis   128049  2018-09-25 09:01:57 Z1 days
Testing same since   128094  2018-09-26 06:27:55 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Bartlomiej Zolnierkiewicz 
  Collin Walling 
  Cornelia Huck 
  Cédric Le Goater 
  David Gibson 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eric Auger 
  Fam Zheng 
  Guenter Roeck 
  Hervé Poussineau 
  Jeff Cody 
  Joel Stanley 
  John Snow 
  Kevin Wolf 
  Mao Zhongyi 
  Marc-André Lureau 
  Marcus Comstedt 
  Mark Cave-Ayland 
  Markus Armbruster 
  Max Filippov 
  Max Reitz 
  Peter Maydell 
  Peter Maydell  [arm parts]
  Richard Henderson 
  Richard W.M. Jones 
  Sergio Lopez 
  Shannon Zhao 
  Thomas Huth 

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

[Xen-devel] [PATCH] tools/ocaml: Add OCaml binding of virq bind

[Yang Qian]

1. Add a common bind virq function
2. Reduce the stub code of `bind_dom_exc_virq`

Signed-off-by: Yang Qian 
---
 tools/ocaml/libs/eventchn/xeneventchn.ml  | 19 ++-
 tools/ocaml/libs/eventchn/xeneventchn.mli | 21 +
 tools/ocaml/libs/eventchn/xeneventchn_stubs.c |  8 
 3 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/tools/ocaml/libs/eventchn/xeneventchn.ml 
b/tools/ocaml/libs/eventchn/xeneventchn.ml
index 89edb92..dd00a1f 100644
--- a/tools/ocaml/libs/eventchn/xeneventchn.ml
+++ b/tools/ocaml/libs/eventchn/xeneventchn.ml
@@ -21,9 +21,26 @@ external fd: handle -> Unix.file_descr = "stub_eventchn_fd"
 
 type t = int
 
+type virq_t =
+  | Timer(* #define VIRQ_TIMER  0 *)
+  | Debug(* #define VIRQ_DEBUG  1 *)
+  | Console  (* #define VIRQ_CONSOLE2 *)
+  | Dom_exc  (* #define VIRQ_DOM_EXC3 *)
+  | Tbuf (* #define VIRQ_TBUF   4 *)
+  | Reserved_5   (* Do not use this value as it's not defined *)
+  | Debugger (* #define VIRQ_DEBUGGER   6 *)
+  | Xenoprof (* #define VIRQ_XENOPROF   7 *)
+  | Con_ring (* #define VIRQ_CON_RING   8 *)
+  | Pcpu_state   (* #define VIRQ_PCPU_STATE 9 *)
+  | Mem_event(* #define VIRQ_MEM_EVENT  10 *)
+  | Xc_reserved  (* #define VIRQ_XC_RESERVED 11 *)
+  | Enomem   (* #define VIRQ_ENOMEM 12 *)
+  | Xenpmu   (* #define VIRQ_XENPMU 13 *)
+
 external notify: handle -> int -> unit = "stub_eventchn_notify"
 external bind_interdomain: handle -> int -> int -> int = 
"stub_eventchn_bind_interdomain"
-external bind_dom_exc_virq: handle -> int = "stub_eventchn_bind_dom_exc_virq"
+external bind_virq: handle -> virq_t -> int = "stub_eventchn_bind_virq"
+let bind_dom_exc_virq handle = bind_virq handle Dom_exc
 external unbind: handle -> int -> unit = "stub_eventchn_unbind"
 external pending: handle -> int = "stub_eventchn_pending"
 external unmask: handle -> int -> unit = "stub_eventchn_unmask"
diff --git a/tools/ocaml/libs/eventchn/xeneventchn.mli 
b/tools/ocaml/libs/eventchn/xeneventchn.mli
index e180145..08c7337 100644
--- a/tools/ocaml/libs/eventchn/xeneventchn.mli
+++ b/tools/ocaml/libs/eventchn/xeneventchn.mli
@@ -22,6 +22,23 @@ type handle
 type t
 (** A local event channel. *)
 
+type virq_t =
+  | Timer(* #define VIRQ_TIMER  0 *)
+  | Debug(* #define VIRQ_DEBUG  1 *)
+  | Console  (* #define VIRQ_CONSOLE2 *)
+  | Dom_exc  (* #define VIRQ_DOM_EXC3 *)
+  | Tbuf (* #define VIRQ_TBUF   4 *)
+  | Reserved_5   (* Do not use this value as it's not defined *)
+  | Debugger (* #define VIRQ_DEBUGGER   6 *)
+  | Xenoprof (* #define VIRQ_XENOPROF   7 *)
+  | Con_ring (* #define VIRQ_CON_RING   8 *)
+  | Pcpu_state   (* #define VIRQ_PCPU_STATE 9 *)
+  | Mem_event(* #define VIRQ_MEM_EVENT  10 *)
+  | Xc_reserved  (* #define VIRQ_XC_RESERVED 11 *)
+  | Enomem   (* #define VIRQ_ENOMEM 12 *)
+  | Xenpmu   (* #define VIRQ_XENPMU 13 *)
+
+
 val to_int: t -> int
 
 val of_int: int -> t
@@ -49,6 +66,10 @@ val bind_dom_exc_virq : handle -> t
 (domain exception VIRQ). On error it will throw a Failure
 exception. *)
 
+val bind_virq: handle -> virq_t -> t
+(** Binds a local event channel to the specific VIRQ type.
+On error it will throw a Failure exception. *)
+
 val unbind : handle -> t -> unit
 (** Unbinds the given event channel. On error it will throw a
 Failure exception. *)
diff --git a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c 
b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
index 45a385d..2b7984f 100644
--- a/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
+++ b/tools/ocaml/libs/eventchn/xeneventchn_stubs.c
@@ -90,15 +90,15 @@ CAMLprim value stub_eventchn_bind_interdomain(value xce, 
value domid,
CAMLreturn(port);
 }
 
-CAMLprim value stub_eventchn_bind_dom_exc_virq(value xce)
+CAMLprim value stub_eventchn_bind_virq(value xce, value virq_type)
 {
-   CAMLparam1(xce);
+   CAMLparam2(xce, virq_type);
CAMLlocal1(port);
xenevtchn_port_or_error_t rc;
 
-   rc = xenevtchn_bind_virq(_H(xce), VIRQ_DOM_EXC);
+   rc = xenevtchn_bind_virq(_H(xce), Int_val(virq_type));
if (rc == -1)
-   caml_failwith("evtchn bind_dom_exc_virq failed");
+   caml_failwith("evtchn bind_virq failed");
port = Val_int(rc);
 
CAMLreturn(port);
-- 
2.9.5


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

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

[Arun KS]

On 2018-09-27 12:41, Juergen Gross wrote:

On 27/09/18 08:58, Arun KS wrote:

When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less than 1 ms, hence
improving the hot add latency by 60%.

Modify external providers of online callback to align with
the change.

Signed-off-by: Arun KS 
---
Changes since v2:
reuse code from __free_pages_boot_core()

Changes since v1:
- Removed prefetch()

Changes since RFC:
- Rebase.
- As suggested by Michal Hocko remove pages_per_block.
- Modifed external providers of online_page_callback.

v2: https://lore.kernel.org/patchwork/patch/991363/
v1: https://lore.kernel.org/patchwork/patch/989445/
RFC: https://lore.kernel.org/patchwork/patch/984754/

---
 drivers/hv/hv_balloon.c|  6 --
 drivers/xen/balloon.c  | 18 ++---
 include/linux/memory_hotplug.h |  2 +-
 mm/internal.h  |  1 +
 mm/memory_hotplug.c| 44 
++

 mm/page_alloc.c|  2 +-
 6 files changed, 54 insertions(+), 19 deletions(-)



...


diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index e12bb25..010cf4d 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -390,8 +390,8 @@ static enum bp_state 
reserve_additional_memory(void)


/*
 * add_memory_resource() will call online_pages() which in its turn
-* will call xen_online_page() callback causing deadlock if we don't
-* release balloon_mutex here. Unlocking here is safe because the
+* will call xen_bring_pgs_online() callback causing deadlock if we
+	 * don't release balloon_mutex here. Unlocking here is safe because 
the

 * callers drop the mutex before trying again.
 */
mutex_unlock(_mutex);
@@ -422,6 +422,18 @@ static void xen_online_page(struct page *page)
mutex_unlock(_mutex);
 }

+static int xen_bring_pgs_online(struct page *pg, unsigned int order)
+{
+   unsigned long i, size = (1 << order);
+   unsigned long start_pfn = page_to_pfn(pg);
+
+	pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, 
start_pfn);

+   for (i = 0; i < size; i++)
+   xen_online_page(pfn_to_page(start_pfn + i));




Hi,


xen_online_page() isn't very complex and this is the only user.

Why don't you move its body in here and drop the extra function?
And now you can execute the loop with balloon_mutex held instead of
taking and releasing it in each iteration of the loop.

Point taken. Will incorporate them.

Regards,
Arun



Juergen


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

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

[Arun KS]

On 2018-09-27 12:39, Oscar Salvador wrote:

On Thu, Sep 27, 2018 at 12:28:50PM +0530, Arun KS wrote:

+   __free_pages_boot_core(page, order);



Hi,


I am not sure, but if we are going to use that function from the
memory-hotplug code,
we might want to rename that function to something more generic?
The word "boot" suggests that this is only called from the boot stage.

I ll rename it to __free_pages_core()



And what about the prefetch operations?
I saw that you removed them in your previous patch and that had some
benefits [1].

Should we remove them here as well?

Sure. Will update this as well.

Thanks,
Arun


[1] https://patchwork.kernel.org/patch/10613359/

Thanks


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

[Xen-devel] [PATCH V6] x86/altp2m: Add a subop for obtaining the mem access of a page

[Razvan Cojocaru]

Currently there is a subop for setting the memaccess of a page, but not
for consulting it.  The new HVMOP_altp2m_get_mem_access adds this
functionality.

Both altp2m get/set mem access functions use the struct
xen_hvm_altp2m_mem_access which has now dropped the `set' part and has
been renamed from xen_hvm_altp2m_set_mem_access.

Signed-off-by: Adrian Pop 
Signed-off-by: Razvan Cojocaru 

---
Changes since V5:
 - Fixed the build by conditionally-compiling the altp2m code
   gated on CONFIG_HVM being #defined.
---
 tools/libxc/include/xenctrl.h   |  3 +++
 tools/libxc/xc_altp2m.c | 33 ++---
 xen/arch/arm/mem_access.c   |  7 +--
 xen/arch/x86/hvm/hvm.c  | 30 --
 xen/arch/x86/mm/mem_access.c| 21 -
 xen/common/mem_access.c |  2 +-
 xen/include/public/hvm/hvm_op.h | 21 -
 xen/include/public/xen-compat.h |  2 +-
 xen/include/xen/mem_access.h|  3 ++-
 9 files changed, 106 insertions(+), 16 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index dad96a9..618f3cb 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1949,6 +1949,9 @@ int xc_altp2m_set_mem_access(xc_interface *handle, 
uint32_t domid,
 int xc_altp2m_set_mem_access_multi(xc_interface *handle, uint32_t domid,
uint16_t view_id, uint8_t *access,
uint64_t *gfns, uint32_t nr);
+int xc_altp2m_get_mem_access(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn,
+ xenmem_access_t *access);
 int xc_altp2m_change_gfn(xc_interface *handle, uint32_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index be5bfd2..844b9f1 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -226,9 +226,9 @@ int xc_altp2m_set_mem_access(xc_interface *handle, uint32_t 
domid,
 arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
 arg->cmd = HVMOP_altp2m_set_mem_access;
 arg->domain = domid;
-arg->u.set_mem_access.view = view_id;
-arg->u.set_mem_access.hvmmem_access = access;
-arg->u.set_mem_access.gfn = gfn;
+arg->u.mem_access.view = view_id;
+arg->u.mem_access.access = access;
+arg->u.mem_access.gfn = gfn;
 
 rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
  HYPERCALL_BUFFER_AS_ARG(arg));
@@ -303,3 +303,30 @@ int xc_altp2m_set_mem_access_multi(xc_interface *xch, 
uint32_t domid,
 
 return rc;
 }
+
+int xc_altp2m_get_mem_access(xc_interface *handle, uint32_t domid,
+ uint16_t view_id, xen_pfn_t gfn,
+ xenmem_access_t *access)
+{
+int rc;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_get_mem_access;
+arg->domain = domid;
+arg->u.mem_access.view = view_id;
+arg->u.mem_access.gfn = gfn;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+if ( !rc )
+*access = arg->u.mem_access.access;
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index ba4ec78..653d960 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -236,7 +236,7 @@ bool p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const 
struct npfec npfec)
 if ( !p2m->mem_access_enabled )
 return true;
 
-rc = p2m_get_mem_access(v->domain, gaddr_to_gfn(gpa), );
+rc = p2m_get_mem_access(v->domain, gaddr_to_gfn(gpa), , 0);
 if ( rc )
 return true;
 
@@ -441,11 +441,14 @@ long p2m_set_mem_access_multi(struct domain *d,
 }
 
 int p2m_get_mem_access(struct domain *d, gfn_t gfn,
-   xenmem_access_t *access)
+   xenmem_access_t *access, unsigned int altp2m_idx)
 {
 int ret;
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
+/* altp2m is not yet implemented on Arm. The altp2m_idx should be 0. */
+ASSERT(altp2m_idx == 0);
+
 p2m_read_lock(p2m);
 ret = __p2m_get_mem_access(d, gfn, access);
 p2m_read_unlock(p2m);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 51fc3ec..8a9abf3 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4473,6 +4473,7 @@ static int do_altp2m_op(
 case HVMOP_altp2m_get_suppress_ve:
 case HVMOP_altp2m_set_mem_access:
 case HVMOP_altp2m_set_mem_access_multi:
+case HVMOP_altp2m_get_mem_access:
 case HVMOP_altp2m_change_gfn:
 break;
 
@@ -4600,8 +4601,8 @@ 

Re: [Xen-devel] [PATCH] x86emul: fix test harness build after e8dfbc2962

[Christopher Clark]

On Wed, Sep 26, 2018 at 1:43 AM Wei Liu  wrote:
>
> On Wed, Sep 26, 2018 at 02:03:36AM -0600, Jan Beulich wrote:
> > There was another stdio.h inclusion left in place. Re-order #include-s
> > altogether in test_x86_emulator.c.
> >
> > Signed-off-by: Jan Beulich 
>
> Reviewed-by: Wei Liu 
> Tested-by: Wei Liu 

Thanks, Jan and Wei. Sorry - I should've found that one too.

Christopher

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

Re: [Xen-devel] [PATCH] xen/blkfront: When purging persistent grants, keep them in the buffer

[Juergen Gross]

On 22/09/18 21:55, Boris Ostrovsky wrote:
> Commit a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> added support for purging persistent grants when they are not in use. As
> part of the purge, the grants were removed from the grant buffer, This
> eventually causes the buffer to become empty, with BUG_ON triggered in
> get_free_grant(). This can be observed even on an idle system, within
> 20-30 minutes.
> 
> We should keep the grants in the buffer when purging, and only free the
> grant ref.
> 
> Fixes: a46b53672b2c ("xen/blkfront: cleanup stale persistent grants")
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH v3] memory_hotplug: Free pages as higher order

[Juergen Gross]

On 27/09/18 08:58, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot add latency by 60%.
> 
> Modify external providers of online callback to align with
> the change.
> 
> Signed-off-by: Arun KS 
> ---
> Changes since v2:
> reuse code from __free_pages_boot_core()
> 
> Changes since v1:
> - Removed prefetch()
> 
> Changes since RFC:
> - Rebase.
> - As suggested by Michal Hocko remove pages_per_block.
> - Modifed external providers of online_page_callback.
> 
> v2: https://lore.kernel.org/patchwork/patch/991363/
> v1: https://lore.kernel.org/patchwork/patch/989445/
> RFC: https://lore.kernel.org/patchwork/patch/984754/
> 
> ---
>  drivers/hv/hv_balloon.c|  6 --
>  drivers/xen/balloon.c  | 18 ++---
>  include/linux/memory_hotplug.h |  2 +-
>  mm/internal.h  |  1 +
>  mm/memory_hotplug.c| 44 
> ++
>  mm/page_alloc.c|  2 +-
>  6 files changed, 54 insertions(+), 19 deletions(-)
>

...

> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index e12bb25..010cf4d 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -390,8 +390,8 @@ static enum bp_state reserve_additional_memory(void)
>  
>   /*
>* add_memory_resource() will call online_pages() which in its turn
> -  * will call xen_online_page() callback causing deadlock if we don't
> -  * release balloon_mutex here. Unlocking here is safe because the
> +  * will call xen_bring_pgs_online() callback causing deadlock if we
> +  * don't release balloon_mutex here. Unlocking here is safe because the
>* callers drop the mutex before trying again.
>*/
>   mutex_unlock(_mutex);
> @@ -422,6 +422,18 @@ static void xen_online_page(struct page *page)
>   mutex_unlock(_mutex);
>  }
>  
> +static int xen_bring_pgs_online(struct page *pg, unsigned int order)
> +{
> + unsigned long i, size = (1 << order);
> + unsigned long start_pfn = page_to_pfn(pg);
> +
> + pr_debug("Online %lu pages starting at pfn 0x%lx\n", size, start_pfn);
> + for (i = 0; i < size; i++)
> + xen_online_page(pfn_to_page(start_pfn + i));

xen_online_page() isn't very complex and this is the only user.

Why don't you move its body in here and drop the extra function?
And now you can execute the loop with balloon_mutex held instead of
taking and releasing it in each iteration of the loop.


Juergen

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