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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 53fa87286b9348d285654dda1ab2274241358ffc
baseline version:
 ovmf c314970984065c98a56097443ae38d57a27bc73b

Last test of basis   110439  2017-06-14 12:53:27 Z1 days
Testing same since   110467  2017-06-15 11:48:36 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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



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

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

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

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


Pushing revision :

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

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

[Zhongze Liu]

currently there is no wrapper for XENMEM_add_to_physmap_batch in libxc.
add a wrapper to do that.

Signed-off-by: Zhongze Liu 
---
Cc: Ian Jackson ,
Cc: Wei Liu ,
Cc: Stefano Stabellini 
---
 tools/libxc/include/xenctrl.h |  9 +
 tools/libxc/xc_domain.c   | 44 +++
 2 files changed, 53 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f412dd..4ea520b188 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1372,6 +1372,15 @@ int xc_domain_add_to_physmap(xc_interface *xch,
  unsigned long idx,
  xen_pfn_t gpfn);
 
+int xc_domain_add_to_physmap_batch(xc_interface *xch,
+   uint32_t domid,
+   uint32_t foreign_domid,
+   unsigned int space,
+   uint16_t size,
+   xen_ulong_t *idxs,
+   xen_pfn_t *gfpns,
+   int *errs);
+
 int xc_domain_populate_physmap(xc_interface *xch,
uint32_t domid,
unsigned long nr_extents,
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 5d192ea0e4..0d34754821 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1032,6 +1032,50 @@ int xc_domain_add_to_physmap(xc_interface *xch,
 return do_memory_op(xch, XENMEM_add_to_physmap, , sizeof(xatp));
 }
 
+int xc_domain_add_to_physmap_batch(xc_interface *xch,
+   uint32_t domid,
+   uint32_t foreign_domid,
+   unsigned int space,
+   uint16_t size,
+   xen_ulong_t *idxs,
+   xen_pfn_t *gpfns,
+   int *errs)
+{
+int rc;
+DECLARE_HYPERCALL_BOUNCE(idxs, size * sizeof(*idxs), 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(gpfns, size * sizeof(*gpfns), 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(errs, size * sizeof(*errs), 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+
+struct xen_add_to_physmap_batch xatp_batch = {
+.domid = domid,
+.space = space,
+.size = size,
+.u = {.foreign_domid = foreign_domid}
+};
+
+if ( xc_hypercall_bounce_pre(xch, idxs)  ||
+ xc_hypercall_bounce_pre(xch, gpfns) ||
+ xc_hypercall_bounce_pre(xch, errs)  )
+{
+PERROR("Could not bounce memory for XENMEM_add_to_physmap_batch");
+goto out;
+}
+
+set_xen_guest_handle(xatp_batch.idxs, idxs);
+set_xen_guest_handle(xatp_batch.gpfns, gpfns);
+set_xen_guest_handle(xatp_batch.errs, errs);
+
+rc = do_memory_op(xch, XENMEM_add_to_physmap_batch,
+  _batch, sizeof(xatp_batch));
+
+out:
+xc_hypercall_bounce_post(xch, idxs);
+xc_hypercall_bounce_post(xch, gpfns);
+xc_hypercall_bounce_post(xch, errs);
+
+return rc;
+}
+
 int xc_domain_claim_pages(xc_interface *xch,
uint32_t domid,
unsigned long nr_pages)
-- 
2.13.1


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

Re: [Xen-devel] questions on mem_sharing_op*'s and tools/tests/mem-sharing/memshrtool

[Zhongze Liu]

2017-06-16 11:50 GMT+08:00 Zhongze Liu :
> Hi there,
>
> I was experimenting with the mem_sharing_op and I found a handy tool:
> tools/tests/mem-sharing/memshrtool
> I set up two bare metal x86_64 VMS running some simple code in 16-bit
> real mode and I tried to share the first physical page among them. so
>

And both of them are hvms and have a memory of 32M.

>
> I use:
>
> "./memshrtool enable src_dom "
> "./memshrtool enable dst_dom"
> "./memshrtool nominate src_dom 0"
>
> And it failed with an "error executing xc_memshr_nominate_gfn(xch,
> domid, gfn, ): Argument list too long "
>
> But when I changed the gfn from 0 to 1000, it succeeds. Is there any
> restrition on the gfns to be shared?
>

and the minimum gfn for the call to succeed is 256.


Cheers,

Zhongze Liu

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

Re: [Xen-devel] [PATCH 17/44] hexagon: switch to use ->mapping_error for error reporting

[Richard Kuo]

On Thu, Jun 08, 2017 at 03:25:42PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/hexagon/include/asm/dma-mapping.h |  2 --
>  arch/hexagon/kernel/dma.c  | 12 +---
>  arch/hexagon/kernel/hexagon_ksyms.c|  1 -
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 

Acked-by: Richard Kuo 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project

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

Re: [Xen-devel] [PATCH 31/44] hexagon: remove arch-specific dma_supported implementation

[Richard Kuo]

On Thu, Jun 08, 2017 at 03:25:56PM +0200, Christoph Hellwig wrote:
> This implementation is simply bogus - hexagon only has a simple
> direct mapped DMA implementation and thus doesn't care about the
> address.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/hexagon/include/asm/dma-mapping.h | 2 --
>  arch/hexagon/kernel/dma.c  | 9 -
>  2 files changed, 11 deletions(-)
> 

Acked-by: Richard Kuo 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, 
a Linux Foundation Collaborative Project

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

[Xen-devel] questions on mem_sharing_op*'s and tools/tests/mem-sharing/memshrtool

[Zhongze Liu]

Hi there,

I was experimenting with the mem_sharing_op and I found a handy tool:
tools/tests/mem-sharing/memshrtool
I set up two bare metal x86_64 VMS running some simple code in 16-bit
real mode and I tried to share the first physical page among them. so
I use:

"./memshrtool enable src_dom "
"./memshrtool enable dst_dom"
"./memshrtool nominate src_dom 0"

And it failed with an "error executing xc_memshr_nominate_gfn(xch,
domid, gfn, ): Argument list too long "

But when I changed the gfn from 0 to 1000, it succeeds. Is there any
restrition on the gfns to be shared?


Cheers,


Zhongze Liu

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   5 xen-install  fail in 110428 pass in 110458
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
110428
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 110428

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

version targeted for testing:
 qemuu3f0602927b120a480b35dcf58cf6f95435b3ae91
baseline version:
 qemuuc6e84fbd447a51e1161d74d71566a5f67b47eac5

Last test of basis   109975  2017-06-04 00:16:43 Z   12 days
Failing since110013  2017-06-05 10:45:10 Z   10 days   14 attempts
Testing same since   110428  2017-06-14 05:53:59 Z1 days2 attempts


People who touched revisions under test:
  Aaron Larson 
  Abdallah Bouassida 
  Alex Bennée 
  Aurelien Jarno 
  Bruno Dominguez 
  Christian Borntraeger 
  Cornelia Huck 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  534ecddd8a961a44356fcab576bd68d6900bfa74
baseline version:
 xen  695bb5f504ab48c1d546446f104c1b6c0ead126d

Last test of basis   110455  2017-06-14 19:02:27 Z1 days
Testing same since   110476  2017-06-16 01:03:18 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-4.7-testing baseline-only test] 71565: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71380
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail like 71380

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  84cd8d3fbdfbc0655ad242da1d2fdadddf5be89e
baseline version:
 xen  7a0bf3eef7b9cc3958de61d537c699b200be4163

Last test of basis71380  2017-05-20 22:47:19 Z   26 days
Testing same since71565  2017-06-15 04:44:11 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Gary Lin 
  George Dunlap 
  Gregory Herrero 
  Igor 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 107358
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 107358
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

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

version targeted for testing:
 linux05afd4c0af6a43f6bda7caaacb01bc0116d50d3b
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   66 days
Failing since107396  2017-04-12 11:15:19 Z   64 days   97 attempts
Testing same since   110456  2017-06-14 22:55:22 Z1 days1 attempts


670 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Tue, 30 May 2017, Julien Grall wrote:
> > > In this design document, we are considering that the host bridge driver
> > > can
> > > be ported in Xen. In the case it is not possible, a interface to forward
> > > configuration space access would need to be defined. The interface details
> > > is out of scope.
> > 
> > I think that you have to state that the driver is ported to Xen or the
> > bridge will not be supported. I don't think it's feasible to forward
> > PCI config space access from Xen to Dom0 at all.

Easy to say, but in practice there might be boards that we want to
support which require complex configurations.

Obviously having to send PCI config space read/write requests from Xen
to Dom0 is ugly and slow and doesn't match the Xen architecture, but it
might be the only solution in these cases. This is ARM: the ecosystem
has a lot more variety compared to x86: a single approach might simply
not be possible.

Another ugly (and fragile) idea to solve this problem would be to
initialize those difficult PCI host bridges in Dom0, then cede control
of them from Dom0 to Xen: I expect that once they are initialized, Xen
might be able to drive them more easily, without getting entangled with
clocks and regulators. 


> Rather than arguing on the code is not ready for that. I would have
> appreciated if you gave technical details on why it is not feasible.
> 
> I already gave quite a few times insights on why it might be difficult to port
> an host bridges in Xen.
>   - How do you configure the clock? What if they are shared?
>   - How about host bridges using indirect access (e.g cf8 like)? What
> you expose to DOM0?
>   - 
> 
> Such host bridges will end up to pull a lot of code in Xen and require more
> design than finding about a way to forward configuration space in Xen. Those
> boards exists and people are looking at using Xen + PCI passthrough. So saying
> they are not supported is not the right solution here.

I agree


> Anyway, I mentioned it in the design document to open a discussion and not
> something I am going to focus for a first version of PCI pass-through.

Indeed: we'll cross that bridge when we get to it.

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

Re: [Xen-devel] [RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Fri, 26 May 2017, Julien Grall wrote:
> Hi all,
> 
> The document below is an RFC version of a design proposal for PCI
> Passthrough in Xen on ARM. It aims to describe from an high level perspective
> the interaction with the different subsystems and how guest will be able
> to discover and access PCI.
> 
> Currently on ARM, Xen does not have any knowledge about PCI devices. This
> means that IOMMU and interrupt controller (such as ITS) requiring specific
> configuration will not work with PCI even with DOM0.
> 
> The PCI Passthrough work could be divided in 2 phases:
> * Phase 1: Register all PCI devices in Xen => will allow
>to use ITS and SMMU with PCI in Xen
> * Phase 2: Assign devices to guests
> 
> This document aims to describe the 2 phases, but for now only phase
> 1 is fully described.
> 
> 
> I think I was able to gather all of the feedbacks and come up with a solution
> that will satisfy all the parties. The design document has changed quite a lot
> compare to the early draft sent few months ago. The major changes are:
>   * Provide more details how PCI works on ARM and the interactions with
>   MSI controller and IOMMU
>   * Provide details on the existing host bridge implementations
>   * Give more explanation and justifications on the approach chosen 
>   * Describing the hypercalls used and how they should be called
> 
> Feedbacks are welcomed.
> 
> Cheers,

Hi Julien,

I think this document is a very good first step in the right direction
and I fully agree with the approaches taken here.

A noticed a couple of grammar errors that I pointed out below.


> 
> 
> % PCI pass-through support on ARM
> % Julien Grall 
> % Draft B
> 
> # Preface
> 
> This document aims to describe the components required to enable the PCI
> pass-through on ARM.
> 
> This is an early draft and some questions are still unanswered. When this is
> the case, the text will contain XXX.
> 
> # Introduction
> 
> PCI pass-through allows the guest to receive full control of physical PCI
> devices. This means the guest will have full and direct access to the PCI
> device.
> 
> ARM is supporting a kind of guest that exploits as much as possible
> virtualization support in hardware. The guest will rely on PV driver only
> for IO (e.g block, network) and interrupts will come through the virtualized
> interrupt controller, therefore there are no big changes required within the
> kernel.
> 
> As a consequence, it would be possible to replace PV drivers by assigning real
> devices to the guest for I/O access. Xen on ARM would therefore be able to
> run unmodified operating system.
> 
> To achieve this goal, it looks more sensible to go towards emulating the
> host bridge (there will be more details later). A guest would be able to take
> advantage of the firmware tables, obviating the need for a specific driver
> for Xen.
> 
> Thus, in this document we follow the emulated host bridge approach.
> 
> # PCI terminologies
> 
> Each PCI device under a host bridge is uniquely identified by its Requester ID
> (AKA RID). A Requester ID is a triplet of Bus number, Device number, and
> Function.
> 
> When the platform has multiple host bridges, the software can add a fourth
> number called Segment (sometimes called Domain) to differentiate host bridges.
> A PCI device will then uniquely by segment:bus:device:function (AKA SBDF).
> 
> So given a specific SBDF, it would be possible to find the host bridge and the
> RID associated to a PCI device. The pair (host bridge, RID) will often be used
> to find the relevant information for configuring the different subsystems (e.g
> IOMMU, MSI controller). For convenience, the rest of the document will use
> SBDF to refer to the pair (host bridge, RID).
> 
> # PCI host bridge
> 
> PCI host bridge enables data transfer between a host processor and PCI bus
> based devices. The bridge is used to access the configuration space of each
> PCI devices and, on some platform may also act as an MSI controller.
> 
> ## Initialization of the PCI host bridge
> 
> Whilst it would be expected that the bootloader takes care of initializing
> the PCI host bridge, on some platforms it is done in the Operating System.
> 
> This may include enabling/configuring the clocks that could be shared among
> multiple devices.
> 
> ## Accessing PCI configuration space
> 
> Accessing the PCI configuration space can be divided in 2 category:
> * Indirect access, where the configuration spaces are multiplexed. An
> example would be legacy method on x86 (e.g 0xcf8 and 0xcfc). On ARM a
> similar method is used by PCIe RCar root complex (see [12]).
> * ECAM access, each configuration space will have its own address space.
> 
> Whilst ECAM is a standard, some PCI host bridges will require specific 
> fiddling
> when access the registers (see thunder-ecam 

[Xen-devel] [libvirt test] 110460: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  f0a3fe1b0a2996272dd167501bb5de752d9d1956
baseline version:
 libvirt  992bf863fccfe1fa1d0c5a5277b9cee50abc48ef

Last test of basis   110425  2017-06-14 04:26:23 Z1 days
Testing same since   110460  2017-06-15 04:31:18 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Erik Skultety 
  Jiri Denemark 
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

Test 

Re: [Xen-devel] [PATCH 00/24] xen/arm: Extend the usage of typesafe MFN

[Stefano Stabellini]

Hi Julien,

thanks for the series!

I committed patches 2, 4-15, 17,18.

Cheers,

Stefano

On Tue, 13 Jun 2017, Julien Grall wrote:
> Hello all,
> 
> This patch series extend the usage of typesafe MFN in the ARM code. _mfn(...)
> and mfn_x(...) are pushed further down in the call stack.
> 
> Cheers,
> 
> Julien Grall (24):
>   xen/mm: Don't use _{g,m}fn for defining INVALID_{G,M}FN
>   xen/arm: gic-v2: Fix indentation in gicv2_map_hwdom_extra_mappings
>   xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64
>   xen/arm: mm: Introduce clear_table and use it
>   xen/arm: mm: Move mfn_to_xen_entry from page.h to mm.c
>   xen/arm: mm: Fix coding style of mfn_to_xen_entry
>   xen/arm: mm: Clean-up mfn_to_xen_entry
>   xen/arm: mm: Use typesafe MFN in mfn_to_xen_entry
>   xen/arm: Define mfn_to_page/page_to_mfn in term of
> __mfn_to_page/__page_to_mfn
>   xen/arm: domain_build: Replace paddr_to_pfn(virt_to_maddr(.)) by
> virt_to_mfn(.)
>   xen/arm: mm: Replace __va(pfn_to_paddr(...)) by mfn_to_virt
>   xen/arm: Replace DIV_ROUND_UP(..., PAGE_SIZE) by PFN_UP(...)
>   xen/arm: traps: Replace p2m_lookup(..., ..., NULL) by gfn_to_mfn(...,
> ...)
>   xen/arm: Introduce wrappers for MFN <-> MADDR and GFN <-> GADDR
>   xen/arm: Use the newly introduced MFN <-> MADDR and GFN <-> MADDR
> helpers
>   xen/arm: mm: Use typesafe mfn for xenheap_mfn_*
>   xen/arm: mm: Use typesafe MFN in set_fixmap
>   xen/arm: mm: Use typesafe MFN in dump_pt_walk
>   xen/arm: p2m: Redefine mfn_to_page and page_to_mfn to use typesafe
>   xen/arm: mm: Redefine virt_to_mfn to support typesafe
>   xen/arm: domain_build: Redefine virt_to_mfn to support typesafe
>   xen/arm: alternative: Redefine virt_to_mfn to support typesafe
>   xen/arm: livepatch: Redefine virt_to_mfn to support typesafe
>   xen/arm: create_xen_entries: Use typesafe MFN
> 
>  xen/arch/arm/acpi/lib.c   |   4 +-
>  xen/arch/arm/alternative.c|   6 +-
>  xen/arch/arm/domain_build.c   |  22 ++---
>  xen/arch/arm/gic-v2.c |   6 +-
>  xen/arch/arm/gic-v3.c |   8 +-
>  xen/arch/arm/kernel.c |   8 +-
>  xen/arch/arm/livepatch.c  |   6 +-
>  xen/arch/arm/mem_access.c |  10 +--
>  xen/arch/arm/mm.c | 166 
> +++---
>  xen/arch/arm/p2m.c|  28 ---
>  xen/arch/arm/platforms/exynos5.c  |   8 +-
>  xen/arch/arm/platforms/omap5.c|  16 ++--
>  xen/arch/arm/platforms/vexpress.c |   2 +-
>  xen/arch/arm/setup.c  |  20 +++--
>  xen/arch/arm/traps.c  |  16 ++--
>  xen/arch/arm/vgic-v2.c|   4 +-
>  xen/drivers/video/arm_hdlcd.c |   2 +-
>  xen/include/asm-arm/mm.h  |  33 +---
>  xen/include/asm-arm/page.h|  65 ---
>  xen/include/xen/mm.h  |   4 +-
>  20 files changed, 235 insertions(+), 199 deletions(-)
> 
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 24/24] xen/arm: create_xen_entries: Use typesafe MFN

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Add a bit more safety when using create_xen_entries.
> 
> Also when destroying/modifying mapping, the MFN is currently not used.
> Rather than passing _mfn(0) use INVALID_MFN to stay consistent with the
> other usage.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


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

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

Re: [Xen-devel] [PATCH 23/24] xen/arm: livepatch: Redefine virt_to_mfn to support typesafe

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file xen/arch/arm/livepatch.c is using typesafe MFN in most of
> the place. The only caller to virt_to_mfn is using with _mfn(...).
> 
> To avoid extra _mfn(...), re-define virt_to_mfn within
> xen/arch/arm/livepatch.c to handle typesafe MFN.
> 
> Signed-off-by: Julien Grall 
> Cc: Ross Lagerwall 
> Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Stefano Stabellini 


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

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

Re: [Xen-devel] [PATCH 22/24] xen/arm: alternative: Redefine virt_to_mfn to support typesafe

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file xen/arch/arm/alternative.c is using typesafe MFN in most of
> the place. The only caller to virt_to_mfn is using with _mfn(...).
> 
> To avoid extra _mfn(...), re-define virt_to_mfn within
> xen/arch/arm/alternative.c to handle typesafe MFN.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

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

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

Re: [Xen-devel] [PATCH 21/24] xen/arm: domain_build: Redefine virt_to_mfn to support typesafe

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file xen/arch/arm/domain_build.c is using typesafe MFN in most of
> the place. The only caller to virt_to_mfn is using prefixed with
> _mfn(...).
> 
> To avoid extra _mfn(...), re-define virt_to_mfn within
> arch/arm/domain_build.c to handle typesafe MFN.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


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

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

Re: [Xen-devel] [PATCH 20/24] xen/arm: mm: Redefine virt_to_mfn to support typesafe

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file xen/arch/arm/mm.c is using the typesafe MFN in most of the
> place. This requires all caller of virt_to_mfn to prefixed by _mfn(...).
> 
> To avoid the extra _mfn(...), re-defined virt_to_mfn within arch/arm/mm.c
> to handle typesafe MFN.
> 
> This patch also introduce __virt_to_mfn, so virt_to_mfn can be
> re-defined easily.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c| 16 ++--
>  xen/include/asm-arm/mm.h |  3 ++-
>  2 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 452c1e26c3..2ff1688f3f 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -44,6 +44,10 @@
>  
>  struct domain *dom_xen, *dom_io, *dom_cow;
>  
> +/* Override macros from asm/page.h to make them work with mfn_t */
> +#undef virt_to_mfn
> +#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
> +
>  /* Static start-of-day pagetables that we use before the allocators
>   * are up. These are used by all CPUs during bringup before switching
>   * to the CPUs own pagetables.
> @@ -479,7 +483,7 @@ unsigned long domain_page_map_to_mfn(const void *ptr)
>  unsigned long offset = (va>>THIRD_SHIFT) & LPAE_ENTRY_MASK;
>  
>  if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END )
> -return virt_to_mfn(va);
> +return mfn_x(virt_to_mfn(va));

__virt_to_mfn?


>  ASSERT(slot >= 0 && slot < DOMHEAP_ENTRIES);
>  ASSERT(map[slot].pt.avail != 0);
> @@ -764,7 +768,7 @@ int init_secondary_pagetables(int cpu)
>   * domheap mapping pages. */
>  for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
>  {
> -pte = mfn_to_xen_entry(_mfn(virt_to_mfn(domheap+i*LPAE_ENTRIES)),
> +pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES),
> WRITEALLOC);
>  pte.pt.table = 1;
>  
> write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], pte);
> @@ -961,7 +965,7 @@ static int create_xen_table(lpae_t *entry)
>  if ( p == NULL )
>  return -ENOMEM;
>  clear_page(p);
> -pte = mfn_to_xen_entry(_mfn(virt_to_mfn(p)), WRITEALLOC);
> +pte = mfn_to_xen_entry(virt_to_mfn(p), WRITEALLOC);
>  pte.pt.table = 1;
>  write_pte(entry, pte);
>  return 0;
> @@ -1216,7 +1220,7 @@ int xenmem_add_to_physmap_one(
>  unsigned long idx,
>  gfn_t gfn)
>  {
> -unsigned long mfn = 0;
> +mfn_t mfn = INVALID_MFN;
>  int rc;
>  p2m_type_t t;
>  struct page_info *page = NULL;
> @@ -1302,7 +1306,7 @@ int xenmem_add_to_physmap_one(
>  return -EINVAL;
>  }
>  
> -mfn = page_to_mfn(page);
> +mfn = _mfn(page_to_mfn(page));
>  t = p2m_map_foreign;
>  
>  rcu_unlock_domain(od);
> @@ -1321,7 +1325,7 @@ int xenmem_add_to_physmap_one(
>  }
>  
>  /* Map at new location. */
> -rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
> +rc = guest_physmap_add_entry(d, gfn, mfn, 0, t);
>  
>  /* If we fail to add the mapping, we need to drop the reference we
>   * took earlier on foreign pages */
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index b2e7ea7761..6e2b3c7f2b 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -264,7 +264,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
> unsigned int flags)
>  #define __va(x) (maddr_to_virt(x))
>  
>  /* Convert between Xen-heap virtual addresses and machine frame numbers. */
> -#define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
> +#define __virt_to_mfn(va) (virt_to_maddr(va) >> PAGE_SHIFT)
>  #define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
>  
>  /*
> @@ -274,6 +274,7 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t *pa, 
> unsigned int flags)
>   */
>  #define mfn_to_page(mfn)__mfn_to_page(mfn)
>  #define page_to_mfn(pg) __page_to_mfn(pg)
> +#define virt_to_mfn(va) __virt_to_mfn(va)
>  
>  /* Convert between Xen-heap virtual addresses and page-info structures. */
>  static inline struct page_info *virt_to_page(const void *v)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 19/24] xen/arm: p2m: Redefine mfn_to_page and page_to_mfn to use typesafe

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file xen/arch/arm/p2m.c is using typesafe MFN in most of the place.
> This requires caller to mfn_to_page and page_to_mfn to use _mfn/mfn_x.
> 
> To avoid extra _mfn/mfn_x, re-define mfn_to_page and page_to_mfn within
> xen/arch/arm/p2m.c to handle typesafe MFN.

This is the same thing that x86/p2m.c does. At some point one has to
wonder if it makes sense to just bite the bullet and change mfn_to_page
everywhere.


> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/p2m.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 266d1c3bd6..6c1ac70044 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -38,6 +38,12 @@ static unsigned int __read_mostly max_vmid = 
> MAX_VMID_8_BIT;
>  
>  #define P2M_ROOT_PAGES(1<  
> +/* Override macros from asm/mm.h to make them work with mfn_t */
> +#undef mfn_to_page
> +#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
> +#undef page_to_mfn
> +#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
> +
>  unsigned int __read_mostly p2m_ipa_bits;
>  
>  /* Helpers to lookup the properties of each level */
> @@ -115,7 +121,7 @@ void dump_p2m_lookup(struct domain *d, paddr_t addr)
>  printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
>  
>  printk("P2M @ %p mfn:0x%lx\n",
> -   p2m->root, page_to_mfn(p2m->root));
> +   p2m->root, mfn_x(page_to_mfn(p2m->root)));

__page_to_mfn(pg) ?

The rest looks good


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

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

Re: [Xen-devel] [PATCH 18/24] xen/arm: mm: Use typesafe MFN in dump_pt_walk

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/mm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 8573192e3a..452c1e26c3 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -181,7 +181,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
>unsigned int nr_root_tables)
>  {
>  static const char *level_strs[4] = { "0TH", "1ST", "2ND", "3RD" };
> -const unsigned long root_pfn = paddr_to_pfn(ttbr);
> +const mfn_t root_mfn = maddr_to_mfn(ttbr);
>  const unsigned int offsets[4] = {
>  zeroeth_table_offset(addr),
>  first_table_offset(addr),
> @@ -215,7 +215,7 @@ void dump_pt_walk(paddr_t ttbr, paddr_t addr,
>  else
>  root_table = 0;
>  
> -mapping = map_domain_page(_mfn(root_pfn + root_table));
> +mapping = map_domain_page(mfn_add(root_mfn, root_table));
>  
>  for ( level = root_level; ; level++ )
>  {
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 17/24] xen/arm: mm: Use typesafe MFN in set_fixmap

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/acpi/lib.c   | 4 ++--
>  xen/arch/arm/kernel.c | 4 +---
>  xen/arch/arm/mm.c | 4 ++--
>  xen/arch/arm/platforms/vexpress.c | 2 +-
>  xen/drivers/video/arm_hdlcd.c | 2 +-
>  xen/include/asm-arm/mm.h  | 2 +-
>  6 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
> index 9bd769cff6..70131b0736 100644
> --- a/xen/arch/arm/acpi/lib.c
> +++ b/xen/arch/arm/acpi/lib.c
> @@ -31,7 +31,7 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
>  
>  offset = phys & (PAGE_SIZE - 1);
>  mapped_size = PAGE_SIZE - offset;
> -set_fixmap(FIXMAP_ACPI_BEGIN, phys >> PAGE_SHIFT, PAGE_HYPERVISOR);
> +set_fixmap(FIXMAP_ACPI_BEGIN, maddr_to_mfn(phys), PAGE_HYPERVISOR);
>  base = FIXMAP_ADDR(FIXMAP_ACPI_BEGIN);
>  
>  /* Most cases can be covered by the below. */
> @@ -41,7 +41,7 @@ char *__acpi_map_table(paddr_t phys, unsigned long size)
>  if ( ++idx > FIXMAP_ACPI_END )
>  return NULL;/* cannot handle this */
>  phys += PAGE_SIZE;
> -set_fixmap(idx, phys >> PAGE_SHIFT, PAGE_HYPERVISOR);
> +set_fixmap(idx, maddr_to_mfn(phys), PAGE_HYPERVISOR);
>  mapped_size += PAGE_SIZE;
>  }
>  
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 1b32d55284..7403ec0c0e 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -49,14 +49,12 @@ void copy_from_paddr(void *dst, paddr_t paddr, unsigned 
> long len)
>  void *src = (void *)FIXMAP_ADDR(FIXMAP_MISC);
>  
>  while (len) {
> -paddr_t p;
>  unsigned long l, s;
>  
> -p = paddr >> PAGE_SHIFT;
>  s = paddr & (PAGE_SIZE-1);
>  l = min(PAGE_SIZE - s, len);
>  
> -set_fixmap(FIXMAP_MISC, p, BUFFERABLE);
> +set_fixmap(FIXMAP_MISC, maddr_to_mfn(paddr), BUFFERABLE);
>  memcpy(dst, src + s, l);
>  clean_dcache_va_range(dst, l);
>  
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index fb01f01879..8573192e3a 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -323,9 +323,9 @@ static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned 
> attr)
>  }
>  
>  /* Map a 4k page in a fixmap entry */
> -void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
> +void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes)
>  {
> -lpae_t pte = mfn_to_xen_entry(_mfn(mfn), attributes);
> +lpae_t pte = mfn_to_xen_entry(mfn, attributes);
>  pte.pt.table = 1; /* 4k mappings always have this bit set */
>  pte.pt.xn = 1;
>  write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
> diff --git a/xen/arch/arm/platforms/vexpress.c 
> b/xen/arch/arm/platforms/vexpress.c
> index 8e6a4eaa32..a26ac324ba 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -65,7 +65,7 @@ int vexpress_syscfg(int write, int function, int device, 
> uint32_t *data)
>  uint32_t *syscfg = (uint32_t *) FIXMAP_ADDR(FIXMAP_MISC);
>  int ret = -1;
>  
> -set_fixmap(FIXMAP_MISC, V2M_SYS_MMIO_BASE >> PAGE_SHIFT, DEV_SHARED);
> +set_fixmap(FIXMAP_MISC, maddr_to_mfn(V2M_SYS_MMIO_BASE), DEV_SHARED);
>  
>  if ( syscfg[V2M_SYS_CFGCTRL/4] & V2M_SYS_CFG_START )
>  goto out;
> diff --git a/xen/drivers/video/arm_hdlcd.c b/xen/drivers/video/arm_hdlcd.c
> index 8241cae117..3915f731f5 100644
> --- a/xen/drivers/video/arm_hdlcd.c
> +++ b/xen/drivers/video/arm_hdlcd.c
> @@ -227,7 +227,7 @@ void __init video_init(void)
>  /* uses FIXMAP_MISC */
>  set_pixclock(videomode->pixclock);
>  
> -set_fixmap(FIXMAP_MISC, hdlcd_start >> PAGE_SHIFT, DEV_SHARED);
> +set_fixmap(FIXMAP_MISC, maddr_to_mfn(hdlcd_start), DEV_SHARED);
>  HDLCD[HDLCD_COMMAND] = 0;
>  
>  HDLCD[HDLCD_LINELENGTH] = videomode->xres * bytes_per_pixel;
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index 3dab6dc9a1..b2e7ea7761 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -176,7 +176,7 @@ extern void setup_xenheap_mappings(unsigned long 
> base_mfn, unsigned long nr_mfns
>  /* Map a frame table to cover physical addresses ps through pe */
>  extern void setup_frametable_mappings(paddr_t ps, paddr_t pe);
>  /* Map a 4k page in a fixmap entry */
> -extern void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes);
> +extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
>  /* Remove a mapping from a fixmap entry */
>  extern void clear_fixmap(unsigned map);
>  /* map a physical range in virtual memory */
> -- 
> 2.11.0

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

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

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Add more safety when using xenheap_mfn_*.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c| 16 
>  xen/arch/arm/setup.c | 18 +-
>  xen/include/asm-arm/mm.h | 11 ++-
>  3 files changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 0014c24ecc..fb01f01879 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -138,8 +138,8 @@ uint64_t init_ttbr;
>  static paddr_t phys_offset;
>  
>  /* Limits of the Xen heap */
> -unsigned long xenheap_mfn_start __read_mostly = ~0UL;
> -unsigned long xenheap_mfn_end __read_mostly;
> +mfn_t xenheap_mfn_start __read_mostly = INVALID_MFN;
> +mfn_t xenheap_mfn_end __read_mostly;

The patch is fine, but given that xenheap_mfn_end is unused on arm64, I
would like to make it arm32 only.


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

Re: [Xen-devel] [PATCH 15/24] xen/arm: Use the newly introduced MFN <-> MADDR and GFN <-> MADDR helpers

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Replace the following constructions:
> - _gfn(paddr_to_pfn(...))   => gaddr_to_gfn(...)
> - _mfn(paddr_to_pfn(...))   => maddr_to_mfn(...)
> - pfn_to_paddr(mfn_x(...))  => mfn_to_maddr(...)
> - pfn_to_paddr(gfn_x(...))  => gfn_to_gaddr(...)
> - _mfn(... >> PAGE_SHIFT)   => maddr_to_mfn(...)
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> ---
>  xen/arch/arm/domain_build.c  | 12 ++--
>  xen/arch/arm/gic-v2.c|  4 ++--
>  xen/arch/arm/kernel.c|  2 +-
>  xen/arch/arm/mem_access.c| 10 +-
>  xen/arch/arm/mm.c| 14 +++---
>  xen/arch/arm/p2m.c   | 10 +-
>  xen/arch/arm/platforms/exynos5.c |  8 
>  xen/arch/arm/platforms/omap5.c   | 16 
>  xen/arch/arm/traps.c | 14 +++---
>  xen/arch/arm/vgic-v2.c   |  4 ++--
>  10 files changed, 47 insertions(+), 47 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a3243bdb5d..c6776d76fc 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1007,9 +1007,9 @@ static int map_range_to_domain(const struct 
> dt_device_node *dev,
>  if ( need_mapping )
>  {
>  res = map_regions_p2mt(d,
> -   _gfn(paddr_to_pfn(addr)),
> +   gaddr_to_gfn(addr),
> PFN_UP(len),
> -   _mfn(paddr_to_pfn(addr)),
> +   maddr_to_mfn(addr),
> mr_data->p2mt);
>  
>  if ( res < 0 )
> @@ -1544,9 +1544,9 @@ static void acpi_map_other_tables(struct domain *d)
>  addr = acpi_gbl_root_table_list.tables[i].address;
>  size = acpi_gbl_root_table_list.tables[i].length;
>  res = map_regions_p2mt(d,
> -   _gfn(paddr_to_pfn(addr)),
> +   gaddr_to_gfn(addr),
> PFN_UP(size),
> -   _mfn(paddr_to_pfn(addr)),
> +   maddr_to_mfn(addr),
> p2m_mmio_direct_c);
>  if ( res )
>  {
> @@ -1901,7 +1901,7 @@ static int prepare_acpi(struct domain *d, struct 
> kernel_info *kinfo)
>  
>  /* Map the EFI and ACPI tables to Dom0 */
>  rc = map_regions_p2mt(d,
> -  _gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
> +  gaddr_to_gfn(d->arch.efi_acpi_gpa),
>PFN_UP(d->arch.efi_acpi_len),
>_mfn(virt_to_mfn(d->arch.efi_acpi_table)),
>p2m_mmio_direct_c);
> @@ -2014,7 +2014,7 @@ static void initrd_load(struct kernel_info *kinfo)
>  return;
>  }
>  
> -dst = map_domain_page(_mfn(paddr_to_pfn(ma)));
> +dst = map_domain_page(maddr_to_mfn(ma));
>  
>  copy_from_paddr(dst + s, paddr + offs, l);
>  
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 0482b1fe32..5bf7d35a7e 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -597,9 +597,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain 
> *d)
> d->domain_id, v2m_data->addr, v2m_data->size,
> v2m_data->spi_start, v2m_data->nr_spis);
>  
> -ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
> +ret = map_mmio_regions(d, gaddr_to_gfn(v2m_data->addr),
> PFN_UP(v2m_data->size),
> -   _mfn(paddr_to_pfn(v2m_data->addr)));
> +   maddr_to_mfn(v2m_data->addr));
>  if ( ret )
>  {
>  printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 0ed8b6005c..1b32d55284 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -183,7 +183,7 @@ static void kernel_zimage_load(struct kernel_info *info)
>  return;
>  }
>  
> -dst = map_domain_page(_mfn(paddr_to_pfn(ma)));
> +dst = map_domain_page(maddr_to_mfn(ma));
>  
>  copy_from_paddr(dst + s, paddr + offs, l);
>  
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index 04b1506b00..bcf49f5c15 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -113,7 +113,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>  if ( rc < 0 )
>  goto err;
>  
> -gfn = _gfn(paddr_to_pfn(ipa));
> +gfn = gaddr_to_gfn(ipa);
>  
>  /*
>   * We do this first as this is faster in the default case when no
> @@ -203,7 +203,7 @@ bool_t 

Re: [Xen-devel] [PATCH 14/24] xen/arm: Introduce wrappers for MFN <-> MADDR and GFN <-> GADDR

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The new wrappers will add more safety when converting an address to a
> frame number (either machine or guest). A follow-up patch will use them
> to simplify the code.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/include/asm-arm/mm.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index cc3220a6b7..a42da20f0a 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -214,6 +214,10 @@ static inline void __iomem *ioremap_wc(paddr_t start, 
> size_t len)
>  #define pfn_to_paddr(pfn) ((paddr_t)(pfn) << PAGE_SHIFT)
>  #define paddr_to_pfn(pa)  ((unsigned long)((pa) >> PAGE_SHIFT))
>  #define paddr_to_pdx(pa)pfn_to_pdx(paddr_to_pfn(pa))
> +#define gfn_to_gaddr(gfn)   pfn_to_paddr(gfn_x(gfn))
> +#define gaddr_to_gfn(ga)_gfn(paddr_to_pfn(ga))
> +#define mfn_to_maddr(mfn)   pfn_to_paddr(mfn_x(mfn))
> +#define maddr_to_mfn(ma)_mfn(paddr_to_pfn(ma))
>  #define vmap_to_mfn(va) paddr_to_pfn(virt_to_maddr((vaddr_t)va))
>  #define vmap_to_page(va)mfn_to_page(vmap_to_mfn(va))
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 13/24] xen/arm: traps: Replace p2m_lookup(..., ..., NULL) by gfn_to_mfn(..., ...)

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> gfn_to_mfn is a wrapper of p2m_lookup which does not return the
> p2m_type.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/traps.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 6cf9ee7244..ce19021f01 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2481,7 +2481,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
>  uint32_t *first = NULL, *second = NULL;
>  mfn_t mfn;
>  
> -mfn = p2m_lookup(d, _gfn(paddr_to_pfn(ttbr0)), NULL);
> +mfn = gfn_to_mfn(d, _gfn(paddr_to_pfn(ttbr0)));
>  
>  printk("dom%d VA 0x%08"PRIvaddr"\n", d->domain_id, addr);
>  printk("TTBCR: 0x%08"PRIregister"\n", ttbcr);
> @@ -2513,7 +2513,7 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
>(first[offset] & 0x2) )
>  goto done;
>  
> -mfn = p2m_lookup(d, _gfn(paddr_to_pfn(first[offset])), NULL);
> +mfn = gfn_to_mfn(d, _gfn(paddr_to_pfn(first[offset])));
>  
>  if ( mfn_eq(mfn, INVALID_MFN) )
>  {
> @@ -2619,7 +2619,7 @@ static void do_trap_instr_abort_guest(struct 
> cpu_user_regs *regs,
>   * with the Stage-2 page table. Walk the Stage-2 PT to check
>   * if the entry exists. If it's the case, return to the guest
>   */
> -mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(gpa)), NULL);
> +mfn = gfn_to_mfn(current->domain, _gfn(paddr_to_pfn(gpa)));
>  if ( !mfn_eq(mfn, INVALID_MFN) )
>  return;
>  }
> @@ -2759,7 +2759,7 @@ static void do_trap_data_abort_guest(struct 
> cpu_user_regs *regs,
>   * with the Stage-2 page table. Walk the Stage-2 PT to check
>   * if the entry exists. If it's the case, return to the guest
>   */
> -mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(info.gpa)), 
> NULL);
> +mfn = gfn_to_mfn(current->domain, _gfn(paddr_to_pfn(info.gpa)));
>  if ( !mfn_eq(mfn, INVALID_MFN) )
>  return;
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 12/24] xen/arm: Replace DIV_ROUND_UP(..., PAGE_SIZE) by PFN_UP(...)

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> DIV_ROUND_UP(..., PAGE_SIZE) and PFN_UP(...) are equivalent.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c | 4 ++--
>  xen/arch/arm/gic-v2.c   | 2 +-
>  xen/arch/arm/gic-v3.c   | 8 
>  xen/arch/arm/kernel.c   | 2 +-
>  4 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index a04c8862db..a3243bdb5d 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1008,7 +1008,7 @@ static int map_range_to_domain(const struct 
> dt_device_node *dev,
>  {
>  res = map_regions_p2mt(d,
> _gfn(paddr_to_pfn(addr)),
> -   DIV_ROUND_UP(len, PAGE_SIZE),
> +   PFN_UP(len),
> _mfn(paddr_to_pfn(addr)),
> mr_data->p2mt);
>  
> @@ -1545,7 +1545,7 @@ static void acpi_map_other_tables(struct domain *d)
>  size = acpi_gbl_root_table_list.tables[i].length;
>  res = map_regions_p2mt(d,
> _gfn(paddr_to_pfn(addr)),
> -   DIV_ROUND_UP(size, PAGE_SIZE),
> +   PFN_UP(size),
> _mfn(paddr_to_pfn(addr)),
> p2m_mmio_direct_c);
>  if ( res )
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index f8124e5e54..0482b1fe32 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -598,7 +598,7 @@ static int gicv2_map_hwdown_extra_mappings(struct domain 
> *d)
> v2m_data->spi_start, v2m_data->nr_spis);
>  
>  ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
> -   DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
> +   PFN_UP(v2m_data->size),
> _mfn(paddr_to_pfn(v2m_data->addr)));
>  if ( ret )
>  {
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index a559e5e260..bb845e955d 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1283,7 +1283,7 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  unsigned long mfn, nr;
>  
>  mfn = dbase >> PAGE_SHIFT;
> -nr = DIV_ROUND_UP(SZ_64K, PAGE_SIZE);
> +nr = PFN_UP(SZ_64K);
>  rc = iomem_deny_access(d, mfn, mfn + nr);
>  if ( rc )
>  return rc;
> @@ -1291,7 +1291,7 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  for ( i = 0; i < gicv3.rdist_count; i++ )
>  {
>  mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
> -nr = DIV_ROUND_UP(gicv3.rdist_regions[i].size, PAGE_SIZE);
> +nr = PFN_UP(gicv3.rdist_regions[i].size);
>  rc = iomem_deny_access(d, mfn, mfn + nr);
>  if ( rc )
>  return rc;
> @@ -1300,7 +1300,7 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  if ( cbase != INVALID_PADDR )
>  {
>  mfn = cbase >> PAGE_SHIFT;
> -nr = DIV_ROUND_UP(csize, PAGE_SIZE);
> +nr = PFN_UP(csize);
>  rc = iomem_deny_access(d, mfn, mfn + nr);
>  if ( rc )
>  return rc;
> @@ -1309,7 +1309,7 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  if ( vbase != INVALID_PADDR )
>  {
>  mfn = vbase >> PAGE_SHIFT;
> -nr = DIV_ROUND_UP(csize, PAGE_SIZE);
> +nr = PFN_UP(csize);
>  return iomem_deny_access(d, mfn, mfn + nr);
>  }
>  
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index e2512c4612..0ed8b6005c 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -312,7 +312,7 @@ static __init int kernel_decompress(struct bootmodule 
> *mod)
>   * Need to free pages after output_size here because they won't be
>   * freed by discard_initial_modules
>   */
> -i = DIV_ROUND_UP(output_size, PAGE_SIZE);
> +i = PFN_UP(output_size);
>  for ( ; i < (1 << kernel_order_out); i++ )
>  free_domheap_page(pages + i);
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 11/24] xen/arm: mm: Replace __va(pfn_to_paddr(...)) by mfn_to_virt

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> __va(pfn_to_paddr(...)) and mfn_to_virt are equivalent.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/mm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 08116679ec..f5df669d92 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -999,7 +999,7 @@ static int create_xen_entries(enum xenmap_operation op,
>  
>  BUG_ON(!xen_second[second_linear_offset(addr)].pt.valid);
>  
> -third = 
> __va(pfn_to_paddr(xen_second[second_linear_offset(addr)].pt.base));
> +third = mfn_to_virt(xen_second[second_linear_offset(addr)].pt.base);
>  
>  switch ( op ) {
>  case INSERT:
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 10/24] xen/arm: domain_build: Replace paddr_to_pfn(virt_to_maddr(.)) by virt_to_mfn(.)

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> paddr_to_pfn(virt_to_maddr(.)) and virt_to_mfn(.) are equivalent.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/domain_build.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 3abacc0d80..a04c8862db 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1903,7 +1903,7 @@ static int prepare_acpi(struct domain *d, struct 
> kernel_info *kinfo)
>  rc = map_regions_p2mt(d,
>_gfn(paddr_to_pfn(d->arch.efi_acpi_gpa)),
>PFN_UP(d->arch.efi_acpi_len),
> -  
> _mfn(paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table))),
> +  _mfn(virt_to_mfn(d->arch.efi_acpi_table)),
>p2m_mmio_direct_c);
>  if ( rc != 0 )
>  {
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 09/24] xen/arm: Define mfn_to_page/page_to_mfn in term of __mfn_to_page/__page_to_mfn

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> This is matching the x86 side where the __* version is used if you need
> to override the helpers in source files.
> 
> At the same time, move the non-underscore version at the end of the
> defintion and add a comment to explain them.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/include/asm-arm/mm.h | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
> index f6915ad882..cc3220a6b7 100644
> --- a/xen/include/asm-arm/mm.h
> +++ b/xen/include/asm-arm/mm.h
> @@ -203,10 +203,8 @@ static inline void __iomem *ioremap_wc(paddr_t start, 
> size_t len)
>  })
>  
>  /* Convert between machine frame numbers and page-info structures. */
> -#define mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - 
> frametable_base_pdx))
> -#define page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + 
> frametable_base_pdx)
> -#define __page_to_mfn(pg)  page_to_mfn(pg)
> -#define __mfn_to_page(mfn) mfn_to_page(mfn)
> +#define __mfn_to_page(mfn)  (frame_table + (pfn_to_pdx(mfn) - 
> frametable_base_pdx))
> +#define __page_to_mfn(pg)   pdx_to_pfn((unsigned long)((pg) - frame_table) + 
> frametable_base_pdx)
>  
>  /* Convert between machine addresses and page-info structures. */
>  #define maddr_to_page(ma) __mfn_to_page((ma) >> PAGE_SHIFT)
> @@ -264,6 +262,13 @@ static inline int gvirt_to_maddr(vaddr_t va, paddr_t 
> *pa, unsigned int flags)
>  #define virt_to_mfn(va)   (virt_to_maddr(va) >> PAGE_SHIFT)
>  #define mfn_to_virt(mfn)  (maddr_to_virt((paddr_t)(mfn) << PAGE_SHIFT))
>  
> +/*
> + * We define non-underscored wrappers for above conversion functions.
> + * These are overriden in various source files while underscored version
> + * remain intact.
> + */
> +#define mfn_to_page(mfn)__mfn_to_page(mfn)
> +#define page_to_mfn(pg) __page_to_mfn(pg)
>  
>  /* Convert between Xen-heap virtual addresses and page-info structures. */
>  static inline struct page_info *virt_to_page(const void *v)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 08/24] xen/arm: mm: Use typesafe MFN in mfn_to_xen_entry

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/mm.c | 33 +
>  1 file changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index d164ed2eda..08116679ec 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -259,7 +259,7 @@ void dump_hyp_walk(vaddr_t addr)
>   * We put the same permissions at every level, because they're ignored
>   * by the walker in non-leaf entries.
>   */
> -static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr)
> +static inline lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned attr)
>  {
>  lpae_t e = (lpae_t) {
>  .pt = {
> @@ -315,9 +315,9 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, 
> unsigned attr)
>  break;
>  }
>  
> -ASSERT(!(pfn_to_paddr(mfn) & ~PADDR_MASK));
> +ASSERT(!(pfn_to_paddr(mfn_x(mfn)) & ~PADDR_MASK));
>  
> -e.pt.base = mfn;
> +e.pt.base = mfn_x(mfn);
>  
>  return e;
>  }
> @@ -325,7 +325,7 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, 
> unsigned attr)
>  /* Map a 4k page in a fixmap entry */
>  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>  {
> -lpae_t pte = mfn_to_xen_entry(mfn, attributes);
> +lpae_t pte = mfn_to_xen_entry(_mfn(mfn), attributes);
>  pte.pt.table = 1; /* 4k mappings always have this bit set */
>  pte.pt.xn = 1;
>  write_pte(xen_fixmap + third_table_offset(FIXMAP_ADDR(map)), pte);
> @@ -363,7 +363,7 @@ static void __init create_mappings(lpae_t *second,
>  
>  count = nr_mfns / LPAE_ENTRIES;
>  p = second + second_linear_offset(virt_offset);
> -pte = mfn_to_xen_entry(base_mfn, WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(base_mfn), WRITEALLOC);
>  if ( granularity == 16 * LPAE_ENTRIES )
>  pte.pt.contig = 1;  /* These maps are in 16-entry contiguous chunks. 
> */
>  for ( i = 0; i < count; i++ )
> @@ -416,7 +416,7 @@ void *map_domain_page(mfn_t mfn)
>  else if ( map[slot].pt.avail == 0 )
>  {
>  /* Commandeer this 2MB slot */
> -pte = mfn_to_xen_entry(slot_mfn, WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(slot_mfn), WRITEALLOC);
>  pte.pt.avail = 1;
>  write_pte(map + slot, pte);
>  break;
> @@ -537,7 +537,7 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
>  {
>  paddr_t ma = va + phys_offset;
>  unsigned long mfn = ma >> PAGE_SHIFT;
> -return mfn_to_xen_entry(mfn, WRITEALLOC);
> +return mfn_to_xen_entry(_mfn(mfn), WRITEALLOC);
>  }
>  
>  /* Map the FDT in the early boot page table */
> @@ -646,7 +646,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  /* Initialise xen second level entries ... */
>  /* ... Xen's text etc */
>  
> -pte = mfn_to_xen_entry(xen_paddr>>PAGE_SHIFT, WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(xen_paddr>>PAGE_SHIFT), WRITEALLOC);
>  pte.pt.xn = 0;/* Contains our text mapping! */
>  xen_second[second_table_offset(XEN_VIRT_START)] = pte;
>  
> @@ -663,7 +663,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  
>  /* ... Boot Misc area for xen relocation */
>  dest_va = BOOT_RELOC_VIRT_START;
> -pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(xen_paddr >> PAGE_SHIFT), WRITEALLOC);
>  /* Map the destination in xen_second. */
>  xen_second[second_table_offset(dest_va)] = pte;
>  /* Map the destination in boot_second. */
> @@ -694,7 +694,7 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  unsigned long va = XEN_VIRT_START + (i << PAGE_SHIFT);
>  if ( !is_kernel(va) )
>  break;
> -pte = mfn_to_xen_entry(mfn, WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(mfn), WRITEALLOC);
>  pte.pt.table = 1; /* 4k mappings always have this bit set */
>  if ( is_kernel_text(va) || is_kernel_inittext(va) )
>  {
> @@ -764,7 +764,8 @@ int init_secondary_pagetables(int cpu)
>   * domheap mapping pages. */
>  for ( i = 0; i < DOMHEAP_SECOND_PAGES; i++ )
>  {
> -pte = mfn_to_xen_entry(virt_to_mfn(domheap+i*LPAE_ENTRIES), 
> WRITEALLOC);
> +pte = mfn_to_xen_entry(_mfn(virt_to_mfn(domheap+i*LPAE_ENTRIES)),
> +   WRITEALLOC);
>  pte.pt.table = 1;
>  
> write_pte([first_table_offset(DOMHEAP_VIRT_START+i*FIRST_SIZE)], pte);
>  }
> @@ -862,13 +863,13 @@ void __init setup_xenheap_mappings(unsigned long 
> base_mfn,
>  unsigned long first_mfn = alloc_boot_pages(1, 1);
>  
>  clear_page(mfn_to_virt(first_mfn));
> -pte = mfn_to_xen_entry(first_mfn, WRITEALLOC);
> +pte = 

Re: [Xen-devel] [PATCH 07/24] xen/arm: mm: Clean-up mfn_to_xen_entry

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The physical address is computed from the machine frame number, so
> checking if the physical address is page aligned is pointless.
> 
> Furthermore, directly assigned the MFN to the corresponding field in the
> entry rather than converting to a physical address and orring the value.
> It will avoid to rely on the field position and make the code clearer.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/mm.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 6f63e4315a..d164ed2eda 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -261,7 +261,6 @@ void dump_hyp_walk(vaddr_t addr)
>   */
>  static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr)
>  {
> -paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
>  lpae_t e = (lpae_t) {
>  .pt = {
>  .valid = 1,   /* Mappings are present */
> @@ -316,11 +315,9 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, 
> unsigned attr)
>  break;
>  }
>  
> -ASSERT(!(pa & ~PAGE_MASK));
> -ASSERT(!(pa & ~PADDR_MASK));
> +ASSERT(!(pfn_to_paddr(mfn) & ~PADDR_MASK));
>  
> -/* XXX shifts */
> -e.bits |= pa;
> +e.pt.base = mfn;
>  
>  return e;
>  }
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 06/24] xen/arm: mm: Fix coding style of mfn_to_xen_entry

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Fix the comment coding style and add a newline before the return.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/mm.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 587a6b3975..6f63e4315a 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -254,9 +254,11 @@ void dump_hyp_walk(vaddr_t addr)
>  dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
>  }
>  
> -/* Standard entry type that we'll use to build Xen's own pagetables.
> +/*
> + * Standard entry type that we'll use to build Xen's own pagetables.
>   * We put the same permissions at every level, because they're ignored
> - * by the walker in non-leaf entries. */
> + * by the walker in non-leaf entries.
> + */
>  static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr)
>  {
>  paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
> @@ -274,10 +276,12 @@ static inline lpae_t mfn_to_xen_entry(unsigned long 
> mfn, unsigned attr)
>  .xn = 1,  /* No need to execute outside .text */
>  .avail = 0,   /* Reference count for domheap mapping */
>  }};;
> -/* Setting the User bit is strange, but the ATS1H[RW] instructions
> +/*
> + * Setting the User bit is strange, but the ATS1H[RW] instructions
>   * don't seem to work otherwise, and since we never run on Xen
>   * pagetables in User mode it's OK.  If this changes, remember
> - * to update the hard-coded values in head.S too */
> + * to update the hard-coded values in head.S too.
> + */
>  
>  switch ( attr )
>  {
> @@ -298,7 +302,8 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, 
> unsigned attr)
>  break;
>  case UNCACHED:
>  case DEV_SHARED:
> -/* Shareability is ignored for non-Normal memory, Outer is as
> +/*
> + * Shareability is ignored for non-Normal memory, Outer is as
>   * good as anything.
>   *
>   * On ARMv8 sharability is ignored and explicitly treated as Outer
> @@ -314,8 +319,9 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, 
> unsigned attr)
>  ASSERT(!(pa & ~PAGE_MASK));
>  ASSERT(!(pa & ~PADDR_MASK));
>  
> -// XXX shifts
> +/* XXX shifts */
>  e.bits |= pa;
> +
>  return e;
>  }
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 05/24] xen/arm: mm: Move mfn_to_xen_entry from page.h to mm.c

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> The file mm.c is the only user of mfn_to_xen_entry. This will also help
> to use the typesafe MFN.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/mm.c  | 65 
> ++
>  xen/include/asm-arm/page.h | 65 
> --
>  2 files changed, 65 insertions(+), 65 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index b4ff777b55..587a6b3975 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -254,6 +254,71 @@ void dump_hyp_walk(vaddr_t addr)
>  dump_pt_walk(ttbr, addr, HYP_PT_ROOT_LEVEL, 1);
>  }
>  
> +/* Standard entry type that we'll use to build Xen's own pagetables.
> + * We put the same permissions at every level, because they're ignored
> + * by the walker in non-leaf entries. */
> +static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr)
> +{
> +paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
> +lpae_t e = (lpae_t) {
> +.pt = {
> +.valid = 1,   /* Mappings are present */
> +.table = 0,   /* Set to 1 for links and 4k maps */
> +.ai = attr,
> +.ns = 1,  /* Hyp mode is in the non-secure world */
> +.user = 1,/* See below */
> +.ro = 0,  /* Assume read-write */
> +.af = 1,  /* No need for access tracking */
> +.ng = 1,  /* Makes TLB flushes easier */
> +.contig = 0,  /* Assume non-contiguous */
> +.xn = 1,  /* No need to execute outside .text */
> +.avail = 0,   /* Reference count for domheap mapping */
> +}};;
> +/* Setting the User bit is strange, but the ATS1H[RW] instructions
> + * don't seem to work otherwise, and since we never run on Xen
> + * pagetables in User mode it's OK.  If this changes, remember
> + * to update the hard-coded values in head.S too */
> +
> +switch ( attr )
> +{
> +case BUFFERABLE:
> +/*
> + * ARM ARM: Overlaying the shareability attribute (DDI
> + * 0406C.b B3-1376 to 1377)
> + *
> + * A memory region with a resultant memory type attribute of Normal,
> + * and a resultant cacheability attribute of Inner Non-cacheable,
> + * Outer Non-cacheable, must have a resultant shareability attribute
> + * of Outer Shareable, otherwise shareability is UNPREDICTABLE.
> + *
> + * On ARMv8 sharability is ignored and explicitly treated as Outer
> + * Shareable for Normal Inner Non_cacheable, Outer Non-cacheable.
> + */
> +e.pt.sh = LPAE_SH_OUTER;
> +break;
> +case UNCACHED:
> +case DEV_SHARED:
> +/* Shareability is ignored for non-Normal memory, Outer is as
> + * good as anything.
> + *
> + * On ARMv8 sharability is ignored and explicitly treated as Outer
> + * Shareable for any device memory type.
> + */
> +e.pt.sh = LPAE_SH_OUTER;
> +break;
> +default:
> +e.pt.sh = LPAE_SH_INNER;  /* Xen mappings are SMP coherent */
> +break;
> +}
> +
> +ASSERT(!(pa & ~PAGE_MASK));
> +ASSERT(!(pa & ~PADDR_MASK));
> +
> +// XXX shifts
> +e.bits |= pa;
> +return e;
> +}
> +
>  /* Map a 4k page in a fixmap entry */
>  void set_fixmap(unsigned map, unsigned long mfn, unsigned attributes)
>  {
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index 497b4c86ad..3670ab665d 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -205,71 +205,6 @@ typedef union {
>  lpae_walk_t walk;
>  } lpae_t;
>  
> -/* Standard entry type that we'll use to build Xen's own pagetables.
> - * We put the same permissions at every level, because they're ignored
> - * by the walker in non-leaf entries. */
> -static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr)
> -{
> -paddr_t pa = ((paddr_t) mfn) << PAGE_SHIFT;
> -lpae_t e = (lpae_t) {
> -.pt = {
> -.valid = 1,   /* Mappings are present */
> -.table = 0,   /* Set to 1 for links and 4k maps */
> -.ai = attr,
> -.ns = 1,  /* Hyp mode is in the non-secure world */
> -.user = 1,/* See below */
> -.ro = 0,  /* Assume read-write */
> -.af = 1,  /* No need for access tracking */
> -.ng = 1,  /* Makes TLB flushes easier */
> -.contig = 0,  /* Assume non-contiguous */
> -.xn = 1,  /* No need to execute outside .text */
> -.avail = 0,   /* Reference count for domheap mapping */
> -}};;
> -/* Setting 

Re: [Xen-devel] [PATCH 04/24] xen/arm: mm: Introduce clear_table and use it

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Add a new helper clear_table to clear a page table entry and invalidate
> the cache.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 082c872c72..b4ff777b55 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -529,6 +529,13 @@ void __init remove_early_mappings(void)
>  
>  extern void relocate_xen(uint64_t ttbr, void *src, void *dst, size_t len);
>  
> +/* Clear a translation table and clean & invalidate the cache */
> +static void clear_table(void *table)

This could be a static inline. In any case:

Reviewed-by: Stefano Stabellini 


> +{
> +clear_page(table);
> +clean_and_invalidate_dcache_va_range(table, PAGE_SIZE);
> +}
> +
>  /* Boot-time pagetable setup.
>   * Changes here may need matching changes in head.S */
>  void __init setup_pagetables(unsigned long boot_phys_offset, paddr_t 
> xen_paddr)
> @@ -604,18 +611,13 @@ void __init setup_pagetables(unsigned long 
> boot_phys_offset, paddr_t xen_paddr)
>  
>  /* Clear the copy of the boot pagetables. Each secondary CPU
>   * rebuilds these itself (see head.S) */
> -memset(boot_pgtable, 0x0, PAGE_SIZE);
> -clean_and_invalidate_dcache(boot_pgtable);
> +clear_table(boot_pgtable);
>  #ifdef CONFIG_ARM_64
> -memset(boot_first, 0x0, PAGE_SIZE);
> -clean_and_invalidate_dcache(boot_first);
> -memset(boot_first_id, 0x0, PAGE_SIZE);
> -clean_and_invalidate_dcache(boot_first_id);
> +clear_table(boot_first);
> +clear_table(boot_first_id);
>  #endif
> -memset(boot_second, 0x0, PAGE_SIZE);
> -clean_and_invalidate_dcache(boot_second);
> -memset(boot_third, 0x0, PAGE_SIZE);
> -clean_and_invalidate_dcache(boot_third);
> +clear_table(boot_second);
> +clear_table(boot_third);
>  
>  /* Break up the Xen mapping into 4k pages and protect them separately. */
>  for ( i = 0; i < LPAE_ENTRIES; i++ )
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 03/24] xen/arm: setup: Remove bogus xenheap_mfn_end in setup_mm for arm64

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> xenheap_mfn_end is storing an MFN and not a physical address. Thankfully
> xenheap_mfn_end is not used in the arm64 code. So drop it.

That's fine, but in that case I would prefer to move the definition of
xenheap_mfn_end under #ifdef CONFIG_ARM_32. In fact, there is another
assignment of xenheap_mfn_end few lines below in the arm64 version of
setup_mm: don't we need to remove that too?


> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/setup.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index f00f29a45b..ab4d8e4218 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -654,8 +654,6 @@ static void __init setup_mm(unsigned long dtb_paddr, 
> size_t dtb_size)
>  if ( e > bank_end )
>  e = bank_end;
>  
> -xenheap_mfn_end = e;
> -
>  dt_unreserved_regions(s, e, init_boot_pages, 0);
>  s = n;
>  }
> -- 
> 2.11.0
> 

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

[Xen-devel] [distros-debian-wheezy test] 71566: tolerable trouble: broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   71534

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 02/24] xen/arm: gic-v2: Fix indentation in gicv2_map_hwdom_extra_mappings

[Stefano Stabellini]

On Tue, 13 Jun 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic-v2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 270a1362ec..f8124e5e54 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -598,8 +598,8 @@ static int gicv2_map_hwdown_extra_mappings(struct domain 
> *d)
> v2m_data->spi_start, v2m_data->nr_spis);
>  
>  ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
> -DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
> -_mfn(paddr_to_pfn(v2m_data->addr)));
> +   DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
> +   _mfn(paddr_to_pfn(v2m_data->addr)));
>  if ( ret )
>  {
>  printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 2/2] xen/arm: lpae: Fix comments coding style

[Andrew Cooper]

On 15/06/2017 21:30, Julien Grall wrote:
> Also adding one missing full stop.
>
> Signed-off-by: Julien Grall 
> ---
>  xen/include/asm-arm/lpae.h | 45 ++---
>  1 file changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index 1e6a68926e..6244240ca0 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -3,10 +3,12 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
> +/*
> + * WARNING!  Unlike the Intel pagetable code, where l1 is the lowest

As your changing the comment, it would be more correct to say "Unlike
the x86 pagetable code".  L1 through L4 is only the Xen naming scheme;
neither Intel nor AMD use it in their manuals.

~Andrew

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
110417
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
110417
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 110417
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
110417

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

version targeted for testing:
 xen  e197d29514165202308fe65db6effc4835aabfeb
baseline version:
 xen  91503b282eff582d74927ed25668fae65fd228ba

Last test of basis   110417  2017-06-13 21:31:36 Z2 days
Testing same since   110453  2017-06-14 16:28:42 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

[Xen-devel] [distros-debian-squeeze test] 71561: tolerable trouble: broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
71523
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 71523
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
71523
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
71523

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass

baseline version:
 flight   71523

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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

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

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


Push not applicable.


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-120 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 71541
 test-xtf-amd64-amd64-1 33 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 71541
 test-xtf-amd64-amd64-144 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 71541

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail   like 71541
 test-xtf-amd64-amd64-2   20 xtf/test-hvm32-invlpg~shadow fail   like 71541
 test-xtf-amd64-amd64-3  33 xtf/test-hvm32pae-invlpg~shadow fail like 71541
 test-xtf-amd64-amd64-2  33 xtf/test-hvm32pae-invlpg~shadow fail like 71541
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail   like 71541
 test-xtf-amd64-amd64-2   44 xtf/test-hvm64-invlpg~shadow fail   like 71541
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71541
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71541
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71541
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 71541
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 71541
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71541

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   65 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   65 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   65 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   65 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   65 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  2893fce1b7a748fd13b0fb8cbed9e8f7b62ef07b
baseline version:
 xen  314915cb4aa3865c8623516b65216b974a7d4e9a

Last test of basis71541  2017-06-11 09:13:50 Z4 days
Testing same since71559  2017-06-13 14:14:04 Z2 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Mark Rutland 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Chen 
  Wei Liu 

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

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Volodymyr Babchuk]

On 15 June 2017 at 23:14, Stefano Stabellini  wrote:
>> > If so, would Wednesday the 28th of June at 9AM PST work for you?
>> I would prefer later time (like 5PM), but 9AM also works for me.
>
> Wait, did you get the timezone right?
>
> 1) 9AM PST = 5PM London = 7PM Kyiv
>
>
> I could do 5PM PST without troubles, but:
>
> 2) 5PM PST = 1AM London = 3AM Kyiv
>
>
> I think it's best to stay with the first option :-)

Oh, it is *PM*. Yeah, my fault. I prefer first option, indeed :-)

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

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

[Xen-devel] [PATCH 1/2] xen/arm: Move LPAE definition in a separate header

[Julien Grall]

page.h is getting bigger. Move out every LPAE definitions in a separate
header. There is no functional changes.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/lpae.h | 169 +
 xen/include/asm-arm/page.h | 152 +---
 2 files changed, 170 insertions(+), 151 deletions(-)
 create mode 100644 xen/include/asm-arm/lpae.h

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

[Xen-devel] [PATCH 2/2] xen/arm: lpae: Fix comments coding style

[Julien Grall]

Also adding one missing full stop.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/lpae.h | 45 ++---
 1 file changed, 30 insertions(+), 15 deletions(-)

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


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

[Xen-devel] [PATCH 0/2] xen/arm: Move LPAE definition in a separate header.

[Julien Grall]

This small patch series is moving out LPAE definition from page.h. This is
based on my series "xen/arm: Extend usage of typesafe MFN" [1] due to a small
conflict with patch #5.

Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-06/msg01361.html

Julien Grall (2):
  xen/arm: Move LPAE definition in a separate header
  xen/arm: lpae: Fix comments coding style

 xen/include/asm-arm/lpae.h | 184 +
 xen/include/asm-arm/page.h | 152 +
 2 files changed, 185 insertions(+), 151 deletions(-)
 create mode 100644 xen/include/asm-arm/lpae.h

-- 
2.11.0


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

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Stefano Stabellini]

On Thu, 15 Jun 2017, Volodymyr Babchuk wrote:
> Hello Stefano,
> 
> On 15 June 2017 at 21:21, Stefano Stabellini  wrote:
> > Would you be up for joining a conf call to discuss EL0 apps and stubdoms
> > on ARM in preparation for Xen Developer Summit?
> >
> > If so, would Wednesday the 28th of June at 9AM PST work for you?
> I would prefer later time (like 5PM), but 9AM also works for me.
 
Wait, did you get the timezone right?

1) 9AM PST = 5PM London = 7PM Kyiv


I could do 5PM PST without troubles, but:

2) 5PM PST = 1AM London = 3AM Kyiv


I think it's best to stay with the first option :-)

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

Re: [Xen-devel] [RFC PATCH v3 06/10] arm/mem_access: Introduce GV2M_EXEC permission

[Julien Grall]

Hi Sergej,

On 06/15/2017 12:05 PM, Sergej Proskurin wrote:

We extend the current implementation by an additional permission,
GV2M_EXEC, which will be used to describe execute permissions of PTE's
as part of our guest translation table walk implementation.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v3 04/10] arm/mem_access: Add short-descriptor pte typedefs

[Julien Grall]

Hi Sergej,

On 06/15/2017 12:05 PM, Sergej Proskurin wrote:

The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Add more short-descriptor related pte typedefs that will be used by
 the following commits.
---
  xen/include/asm-arm/page.h | 104 +
  1 file changed, 104 insertions(+)


page.h is already big and I don't like the idea of mixing lpae and short 
descriptor in the same header. Hence the latter is only used for guest 
page table walk.


As mentioned in a follow-up patch, I would like to start moving out LPAE 
code and short descriptor code in separate header.


I am happy if you only move short-descriptor for now.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v3 05/10] arm/p2m: Make PTE helpers publicly available

[Julien Grall]

Hi Sergej,

On 06/15/2017 12:05 PM, Sergej Proskurin wrote:

In this commit we make the p2m_* helpers, which access PTE properties in
a simplified way, publicly available. This is due to the fact that the
helpers will be used in guest_walk.c in one of the following commits.

Signed-off-by: Sergej Proskurin 
---
Cc:
---
  xen/arch/arm/p2m.c| 23 ---
  xen/include/asm-arm/p2m.h | 27 +++
  2 files changed, 27 insertions(+), 23 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b7bbea1d81..eecbcdf870 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -46,29 +46,6 @@ static const paddr_t level_masks[] =
  static const uint8_t level_orders[] =
  { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
  
-static inline bool_t p2m_valid(lpae_t pte)

-{
-return pte.p2m.valid;
-}
-/*
- * These two can only be used on L0..L2 ptes because L3 mappings set
- * the table bit and therefore these would return the opposite to what
- * you would expect.
- */
-static inline bool_t p2m_table(lpae_t pte)
-{
-return p2m_valid(pte) && pte.p2m.table;
-}
-static inline bool_t p2m_mapping(lpae_t pte)
-{
-return p2m_valid(pte) && !pte.p2m.table;
-}
-
-static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
-{
-return (level < 3) && p2m_mapping(pte);
-}
-
  static void p2m_flush_tlb(struct p2m_domain *p2m);
  
  /* Unlock the flush and do a P2M TLB flush if necessary */

diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 18c57f936e..8053f2a0cf 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -198,6 +198,33 @@ static inline int p2m_is_write_locked(struct p2m_domain 
*p2m)
  return rw_is_write_locked(>lock);
  }
  
+/*

+ * Helpers to lookup properties of ptes.
+ */
+
+static inline bool_t p2m_valid(lpae_t pte)


The name implies they should only be used for stage-2 page table. But 
you are using for other place such as for stage-1 page table.


This means that they are in the wrong header (they should go in page.h).

I would actually start to split page.h with lpae.h and 
short-descriptor.h to avoid mixing two type of page table in the same 
header. Note that I would be happy if you keep lpae in page.h for the 
time being. But short-descriptor should definitely go in a separate file.


I would also rename the helpers you move to lpae_*.


+{
+return pte.p2m.valid;


As you plan to re-use for other things than stage-2 page-table, you use 
pte.walk rather than pte.p2m.


All those comments applies for the rest of the helpers.


+}
+/*
+ * These two can only be used on L0..L2 ptes because L3 mappings set
+ * the table bit and therefore these would return the opposite to what
+ * you would expect.
+ */
+static inline bool_t p2m_table(lpae_t pte)
+{
+return p2m_valid(pte) && pte.p2m.table;
+}
+static inline bool_t p2m_mapping(lpae_t pte)
+{
+return p2m_valid(pte) && !pte.p2m.table;
+}
+
+static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
+{
+return (level < 3) && p2m_mapping(pte);
+}
+
  /* Look up the MFN corresponding to a domain's GFN. */
  mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v3 04/10] arm/mem_access: Add short-descriptor pte typedefs

[Andrew Cooper]

On 15/06/17 20:44, Julien Grall wrote:
> Hi Andrew,
>
> On 06/15/2017 01:03 PM, Andrew Cooper wrote:
>> On 15/06/17 12:05, Sergej Proskurin wrote:
>>> The current implementation does not provide appropriate types for
>>> short-descriptor translation table entries. As such, this commit
>>> adds new
>>> types, which simplify managing the respective translation table
>>> entries.
>>>
>>> Signed-off-by: Sergej Proskurin 
>>> ---
>>> Cc: Stefano Stabellini 
>>> Cc: Julien Grall 
>>> ---
>>> v3: Add more short-descriptor related pte typedefs that will be used by
>>>  the following commits.
>>> ---
>>>   xen/include/asm-arm/page.h | 104
>>> +
>>>   1 file changed, 104 insertions(+)
>>>
>>> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
>>> index e2e4b597a5..7a4aa64144 100644
>>> --- a/xen/include/asm-arm/page.h
>>> +++ b/xen/include/asm-arm/page.h
>>> @@ -205,6 +205,110 @@ typedef union {
>>>   lpae_walk_t walk;
>>>   } lpae_t;
>>>   +/*
>>> + *  Comprises bits of the level 1 short-descriptor format representing
>>> + *  a section.
>>> + */
>>> +typedef struct __packed {
>>> +unsigned int pxn:1; /* Privileged Execute Never */
>>
>> (I'm not an ARM maintainer, but) can I recommend using bool bitfields
>> for boolean fields like this.
>
> I was not aware it was possible to do boolean fields. I am all for it.

There isn't a good example in xen yet, but
http://xenbits.xen.org/gitweb/?p=xtf.git;a=commitdiff;h=f099211f2ebdadf61ae6416559220d69b788cd2b
is the XTF work I'm basing some imminent Xen improvements on.

~Andrew

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

Re: [Xen-devel] [RFC PATCH v3 04/10] arm/mem_access: Add short-descriptor pte typedefs

[Julien Grall]

Hi Andrew,

On 06/15/2017 01:03 PM, Andrew Cooper wrote:

On 15/06/17 12:05, Sergej Proskurin wrote:

The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Add more short-descriptor related pte typedefs that will be used by
 the following commits.
---
  xen/include/asm-arm/page.h | 104 +
  1 file changed, 104 insertions(+)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index e2e4b597a5..7a4aa64144 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -205,6 +205,110 @@ typedef union {
  lpae_walk_t walk;
  } lpae_t;
  
+/*

+ *  Comprises bits of the level 1 short-descriptor format representing
+ *  a section.
+ */
+typedef struct __packed {
+unsigned int pxn:1; /* Privileged Execute Never */


(I'm not an ARM maintainer, but) can I recommend using bool bitfields
for boolean fields like this.


I was not aware it was possible to do boolean fields. I am all for it.



There's no difference when using the structure for reading data, but it
helps reduce subtle bugs such as

foo.pxn = (flags & NO_EXECUTE);

when using the structures to create a new value, or modify existing ones.

~Andrew



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH v3 03/10] arm/mem_access: Add defines supporting PTs with varying page sizes

[Julien Grall]

Hi Sergej,

On 06/15/2017 12:05 PM, Sergej Proskurin wrote:

The ARMv8 architecture supports pages with different (4K, 16K, and 64K) sizes.
To enable guest page table walks for various configurations, this commit
extends the defines and helpers of the current implementation.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Eliminate redundant macro definitions by introducing generic macros.
---
  xen/include/asm-arm/page.h | 45 +
  1 file changed, 45 insertions(+)

diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 497b4c86ad..e2e4b597a5 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -500,6 +500,51 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr, 
unsigned int flags)
  
  #define PAGE_ALIGN(x) (((x) + PAGE_SIZE - 1) & PAGE_MASK)
  
+#define LPAE_SHIFT_4K   (9)

+#define LPAE_SHIFT_16K  (11)
+#define LPAE_SHIFT_64K  (13)
+
+#define lpae_entries(gran)  (_AC(1,U) << LPAE_SHIFT_##gran)
+#define lpae_entry_mask(gran)   (lpae_entries(gran) - 1)
+
+#define PAGE_SHIFT_4K   (12)
+#define PAGE_SHIFT_16K  (14)
+#define PAGE_SHIFT_64K  (16)
+
+#define third_shift(gran)   (PAGE_SHIFT_##gran)
+#define third_size(gran)((paddr_t)1 << third_shift(gran))
+
+#define second_shift(gran)  (third_shift(gran) + LPAE_SHIFT_##gran)
+#define second_size(gran)   ((paddr_t)1 << second_shift(gran))
+
+#define first_shift(gran)   (second_shift(gran) + LPAE_SHIFT_##gran)
+#define first_size(gran)((paddr_t)1 << first_shift(gran))
+
+/* Note that there is no zeroeth lookup level with a 64K granule size. */
+#define zeroeth_shift(gran) (first_shift(gran) + LPAE_SHIFT_##gran)
+#define zeroeth_size(gran)  ((paddr_t)1 << zeroeth_shift(gran))
+
+#define GUEST_TABLE_OFFSET(offs, gran)  ((paddr_t)(offs) & 
lpae_entry_mask(gran))
+#define third_guest_table_offset(va, gran)  GUEST_TABLE_OFFSET((va >> 
third_shift(gran)), gran)
+#define second_guest_table_offset(va, gran) GUEST_TABLE_OFFSET((va >> 
second_shift(gran)), gran)
+#define first_guest_table_offset(va, gran)  GUEST_TABLE_OFFSET((va >> 
first_shift(gran)), gran)
+#define zeroeth_guest_table_offset(va, gran)GUEST_TABLE_OFFSET((va >> 
zeroeth_shift(gran)), gran)
+
+#define third_guest_table_offset_4k(va) third_guest_table_offset(va, 
4K)
+#define third_guest_table_offset_16k(va)third_guest_table_offset(va, 
16K)
+#define third_guest_table_offset_64k(va)third_guest_table_offset(va, 
64K)
+
+#define second_guest_table_offset_4k(va)second_guest_table_offset(va, 
4K)
+#define second_guest_table_offset_16k(va)   second_guest_table_offset(va, 
16K)
+#define second_guest_table_offset_64k(va)   second_guest_table_offset(va, 
64K)
+
+#define first_guest_table_offset_4k(va) first_guest_table_offset(va, 
4K)
+#define first_guest_table_offset_16k(va)first_guest_table_offset(va, 
16K)
+#define first_guest_table_offset_64k(va)first_guest_table_offset(va, 
64K)
+
+#define zeroeth_guest_table_offset_4k(va)   zeroeth_guest_table_offset(va, 
4K)
+#define zeroeth_guest_table_offset_16k(va)  zeroeth_guest_table_offset(va, 
16K)


So this is really confusing to group by level rather than granularity.

Also, I still think you can make this more generic by introducing macros 
that will generate helpers (see VGIC_REG_HELPERS).


This would require to use static inline function, but at least it would 
avoid to duplicate some much code.



+
  #endif /* __ARM_PAGE_H__ */
  
  /*




Cheers,

--
Julien Grall

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

Re: [Xen-devel] EL0 app, stubdoms on ARM conf call

[Volodymyr Babchuk]

Hello Stefano,

On 15 June 2017 at 21:21, Stefano Stabellini  wrote:
> Would you be up for joining a conf call to discuss EL0 apps and stubdoms
> on ARM in preparation for Xen Developer Summit?
>
> If so, would Wednesday the 28th of June at 9AM PST work for you?
I would prefer later time (like 5PM), but 9AM also works for me.


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

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

[Xen-devel] [PATCH v4 12/18] xen/pvcalls: implement poll command

[Stefano Stabellini]

Implement poll on passive sockets by requesting a delayed response with
mappass->reqcopy, and reply back when there is data on the passive
socket.

Poll on active socket is unimplemented as by the spec, as the frontend
should just wait for events and check the indexes on the indexes page.

Only support one outstanding poll (or accept) request for every passive
socket at any given time.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 73 +-
 1 file changed, 72 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 701f1fc..be85977 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -348,11 +348,33 @@ static void __pvcalls_back_accept(struct work_struct 
*work)
 static void pvcalls_pass_sk_data_ready(struct sock *sock)
 {
struct sockpass_mapping *mappass = sock->sk_user_data;
+   struct pvcalls_fedata *fedata;
+   struct xen_pvcalls_response *rsp;
+   unsigned long flags;
+   int notify;
 
if (mappass == NULL)
return;
 
-   queue_work(mappass->wq, >register_work);
+   fedata = mappass->fedata;
+   spin_lock_irqsave(>copy_lock, flags);
+   if (mappass->reqcopy.cmd == PVCALLS_POLL) {
+   rsp = RING_GET_RESPONSE(>ring, 
fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = mappass->reqcopy.req_id;
+   rsp->u.poll.id = mappass->reqcopy.u.poll.id;
+   rsp->cmd = mappass->reqcopy.cmd;
+   rsp->ret = 0;
+
+   mappass->reqcopy.cmd = 0;
+   spin_unlock_irqrestore(>copy_lock, flags);
+
+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>ring, notify);
+   if (notify)
+   notify_remote_via_irq(mappass->fedata->irq);
+   } else {
+   spin_unlock_irqrestore(>copy_lock, flags);
+   queue_work(mappass->wq, >register_work);
+   }
 }
 
 static int pvcalls_back_bind(struct xenbus_device *dev,
@@ -499,6 +521,55 @@ static int pvcalls_back_accept(struct xenbus_device *dev,
 static int pvcalls_back_poll(struct xenbus_device *dev,
 struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   struct sockpass_mapping *mappass;
+   struct xen_pvcalls_response *rsp;
+   struct inet_connection_sock *icsk;
+   struct request_sock_queue *queue;
+   unsigned long flags;
+   int ret;
+   bool data;
+
+   fedata = dev_get_drvdata(>dev);
+
+   mappass = radix_tree_lookup(>socketpass_mappings, 
req->u.poll.id);
+   if (mappass == NULL)
+   return -EINVAL;
+
+   /*
+* Limitation of the current implementation: only support one
+* concurrent accept or poll call on one socket.
+*/
+   spin_lock_irqsave(>copy_lock, flags);
+   if (mappass->reqcopy.cmd != 0) {
+   ret = -EINTR;
+   goto out;
+   }
+
+   mappass->reqcopy = *req;
+   icsk = inet_csk(mappass->sock->sk);
+   queue = >icsk_accept_queue;
+   spin_lock(>rskq_lock);
+   data = queue->rskq_accept_head != NULL;
+   spin_unlock(>rskq_lock);
+   if (data) {
+   mappass->reqcopy.cmd = 0;
+   ret = 0;
+   goto out;
+   }
+   spin_unlock_irqrestore(>copy_lock, flags);
+
+   /* Tell the caller we don't need to send back a notification yet */
+   return -1;
+
+out:
+   spin_unlock_irqrestore(>copy_lock, flags);
+
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.poll.id = req->u.poll.id;
+   rsp->ret = ret;
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 00/18] introduce the Xen PV Calls backend

[Stefano Stabellini]

Hi all,

this series introduces the backend for the newly introduced PV Calls
procotol.

PV Calls is a paravirtualized protocol that allows the implementation of
a set of POSIX functions in a different domain. The PV Calls frontend
sends POSIX function calls to the backend, which implements them and
returns a value to the frontend and acts on the function call.

For more information about PV Calls, please read:

https://xenbits.xen.org/docs/unstable/misc/pvcalls.html

I tried to split the source code into small pieces to make it easier to
read and understand. Please review!


Changes in v4:
- add reviewed-bys
- fix return values of many functions
- remove pointless initializers
- print a warning if ring_order > MAX_RING_ORDER
- remove map->ioworker.cpu
- use queue_work instead of queue_work_on
- add sock_release() on error paths where appropriate
- add a comment in __pvcalls_back_accept about racing with
  pvcalls_back_accept and atomicity of reqcopy
- remove unneded (void*) casts
- remove unneded {}
- fix backend_disconnect if !mappass
- remove pointless continue in backend_disconnect
- remove pointless memset of _back_global
- pass *opaque to pvcalls_conn_back_read
- improve WARN_ON in pvcalls_conn_back_read
- fix error checks in pvcalls_conn_back_write
- XEN_PVCALLS_BACKEND depends on XEN_BACKEND
- rename priv to fedata across all patches

Changes in v3:
- added reviewed-bys
- return err from pvcalls_back_probe
- remove old comments
- use a xenstore transaction in pvcalls_back_probe
- ignore errors from xenbus_switch_state
- rename pvcalls_back_priv to pvcalls_fedata
- remove addr from backend_connect
- remove priv->work, add comment about theoretical race
- use IPPROTO_IP
- refactor active socket allocation in a single new function

Changes in v2:
- allocate one ioworker per socket (rather than 1 per vcpu)
- rename privs to frontends
- add newlines
- define "1" in the public header
- better error returns in pvcalls_back_probe
- do not set XenbusStateClosed twice in set_backend_state
- add more comments
- replace rw_semaphore with semaphore
- rename pvcallss to socket_lock
- move xenbus_map_ring_valloc closer to first use in backend_connect
- use more traditional return codes from pvcalls_back_handle_cmd and
  callees
- remove useless dev == NULL checks
- replace lock_sock with more appropriate and fine grained socket locks


Stefano Stabellini (18):
  xen: introduce the pvcalls interface header
  xen/pvcalls: introduce the pvcalls xenbus backend
  xen/pvcalls: initialize the module and register the xenbus backend
  xen/pvcalls: xenbus state handling
  xen/pvcalls: connect to a frontend
  xen/pvcalls: handle commands from the frontend
  xen/pvcalls: implement socket command
  xen/pvcalls: implement connect command
  xen/pvcalls: implement bind command
  xen/pvcalls: implement listen command
  xen/pvcalls: implement accept command
  xen/pvcalls: implement poll command
  xen/pvcalls: implement release command
  xen/pvcalls: disconnect and module_exit
  xen/pvcalls: implement the ioworker functions
  xen/pvcalls: implement read
  xen/pvcalls: implement write
  xen: introduce a Kconfig option to enable the pvcalls backend

 drivers/xen/Kconfig|   12 +
 drivers/xen/Makefile   |1 +
 drivers/xen/pvcalls-back.c | 1232 
 include/xen/interface/io/pvcalls.h |  121 
 include/xen/interface/io/ring.h|2 +
 5 files changed, 1368 insertions(+)
 create mode 100644 drivers/xen/pvcalls-back.c
 create mode 100644 include/xen/interface/io/pvcalls.h

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

[Xen-devel] [PATCH v4 14/18] xen/pvcalls: disconnect and module_exit

[Stefano Stabellini]

Implement backend_disconnect. Call pvcalls_back_release_active on active
sockets and pvcalls_back_release_passive on passive sockets.

Implement module_exit by calling backend_disconnect on frontend
connections.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 47 ++
 1 file changed, 47 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index afc9575..94e4c3f 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -806,6 +806,37 @@ static int backend_connect(struct xenbus_device *dev)
 
 static int backend_disconnect(struct xenbus_device *dev)
 {
+   struct pvcalls_fedata *fedata;
+   struct sock_mapping *map, *n;
+   struct sockpass_mapping *mappass;
+   struct radix_tree_iter iter;
+   void **slot;
+
+
+   fedata = dev_get_drvdata(>dev);
+
+   list_for_each_entry_safe(map, n, >socket_mappings, list)
+   pvcalls_back_release_active(dev, fedata, map);
+
+   radix_tree_for_each_slot(slot, >socketpass_mappings, , 0) {
+   mappass = radix_tree_deref_slot(slot);
+   if (!mappass)
+   continue;
+   if (radix_tree_exception(mappass)) {
+   if (radix_tree_deref_retry(mappass))
+   slot = radix_tree_iter_retry();
+   } else
+   pvcalls_back_release_passive(dev, fedata, mappass);
+   }
+
+   xenbus_unmap_ring_vfree(dev, fedata->sring);
+   unbind_from_irqhandler(fedata->irq, dev);
+
+   list_del(>list);
+   destroy_workqueue(fedata->wq);
+   kfree(fedata);
+   dev_set_drvdata(>dev, NULL);
+
return 0;
 }
 
@@ -999,3 +1030,19 @@ static int __init pvcalls_back_init(void)
return 0;
 }
 module_init(pvcalls_back_init);
+
+static void __exit pvcalls_back_fin(void)
+{
+   struct pvcalls_fedata *fedata, *nfedata;
+
+   down(_back_global.frontends_lock);
+   list_for_each_entry_safe(fedata, nfedata, 
_back_global.frontends,
+list) {
+   backend_disconnect(fedata->dev);
+   }
+   up(_back_global.frontends_lock);
+
+   xenbus_unregister_driver(_back_driver);
+}
+
+module_exit(pvcalls_back_fin);
-- 
1.9.1


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

[Xen-devel] [PATCH v4 04/18] xen/pvcalls: xenbus state handling

[Stefano Stabellini]

Introduce the code to handle xenbus state changes.

Implement the probe function for the pvcalls backend. Write the
supported versions, max-page-order and function-calls nodes to xenstore,
as required by the protocol.

Introduce stub functions for disconnecting/connecting to a frontend.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 152 +
 1 file changed, 152 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 9044cf2..7bce750 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -25,20 +25,172 @@
 #include 
 #include 
 
+#define PVCALLS_VERSIONS "1"
+#define MAX_RING_ORDER XENBUS_MAX_RING_GRANT_ORDER
+
 struct pvcalls_back_global {
struct list_head frontends;
struct semaphore frontends_lock;
 } pvcalls_back_global;
 
+static int backend_connect(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static int backend_disconnect(struct xenbus_device *dev)
+{
+   return 0;
+}
+
 static int pvcalls_back_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
+   int err, abort;
+   struct xenbus_transaction xbt;
+
+again:
+   abort = 1;
+
+   err = xenbus_transaction_start();
+   if (err) {
+   pr_warn("%s cannot create xenstore transaction\n", __func__);
+   return err;
+   }
+
+   err = xenbus_printf(xbt, dev->nodename, "versions", "%s",
+   PVCALLS_VERSIONS);
+   if (err) {
+   pr_warn("%s write out 'version' failed\n", __func__);
+   goto abort;
+   }
+
+   err = xenbus_printf(xbt, dev->nodename, "max-page-order", "%u",
+   MAX_RING_ORDER);
+   if (err) {
+   pr_warn("%s write out 'max-page-order' failed\n", __func__);
+   goto abort;
+   }
+
+   err = xenbus_printf(xbt, dev->nodename, "function-calls",
+   XENBUS_FUNCTIONS_CALLS);
+   if (err) {
+   pr_warn("%s write out 'function-calls' failed\n", __func__);
+   goto abort;
+   }
+
+   abort = 0;
+abort:
+   err = xenbus_transaction_end(xbt, abort);
+   if (err) {
+   if (err == -EAGAIN && !abort)
+   goto again;
+   pr_warn("%s cannot complete xenstore transaction\n", __func__);
+   return err;
+   }
+
+   xenbus_switch_state(dev, XenbusStateInitWait);
+
return 0;
 }
 
+static void set_backend_state(struct xenbus_device *dev,
+ enum xenbus_state state)
+{
+   while (dev->state != state) {
+   switch (dev->state) {
+   case XenbusStateClosed:
+   switch (state) {
+   case XenbusStateInitWait:
+   case XenbusStateConnected:
+   xenbus_switch_state(dev, XenbusStateInitWait);
+   break;
+   case XenbusStateClosing:
+   xenbus_switch_state(dev, XenbusStateClosing);
+   break;
+   default:
+   __WARN();
+   }
+   break;
+   case XenbusStateInitWait:
+   case XenbusStateInitialised:
+   switch (state) {
+   case XenbusStateConnected:
+   backend_connect(dev);
+   xenbus_switch_state(dev, XenbusStateConnected);
+   break;
+   case XenbusStateClosing:
+   case XenbusStateClosed:
+   xenbus_switch_state(dev, XenbusStateClosing);
+   break;
+   default:
+   __WARN();
+   }
+   break;
+   case XenbusStateConnected:
+   switch (state) {
+   case XenbusStateInitWait:
+   case XenbusStateClosing:
+   case XenbusStateClosed:
+   down(_back_global.frontends_lock);
+   backend_disconnect(dev);
+   up(_back_global.frontends_lock);
+   xenbus_switch_state(dev, XenbusStateClosing);
+   break;
+   default:
+   __WARN();
+   }
+   break;
+   case XenbusStateClosing:
+   switch (state) {
+   case XenbusStateInitWait:
+

[Xen-devel] [PATCH v4 07/18] xen/pvcalls: implement socket command

[Stefano Stabellini]

Just reply with success to the other end for now. Delay the allocation
of the actual socket to bind and/or connect.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 437c2ad..953458b 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -12,12 +12,17 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -54,6 +59,28 @@ struct pvcalls_fedata {
 static int pvcalls_back_socket(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   int ret;
+   struct xen_pvcalls_response *rsp;
+
+   fedata = dev_get_drvdata(>dev);
+
+   if (req->u.socket.domain != AF_INET ||
+   req->u.socket.type != SOCK_STREAM ||
+   (req->u.socket.protocol != IPPROTO_IP &&
+req->u.socket.protocol != AF_INET))
+   ret = -EAFNOSUPPORT;
+   else
+   ret = 0;
+
+   /* leave the actual socket allocation for later */
+
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.socket.id = req->u.socket.id;
+   rsp->ret = ret;
+
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 01/18] xen: introduce the pvcalls interface header

[Stefano Stabellini]

Introduce the C header file which defines the PV Calls interface. It is
imported from xen/include/public/io/pvcalls.h.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 include/xen/interface/io/pvcalls.h | 121 +
 include/xen/interface/io/ring.h|   2 +
 2 files changed, 123 insertions(+)
 create mode 100644 include/xen/interface/io/pvcalls.h

diff --git a/include/xen/interface/io/pvcalls.h 
b/include/xen/interface/io/pvcalls.h
new file mode 100644
index 000..ccf97b8
--- /dev/null
+++ b/include/xen/interface/io/pvcalls.h
@@ -0,0 +1,121 @@
+#ifndef __XEN_PUBLIC_IO_XEN_PVCALLS_H__
+#define __XEN_PUBLIC_IO_XEN_PVCALLS_H__
+
+#include 
+#include 
+#include 
+
+/* "1" means socket, connect, release, bind, listen, accept and poll */
+#define XENBUS_FUNCTIONS_CALLS "1"
+
+/*
+ * See docs/misc/pvcalls.markdown in xen.git for the full specification:
+ * https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
+ */
+struct pvcalls_data_intf {
+RING_IDX in_cons, in_prod, in_error;
+
+uint8_t pad1[52];
+
+RING_IDX out_cons, out_prod, out_error;
+
+uint8_t pad2[52];
+
+RING_IDX ring_order;
+grant_ref_t ref[];
+};
+DEFINE_XEN_FLEX_RING(pvcalls);
+
+#define PVCALLS_SOCKET 0
+#define PVCALLS_CONNECT1
+#define PVCALLS_RELEASE2
+#define PVCALLS_BIND   3
+#define PVCALLS_LISTEN 4
+#define PVCALLS_ACCEPT 5
+#define PVCALLS_POLL   6
+
+struct xen_pvcalls_request {
+uint32_t req_id; /* private to guest, echoed in response */
+uint32_t cmd;/* command to execute */
+union {
+struct xen_pvcalls_socket {
+uint64_t id;
+uint32_t domain;
+uint32_t type;
+uint32_t protocol;
+} socket;
+struct xen_pvcalls_connect {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+uint32_t flags;
+grant_ref_t ref;
+uint32_t evtchn;
+} connect;
+struct xen_pvcalls_release {
+uint64_t id;
+uint8_t reuse;
+} release;
+struct xen_pvcalls_bind {
+uint64_t id;
+uint8_t addr[28];
+uint32_t len;
+} bind;
+struct xen_pvcalls_listen {
+uint64_t id;
+uint32_t backlog;
+} listen;
+struct xen_pvcalls_accept {
+uint64_t id;
+uint64_t id_new;
+grant_ref_t ref;
+uint32_t evtchn;
+} accept;
+struct xen_pvcalls_poll {
+uint64_t id;
+} poll;
+/* dummy member to force sizeof(struct xen_pvcalls_request)
+ * to match across archs */
+struct xen_pvcalls_dummy {
+uint8_t dummy[56];
+} dummy;
+} u;
+};
+
+struct xen_pvcalls_response {
+uint32_t req_id;
+uint32_t cmd;
+int32_t ret;
+uint32_t pad;
+union {
+struct _xen_pvcalls_socket {
+uint64_t id;
+} socket;
+struct _xen_pvcalls_connect {
+uint64_t id;
+} connect;
+struct _xen_pvcalls_release {
+uint64_t id;
+} release;
+struct _xen_pvcalls_bind {
+uint64_t id;
+} bind;
+struct _xen_pvcalls_listen {
+uint64_t id;
+} listen;
+struct _xen_pvcalls_accept {
+uint64_t id;
+} accept;
+struct _xen_pvcalls_poll {
+uint64_t id;
+} poll;
+struct _xen_pvcalls_dummy {
+uint8_t dummy[8];
+} dummy;
+} u;
+};
+
+DEFINE_RING_TYPES(xen_pvcalls, struct xen_pvcalls_request,
+  struct xen_pvcalls_response);
+
+#endif
diff --git a/include/xen/interface/io/ring.h b/include/xen/interface/io/ring.h
index c794568..e547088 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h
@@ -9,6 +9,8 @@
 #ifndef __XEN_PUBLIC_IO_RING_H__
 #define __XEN_PUBLIC_IO_RING_H__
 
+#include 
+
 typedef unsigned int RING_IDX;
 
 /* Round a 32-bit unsigned constant down to the nearest power of two. */
-- 
1.9.1


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

[Xen-devel] [PATCH v4 08/18] xen/pvcalls: implement connect command

[Stefano Stabellini]

Allocate a socket. Keep track of socket <-> ring mappings with a new data
structure, called sock_mapping. Implement the connect command by calling
inet_stream_connect, and mapping the new indexes page and data ring.
Allocate a workqueue and a work_struct, called ioworker, to perform
reads and writes to the socket.

When an active socket is closed (sk_state_change), set in_error to
-ENOTCONN and notify the other end, as specified by the protocol.

sk_data_ready and pvcalls_back_ioworker will be implemented later.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 171 +
 1 file changed, 171 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 953458b..4eecd83 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -56,6 +56,39 @@ struct pvcalls_fedata {
struct work_struct register_work;
 };
 
+struct pvcalls_ioworker {
+   struct work_struct register_work;
+   struct workqueue_struct *wq;
+};
+
+struct sock_mapping {
+   struct list_head list;
+   struct pvcalls_fedata *fedata;
+   struct socket *sock;
+   uint64_t id;
+   grant_ref_t ref;
+   struct pvcalls_data_intf *ring;
+   void *bytes;
+   struct pvcalls_data data;
+   uint32_t ring_order;
+   int irq;
+   atomic_t read;
+   atomic_t write;
+   atomic_t io;
+   atomic_t release;
+   void (*saved_data_ready)(struct sock *sk);
+   struct pvcalls_ioworker ioworker;
+};
+
+static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map);
+static int pvcalls_back_release_active(struct xenbus_device *dev,
+  struct pvcalls_fedata *fedata,
+  struct sock_mapping *map);
+
+static void pvcalls_back_ioworker(struct work_struct *work)
+{
+}
+
 static int pvcalls_back_socket(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
@@ -84,9 +117,142 @@ static int pvcalls_back_socket(struct xenbus_device *dev,
return 0;
 }
 
+static void pvcalls_sk_state_change(struct sock *sock)
+{
+   struct sock_mapping *map = sock->sk_user_data;
+   struct pvcalls_data_intf *intf;
+
+   if (map == NULL)
+   return;
+
+   intf = map->ring;
+   intf->in_error = -ENOTCONN;
+   notify_remote_via_irq(map->irq);
+}
+
+static void pvcalls_sk_data_ready(struct sock *sock)
+{
+}
+
+static struct sock_mapping *pvcalls_new_active_socket(
+   struct pvcalls_fedata *fedata,
+   uint64_t id,
+   grant_ref_t ref,
+   uint32_t evtchn,
+   struct socket *sock)
+{
+   int ret;
+   struct sock_mapping *map;
+   void *page;
+
+   map = kzalloc(sizeof(*map), GFP_KERNEL);
+   if (map == NULL)
+   return NULL;
+
+   map->fedata = fedata;
+   map->sock = sock;
+   map->id = id;
+   map->ref = ref;
+
+   ret = xenbus_map_ring_valloc(fedata->dev, , 1, );
+   if (ret < 0)
+   goto out;
+   map->ring = page;
+   map->ring_order = map->ring->ring_order;
+   /* first read the order, then map the data ring */
+   virt_rmb();
+   if (map->ring_order > MAX_RING_ORDER) {
+   pr_warn("%s frontend requested ring_order %u, which is > MAX 
(%u)\n",
+   __func__, map->ring_order, MAX_RING_ORDER);
+   goto out;
+   }
+   ret = xenbus_map_ring_valloc(fedata->dev, map->ring->ref,
+(1 << map->ring_order), );
+   if (ret < 0)
+   goto out;
+   map->bytes = page;
+
+   ret = bind_interdomain_evtchn_to_irqhandler(fedata->dev->otherend_id,
+   evtchn,
+   pvcalls_back_conn_event,
+   0,
+   "pvcalls-backend",
+   map);
+   if (ret < 0)
+   goto out;
+   map->irq = ret;
+
+   map->data.in = map->bytes;
+   map->data.out = map->bytes + XEN_FLEX_RING_SIZE(map->ring_order);
+   
+   map->ioworker.wq = alloc_workqueue("pvcalls_io", WQ_UNBOUND, 1);
+   if (!map->ioworker.wq)
+   goto out;
+   atomic_set(>io, 1);
+   INIT_WORK(>ioworker.register_work, pvcalls_back_ioworker);
+
+   down(>socket_lock);
+   list_add_tail(>list, >socket_mappings);
+   up(>socket_lock);
+
+   write_lock_bh(>sock->sk->sk_callback_lock);
+   map->saved_data_ready = map->sock->sk->sk_data_ready;
+   map->sock->sk->sk_user_data = map;
+   map->sock->sk->sk_data_ready = pvcalls_sk_data_ready;
+   map->sock->sk->sk_state_change = pvcalls_sk_state_change;
+   

[Xen-devel] [PATCH v4 13/18] xen/pvcalls: implement release command

[Stefano Stabellini]

Release both active and passive sockets. For active sockets, make sure
to avoid possible conflicts with the ioworker reading/writing to those
sockets concurrently. Set map->release to let the ioworker know
atomically that the socket will be released soon, then wait until the
ioworker finishes (flush_work).

Unmap indexes pages and data rings.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index be85977..afc9575 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -266,12 +266,82 @@ static int pvcalls_back_release_active(struct 
xenbus_device *dev,
   struct pvcalls_fedata *fedata,
   struct sock_mapping *map)
 {
+   disable_irq(map->irq);
+   if (map->sock->sk != NULL) {
+   write_lock_bh(>sock->sk->sk_callback_lock);
+   map->sock->sk->sk_user_data = NULL;
+   map->sock->sk->sk_data_ready = map->saved_data_ready;
+   write_unlock_bh(>sock->sk->sk_callback_lock);
+   }
+
+   atomic_set(>release, 1);
+   flush_work(>ioworker.register_work);
+
+   down(>socket_lock);
+   list_del(>list);
+   up(>socket_lock);
+
+   xenbus_unmap_ring_vfree(dev, map->bytes);
+   xenbus_unmap_ring_vfree(dev, (void *)map->ring);
+   unbind_from_irqhandler(map->irq, map);
+
+   sock_release(map->sock);
+   kfree(map);
+
+   return 0;
+}
+
+static int pvcalls_back_release_passive(struct xenbus_device *dev,
+   struct pvcalls_fedata *fedata,
+   struct sockpass_mapping *mappass)
+{
+   if (mappass->sock->sk != NULL) {
+   write_lock_bh(>sock->sk->sk_callback_lock);
+   mappass->sock->sk->sk_user_data = NULL;
+   mappass->sock->sk->sk_data_ready = mappass->saved_data_ready;
+   write_unlock_bh(>sock->sk->sk_callback_lock);
+   }
+   down(>socket_lock);
+   radix_tree_delete(>socketpass_mappings, mappass->id);
+   sock_release(mappass->sock);
+   flush_workqueue(mappass->wq);
+   destroy_workqueue(mappass->wq);
+   kfree(mappass);
+   up(>socket_lock);
+
return 0;
 }
 
 static int pvcalls_back_release(struct xenbus_device *dev,
struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   struct sock_mapping *map, *n;
+   struct sockpass_mapping *mappass;
+   int ret = 0;
+   struct xen_pvcalls_response *rsp;
+
+   fedata = dev_get_drvdata(>dev);
+
+   list_for_each_entry_safe(map, n, >socket_mappings, list) {
+   if (map->id == req->u.release.id) {
+   ret = pvcalls_back_release_active(dev, fedata, map);
+   goto out;
+   }
+   }
+   mappass = radix_tree_lookup(>socketpass_mappings,
+   req->u.release.id);
+   if (mappass != NULL) {
+   ret = pvcalls_back_release_passive(dev, fedata, mappass);
+   goto out;
+   }
+
+out:
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->u.release.id = req->u.release.id;
+   rsp->cmd = req->cmd;
+   rsp->ret = ret;
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 02/18] xen/pvcalls: introduce the pvcalls xenbus backend

[Stefano Stabellini]

Introduce a xenbus backend for the pvcalls protocol, as defined by
https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.

This patch only adds the stubs, the code will be added by the following
patches.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 drivers/xen/pvcalls-back.c

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
new file mode 100644
index 000..f3d0daa
--- /dev/null
+++ b/drivers/xen/pvcalls-back.c
@@ -0,0 +1,61 @@
+/*
+ * (c) 2017 Stefano Stabellini 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int pvcalls_back_probe(struct xenbus_device *dev,
+ const struct xenbus_device_id *id)
+{
+   return 0;
+}
+
+static void pvcalls_back_changed(struct xenbus_device *dev,
+enum xenbus_state frontend_state)
+{
+}
+
+static int pvcalls_back_remove(struct xenbus_device *dev)
+{
+   return 0;
+}
+
+static int pvcalls_back_uevent(struct xenbus_device *xdev,
+  struct kobj_uevent_env *env)
+{
+   return 0;
+}
+
+static const struct xenbus_device_id pvcalls_back_ids[] = {
+   { "pvcalls" },
+   { "" }
+};
+
+static struct xenbus_driver pvcalls_back_driver = {
+   .ids = pvcalls_back_ids,
+   .probe = pvcalls_back_probe,
+   .remove = pvcalls_back_remove,
+   .uevent = pvcalls_back_uevent,
+   .otherend_changed = pvcalls_back_changed,
+};
-- 
1.9.1


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

[Xen-devel] [PATCH v4 10/18] xen/pvcalls: implement listen command

[Stefano Stabellini]

Call inet_listen to implement the listen command.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index c17d970..e5c535d 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -358,6 +358,25 @@ static int pvcalls_back_bind(struct xenbus_device *dev,
 static int pvcalls_back_listen(struct xenbus_device *dev,
   struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   int ret = -EINVAL;
+   struct sockpass_mapping *map;
+   struct xen_pvcalls_response *rsp;
+
+   fedata = dev_get_drvdata(>dev);
+
+   map = radix_tree_lookup(>socketpass_mappings, req->u.listen.id);
+   if (map == NULL)
+   goto out;
+
+   ret = inet_listen(map->sock, req->u.listen.backlog);
+
+out:
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.listen.id = req->u.listen.id;
+   rsp->ret = ret;
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 16/18] xen/pvcalls: implement read

[Stefano Stabellini]

When an active socket has data available, increment the io and read
counters, and schedule the ioworker.

Implement the read function by reading from the socket, writing the data
to the data ring.

Set in_error on error.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 85 ++
 1 file changed, 85 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index b9a10b9..65d9eba 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -100,6 +100,81 @@ static int pvcalls_back_release_active(struct 
xenbus_device *dev,
 
 static void pvcalls_conn_back_read(void *opaque)
 {
+   struct sock_mapping *map = (struct sock_mapping *)opaque;
+   struct msghdr msg;
+   struct kvec vec[2];
+   RING_IDX cons, prod, size, wanted, array_size, masked_prod, masked_cons;
+   int32_t error;
+   struct pvcalls_data_intf *intf = map->ring;
+   struct pvcalls_data *data = >data;
+   unsigned long flags;
+   int ret;
+
+   array_size = XEN_FLEX_RING_SIZE(map->ring_order);
+   cons = intf->in_cons;
+   prod = intf->in_prod;
+   error = intf->in_error;
+   /* read the indexes first, then deal with the data */
+   virt_mb();
+
+   if (error)
+   return;
+
+   size = pvcalls_queued(prod, cons, array_size);
+   if (size >= array_size)
+   return;
+   spin_lock_irqsave(>sock->sk->sk_receive_queue.lock, flags);
+   if (skb_queue_empty(>sock->sk->sk_receive_queue)) {
+   atomic_set(>read, 0);
+   spin_unlock_irqrestore(>sock->sk->sk_receive_queue.lock,
+   flags);
+   return;
+   }
+   spin_unlock_irqrestore(>sock->sk->sk_receive_queue.lock, flags);
+   wanted = array_size - size;
+   masked_prod = pvcalls_mask(prod, array_size);
+   masked_cons = pvcalls_mask(cons, array_size);
+
+   memset(, 0, sizeof(msg));
+   msg.msg_iter.type = ITER_KVEC|WRITE;
+   msg.msg_iter.count = wanted;
+   if (masked_prod < masked_cons) {
+   vec[0].iov_base = data->in + masked_prod;
+   vec[0].iov_len = wanted;
+   msg.msg_iter.kvec = vec;
+   msg.msg_iter.nr_segs = 1;
+   } else {
+   vec[0].iov_base = data->in + masked_prod;
+   vec[0].iov_len = array_size - masked_prod;
+   vec[1].iov_base = data->in;
+   vec[1].iov_len = wanted - vec[0].iov_len;
+   msg.msg_iter.kvec = vec;
+   msg.msg_iter.nr_segs = 2;
+   }
+
+   atomic_set(>read, 0);
+   ret = inet_recvmsg(map->sock, , wanted, MSG_DONTWAIT);
+   WARN_ON(ret > wanted);
+   if (ret == -EAGAIN) /* shouldn't happen */
+   return;
+   if (!ret)
+   ret = -ENOTCONN;
+   spin_lock_irqsave(>sock->sk->sk_receive_queue.lock, flags);
+   if (ret > 0 && !skb_queue_empty(>sock->sk->sk_receive_queue))
+   atomic_inc(>read);
+   spin_unlock_irqrestore(>sock->sk->sk_receive_queue.lock, flags);
+
+   /* write the data, then modify the indexes */
+   virt_wmb();
+   if (ret < 0)
+   intf->in_error = ret;
+   else
+   intf->in_prod = prod + ret;
+   /* update the indexes, then notify the other end */
+   virt_wmb();
+   notify_remote_via_irq(map->irq);
+
+   return;
 }
 
 static int pvcalls_conn_back_write(struct sock_mapping *map)
@@ -172,6 +247,16 @@ static void pvcalls_sk_state_change(struct sock *sock)
 
 static void pvcalls_sk_data_ready(struct sock *sock)
 {
+   struct sock_mapping *map = sock->sk_user_data;
+   struct pvcalls_ioworker *iow;
+
+   if (map == NULL)
+   return;
+
+   iow = >ioworker;
+   atomic_inc(>read);
+   atomic_inc(>io);
+   queue_work(iow->wq, >register_work);
 }
 
 static struct sock_mapping *pvcalls_new_active_socket(
-- 
1.9.1


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

[Xen-devel] [PATCH v4 17/18] xen/pvcalls: implement write

[Stefano Stabellini]

When the other end notifies us that there is data to be written
(pvcalls_back_conn_event), increment the io and write counters, and
schedule the ioworker.

Implement the write function called by ioworker by reading the data from
the data ring, writing it to the socket by calling inet_sendmsg.

Set out_error on error.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 74 +-
 1 file changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 65d9eba..91ab11b 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -179,7 +179,66 @@ static void pvcalls_conn_back_read(void *opaque)
 
 static int pvcalls_conn_back_write(struct sock_mapping *map)
 {
-   return 0;
+   struct pvcalls_data_intf *intf = map->ring;
+   struct pvcalls_data *data = >data;
+   struct msghdr msg;
+   struct kvec vec[2];
+   RING_IDX cons, prod, size, ring_size;
+   int ret;
+
+   cons = intf->out_cons;
+   prod = intf->out_prod;
+   /* read the indexes before dealing with the data */
+   virt_mb();
+
+   ring_size = XEN_FLEX_RING_SIZE(map->ring_order);
+   size = pvcalls_queued(prod, cons, ring_size);
+   if (size == 0)
+   return 0;
+
+   memset(, 0, sizeof(msg));
+   msg.msg_flags |= MSG_DONTWAIT;
+   msg.msg_iter.type = ITER_KVEC|READ;
+   msg.msg_iter.count = size;
+   if (pvcalls_mask(prod, ring_size) > pvcalls_mask(cons, ring_size)) {
+   vec[0].iov_base = data->out + pvcalls_mask(cons, ring_size);
+   vec[0].iov_len = size;
+   msg.msg_iter.kvec = vec;
+   msg.msg_iter.nr_segs = 1;
+   } else {
+   vec[0].iov_base = data->out + pvcalls_mask(cons, ring_size);
+   vec[0].iov_len = ring_size - pvcalls_mask(cons, ring_size);
+   vec[1].iov_base = data->out;
+   vec[1].iov_len = size - vec[0].iov_len;
+   msg.msg_iter.kvec = vec;
+   msg.msg_iter.nr_segs = 2;
+   }
+
+   atomic_set(>write, 0);
+   ret = inet_sendmsg(map->sock, , size);
+   if (ret == -EAGAIN || (ret >= 0 && ret < size)) {
+   atomic_inc(>write);
+   atomic_inc(>io);
+   }
+   if (ret == -EAGAIN)
+   return ret;
+
+   /* write the data, then update the indexes */
+   virt_wmb();
+   if (ret < 0) {
+   intf->out_error = ret;
+   } else {
+   intf->out_error = 0;
+   intf->out_cons = cons + ret;
+   prod = intf->out_prod;
+   }
+   /* update the indexes, then notify the other end */
+   virt_wmb();
+   if (prod != cons + ret)
+   atomic_inc(>write);
+   notify_remote_via_irq(map->irq);
+
+   return ret;
 }
 
 static void pvcalls_back_ioworker(struct work_struct *work)
@@ -843,6 +902,19 @@ static irqreturn_t pvcalls_back_event(int irq, void 
*dev_id)
 
 static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map)
 {
+   struct sock_mapping *map = sock_map;
+   struct pvcalls_ioworker *iow;
+
+   if (map == NULL || map->sock == NULL || map->sock->sk == NULL ||
+   map->sock->sk->sk_user_data != map)
+   return IRQ_HANDLED;
+
+   iow = >ioworker;
+
+   atomic_inc(>write);
+   atomic_inc(>io);
+   queue_work(iow->wq, >register_work);
+
return IRQ_HANDLED;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 09/18] xen/pvcalls: implement bind command

[Stefano Stabellini]

Allocate a socket. Track the allocated passive sockets with a new data
structure named sockpass_mapping. It contains an unbound workqueue to
schedule delayed work for the accept and poll commands. It also has a
reqcopy field to be used to store a copy of a request for delayed work.
Reads/writes to it are protected by a lock (the "copy_lock" spinlock).
Initialize the workqueue in pvcalls_back_bind.

Implement the bind command with inet_bind.

The pass_sk_data_ready event handler will be added later.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 87 ++
 1 file changed, 87 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 4eecd83..c17d970 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -80,6 +80,18 @@ struct sock_mapping {
struct pvcalls_ioworker ioworker;
 };
 
+struct sockpass_mapping {
+   struct list_head list;
+   struct pvcalls_fedata *fedata;
+   struct socket *sock;
+   uint64_t id;
+   struct xen_pvcalls_request reqcopy;
+   spinlock_t copy_lock;
+   struct workqueue_struct *wq;
+   struct work_struct register_work;
+   void (*saved_data_ready)(struct sock *sk);
+};
+
 static irqreturn_t pvcalls_back_conn_event(int irq, void *sock_map);
 static int pvcalls_back_release_active(struct xenbus_device *dev,
   struct pvcalls_fedata *fedata,
@@ -262,9 +274,84 @@ static int pvcalls_back_release(struct xenbus_device *dev,
return 0;
 }
 
+static void __pvcalls_back_accept(struct work_struct *work)
+{
+}
+
+static void pvcalls_pass_sk_data_ready(struct sock *sock)
+{
+}
+
 static int pvcalls_back_bind(struct xenbus_device *dev,
 struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   int ret, err;
+   struct socket *sock;
+   struct sockpass_mapping *map;
+   struct xen_pvcalls_response *rsp;
+
+   fedata = dev_get_drvdata(>dev);
+
+   map = kzalloc(sizeof(*map), GFP_KERNEL);
+   if (map == NULL) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   INIT_WORK(>register_work, __pvcalls_back_accept);
+   spin_lock_init(>copy_lock);
+   map->wq = alloc_workqueue("pvcalls_wq", WQ_UNBOUND, 1);
+   if (!map->wq) {
+   ret = -ENOMEM;
+   kfree(map);
+   goto out;
+   }
+
+   ret = sock_create(AF_INET, SOCK_STREAM, 0, );
+   if (ret < 0) {
+   destroy_workqueue(map->wq);
+   kfree(map);
+   goto out;
+   }
+
+   ret = inet_bind(sock, (struct sockaddr *)>u.bind.addr,
+   req->u.bind.len);
+   if (ret < 0) {
+   sock_release(sock);
+   destroy_workqueue(map->wq);
+   kfree(map);
+   goto out;
+   }
+
+   map->fedata = fedata;
+   map->sock = sock;
+   map->id = req->u.bind.id;
+
+   down(>socket_lock);
+   err = radix_tree_insert(>socketpass_mappings, map->id,
+   map);
+   up(>socket_lock);
+   if (err) {
+   ret = err;
+   sock_release(sock);
+   destroy_workqueue(map->wq);
+   kfree(map);
+   goto out;
+   }
+
+   write_lock_bh(>sk->sk_callback_lock);
+   map->saved_data_ready = sock->sk->sk_data_ready;
+   sock->sk->sk_user_data = map;
+   sock->sk->sk_data_ready = pvcalls_pass_sk_data_ready;
+   write_unlock_bh(>sk->sk_callback_lock);
+
+out:
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.bind.id = req->u.bind.id;
+   rsp->ret = ret;
return 0;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 11/18] xen/pvcalls: implement accept command

[Stefano Stabellini]

Implement the accept command by calling inet_accept. To avoid blocking
in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
scheduled on sk_data_ready (for a passive socket, it means that there
are connections to accept).

Use the reqcopy field to store the request. Accept the new socket from
the delayed work function, create a new sock_mapping for it, map
the indexes page and data ring, and reply to the other end. Allocate an
ioworker for the socket.

Only support one outstanding blocking accept request for every socket at
any time.

Add a field to sock_mapping to remember the passive socket from which an
active socket was created.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 110 +
 1 file changed, 110 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index e5c535d..701f1fc 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -64,6 +64,7 @@ struct pvcalls_ioworker {
 struct sock_mapping {
struct list_head list;
struct pvcalls_fedata *fedata;
+   struct sockpass_mapping *sockpass;
struct socket *sock;
uint64_t id;
grant_ref_t ref;
@@ -276,10 +277,82 @@ static int pvcalls_back_release(struct xenbus_device *dev,
 
 static void __pvcalls_back_accept(struct work_struct *work)
 {
+   struct sockpass_mapping *mappass = container_of(
+   work, struct sockpass_mapping, register_work);
+   struct sock_mapping *map;
+   struct pvcalls_ioworker *iow;
+   struct pvcalls_fedata *fedata;
+   struct socket *sock;
+   struct xen_pvcalls_response *rsp;
+   struct xen_pvcalls_request *req;
+   int notify;
+   int ret = -EINVAL;
+   unsigned long flags;
+
+   fedata = mappass->fedata;
+   /*
+* __pvcalls_back_accept can race against pvcalls_back_accept.
+* We only need to check the value of "cmd" on read. It could be
+* done atomically, but to simplify the code on the write side, we
+* use a spinlock.
+*/
+   spin_lock_irqsave(>copy_lock, flags);
+   req = >reqcopy;
+   if (req->cmd != PVCALLS_ACCEPT) {
+   spin_unlock_irqrestore(>copy_lock, flags);
+   return;
+   }
+   spin_unlock_irqrestore(>copy_lock, flags);
+
+   sock = sock_alloc();
+   if (sock == NULL)
+   goto out_error;
+   sock->type = mappass->sock->type;
+   sock->ops = mappass->sock->ops;
+
+   ret = inet_accept(mappass->sock, sock, O_NONBLOCK, true);
+   if (ret == -EAGAIN) {
+   sock_release(sock);
+   goto out_error;
+   }
+
+   map = pvcalls_new_active_socket(fedata,
+   req->u.accept.id_new,
+   req->u.accept.ref,
+   req->u.accept.evtchn,
+   sock);
+   if (!map) {
+   sock_release(sock);
+   goto out_error;
+   }
+
+   map->sockpass = mappass;
+   iow = >ioworker;
+   atomic_inc(>read);
+   atomic_inc(>io);
+   queue_work(iow->wq, >register_work);
+
+out_error:
+   rsp = RING_GET_RESPONSE(>ring, fedata->ring.rsp_prod_pvt++);
+   rsp->req_id = req->req_id;
+   rsp->cmd = req->cmd;
+   rsp->u.accept.id = req->u.accept.id;
+   rsp->ret = ret;
+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>ring, notify);
+   if (notify)
+   notify_remote_via_irq(fedata->irq);
+
+   mappass->reqcopy.cmd = 0;
 }
 
 static void pvcalls_pass_sk_data_ready(struct sock *sock)
 {
+   struct sockpass_mapping *mappass = sock->sk_user_data;
+
+   if (mappass == NULL)
+   return;
+
+   queue_work(mappass->wq, >register_work);
 }
 
 static int pvcalls_back_bind(struct xenbus_device *dev,
@@ -383,6 +456,43 @@ static int pvcalls_back_listen(struct xenbus_device *dev,
 static int pvcalls_back_accept(struct xenbus_device *dev,
   struct xen_pvcalls_request *req)
 {
+   struct pvcalls_fedata *fedata;
+   struct sockpass_mapping *mappass;
+   int ret = -EINVAL;
+   struct xen_pvcalls_response *rsp;
+   unsigned long flags;
+
+   fedata = dev_get_drvdata(>dev);
+
+   mappass = radix_tree_lookup(>socketpass_mappings,
+   req->u.accept.id);
+   if (mappass == NULL)
+   goto out_error;
+
+   /* 
+* Limitation of the current implementation: only support one
+* concurrent accept or poll call on one socket.
+*/
+   spin_lock_irqsave(>copy_lock, flags);
+   if (mappass->reqcopy.cmd != 0) {
+   spin_unlock_irqrestore(>copy_lock, flags);
+   ret = -EINTR;
+   goto out_error;
+   }
+
+   mappass->reqcopy = *req;
+   

[Xen-devel] [PATCH v4 05/18] xen/pvcalls: connect to a frontend

[Stefano Stabellini]

Introduce a per-frontend data structure named pvcalls_fedata. It
contains pointers to the command ring, its event channel, a list of
active sockets and a tree of passive sockets (passing sockets need to be
looked up from the id on listen, accept and poll commands, while active
sockets only on release).

It also has an unbound workqueue to schedule the work of parsing and
executing commands on the command ring. socket_lock protects the two
lists. In pvcalls_back_global, keep a list of connected frontends.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 92 ++
 1 file changed, 92 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 7bce750..e4c2e46 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -33,9 +33,101 @@ struct pvcalls_back_global {
struct semaphore frontends_lock;
 } pvcalls_back_global;
 
+/*
+ * Per-frontend data structure. It contains pointers to the command
+ * ring, its event channel, a list of active sockets and a tree of
+ * passive sockets.
+ */
+struct pvcalls_fedata {
+   struct list_head list;
+   struct xenbus_device *dev;
+   struct xen_pvcalls_sring *sring;
+   struct xen_pvcalls_back_ring ring;
+   int irq;
+   struct list_head socket_mappings;
+   struct radix_tree_root socketpass_mappings;
+   struct semaphore socket_lock;
+   struct workqueue_struct *wq;
+   struct work_struct register_work;
+};
+
+static void pvcalls_back_work(struct work_struct *work)
+{
+}
+
+static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
+{
+   return IRQ_HANDLED;
+}
+
 static int backend_connect(struct xenbus_device *dev)
 {
+   int err, evtchn;
+   grant_ref_t ring_ref;
+   struct pvcalls_fedata *fedata = NULL;
+
+   fedata = kzalloc(sizeof(struct pvcalls_fedata), GFP_KERNEL);
+   if (!fedata)
+   return -ENOMEM;
+
+   err = xenbus_scanf(XBT_NIL, dev->otherend, "port", "%u",
+  );
+   if (err != 1) {
+   err = -EINVAL;
+   xenbus_dev_fatal(dev, err, "reading %s/event-channel",
+dev->otherend);
+   goto error;
+   }
+
+   err = xenbus_scanf(XBT_NIL, dev->otherend, "ring-ref", "%u", _ref);
+   if (err != 1) {
+   err = -EINVAL;
+   xenbus_dev_fatal(dev, err, "reading %s/ring-ref",
+dev->otherend);
+   goto error;
+   }
+
+   err = bind_interdomain_evtchn_to_irqhandler(dev->otherend_id, evtchn,
+   pvcalls_back_event, 0,
+   "pvcalls-backend", dev);
+   if (err < 0)
+   goto error;
+   fedata->irq = err;
+
+   fedata->wq = alloc_workqueue("pvcalls_back_wq", WQ_UNBOUND, 1);
+   if (!fedata->wq) {
+   err = -ENOMEM;
+   goto error;
+   }
+
+   err = xenbus_map_ring_valloc(dev, _ref, 1, (void**)>sring);
+   if (err < 0)
+   goto error;
+
+   BACK_RING_INIT(>ring, fedata->sring, XEN_PAGE_SIZE * 1);
+   fedata->dev = dev;
+
+   INIT_WORK(>register_work, pvcalls_back_work);
+   INIT_LIST_HEAD(>socket_mappings);
+   INIT_RADIX_TREE(>socketpass_mappings, GFP_KERNEL);
+   sema_init(>socket_lock, 1);
+   dev_set_drvdata(>dev, fedata);
+
+   down(_back_global.frontends_lock);
+   list_add_tail(>list, _back_global.frontends);
+   up(_back_global.frontends_lock);
+   queue_work(fedata->wq, >register_work);
+
return 0;
+
+ error:
+   if (fedata->sring != NULL)
+   xenbus_unmap_ring_vfree(dev, fedata->sring);
+   if (fedata->wq)
+   destroy_workqueue(fedata->wq);
+   unbind_from_irqhandler(fedata->irq, dev);
+   kfree(fedata);
+   return err;
 }
 
 static int backend_disconnect(struct xenbus_device *dev)
-- 
1.9.1


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

[Xen-devel] [PATCH v4 15/18] xen/pvcalls: implement the ioworker functions

[Stefano Stabellini]

We have one ioworker per socket. Each ioworker goes through the list of
outstanding read/write requests. Once all requests have been dealt with,
it returns.

We use one atomic counter per socket for "read" operations and one
for "write" operations to keep track of the reads/writes to do.

We also use one atomic counter ("io") per ioworker to keep track of how
many outstanding requests we have in total assigned to the ioworker. The
ioworker finishes when there are none.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index 94e4c3f..b9a10b9 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -98,8 +98,35 @@ static int pvcalls_back_release_active(struct xenbus_device 
*dev,
   struct pvcalls_fedata *fedata,
   struct sock_mapping *map);
 
+static void pvcalls_conn_back_read(void *opaque)
+{
+}
+
+static int pvcalls_conn_back_write(struct sock_mapping *map)
+{
+   return 0;
+}
+
 static void pvcalls_back_ioworker(struct work_struct *work)
 {
+   struct pvcalls_ioworker *ioworker = container_of(work,
+   struct pvcalls_ioworker, register_work);
+   struct sock_mapping *map = container_of(ioworker, struct sock_mapping,
+   ioworker);
+
+   while (atomic_read(>io) > 0) {
+   if (atomic_read(>release) > 0) {
+   atomic_set(>release, 0);
+   return;
+   }
+
+   if (atomic_read(>read) > 0)
+   pvcalls_conn_back_read(map);
+   if (atomic_read(>write) > 0)
+   pvcalls_conn_back_write(map);
+
+   atomic_dec(>io);
+   }
 }
 
 static int pvcalls_back_socket(struct xenbus_device *dev,
-- 
1.9.1


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

[Xen-devel] [PATCH v4 06/18] xen/pvcalls: handle commands from the frontend

[Stefano Stabellini]

When the other end notifies us that there are commands to be read
(pvcalls_back_event), wake up the backend thread to parse the command.

The command ring works like most other Xen rings, so use the usual
ring macros to read and write to it. The functions implementing the
commands are empty stubs for now.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 119 +
 1 file changed, 119 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index e4c2e46..437c2ad 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -51,12 +51,131 @@ struct pvcalls_fedata {
struct work_struct register_work;
 };
 
+static int pvcalls_back_socket(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_connect(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_release(struct xenbus_device *dev,
+   struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_bind(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_listen(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_accept(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_poll(struct xenbus_device *dev,
+struct xen_pvcalls_request *req)
+{
+   return 0;
+}
+
+static int pvcalls_back_handle_cmd(struct xenbus_device *dev,
+  struct xen_pvcalls_request *req)
+{
+   int ret = 0;
+
+   switch (req->cmd) {
+   case PVCALLS_SOCKET:
+   ret = pvcalls_back_socket(dev, req);
+   break;
+   case PVCALLS_CONNECT:
+   ret = pvcalls_back_connect(dev, req);
+   break;
+   case PVCALLS_RELEASE:
+   ret = pvcalls_back_release(dev, req);
+   break;
+   case PVCALLS_BIND:
+   ret = pvcalls_back_bind(dev, req);
+   break;
+   case PVCALLS_LISTEN:
+   ret = pvcalls_back_listen(dev, req);
+   break;
+   case PVCALLS_ACCEPT:
+   ret = pvcalls_back_accept(dev, req);
+   break;
+   case PVCALLS_POLL:
+   ret = pvcalls_back_poll(dev, req);
+   break;
+   default:
+   ret = -ENOTSUPP;
+   break;
+   }
+   return ret;
+}
+
 static void pvcalls_back_work(struct work_struct *work)
 {
+   struct pvcalls_fedata *fedata = container_of(work,
+   struct pvcalls_fedata, register_work);
+   int notify, notify_all = 0, more = 1;
+   struct xen_pvcalls_request req;
+   struct xenbus_device *dev = fedata->dev;
+
+   while (more) {
+   while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
+   RING_COPY_REQUEST(>ring,
+ fedata->ring.req_cons++,
+ );
+
+   if (!pvcalls_back_handle_cmd(dev, )) {
+   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
+   >ring, notify);
+   notify_all += notify;
+   }
+   }
+
+   if (notify_all)
+   notify_remote_via_irq(fedata->irq);
+
+   RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
+   }
 }
 
 static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
 {
+   struct xenbus_device *dev = dev_id;
+   struct pvcalls_fedata *fedata = NULL;
+
+   if (dev == NULL)
+   return IRQ_HANDLED;
+
+   fedata = dev_get_drvdata(>dev);
+   if (fedata == NULL)
+   return IRQ_HANDLED;
+
+   /*
+* TODO: a small theoretical race exists if we try to queue work
+* after pvcalls_back_work checked for final requests and before
+* it returns. The queuing will fail, and pvcalls_back_work
+* won't do the work because it is about to return. In that
+* case, we lose the notification.
+*/
+   queue_work(fedata->wq, >register_work);
+
return IRQ_HANDLED;
 }
 
-- 
1.9.1


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

[Xen-devel] [PATCH v4 18/18] xen: introduce a Kconfig option to enable the pvcalls backend

[Stefano Stabellini]

Also add pvcalls-back to the Makefile.

Signed-off-by: Stefano Stabellini 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/Kconfig  | 12 
 drivers/xen/Makefile |  1 +
 2 files changed, 13 insertions(+)

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index f15bb3b7..4545561 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -196,6 +196,18 @@ config XEN_PCIDEV_BACKEND
 
  If in doubt, say m.
 
+config XEN_PVCALLS_BACKEND
+   bool "XEN PV Calls backend driver"
+   depends on INET && XEN && XEN_BACKEND
+   default n
+   help
+ Experimental backend for the Xen PV Calls protocol
+ (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
+ allows PV Calls frontends to send POSIX calls to the backend,
+ which implements them.
+
+ If in doubt, say n.
+
 config XEN_SCSI_BACKEND
tristate "XEN SCSI backend driver"
depends on XEN && XEN_BACKEND && TARGET_CORE
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 8feab810..480b928 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_XEN_ACPI_PROCESSOR)  += xen-acpi-processor.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
 obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o
 obj-$(CONFIG_XEN_AUTO_XLATE)   += xlate_mmu.o
+obj-$(CONFIG_XEN_PVCALLS_BACKEND)  += pvcalls-back.o
 xen-evtchn-y   := evtchn.o
 xen-gntdev-y   := gntdev.o
 xen-gntalloc-y := gntalloc.o
-- 
1.9.1


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

[Xen-devel] [PATCH v4 03/18] xen/pvcalls: initialize the module and register the xenbus backend

[Stefano Stabellini]

Keep a list of connected frontends. Use a semaphore to protect list
accesses.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky 
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com
---
 drivers/xen/pvcalls-back.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index f3d0daa..9044cf2 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -25,6 +25,11 @@
 #include 
 #include 
 
+struct pvcalls_back_global {
+   struct list_head frontends;
+   struct semaphore frontends_lock;
+} pvcalls_back_global;
+
 static int pvcalls_back_probe(struct xenbus_device *dev,
  const struct xenbus_device_id *id)
 {
@@ -59,3 +64,20 @@ static int pvcalls_back_uevent(struct xenbus_device *xdev,
.uevent = pvcalls_back_uevent,
.otherend_changed = pvcalls_back_changed,
 };
+
+static int __init pvcalls_back_init(void)
+{
+   int ret;
+
+   if (!xen_domain())
+   return -ENODEV;
+
+   ret = xenbus_register_backend(_back_driver);
+   if (ret < 0)
+   return ret;
+
+   sema_init(_back_global.frontends_lock, 1);
+   INIT_LIST_HEAD(_back_global.frontends);
+   return 0;
+}
+module_init(pvcalls_back_init);
-- 
1.9.1


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

Re: [Xen-devel] [PATCH 2/2] x86/altp2m: Add a hvmop for setting the suppress #VE bit

[Tamas K Lengyel]

On Fri, Jun 9, 2017 at 10:51 AM, Adrian Pop  wrote:
> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> privileged domain to change the value of the #VE suppress bit for a
> page.
>
> Add a libxc wrapper for invoking this hvmop.
>
> Signed-off-by: Adrian Pop 
> ---
>  tools/libxc/include/xenctrl.h   |  2 ++
>  tools/libxc/xc_altp2m.c | 24 +++
>  xen/arch/x86/hvm/hvm.c  | 14 +++
>  xen/arch/x86/mm/mem_access.c| 52 
> +
>  xen/include/public/hvm/hvm_op.h | 15 
>  xen/include/xen/mem_access.h|  3 +++
>  6 files changed, 110 insertions(+)
>
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 1629f412dd..f6ba8635bf 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1926,6 +1926,8 @@ int xc_altp2m_destroy_view(xc_interface *handle, 
> domid_t domid,
>  /* Switch all vCPUs of the domain to the specified altp2m view */
>  int xc_altp2m_switch_to_view(xc_interface *handle, domid_t domid,
>   uint16_t view_id);
> +int xc_altp2m_set_suppress_ve(xc_interface *handle, domid_t domid,
> +  uint16_t view_id, xen_pfn_t gfn, bool sve);
>  int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
>   uint16_t view_id, xen_pfn_t gfn,
>   xenmem_access_t access);
> diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
> index 0639632477..4710133918 100644
> --- a/tools/libxc/xc_altp2m.c
> +++ b/tools/libxc/xc_altp2m.c
> @@ -163,6 +163,30 @@ int xc_altp2m_switch_to_view(xc_interface *handle, 
> domid_t domid,
>  return rc;
>  }
>
> +int xc_altp2m_set_suppress_ve(xc_interface *handle, domid_t domid,
> +  uint16_t view_id, xen_pfn_t gfn, bool sve)
> +{
> +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_set_suppress_ve;
> +arg->domain = domid;
> +arg->u.set_suppress_ve.view = view_id;
> +arg->u.set_suppress_ve.gfn = gfn;
> +arg->u.set_suppress_ve.suppress_ve = sve;
> +
> +rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
> + HYPERCALL_BUFFER_AS_ARG(arg));
> +
> +xc_hypercall_buffer_free(handle, arg);
> +return rc;
> +}
> +
>  int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
>   uint16_t view_id, xen_pfn_t gfn,
>   xenmem_access_t access)
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 70ddc81d44..dd8e205551 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4358,6 +4358,7 @@ static int do_altp2m_op(
>  case HVMOP_altp2m_destroy_p2m:
>  case HVMOP_altp2m_switch_p2m:
>  case HVMOP_altp2m_set_mem_access:
> +case HVMOP_altp2m_set_suppress_ve:
>  case HVMOP_altp2m_change_gfn:
>  break;
>  default:
> @@ -4475,6 +4476,19 @@ static int do_altp2m_op(
>  a.u.set_mem_access.view);
>  break;
>
> +case HVMOP_altp2m_set_suppress_ve:
> +if ( a.u.set_suppress_ve.pad1 || a.u.set_suppress_ve.pad2 )
> +rc = -EINVAL;
> +else
> +{
> +gfn_t gfn = _gfn(a.u.set_mem_access.gfn);
> +unsigned int altp2m_idx = a.u.set_mem_access.view;
> +bool suppress_ve = a.u.set_suppress_ve.suppress_ve;
> +
> +rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
> +}
> +break;
> +
>  case HVMOP_altp2m_change_gfn:
>  if ( a.u.change_gfn.pad1 || a.u.change_gfn.pad2 )
>  rc = -EINVAL;
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index d0b0767855..8c39db13e3 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -466,6 +466,58 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn, 
> xenmem_access_t *access)
>  }
>
>  /*
> + * Set/clear the #VE suppress bit for a page.  Only available on VMX.
> + */
> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, bool suppress_ve,
> +unsigned int altp2m_idx)
> +{
> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
> +struct p2m_domain *ap2m = NULL;
> +struct p2m_domain *p2m;
> +mfn_t mfn;
> +p2m_access_t a;
> +p2m_type_t t;
> +int rc;
> +
> +if ( !cpu_has_vmx_virt_exceptions )
> +return -EOPNOTSUPP;
> +
> +/* This subop should only be used from a privileged domain. */
> +if ( !current->domain->is_privileged )
> +return -EINVAL;

This check looks wrong to me. If this subop should only be used by an

Re: [Xen-devel] [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

[Stefano Stabellini]

On Thu, 15 Jun 2017, Boris Ostrovsky wrote:
> On 06/14/2017 05:03 PM, Stefano Stabellini wrote:
> > On Mon, 12 Jun 2017, Boris Ostrovsky wrote:
> >>> +
> >>>  static void pvcalls_back_work(struct work_struct *work)
> >>>  {
> >>> + struct pvcalls_fedata *priv = container_of(work,
> >>> + struct pvcalls_fedata, register_work);
> >>> + int notify, notify_all = 0, more = 1;
> >>> + struct xen_pvcalls_request req;
> >>> + struct xenbus_device *dev = priv->dev;
> >>> +
> >>> + while (more) {
> >>> + while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
> >>> + RING_COPY_REQUEST(>ring,
> >>> +   priv->ring.req_cons++,
> >>> +   );
> >>> +
> >>> + if (!pvcalls_back_handle_cmd(dev, )) {
> >>> + RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
> >>> + >ring, notify);
> >>> + notify_all += notify;
> >>> + }
> >>> + }
> >>> +
> >>> + if (notify_all)
> >>> + notify_remote_via_irq(priv->irq);
> >>> +
> >>> + RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
> >>> + }
> >>>  }
> >>>  
> >>>  static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
> >>>  {
> >>> + struct xenbus_device *dev = dev_id;
> >>> + struct pvcalls_fedata *priv = NULL;
> >>> +
> >>> + if (dev == NULL)
> >>> + return IRQ_HANDLED;
> >>> +
> >>> + priv = dev_get_drvdata(>dev);
> >>> + if (priv == NULL)
> >>> + return IRQ_HANDLED;
> >>> +
> >>> + /*
> >>> +  * TODO: a small theoretical race exists if we try to queue work
> >>> +  * after pvcalls_back_work checked for final requests and before
> >>> +  * it returns. The queuing will fail, and pvcalls_back_work
> >>> +  * won't do the work because it is about to return. In that
> >>> +  * case, we lose the notification.
> >>> +  */
> >>> + queue_work(priv->wq, >register_work);
> >> Would queuing delayed work (if queue_work() failed) help? And canceling
> >> it on next invocation of pvcalls_back_event()?
> > Looking at the implementation of queue_delayed_work_on and
> > queue_work_on, it looks like that if queue_work fails then also
> > queue_delayed_work would fail: they both test on
> > WORK_STRUCT_PENDING_BIT.
> 
> Right, I should have looked at this myself. And flush_work() I suppose
> cannot be used here since it may sleep?
> 
> Then I also can't think of anything else.

I guess one way to work around the issue would be to use multiple work
items, and queue a new (different) work item at each pvcalls_back_event.
But that approach would use more memory and would need a new lock
in pvcalls_back_work.

Given that the race is only theoretical (I am running nginx inside a
VM and hitting it with as many multiple requests as I can and still I
cannot reproduce it), I am tempted to leave it as-is with a comment. We
can revisit it in the future if we find any real issues.

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

Re: [Xen-devel] [PATCH 1/2] x86/mm: Change default value for suppress #VE in set_mem_access()

[Tamas K Lengyel]

On Fri, Jun 9, 2017 at 10:51 AM, Adrian Pop  wrote:
> From: Vlad Ioan Topan 
>
> The default value for the "suppress #VE" bit set by set_mem_access()
> currently depends on whether the call is made from the same domain (the
> bit is set when called from another domain and cleared if called from
> the same domain). This patch changes that behavior to inherit the old
> suppress #VE bit value if it is already set and to set it to 1
> otherwise, which is safer and more reliable.

Could you elaborate on why do you think it is safer and more reliable
to switch the behavior? I believe the original idea was that the
domain should only be allowed to clear an SVE bit set by an external
tool. With this change it will allow the guest to request VE for any
page the external tool hasn't itself reserved specifically.

Tamas

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

Re: [Xen-devel] [PATCH 15/24] xen/arm: Use the newly introduced MFN <-> MADDR and GFN <-> MADDR helpers

[Tamas K Lengyel]

On Tue, Jun 13, 2017 at 10:13 AM, Julien Grall  wrote:
> Replace the following constructions:
> - _gfn(paddr_to_pfn(...))   => gaddr_to_gfn(...)
> - _mfn(paddr_to_pfn(...))   => maddr_to_mfn(...)
> - pfn_to_paddr(mfn_x(...))  => mfn_to_maddr(...)
> - pfn_to_paddr(gfn_x(...))  => gfn_to_gaddr(...)
> - _mfn(... >> PAGE_SHIFT)   => maddr_to_mfn(...)
>
> Signed-off-by: Julien Grall 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 

Cool, this makes things a lot more readable!

For the mem_access bits:
Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [RFC PATCH v3 10/10] arm/mem_access: Walk the guest's pt in software

[Tamas K Lengyel]

On Thu, Jun 15, 2017 at 5:05 AM, Sergej Proskurin
 wrote:
> In this commit, we make use of the gpt walk functionality introduced in
> the previous commits. If mem_access is active, hardware-based gva to ipa
> translation might fail, as gva_to_ipa uses the guest's translation
> tables, access to which might be restricted by the active VTTBR. To
> side-step potential translation errors in the function
> p2m_mem_access_check_and_get_page due to restricted memory (e.g. to the
> guest's page tables themselves), we walk the guest's page tables in
> software.
>
> Signed-off-by: Sergej Proskurin 
> ---
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
> v2: Check the returned access rights after walking the guest's page tables in
> the function p2m_mem_access_check_and_get_page.
>
> v3: Adapt Function names and parameter.
> ---
>  xen/arch/arm/mem_access.c | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index 04b1506b00..acb5539bb6 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
>  xenmem_access_t *access)
> @@ -101,6 +102,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>const struct vcpu *v)
>  {
>  long rc;
> +unsigned int perms;
>  paddr_t ipa;
>  gfn_t gfn;
>  mfn_t mfn;
> @@ -110,8 +112,25 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag,
>  struct p2m_domain *p2m = >domain->arch.p2m;
>
>  rc = gva_to_ipa(gva, , flag);
> +
> +/*
> + * In case mem_access is active, hardware-based gva_to_ipa translation
> + * might fail. Since gva_to_ipa uses the guest's translation tables, 
> access
> + * to which might be restricted by the active VTTBR, we perform a gva to
> + * ipa translation in software.
> + */
>  if ( rc < 0 )
> -goto err;
> +{
> +if ( guest_walk_tables(v, gva, , ) < 0 )
> +/*
> + * The software gva to ipa translation can still fail, e.g., if 
> the
> + * gva is not mapped.
> + */
> +goto err;
> +
> +if ( ((flag & GV2M_WRITE) == GV2M_WRITE) && !(perms & GV2M_WRITE) )

Wouldn't it be enough to do (flag & GV2M_WRITE) without the following
comparison? Also, a comment explaining why this is an error-condition
would be nice.

> +goto err;
> +}
>
>  gfn = _gfn(paddr_to_pfn(ipa));
>
> --
> 2.12.2

Thanks,
Tamas

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

Re: [Xen-devel] Next Xen ARM community call - 21st June 2017

[Stefano Stabellini]

On Thu, 15 Jun 2017, Julien Grall wrote:
> Hi all,
> 
> I would suggest to organize the next Xen ARM community on Wednesday 21st June
> at 5PM BST. Any opinions?

It works for me. FYI I sent a separate invite to discuss EL0 apps and
stubdoms on ARM (alpine.DEB.2.10.1706151117090.12156@sstabellini-ThinkPad-X260).

In this call, I would like to discuss Renesas R-Car H3 and NXP i.MX 8
support in Xen.


> Also do you have any specific topic you would like to talk during this call?
> 
> For joining the call, please use either:
> 
> Call+44 1223 406065 (Local dial in)
> and enter the access code below followed by # key.
> Participant code: 4915191
> 
> Mobile Auto Dial:
> VoIP: voip://+441223406065;4915191#
> iOS devices: +44 1223 406065,4915191 and press #
> Other devices: +44 1223 406065x4915191#
> 
> Additional Calling Information:
> 
> UK +44 1142828002
> US CA +1 4085761502
> US TX +1 5123141073
> JP +81 453455355
> DE +49 8945604050
> NO +47 73187518
> SE +46 46313131
> FR +33 497235101
> TW +886 35657119
> HU +36 13275600
> IE +353 91337900
> 
> Toll Free
> 
> UK 0800 1412084
> US +1 8668801148
> CN +86 4006782367
> IN 0008009868365
> IN +918049282778
> TW 08000 22065
> HU 0680981587
> IE 1800800022
> KF +972732558877
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

[Xen-devel] EL0 app, stubdoms on ARM conf call

[Stefano Stabellini]

Hi all,

Would you be up for joining a conf call to discuss EL0 apps and stubdoms
on ARM in preparation for Xen Developer Summit?

If so, would Wednesday the 28th of June at 9AM PST work for you?

I realize we also have the ARM community call next well, but this is a
large topic which deserves an entire slot for itself, and also would be
nice to have scheduling experts involved.

Please reply to confirm your presence. If enough people will attend,
I'll send out meeting invites.

Cheers,

Stefano

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

Re: [Xen-devel] [PATCH v3 11/18] xen/pvcalls: implement accept command

[Stefano Stabellini]

On Thu, 15 Jun 2017, Juergen Gross wrote:
> On 14/06/17 21:27, Stefano Stabellini wrote:
> > On Wed, 14 Jun 2017, Juergen Gross wrote:
> >> On 14/06/17 02:47, Stefano Stabellini wrote:
> >>> On Tue, 13 Jun 2017, Juergen Gross wrote:
>  On 02/06/17 21:31, Stefano Stabellini wrote:
> > Implement the accept command by calling inet_accept. To avoid blocking
> > in the kernel, call inet_accept(O_NONBLOCK) from a workqueue, which get
> > scheduled on sk_data_ready (for a passive socket, it means that there
> > are connections to accept).
> >
> > Use the reqcopy field to store the request. Accept the new socket from
> > the delayed work function, create a new sock_mapping for it, map
> > the indexes page and data ring, and reply to the other end. Allocate an
> > ioworker for the socket.
> >
> > Only support one outstanding blocking accept request for every socket at
> > any time.
> >
> > Add a field to sock_mapping to remember the passive socket from which an
> > active socket was created.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > ---
> >  drivers/xen/pvcalls-back.c | 109 
> > -
> >  1 file changed, 108 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> > index a75586e..f1173f4 100644
> > --- a/drivers/xen/pvcalls-back.c
> > +++ b/drivers/xen/pvcalls-back.c
> > @@ -65,6 +65,7 @@ struct pvcalls_ioworker {
> >  struct sock_mapping {
> > struct list_head list;
> > struct pvcalls_fedata *priv;
> > +   struct sockpass_mapping *sockpass;
> > struct socket *sock;
> > uint64_t id;
> > grant_ref_t ref;
> > @@ -275,10 +276,79 @@ static int pvcalls_back_release(struct 
> > xenbus_device *dev,
> >  
> >  static void __pvcalls_back_accept(struct work_struct *work)
> >  {
> > +   struct sockpass_mapping *mappass = container_of(
> > +   work, struct sockpass_mapping, register_work);
> > +   struct sock_mapping *map;
> > +   struct pvcalls_ioworker *iow;
> > +   struct pvcalls_fedata *priv;
> > +   struct socket *sock;
> > +   struct xen_pvcalls_response *rsp;
> > +   struct xen_pvcalls_request *req;
> > +   int notify;
> > +   int ret = -EINVAL;
> > +   unsigned long flags;
> > +
> > +   priv = mappass->priv;
> > +   /* We only need to check the value of "cmd" atomically on read. 
> > */
> > +   spin_lock_irqsave(>copy_lock, flags);
> > +   req = >reqcopy;
> > +   if (req->cmd != PVCALLS_ACCEPT) {
> > +   spin_unlock_irqrestore(>copy_lock, flags);
> > +   return;
> > +   }
> > +   spin_unlock_irqrestore(>copy_lock, flags);
> 
>  What about:
>   req = >reqcopy;
>   if (ACCESS_ONCE(req->cmd) != PVCALLS_ACCEPT)
>   return;
> 
>  I can't see the need for taking a lock here.
> >>>
> >>> Sure, good idea
> >>>
> >>>
> > +
> > +   sock = sock_alloc();
> > +   if (sock == NULL)
> > +   goto out_error;
> > +   sock->type = mappass->sock->type;
> > +   sock->ops = mappass->sock->ops;
> > +
> > +   ret = inet_accept(mappass->sock, sock, O_NONBLOCK, true);
> > +   if (ret == -EAGAIN) {
> > +   sock_release(sock);
> > +   goto out_error;
> > +   }
> > +
> > +   map = pvcalls_new_active_socket(priv,
> > +   req->u.accept.id_new,
> > +   req->u.accept.ref,
> > +   req->u.accept.evtchn,
> > +   sock);
> > +   if (!map) {
> > +   sock_release(sock);
> > +   goto out_error;
> > +   }
> > +
> > +   map->sockpass = mappass;
> > +   iow = >ioworker;
> > +   atomic_inc(>read);
> > +   atomic_inc(>io);
> > +   queue_work_on(iow->cpu, iow->wq, >register_work);
> > +
> > +out_error:
> > +   rsp = RING_GET_RESPONSE(>ring, priv->ring.rsp_prod_pvt++);
> > +   rsp->req_id = req->req_id;
> > +   rsp->cmd = req->cmd;
> > +   rsp->u.accept.id = req->u.accept.id;
> > +   rsp->ret = ret;
> > +   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(>ring, notify);
> > +   if (notify)
> > +   notify_remote_via_irq(priv->irq);
> > +
> > +   spin_lock_irqsave(>copy_lock, flags);
> > +   mappass->reqcopy.cmd = 0;
> > +   spin_unlock_irqrestore(>copy_lock, flags);
> 
>  

Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

[Stefano Stabellini]

On Thu, 15 Jun 2017, Jan Beulich wrote:
> >>> Stefano Stabellini  06/15/17 2:27 AM >>>
> >On Wed, 14 Jun 2017, Jan Beulich wrote:
> >> >>> Stefano Stabellini  06/14/17 8:45 PM >>>
> >> >On Wed, 14 Jun 2017, Jan Beulich wrote:
> >> >> > +What ACCESS_ONCE does *not* guarantee though is this access is done 
> >> >> > in a
> >> >> > +single instruction, so complex or non-native or unaligned data types 
> >> >> > are
> >> >> > +not guaranteed to be atomic. If for instance counter would be a 
> >> >> > 64-bit value
> >> >> > +on a 32-bit system, the compiler would probably generate two load 
> >> >> > instructions,
> >> >> > +which could end up in reading a wrong value if some other CPU 
> >> >> > changes the other
> >> >> > +half of the variable in between those two reads.
> >> >> > +However accessing _aligned and native_ data types is guaranteed to 
> >> >> > be atomic
> >> >> > +in the architectures supported by Xen, so ACCESS_ONCE is safe to use 
> >> >> > when
> >> >> > +these conditions are met.
> >> >> 
> >> >> As mentioned before, such a guarantee does not exist. Please only
> >> >> state what is really the case, i.e. we _expect_ compilers to behave
> >> >> this way.
> >> >
> >> >Regarding compilers support: do we state clearly in any docs or website
> >> >what are the compilers we actually support? I think this would be the
> >> >right opportunity to do it.
> >> 
> >> At the very least we state somewhere what gcc versions we support. However,
> >> I can't see the relation of such a statement to the discussion here.
> >
> >The relation is that our "compiler expectations" shape what compilers we
> >support.
> 
> I don't view it this way - we implicitly support unknown future versions of 
> gcc,
> and we can't know if they might break our assumptions.

OK. In that case, in the same document or wikipage where we write about
gcc versions, it makes sense to write about compiler
assumptions/expectations too.

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

[Xen-devel] [distros-debian-snapshot test] 71558: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail blocked 
in 71515
 test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start   fail like 71515
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail like 71515
 test-amd64-i386-i386-current-netinst-pygrub 9 debian-di-install fail like 71515
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 71515
 test-amd64-amd64-i386-current-netinst-pygrub 9 debian-di-install fail like 
71515
 test-amd64-i386-amd64-current-netinst-pygrub 9 debian-di-install fail like 
71515
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71515
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
71515
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 71515
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71515

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass

baseline version:
 flight   71515

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [RFC PATCH] docs: add README.atomic

[Andre Przywara]

Hi Jan,

thanks for spending your time on this mind boggling exercise!

On 14/06/17 10:12, Jan Beulich wrote:
 On 13.06.17 at 17:25,  wrote:
>> as mentioned in my previous mail, I consider this more of a discussion
>> base that an actual patch. I am by no means an expert in this area, so
>> part of this exercise here is to write down my understanding and see it
>> corrected by more knowledgable people ;-)
> 
> Nevertheless please follow submission guidelines and send _to_
> the list, _cc_-ing maintainers and other relevant people.

Sure.

>> --- /dev/null
>> +++ b/docs/README.atomic
> 
> I'm not overly happy with that name. Perhaps something line
> atomic.txt? Also I guess this would rather belong under docs/misc/,
> at least based on what's there already.

I was just looking at doc/README.*, but sure I can move and rename it.

>> @@ -0,0 +1,116 @@
>> +Atomic operations in Xen
>> +
>> +
>> +Data structures in Xen memory which can be accessed by multiple CPUs
>> +at the same time need to be protected against getting corrupted.
>> +The easiest way to do this is using a lock (spinlock in Xen's case),
>> +that guarantees that only one CPU can access that memory at a given point
>> +in time, also allows protecting whole data structures against becoming
>> +inconsistent. For most use cases this should be the way to go and 
>> programmers
>> +should stop reading here.
> 
> As further down you talk about lockless approaches only, please
> also mention r/w write locking above.

What do you mean with "r/w write locking" here? Does Xen's rwlock_t use
some lockless tricks?

>> +However sometimes taking and releasing a lock is too costly or creates
>> +deadlocks or potential contention, so some lockless accesses are used.
>> +Those atomic accesses need to be done very carefully to be correct.
>> +
>> +Xen offers three kinds of atomic primitives that deal with those accesses:
>> +
>> +ACCESS_ONCE()
>> +-
> 
> For this I think we should first of all settle whether we want to stay
> with this or use READ_ONCE() / WRITE_ONCE() which modern Linux
> prefers.

Sure.

>> +A macro basically casting the access to a volatile data type. That prevents
>> +the compiler from accessing that memory location multiple times, effectively
>> +caching this value (either in a register or on the stack).
>> +In terms of atomicity this prevents inconsistent values for a certain shared
>> +variable if used multiple times across the same function, as the compiler is
>> +normally free to re-read the value from memory at any time - given that it
>> +doesn't know that another entity might change this value. Consider the
>> +following code:
>> +===
>> +int x = shared_pointer->counter;
>> +
>> +some_var = x + something_else;
>> +function_call(x);
>> +===
>> +The compiler is free to actually *not* use a local variable, instead 
>> derefence
>> +the pointer and directly access the shared memory twice when using the value
>> +of "x" in the assignment and in the function call. Now if some other CPU
>> +changes the value of "counter" meanwhile, the value of "x" is different,
>> +which violates the program semantic. The compiler is not to blame here,
>> +because it cannot know that this memory could change behind its back.
>> +The solution here is to use ACCESS_ONCE, which casts the access with the
>> +"volatile" keyword, thus making sure that the compiler knows that
>> +accessing this memory has side effects, so it needs to cache the value:
>> +===
>> +int x = ACCESS_ONCE(shared_pointer->counter);
>> +
>> +some_var = x + something_else;
>> +function_call(x);
>> +===
>> +
>> +What ACCESS_ONCE does *not* guarantee though is this access is done in a
>> +single instruction, so complex or non-native or unaligned data types are
>> +not guaranteed to be atomic. If for instance counter would be a 64-bit value
>> +on a 32-bit system, the compiler would probably generate two load 
>> instructions,
>> +which could end up in reading a wrong value if some other CPU changes the 
>> other
>> +half of the variable in between those two reads.
>> +However accessing _aligned and native_ data types is guaranteed to be atomic
>> +in the architectures supported by Xen, so ACCESS_ONCE is safe to use when
>> +these conditions are met.
> 
> As mentioned before, such a guarantee does not exist. Please only
> state what is really the case, i.e. we _expect_ compilers to behave
> this way.

Do you mean the guarantee of using a single machine instruction to
access variables?
For the "aligned access to native data types" there are explicit
architectural guarantees:
Intel manual volume 3, chapter 8.1.1 Guaranteed Atomic Operations
ARMv7 ARM, chapter A3.5.3  Atomicity in the ARM architecture
ARMv8 ARM, chapter B2.6.1  Requirements for single-copy atomicity
(I will probably add those references to the document anyway)

>> +We expect a variable to 

[Xen-devel] Patch added to scsi: scsi: xen-scsifront: Remove code that zeroes driver-private command data

[James Bottomley]

Your commit:

scsi: xen-scsifront: Remove code that zeroes driver-private command data

Since the SCSI core zeroes driver-private command data, remove
that code from the xen-scsifront driver.

Signed-off-by: Bart Van Assche 
Reviewed-by: Hannes Reinecke 
Reviewed-by: Juergen Gross 
Reviewed-by: Christoph Hellwig 
Cc: xen-de...@lists.xenproject.org
Cc: Johannes Thumshirn 
Signed-off-by: Martin K. Petersen 

has been added to the upstream scsi tree
On branch "misc"
You can find it here:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi.git;a=commit;h=f7de50da1479156d76c0dd3c29234a44bc4845f0

This patch is scheduled to be pushed when the merge window opens for 4.13

James Bottomley

P.S. If you find this email unwanted, set up a procmail rule junking on
the header:

X-Git-Tree: SCSI

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

Re: [Xen-devel] [PATCH 1/4] xen: credit2: implement utilization cap

[Anshul Makkar]

On 13/06/2017 22:13, Dario Faggioli wrote:

On Tue, 2017-06-13 at 17:07 +0100, Anshul Makkar wrote:

On 12/06/2017 14:19, Dario Faggioli wrote:

@@ -92,6 +92,82 @@
  */


what I want to ask is that if the budget of the domain is
replenished,
but credit for the vcpus of that domain is not available, then what
happens.


Yes, but the point is that budget can be available or not, while
credits are always available. There's no such thing as credit not being
available at all.

The amount of credits each vcpu has decides which vcpu will run, in the
sense that it will be the one that has the highest amount of credits.
The others will indeed wait, but because they've got less credit than
the one that runs, not because they don't have credits available.

Ok, as discussed, credits are resetted if it reaches 0. In that sense 
its being considered "always available"..



I believe, vcpus won't be scheduled (even if they have budget_quota)
till they get their credit replenished.


Credits are not exhausted or replenished.


But... it's already totally dynamic.


csched2_dom_cntl()
{
svc->budget_quota = max(sdom->tot_budget / sdom->nr_vcpus,
 CSCHED2_MIN_TIMER);
}
If domain->tot_budge = 200
nr_cpus is 4, then each cpu gets 50%.
How this is dynamic allocation ? We are not considering vcpu
utilization
of other vcpus of domain before allocating budget_quota for some
vcpu.


Right. Well, what this means is that each vcpu will get budget in
chunks of tot_budget/nr_vcpus. But then, how much budget each vcpu will
actually be able to get and consume in each period, it's impossible to
know in advance, as it will depend on overall system load, and the
behavior of the various vcpus of the domain.
Yeah, the current implementation is dynamic in the sense that vcpu can 
execute in total more than its quota across multiple budget cycles, but 
its static in the sense that vcpu can't execute more than its budget 
quota in a single budget cycle.s



In runq candidate we have a code base


Regards,
Dario


Reviewed-by: Anshul Makkar
Anshul


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

[Xen-devel] [linux-3.18 test] 110441: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linux8366868460f8784e30302f441546a9d72ffe1236
baseline version:
 linux88ff45d07559d2ba05ef7adf0028055454dc548b

Last test of basis   110264  2017-06-10 15:25:19 Z5 days
Testing same since   110441  2017-06-14 13:16:35 Z1 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexander Potapenko 
  Alexander Sverdlin 
  Andrew Morton 
  Arjan van de Ven 
  Arnd Bergmann 
  Ben Hutchings 
  Catalin Marinas 
  Christoffer Dall 
  Christoph Hellwig 
  Craig Gallek 
  Dan Carpenter 
  Daniel Cashman 
  Daniel Micay 
  David Howells 
  David S. Miller 

[Xen-devel] [ovmf baseline-only test] 71567: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71563
 build-i386-libvirt5 libvirt-buildfail   like 71563

version targeted for testing:
 ovmf c314970984065c98a56097443ae38d57a27bc73b
baseline version:
 ovmf 46e2632b4e873dc191bf008c95b47340c8957a47

Last test of basis71563  2017-06-14 13:21:53 Z1 days
Testing same since71567  2017-06-15 11:51:25 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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


Push not applicable.


commit c314970984065c98a56097443ae38d57a27bc73b
Author: Jiaxin Wu 
Date:   Thu Mar 16 09:59:05 2017 +0800

NetworkPkg: Typo fix and comments correction

warter -> water
Maunual -> Manual
TCP and UDP --> TCP4 and TCP6
TCP or UDP --> TCP4 or TCP6

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

commit e826679b5c5817bac3727515c019f50dfb8b0d46
Author: Jiaxin Wu 
Date:   Thu Mar 16 09:58:27 2017 +0800

MdeModulePkg/Network: Typo fix

warter -> water
Maunual -> Manual

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

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

Re: [Xen-devel] [RFC PATCH 0/4] Per-domain locking in xl

[Jan Beulich]

>>> Wei Liu  06/14/17 7:19 PM >>>
>It has always been the case that different xl processes can manipulate the same
>domain at the same time. This could be problematic.
>
>This series attempts to provide facility for xl to have a per-domain lock. This
>lock should be used whenever xl manipulates an existing domain.

Aiui this is in response to the guest-reboot-while-migrating issue.
However, wouldn't migration in such a case better be aborted, the
guest allowed to shut down, and it be restarted on the destination
host (the last step omitted if the guest is shutting down instead of
rebooting)?

Jan


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

Re: [Xen-devel] [PATCH v3 06/18] xen/pvcalls: handle commands from the frontend

[Boris Ostrovsky]

On 06/14/2017 05:03 PM, Stefano Stabellini wrote:
> On Mon, 12 Jun 2017, Boris Ostrovsky wrote:
>>> +
>>>  static void pvcalls_back_work(struct work_struct *work)
>>>  {
>>> +   struct pvcalls_fedata *priv = container_of(work,
>>> +   struct pvcalls_fedata, register_work);
>>> +   int notify, notify_all = 0, more = 1;
>>> +   struct xen_pvcalls_request req;
>>> +   struct xenbus_device *dev = priv->dev;
>>> +
>>> +   while (more) {
>>> +   while (RING_HAS_UNCONSUMED_REQUESTS(>ring)) {
>>> +   RING_COPY_REQUEST(>ring,
>>> + priv->ring.req_cons++,
>>> + );
>>> +
>>> +   if (!pvcalls_back_handle_cmd(dev, )) {
>>> +   RING_PUSH_RESPONSES_AND_CHECK_NOTIFY(
>>> +   >ring, notify);
>>> +   notify_all += notify;
>>> +   }
>>> +   }
>>> +
>>> +   if (notify_all)
>>> +   notify_remote_via_irq(priv->irq);
>>> +
>>> +   RING_FINAL_CHECK_FOR_REQUESTS(>ring, more);
>>> +   }
>>>  }
>>>  
>>>  static irqreturn_t pvcalls_back_event(int irq, void *dev_id)
>>>  {
>>> +   struct xenbus_device *dev = dev_id;
>>> +   struct pvcalls_fedata *priv = NULL;
>>> +
>>> +   if (dev == NULL)
>>> +   return IRQ_HANDLED;
>>> +
>>> +   priv = dev_get_drvdata(>dev);
>>> +   if (priv == NULL)
>>> +   return IRQ_HANDLED;
>>> +
>>> +   /*
>>> +* TODO: a small theoretical race exists if we try to queue work
>>> +* after pvcalls_back_work checked for final requests and before
>>> +* it returns. The queuing will fail, and pvcalls_back_work
>>> +* won't do the work because it is about to return. In that
>>> +* case, we lose the notification.
>>> +*/
>>> +   queue_work(priv->wq, >register_work);
>> Would queuing delayed work (if queue_work() failed) help? And canceling
>> it on next invocation of pvcalls_back_event()?
> Looking at the implementation of queue_delayed_work_on and
> queue_work_on, it looks like that if queue_work fails then also
> queue_delayed_work would fail: they both test on
> WORK_STRUCT_PENDING_BIT.

Right, I should have looked at this myself. And flush_work() I suppose
cannot be used here since it may sleep?

Then I also can't think of anything else.

-boris

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

[Xen-devel] [xen-4.8-testing test] 110437: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  16 guest-start.2fail in 110387 pass in 110437
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
110410 pass in 110437
 test-xtf-amd64-amd64-3   45 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 110387
 test-amd64-amd64-xl-rtds  9 debian-install fail pass in 110387
 test-amd64-amd64-xl-qcow2 9 debian-di-install  fail pass in 110410

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 11 guest-start fail in 110387 like 110295
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 110410 like 
110295
 test-xtf-amd64-amd64-1  45 xtf/test-hvm64-lbr-tsx-vmentry fail like 110182
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 110242
 test-xtf-amd64-amd64-2  45 xtf/test-hvm64-lbr-tsx-vmentry fail like 110295
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 110295
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 110295
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair 20 guest-start/debian  fail REGR. vs. 110427
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail REGR. vs. 110427
 test-arm64-arm64-libvirt-xsm  6 xen-boot fail REGR. vs. 110427
 test-amd64-i386-pair 20 guest-start/debian   fail REGR. vs. 110427
 test-amd64-amd64-pair20 guest-start/debian   fail REGR. vs. 110427
 test-arm64-arm64-xl-credit2   6 xen-boot fail REGR. vs. 110427
 test-arm64-arm64-xl-xsm   6 xen-boot fail REGR. vs. 110427
 test-arm64-arm64-xl   6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-xl-vhd   6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-xl-xsm   6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-xl-multivcpu  6 xen-bootfail REGR. vs. 110427
 test-armhf-armhf-xl   6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-libvirt-raw  6 xen-boot fail REGR. vs. 110427
 test-arm64-arm64-examine  6 reboot   fail REGR. vs. 110427
 test-armhf-armhf-examine  6 reboot   fail REGR. vs. 110427
 test-armhf-armhf-xl-cubietruck  6 xen-boot   fail REGR. vs. 110427
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail REGR. vs. 110427
 test-armhf-armhf-libvirt  6 xen-boot fail REGR. vs. 110427
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
110427
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 110427

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot fail REGR. vs. 110427

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail blocked in 
110427
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail blocked in 
110427
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 110427
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 110427
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass

version targeted for testing:
 linuxb14746170b0684005bab3e07893e6b91baf7dbf6
baseline version:
 linux63f700aab4c11d46626de3cd051dae56cf7e9056

Last test of basis  (not found) 
Failing since   (not found) 
Testing same since   110434  2017-06-14 09:52:58 Z1 days1 attempts

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

Re: [Xen-devel] [RFC PATCH v3 04/10] arm/mem_access: Add short-descriptor pte typedefs

[Andrew Cooper]

On 15/06/17 12:05, Sergej Proskurin wrote:
> The current implementation does not provide appropriate types for
> short-descriptor translation table entries. As such, this commit adds new
> types, which simplify managing the respective translation table entries.
>
> Signed-off-by: Sergej Proskurin 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> ---
> v3: Add more short-descriptor related pte typedefs that will be used by
> the following commits.
> ---
>  xen/include/asm-arm/page.h | 104 
> +
>  1 file changed, 104 insertions(+)
>
> diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
> index e2e4b597a5..7a4aa64144 100644
> --- a/xen/include/asm-arm/page.h
> +++ b/xen/include/asm-arm/page.h
> @@ -205,6 +205,110 @@ typedef union {
>  lpae_walk_t walk;
>  } lpae_t;
>  
> +/*
> + *  Comprises bits of the level 1 short-descriptor format representing
> + *  a section.
> + */
> +typedef struct __packed {
> +unsigned int pxn:1; /* Privileged Execute Never */

(I'm not an ARM maintainer, but) can I recommend using bool bitfields
for boolean fields like this.

There's no difference when using the structure for reading data, but it
helps reduce subtle bugs such as

foo.pxn = (flags & NO_EXECUTE);

when using the structures to create a new value, or modify existing ones.

~Andrew

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

[Xen-devel] Next Xen ARM community call - 21st June 2017

[Julien Grall]

Hi all,

I would suggest to organize the next Xen ARM community on Wednesday 21st 
June at 5PM BST. Any opinions?


Also do you have any specific topic you would like to talk during this call?

For joining the call, please use either:

Call+44 1223 406065 (Local dial in)
and enter the access code below followed by # key.
Participant code: 4915191

Mobile Auto Dial:
VoIP: voip://+441223406065;4915191#
iOS devices: +44 1223 406065,4915191 and press #
Other devices: +44 1223 406065x4915191#

Additional Calling Information:

UK +44 1142828002
US CA +1 4085761502
US TX +1 5123141073
JP +81 453455355
DE +49 8945604050
NO +47 73187518
SE +46 46313131
FR +33 497235101
TW +886 35657119
HU +36 13275600
IE +353 91337900

Toll Free

UK 0800 1412084
US +1 8668801148
CN +86 4006782367
IN 0008009868365
IN +918049282778
TW 08000 22065
HU 0680981587
IE 1800800022
KF +972732558877

Cheers,

--
Julien Grall

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

[Xen-devel] [OSSTEST PATCH 3/4] dhcp leases: Introduce new client/server leases query mechanism

[Ian Jackson]

From: osstest service user 

osstest needs to know (from the DHCP server) what addresses its guests
have.  Until now, the only way to do this has been to read the DHCP
server's leases file - if necessary, fetching the leases file from the
server.

Of course the size of the leases file is proportional to the size of
the installation, as is the number of simultaneous test jobs.  So the
overall impact of this is O(n^2); currently, the leases file in
Massachusetts is about 300kby and is being fetched fairly frequently.

So, we provide an alternative arrangement.

The ISC DHCP server does not support a standard way of querying it
about leases (eg, SNMP).  It does support an ISC protocol called
"OMAPI".

We don't want to have each osstest test job talk to the DHCP server
via OMAPI because this would involve giving them a password to the
DHCP server.  So we need to provide, effectively, a proxy daemon.

The available OMAPI client libraries are synchronous; the best
available library is written in Python.  We could write the whole
daemon in Python but that would involve doing our own select and line
buffering/reassembly, reimplementing command parsing, etc. - which we
already have implementations of in tcl/daemonlib.tcl.

So we provide, instead:

 * A Python program `ms-leases-omapiproxy' which speaks OMAPI to the
   DHCP server, and a simple synchronous query protocol on its
   stdin/stdout.  OMAPI authentication is based on a shared secret; to
   avoid duplicating it any more than necessary, ms-leases-omapiproxy
   half-arsedly parses the relevant DHCP server config fragment.

 * A Tcl daemon `ms-leasesdaemon' which multiplexes the multiple
   clients, and issues queries to the Python program.  It speaks
   a protocol similar to the other Tcl daemons.

 * A client implementation in Osstest/DhcpWatch/leasesdaemon.pm which
   can be requested by per-host configuration, as the DHCP lease
   method.

Like with the `leases' access method, the hostname of the DHCP server
must be specified in the host property.  The Tcl daemon binds to *, so
does not need to know its hostname.  So the config has only the port,
and the on-DHCP-server settings.

Signed-off-by: Ian Jackson 
---
 Osstest.pm|  4 ++
 Osstest/DhcpWatch/leasesdaemon.pm | 98 +++
 ms-leases-omapiproxy  | 43 +
 ms-leasesdaemon   | 51 
 4 files changed, 196 insertions(+)
 create mode 100644 Osstest/DhcpWatch/leasesdaemon.pm
 create mode 100755 ms-leases-omapiproxy
 create mode 100755 ms-leasesdaemon

diff --git a/Osstest.pm b/Osstest.pm
index a78728c..9fdefde 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -104,6 +104,10 @@ our %c = qw(
 HostnameSortSwapWords 0
 
 Timezone UTC
+
+DhcpServerOmapiKeyFile /etc/dhcp/osstest-omapi-key
+DhcpServerOmapiPort 7991
+LeasesDaemonPort 4033
 );
 
 $c{$_}='' foreach qw(
diff --git a/Osstest/DhcpWatch/leasesdaemon.pm 
b/Osstest/DhcpWatch/leasesdaemon.pm
new file mode 100644
index 000..9148880
--- /dev/null
+++ b/Osstest/DhcpWatch/leasesdaemon.pm
@@ -0,0 +1,98 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# 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 Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+package Osstest::DhcpWatch::leasesdaemon;
+
+use strict;
+use warnings;
+
+use POSIX;
+use IO::File;
+use IO::Socket;
+
+use Osstest;
+use Osstest::TestSupport;
+
+BEGIN {
+use Exporter ();
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+$VERSION = 1.00;
+@ISA = qw(Exporter);
+@EXPORT  = qw();
+%EXPORT_TAGS = ( );
+
+@EXPORT_OK   = qw();
+}
+
+sub new {
+my ($class, $ho, $meth, $source) = @_;
+my $mo;
+if ($source =~ m/:(?=[^:]*)$/) {
+   $mo = {
+Host => $`,
+Port => $',
+};
+} else {
+   $mo = {
+Host => $source,
+Port => $c{LeasesDaemonPort},
+};
+}
+return bless $mo, $class;
+}
+
+sub check_ip ($$) {
+my ($mo, $gho) = @_;
+
+my $may_retry = 1;
+while ($may_retry) {
+my $rv;
+eval {
+my $lserv = $mo->{Conn};
+if (!$lserv) {
+logm("leasesdaemon: $gho->{Name}:".
+ 

[Xen-devel] [OSSTEST PATCH 2/4] tcl/daemonlib: tolerate no $c(...Host)

[Ian Jackson]

From: osstest service user 

We are going to want a daemon that bins to * rather than to a known
address.

We achieve this by simply tolerating the lack of the FooHost config
setting; and, in that case, not passing -myaddr to Tcl's socket
command (and adjusting messages accordingly).

Signed-off-by: Ian Jackson 
---
 tcl/daemonlib.tcl | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/tcl/daemonlib.tcl b/tcl/daemonlib.tcl
index 1e86d5f..b23caea 100644
--- a/tcl/daemonlib.tcl
+++ b/tcl/daemonlib.tcl
@@ -195,7 +195,7 @@ proc newconn {chan addr port} {
 proc main-daemon {which setup} {
 global c argv
 
-set host $c(${which}DaemonHost)
+catch { set host $c(${which}DaemonHost) }
 set port $c(${which}DaemonPort)
 
 foreach arg $argv {
@@ -210,12 +210,21 @@ proc main-daemon {which setup} {
 fconfigure stdout -buffering line
 fconfigure stderr -buffering none
 
-log "starting $host:$port"
+set desc $port
+
+set sockcmd {socket -server newconn}
+if {[info exists host]} {
+set desc "$host:$port"
+lappend sockcmd [list -myaddr $host]
+}
+lappend sockcmd $port
+
+log "starting $desc"
 
 uplevel 1 $setup
 
-socket -server newconn -myaddr $host $port
-log "listening $host:$port"
+eval $sockcmd
+log "listening $desc"
 
 vwait forever
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 4/4] production-config: Use the new leases server for all hosts by default

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 production-config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/production-config b/production-config
index 96831c7..63d6641 100644
--- a/production-config
+++ b/production-config
@@ -94,6 +94,8 @@ TftpNetbootGroup osstest
 TftpDiVersion_wheezy 2016-06-08
 TftpDiVersion_jessie 2017-04-06
 
+HostProp_DhcpWatchMethod leasesdaemon infra
+
 # For ISO installs
 DebianImageVersion_wheezy 7.2.0
 DebianImageVersion_jessie 8.2.0
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/4] mg-repro-setup: Use new syntax for cs-adjust-flight

[Ian Jackson]

In 497b2c6c933d "Rework runvar-build-set new value handling" we fixed
bugs in cs-adjust-flight which would make mg-repro-setup's attempt to
adjust build jobs sometimes not match at all, but we also changed the
syntax for specifying just a new flight.  I forgot to update the
one in-tree user of that feature.

Signed-off-by: Ian Jackson 
---
 mg-repro-setup | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-repro-setup b/mg-repro-setup
index 4f2fe54..9663497 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -199,7 +199,7 @@ if $skipcapture; then adjrunvar skip_testids 
"capture-logs*"; fi
 
 ./cs-adjust-flight $flight \
copy-jobs $example_flight $job  \
-   runvar-build-set . '/buildjob$' "^$flight\\." $example_flight \
+   runvar-build-set . '/buildjob$' "^$flight\\." $example_flight.  \
"${adjusts[@]}"
 
 progress "executing ..."
-- 
2.1.4


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c314970984065c98a56097443ae38d57a27bc73b
baseline version:
 ovmf 46e2632b4e873dc191bf008c95b47340c8957a47

Last test of basis   110414  2017-06-13 18:48:24 Z1 days
Testing same since   110439  2017-06-14 12:53:27 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [RFC PATCH v3 10/10] arm/mem_access: Walk the guest's pt in software

[Sergej Proskurin]

In this commit, we make use of the gpt walk functionality introduced in
the previous commits. If mem_access is active, hardware-based gva to ipa
translation might fail, as gva_to_ipa uses the guest's translation
tables, access to which might be restricted by the active VTTBR. To
side-step potential translation errors in the function
p2m_mem_access_check_and_get_page due to restricted memory (e.g. to the
guest's page tables themselves), we walk the guest's page tables in
software.

Signed-off-by: Sergej Proskurin 
---
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Check the returned access rights after walking the guest's page tables in
the function p2m_mem_access_check_and_get_page.

v3: Adapt Function names and parameter.
---
 xen/arch/arm/mem_access.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index 04b1506b00..acb5539bb6 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 xenmem_access_t *access)
@@ -101,6 +102,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
   const struct vcpu *v)
 {
 long rc;
+unsigned int perms;
 paddr_t ipa;
 gfn_t gfn;
 mfn_t mfn;
@@ -110,8 +112,25 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
 struct p2m_domain *p2m = >domain->arch.p2m;
 
 rc = gva_to_ipa(gva, , flag);
+
+/*
+ * In case mem_access is active, hardware-based gva_to_ipa translation
+ * might fail. Since gva_to_ipa uses the guest's translation tables, access
+ * to which might be restricted by the active VTTBR, we perform a gva to
+ * ipa translation in software.
+ */
 if ( rc < 0 )
-goto err;
+{
+if ( guest_walk_tables(v, gva, , ) < 0 )
+/*
+ * The software gva to ipa translation can still fail, e.g., if the
+ * gva is not mapped.
+ */
+goto err;
+
+if ( ((flag & GV2M_WRITE) == GV2M_WRITE) && !(perms & GV2M_WRITE) )
+goto err;
+}
 
 gfn = _gfn(paddr_to_pfn(ipa));
 
-- 
2.12.2


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