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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail REGR. vs. 100773
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 100773
 test-armhf-armhf-xl-vhd   9 debian-di-installfail REGR. vs. 100773

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

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

version targeted for testing:
 xen  d6be2cfccfffd6d5ff1da68277ec3ab13e595368
baseline version:
 xen  343f84be135e6f9e681960a9e235296eae159fc8

Last test of basis   100773  2016-09-06 13:13:28 Z1 days
Testing same since   100789  2016-09-07 09:36:36 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Olaf Hering 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

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

[Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Dongli Zhang]

This patch implemented parts of TODO left in commit id
a902c12ee45fc9389eb8fe54eeddaf267a555c58. It moved TLB-flush filtering out
into populate_physmap. Because of TLB-flush in alloc_heap_pages, it's very
slow to create a guest with memory size of more than 100GB on host with
100+ cpus.

This patch introduced a "MEMF_no_tlbflush" bit to memflags to indicate
whether TLB-flush should be done in alloc_heap_pages or its caller
populate_physmap. Once this bit is set in memflags, alloc_heap_pages will
ignore TLB-flush. To use this bit after vm is created might lead to
security issue, that is, this would make pages accessible to the guest B,
when guest A may still have a cached mapping to them.

Therefore, this patch also introduced a "already_scheduled" field to struct
domain to indicate whether this domain has ever got scheduled by
hypervisor.  MEMF_no_tlbflush can be set only during vm creation phase when
already_scheduled is still 0 before this domain gets scheduled for the
first time.

TODO: ballooning very huge amount of memory cannot benefit from this patch
and might still be slow.

Signed-off-by: Dongli Zhang 

---
Changed since v2:
  * Limit this optimization to domain creation time.

---
 xen/common/domain.c |  2 ++
 xen/common/memory.c | 33 +
 xen/common/page_alloc.c |  3 ++-
 xen/common/schedule.c   |  5 +
 xen/include/xen/mm.h|  2 ++
 xen/include/xen/sched.h |  3 +++
 6 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index a8804e4..611a471 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -303,6 +303,8 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 if ( !zalloc_cpumask_var(>domain_dirty_cpumask) )
 goto fail;
 
+d->already_scheduled = 0;
+
 if ( domcr_flags & DOMCRF_hvm )
 d->guest_type = guest_type_hvm;
 else if ( domcr_flags & DOMCRF_pvh )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index f34dd56..3641469 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -141,6 +141,8 @@ static void populate_physmap(struct memop_args *a)
 unsigned int i, j;
 xen_pfn_t gpfn, mfn;
 struct domain *d = a->domain, *curr_d = current->domain;
+bool_t need_tlbflush = 0;
+uint32_t tlbflush_timestamp = 0;
 
 if ( !guest_handle_subrange_okay(a->extent_list, a->nr_done,
  a->nr_extents-1) )
@@ -150,6 +152,12 @@ static void populate_physmap(struct memop_args *a)
 max_order(curr_d)) )
 return;
 
+/* MEMF_no_tlbflush can be set only during vm creation phase when
+ * already_scheduled is still 0 before this domain gets scheduled for
+ * the first time. */
+if ( d->already_scheduled == 0 )
+a->memflags |= MEMF_no_tlbflush;
+
 for ( i = a->nr_done; i < a->nr_extents; i++ )
 {
 if ( i != a->nr_done && hypercall_preempt_check() )
@@ -214,6 +222,21 @@ static void populate_physmap(struct memop_args *a)
 goto out;
 }
 
+if ( d->already_scheduled == 0 )
+{
+for ( j = 0; j < (1U << a->extent_order); j++ )
+{
+if ( page[j].u.free.need_tlbflush &&
+ (page[j].tlbflush_timestamp <= 
tlbflush_current_time()) &&
+ (!need_tlbflush ||
+ (page[j].tlbflush_timestamp > 
tlbflush_timestamp)) )
+{
+need_tlbflush = 1;
+tlbflush_timestamp = page[j].tlbflush_timestamp;
+}
+}
+}
+
 mfn = page_to_mfn(page);
 }
 
@@ -232,6 +255,16 @@ static void populate_physmap(struct memop_args *a)
 }
 
 out:
+if ( need_tlbflush )
+{
+cpumask_t mask = cpu_online_map;
+tlbflush_filter(mask, tlbflush_timestamp);
+if ( !cpumask_empty() )
+{
+perfc_incr(need_flush_tlb_flush);
+flush_tlb_mask();
+}
+}
 a->nr_done = i;
 }
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 18ff6cf..e0283fc 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -827,7 +827,8 @@ static struct page_info *alloc_heap_pages(
 BUG_ON(pg[i].count_info != PGC_state_free);
 pg[i].count_info = PGC_state_inuse;
 
-if ( pg[i].u.free.need_tlbflush &&
+if ( !(memflags & MEMF_no_tlbflush) &&
+ pg[i].u.free.need_tlbflush &&
  (pg[i].tlbflush_timestamp <= tlbflush_current_time()) &&
  (!need_tlbflush ||
   (pg[i].tlbflush_timestamp > tlbflush_timestamp)) )
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index 32a300f..593541a 100644
--- a/xen/common/schedule.c
+++ 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ad8a2f5e68fd9850c10740a6ace2ab785cb99818
baseline version:
 ovmf 960d0de80b288c7cd9cbccfde7a12a48935055b4

Last test of basis   100796  2016-09-07 18:17:57 Z0 days
Testing same since   100801  2016-09-08 03:01:09 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 

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=ad8a2f5e68fd9850c10740a6ace2ab785cb99818
+ . ./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 
ad8a2f5e68fd9850c10740a6ace2ab785cb99818
+ branch=ovmf
+ revision=ad8a2f5e68fd9850c10740a6ace2ab785cb99818
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xad8a2f5e68fd9850c10740a6ace2ab785cb99818 = 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/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  3d20a6f4faf1c6a18b51b80d99d23daa7762dda2
baseline version:
 xen  6e0815a8d75f1cb90f84894346f9261814d7453a

Last test of basis   100791  2016-09-07 11:02:14 Z0 days
Testing same since   100800  2016-09-08 02:02:05 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 

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



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

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

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

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


Pushing revision :

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 960d0de80b288c7cd9cbccfde7a12a48935055b4
baseline version:
 ovmf ec68dc28557925e0708d5676288ad140651a3851

Last test of basis   100783  2016-09-07 05:09:53 Z0 days
Testing same since   100796  2016-09-07 18:17:57 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Hegde Nagaraj P 
  Jiaxin Wu 
  Jiewen Yao 
  Leif Lindholm 
  Michael Zimmermann 
  Ryan Harkin 

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

Re: [Xen-devel] [PATCH v4 9/9] livepach: Add .livepatch.hooks functions and test-case

[Konrad Rzeszutek Wilk]

On Tue, Sep 06, 2016 at 07:25:23PM +0100, Andrew Cooper wrote:
> On 06/09/16 18:22, Konrad Rzeszutek Wilk wrote:
> > On Tue, Aug 23, 2016 at 10:22:12PM -0400, Konrad Rzeszutek Wilk wrote:
> >> From: Ross Lagerwall 
> >>
> >> Add hook functions which run during patch apply and patch revert.
> >> Hook functions are used by livepatch payloads to manipulate data
> >> structures during patching, etc.
> >>
> >> One use case is the XSA91. As Martin mentions it:
> >> "If we have shadow variables, we also need an unload hook to garbage
> >> collect all the variables introduced by a hotpatch to prevent memory
> >> leaks.  Potentially, we also want to pre-reserve memory for static or
> >> existing dynamic objects in the load-hook instead of on the fly.
> >>
> >> For testing and debugging, various applications are possible.
> >>
> >> In general, the hooks provide flexibility when having to deal with
> >> unforeseen cases, but their application should be rarely required (<
> >> 10%)."
> >>
> >> Furthermore include a test-case for it.
> >>
> >> Signed-off-by: Ross Lagerwall 
> >> Signed-off-by: Konrad Rzeszutek Wilk 
> >
> > So... anybody willing to review it :-)
> >
> >> ---
> >> Cc: Andrew Cooper 
> >> Cc: George Dunlap 
> >> Cc: Ian Jackson 
> >> Cc: Jan Beulich 
> >> Cc: Stefano Stabellini 
> >> Cc: Tim Deegan 
> >> Cc: Wei Liu 
> >
> > In regards to this going in v4.8 my recollection is that:
> >
> >  George: 0
> >  Andrew: +1
> >  Jan: 0 (with a slight leaning towards -1)?
> >
> > I think that means folks are OK or 'don't care'.
> >
> > And the livepatch maintainers:
> >  Ross: +1 (obviously since he wrote it)
> >  Konrad: +1
> 
> Reviewed-by: Andrew Cooper 

Thank you!

If nobody objects I will push this patch (along with some
other ones that have been Reviewed) on Friday morning.


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

[Xen-devel] [qemu-upstream-unstable test] 100786: tolerable FAIL - PUSHED

[osstest service owner]

flight 100786 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/100786/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 99786

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

version targeted for testing:
 qemuu570117996772b762e9654e58e708943a4db68b4f
baseline version:
 qemuud145386f52950c0c5d4587dbb6c3b9cdf3a58309

Last test of basis99786  2016-07-29 12:32:03 Z   40 days
Testing same since   100776  2016-09-06 17:15:50 Z1 days2 attempts


421 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm   

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ec68dc28557925e0708d5676288ad140651a3851
baseline version:
 ovmf 96c13c011766a950247c743887705cc035a15497

Last test of basis67664  2016-09-07 05:18:29 Z0 days
Testing same since67668  2016-09-07 18:16:43 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



sg-report-flight on osstest.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 ec68dc28557925e0708d5676288ad140651a3851
Author: Ard Biesheuvel 
Date:   Tue Sep 6 15:25:03 2016 +0100

ArmPkg/CompilerIntrinsicsLib: use Clang-compatible 'weak' attribute

Clang does not like separate definitions for the __alias__ and the
__weak__ attributes, so merge the definitions into one.

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

commit 4c0b2d25c61c8dad0a9dcf9cb078df102aee6284
Author: Ard Biesheuvel 
Date:   Mon Sep 5 10:00:37 2016 +0100

ArmVirtPkg/FdtPciHostBridgeLib: enable 64-bit PCI DMA

Now that the PCI root bridge driver and various host controller drivers
have been fixed, remove the 4 GB limit on PCI DMA allocation for QEMU's
ECAM PCI host bridge.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 

commit e58a71d9c50ba641b5ab19f5ce2cbf772187de4d
Author: Ard Biesheuvel 
Date:   Mon Sep 5 09:55:16 2016 +0100

MdeModulePkg/PciHostBridgeDxe: restrict 64-bit DMA to devices that support 
it

Currently, the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute is completely
ignored by the PCI host bridge driver, which means that, on an 
implementation
that supports DMA above 4 GB, allocations above 4 GB may be provided to
devices that have not expressed support for it.

So in addition to checking 'RootBridge->DmaAbove4G' to establish whether the
root bridge itself supports DMA above 4 GB, we must also take into account
the operation type (EfiPciOperationBusMaster{Read|Write|CommonBuffer}64),
and the EFI_PCI_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute, when mapping and
allocating DMA memory, respectively.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ruiyu Ni 

commit 5c1b371a8839f970a45df3342529d034524f2507
Author: Ard Biesheuvel 
Date:   Mon Sep 5 09:52:10 2016 +0100

MdeModulePkg/XhciDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE
attribute if the controller supports 64-bit DMA addressing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Feng Tian 

commit df0a0e4b6fae7cef3a652e0d52f0e6753d1f3f54
Author: Ard Biesheuvel 
Date:   Mon Sep 5 09:51:48 2016 +0100

MdeModulePkg/SdMmcPciHcDxe: enable 64-bit PCI DMA

PCI controller drivers must set the EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE
attribute if the controller supports 64-bit DMA addressing.

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 67635
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 67635
 test-amd64-amd64-libvirt-xsm 17 guest-start/debian.repeat fail REGR. vs. 67635
 test-amd64-amd64-pair   5 host-ping-check-native/src_host fail REGR. vs. 67635
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 67635

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

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

version targeted 

[Xen-devel] [xen-4.6-testing baseline-only test] 67667: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  4627e5e5f10bf8cdebaf45b66a476c4adb104f6d
baseline version:
 xen  a00a0f9139c4b3a9db8e74aca0ac0808e6f7d65b

Last test of basis67599  2016-08-26 20:44:22 Z   12 days
Testing same since67667  2016-09-07 15:46:29 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  George Dunlap 
  Jan Beulich 
  Razvan Cojocaru 

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

[Xen-devel] [linux-3.14 test] 100784: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 linuxa38ae26d5b7a39deb83b53e7940acc217428622d
baseline version:
 linuxbb28cae901ddf2a4c708dbd03e9e304536c966dc

Last test of basis   100573  2016-08-20 10:16:21 Z   18 days
Testing same since   100784  2016-09-07 06:46:00 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexey Khoroshilov 
  Alexey Klimov 
  Andrew Morton 
  Andy Lutomirski 
  Bjorn Helgaas 
  Borislav Petkov 
  Bruno Wolff III 
  Dan Carpenter 
  Daniele Palmas 
  Dave Carroll 
  Dmitry Torokhov 
  Emmanouil Maroudas 
  Felipe Balbi 
  Felix Fietkau 
  Gavin Li 
  Greg Kroah-Hartman 
  Helge Deller 
  Herbert Xu 
  Ian Abbott 
  Ingo Molnar 
  James Hogan 
  Jason S. McMullan 
  Jim Lin 
  Johan Hovold 
  Johannes Berg 
  Kashyap Desai 
  Laxman Dewangan 
  Linus Torvalds 
  Linus Walleij 
  Lubomir Rintel 
  Mark Laws 
  Martin K. Petersen 
  Martin Schwidefsky 
  Masahiro Yamada 
  Mathias Nyman 
  Oliver Neukum 
  Peter Zijlstra (Intel) 
  Rafael J. Wysocki 
  Rik van Riel 
  Robert Delien 
  Robert Deliën 
  roswest 
  Sebastian Andrzej Siewior 
  Sheng-Hui J. Chu 
  Simon Horman 
  Stefan Haberland 
  Thierry Reding 
  Vegard Nossum 
  Will Deacon 
  Yinghai Lu 

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
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl 

[Xen-devel] [PATCH Altp2m cleanup v4 4/4] Making altp2m struct dynamically allocated.

[Paul Lai]

Ravi Sahita's dynamically allocated altp2m structs

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

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e63ef0b..e378b9c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5323,7 +5323,7 @@ static int do_altp2m_op(
 
 if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
  (a.cmd != HVMOP_altp2m_set_domain_state) &&
- !d->arch.altp2m_active )
+ !altp2m_active(d) )
 {
 rc = -EOPNOTSUPP;
 goto out;
@@ -5357,11 +5357,11 @@ static int do_altp2m_op(
 break;
 }
 
-ostate = d->arch.altp2m_active;
-d->arch.altp2m_active = !!a.u.domain_state.state;
+ostate = altp2m_active(d);
+set_altp2m_active(d, a.u.domain_state.state);
 
 /* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+if ( altp2m_active(d) != ostate &&
  (ostate || !(rc = p2m_init_altp2m_by_id(d, 0))) )
 {
 for_each_vcpu( d, v )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 2759e6f..45ec308 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2043,7 +2043,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
 {
 v->arch.hvm_vmx.secondary_exec_control |= mask;
 __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
-__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m->eptp));
 
 if ( cpu_has_vmx_virt_exceptions )
 {
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index bf3f46e..6803b36 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -78,23 +78,23 @@ altp2m_domain_init(struct domain *d)
 goto out;
 }
 /* Init alternate p2m data. */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+if ( (d->arch.altp2m->eptp = alloc_xenheap_page()) == NULL )
 {
 rc = -ENOMEM;
 goto out;
 }
 
 for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+d->arch.altp2m->eptp[i] = mfn_x(INVALID_MFN);
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+rc = p2m_alloc_table(d->arch.altp2m->p2m[i]);
 if ( rc != 0 )
goto out;
 }
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, false);
  out:
 return rc;
 }
@@ -107,13 +107,13 @@ altp2m_domain_teardown(struct domain *d)
 if ( !hvm_altp2m_supported() )
return;
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, false);
 
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
+free_xenheap_page(d->arch.altp2m->eptp);
+d->arch.altp2m->eptp = NULL;
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
+p2m_teardown(d->arch.altp2m->p2m[i]);
 }
 
 /*
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index e7c6b74..3fd8380 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -877,7 +877,7 @@ int mem_sharing_nominate_page(struct domain *d,
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-ap2m = d->arch.altp2m_p2m[i];
+ap2m = d->arch.altp2m->p2m[i];
 if ( !ap2m )
 continue;
 
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 74fdfc1..71d3891 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -266,8 +266,8 @@ declare_mm_order_constraint(per_page_sharing)
  */
 
 declare_mm_lock(altp2mlist)
-#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m_list_lock)
-#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m_list_lock)
+#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m->list_lock)
+#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m->list_lock)
 
 /* P2M lock (per-altp2m-table)
  *
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 7ae3168..a54c1cf 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1331,14 +1331,14 @@ void setup_ept_dump(void)
 
 void p2m_init_altp2m_ept( struct domain *d, unsigned int i)
 {
-

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

[Paul Lai]

Indent goto labels by one space
Inline (header) altp2m functions
Define default behavior in switch
Define max and min for range of altp2m macroed values

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c| 46 ---
 xen/include/asm-x86/hvm/hvm.h | 19 +++---
 2 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 787f055..e63ef0b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1942,11 +1942,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  * Otherwise, this is an error condition. */
 rc = fall_through;
 
-out_put_gfn:
+ out_put_gfn:
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
 __put_gfn(hostp2m, gfn);
-out:
+ out:
 /* All of these are delayed until we exit, since we might 
  * sleep on event ring wait queues, and we must not hold
  * locks in such circumstance */
@@ -5291,12 +5291,25 @@ static int do_altp2m_op(
 return -EFAULT;
 
 if ( a.pad1 || a.pad2 ||
- (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
- (a.cmd < HVMOP_altp2m_get_domain_state) ||
- (a.cmd > HVMOP_altp2m_change_gfn) )
+(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
 return -EINVAL;
 
-d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+case HVMOP_altp2m_set_domain_state:
+case HVMOP_altp2m_vcpu_enable_notify:
+case HVMOP_altp2m_create_p2m:
+case HVMOP_altp2m_destroy_p2m:
+case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_change_gfn:
+break;
+default:
+return -ENOSYS;
+}
+
+d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
 rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
 
 if ( d == NULL )
@@ -5413,6 +5426,8 @@ static int do_altp2m_op(
 rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
 _gfn(a.u.change_gfn.old_gfn),
 _gfn(a.u.change_gfn.new_gfn));
+default:
+ASSERT_UNREACHABLE();
 }
 
  out:
@@ -5937,25 +5952,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
 v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step;
 }
 
-void altp2m_vcpu_update_p2m(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_p2m )
-hvm_funcs.altp2m_vcpu_update_p2m(v);
-}
-
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
-hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
-}
-
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_emulate_ve )
-return hvm_funcs.altp2m_vcpu_emulate_ve(v);
-return 0;
-}
-
 int hvm_set_mode(struct vcpu *v, int mode)
 {
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 81b60d5..ed043b2 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -599,13 +599,26 @@ static inline bool_t hvm_altp2m_supported(void)
 }
 
 /* updates the current hardware p2m */
-void altp2m_vcpu_update_p2m(struct vcpu *v);
+static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_p2m )
+hvm_funcs.altp2m_vcpu_update_p2m(v);
+}
 
 /* updates VMCS fields related to VMFUNC and #VE */
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v);
+static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
+hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+}
 
 /* emulates #VE */
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
+static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_emulate_ve )
+return hvm_funcs.altp2m_vcpu_emulate_ve(v);
+return false;
+}
 
 /* Check CR4/EFER values */
 const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
-- 
2.7.4


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

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

[Paul Lai]

Move altp2m specific functions to altp2m files.  This makes the code
a little easier to read.

Also moving ept code to ept specific files as requested in:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html

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

diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 930bdc2..bf3f46e 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -65,6 +66,56 @@ altp2m_vcpu_destroy(struct vcpu *v)
 vcpu_unpause(v);
 }
 
+int
+altp2m_domain_init(struct domain *d)
+{
+int rc;
+unsigned int i;
+
+if ( !hvm_altp2m_supported() )
+{
+rc = 0;
+goto out;
+}
+/* Init alternate p2m data. */
+if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+{
+rc = -ENOMEM;
+goto out;
+}
+
+for ( i = 0; i < MAX_EPTP; i++ )
+d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+if ( rc != 0 )
+   goto out;
+}
+
+d->arch.altp2m_active = 0;
+ out:
+return rc;
+}
+
+void
+altp2m_domain_teardown(struct domain *d)
+{
+unsigned int i;
+
+if ( !hvm_altp2m_supported() )
+   return;
+
+d->arch.altp2m_active = 0;
+
+free_xenheap_page(d->arch.altp2m_eptp);
+d->arch.altp2m_eptp = NULL;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+p2m_teardown(d->arch.altp2m_p2m[i]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 3218fa2..283ec38 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -499,27 +500,7 @@ int hap_enable(struct domain *d, u32 mode)
goto out;
 }
 
-if ( hvm_altp2m_supported() )
-{
-/* Init alternate p2m data */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
-{
-rv = -ENOMEM;
-goto out;
-}
-
-for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
-if ( rv != 0 )
-   goto out;
-}
-
-d->arch.altp2m_active = 0;
-}
+rv = altp2m_domain_init(d);
 
 /* Now let other users see the new mode */
 d->arch.paging.mode = mode | PG_HAP_enable;
@@ -533,19 +514,7 @@ void hap_final_teardown(struct domain *d)
 {
 unsigned int i;
 
-if ( hvm_altp2m_supported() )
-{
-d->arch.altp2m_active = 0;
-
-if ( d->arch.altp2m_eptp )
-{
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
-}
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
-}
+altp2m_domain_teardown(d);
 
 /* Destroy nestedp2m's first */
 for (i = 0; i < MAX_NESTEDP2M; i++) {
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 13cab24..7ae3168 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
 register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
 }
 
+void p2m_init_altp2m_ept( struct domain *d, unsigned int i)
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct ept_data *ept;
+
+p2m->min_remapped_gfn = gfn_x(INVALID_GFN);
+p2m->max_remapped_gfn = 0;
+ept = >ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+}
+
+unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
+{
+struct p2m_domain *p2m;
+struct ept_data *ept;
+unsigned int i;
+
+altp2m_list_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == mfn_x(INVALID_MFN) )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+ept = >ept;
+
+if ( eptp == ept_get_eptp(ept) )
+goto out;
+}
+
+i = INVALID_ALTP2M;
+
+ out:
+altp2m_list_unlock(d);
+return i;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 7d14c3b..9a97962 100644
--- 

[Xen-devel] [PATCH Altp2m cleanup v4 1/4] x86/HVM: adjust feature checking in MSR intercept handling

[Paul Lai]

From: Jan Beulich 

Consistently consult hvm_cpuid(). With that, BNDCFGS gets better
handled outside of VMX specific code, just like XSS. Don't needlessly
check for MTRR support when the MSR being accessed clearly is not an
MTRR one.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c| 88 ---
 xen/arch/x86/hvm/vmx/vmx.c| 40 ++--
 xen/include/asm-x86/hvm/hvm.h | 10 +
 3 files changed, 103 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 98f0740..787f055 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -309,6 +309,14 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
 return 1;
 }
 
+bool hvm_set_guest_bndcfgs(struct vcpu *v, u64 val)
+{
+return hvm_funcs.set_guest_bndcfgs &&
+   is_canonical_address(val) &&
+   !(val & IA32_BNDCFGS_RESERVED) &&
+   hvm_funcs.set_guest_bndcfgs(v, val);
+}
+
 /*
  * Get the ratio to scale host TSC frequency to gtsc_khz. zero will be
  * returned if TSC scaling is unavailable or ratio cannot be handled
@@ -3667,28 +3675,30 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 {
 struct vcpu *v = current;
 uint64_t *var_range_base, *fixed_range_base;
-bool_t mtrr;
-unsigned int edx, index;
+bool mtrr = false;
 int ret = X86EMUL_OKAY;
 
 var_range_base = (uint64_t *)v->arch.hvm_vcpu.mtrr.var_ranges;
 fixed_range_base = (uint64_t *)v->arch.hvm_vcpu.mtrr.fixed_ranges;
 
-hvm_cpuid(1, NULL, NULL, NULL, );
-mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
+if ( msr == MSR_MTRRcap ||
+ (msr >= MSR_IA32_MTRR_PHYSBASE(0) && msr <= MSR_MTRRdefType) )
+{
+unsigned int edx;
+
+hvm_cpuid(1, NULL, NULL, NULL, );
+if ( edx & cpufeat_mask(X86_FEATURE_MTRR) )
+mtrr = true;
+}
 
 switch ( msr )
 {
+unsigned int eax, ebx, ecx, index;
+
 case MSR_EFER:
 *msr_content = v->arch.hvm_vcpu.guest_efer;
 break;
 
-case MSR_IA32_XSS:
-if ( !cpu_has_xsaves )
-goto gp_fault;
-*msr_content = v->arch.hvm_vcpu.msr_xss;
-break;
-
 case MSR_IA32_TSC:
 *msr_content = _hvm_rdtsc_intercept();
 break;
@@ -3754,6 +3764,22 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t 
*msr_content)
 *msr_content = var_range_base[index];
 break;
 
+case MSR_IA32_XSS:
+ecx = 1;
+hvm_cpuid(XSTATE_CPUID, , NULL, , NULL);
+if ( !(eax & cpufeat_mask(X86_FEATURE_XSAVES)) )
+goto gp_fault;
+*msr_content = v->arch.hvm_vcpu.msr_xss;
+break;
+
+case MSR_IA32_BNDCFGS:
+ecx = 0;
+hvm_cpuid(7, NULL, , , NULL);
+if ( !(ebx & cpufeat_mask(X86_FEATURE_MPX)) ||
+ !hvm_get_guest_bndcfgs(v, msr_content) )
+goto gp_fault;
+break;
+
 case MSR_K8_ENABLE_C1E:
 case MSR_AMD64_NB_CFG:
  /*
@@ -3790,15 +3816,20 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 bool_t may_defer)
 {
 struct vcpu *v = current;
-bool_t mtrr;
-unsigned int edx, index;
+bool mtrr = false;
 int ret = X86EMUL_OKAY;
 
 HVMTRACE_3D(MSR_WRITE, msr,
(uint32_t)msr_content, (uint32_t)(msr_content >> 32));
 
-hvm_cpuid(1, NULL, NULL, NULL, );
-mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
+if ( msr >= MSR_IA32_MTRR_PHYSBASE(0) && msr <= MSR_MTRRdefType )
+{
+unsigned int edx;
+
+hvm_cpuid(1, NULL, NULL, NULL, );
+if ( edx & cpufeat_mask(X86_FEATURE_MTRR) )
+mtrr = true;
+}
 
 if ( may_defer && unlikely(monitored_msr(v->domain, msr)) )
 {
@@ -3815,18 +3846,13 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 
 switch ( msr )
 {
+unsigned int eax, ebx, ecx, index;
+
 case MSR_EFER:
 if ( hvm_set_efer(msr_content) )
return X86EMUL_EXCEPTION;
 break;
 
-case MSR_IA32_XSS:
-/* No XSS features currently supported for guests. */
-if ( !cpu_has_xsaves || msr_content != 0 )
-goto gp_fault;
-v->arch.hvm_vcpu.msr_xss = msr_content;
-break;
-
 case MSR_IA32_TSC:
 hvm_set_guest_tsc(v, msr_content);
 break;
@@ -3863,9 +3889,8 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 break;
 
 case MSR_MTRRcap:
-if ( !mtrr )
-goto gp_fault;
 goto gp_fault;
+
 case MSR_MTRRdefType:
 if ( !mtrr )
 goto gp_fault;
@@ -3905,6 +3930,23 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 goto gp_fault;
 break;
 
+case MSR_IA32_XSS:
+ecx = 1;
+

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Stefano Stabellini]

On Wed, 7 Sep 2016, Andrew Cooper wrote:
> On 07/09/2016 22:02, Stefano Stabellini wrote:
> > On Wed, 7 Sep 2016, Meng Xu wrote:
> >> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
> >>  wrote:
> >>> On Wed, 7 Sep 2016, Ian Jackson wrote:
> > Technical
> > =
> > On the technical front, it would be good to understand whether
> > a) This is a real threat and whether thus, we as a community need to
> >take action
>  It is unclear what action the Xen upstream community can usefully
>  take, other than providing users with information.
> 
>  But, users with deployments on actual hardware ought to try to find
>  out whether they are vulnerable.  If they are then they could seek
>  replacement non-faulty hardware from their vendor, or take unpleasant
>  migitation measures (like switching to HVM, perhaps).
> >>> How difficult is to check for it?
> >>>
> >>> Is there a simple test, maybe a little executable, that users could use
> >>> to find out whether their ram is vulnerable? That would be extremely
> >>> valuable.
> >> Google does have a github repo to do the rowhammer test:
> >> https://github.com/google/rowhammer-test
> > Nice! It would be good to document this in a Xen Project document
> > somewhere.
> >
> > The code is small enough that we could even consider pulling it in Xen
> > and running it at boot time (obviously it would be a kconfig option to
> > compile and a xen command line option to run the test). In case of
> > failure we could WARN the sysadmin and refuse to continue.
> 
> -10 for any code in the hypervisor.  That is a knee-jerk reaction.  By
> the same logic, we should also embed memtest and run that during boot.

The difference is that errors typically caught by memtest, such as bad
ram regions, don't end up causing privilege escalations.

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

[Xen-devel] [PATCH Altp2m cleanup v4 0/4] Cleaning up altp2m code

[Paul Lai]

Incorporating comments generated by v3 patch series.

Older comments, reason for the code clean effort, are the following URLs:
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04530.html


Jan Beulich (1):
  x86/HVM: adjust feature checking in MSR intercept handling

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

 xen/arch/x86/hvm/hvm.c| 142 --
 xen/arch/x86/hvm/vmx/vmx.c|  42 +++
 xen/arch/x86/mm/altp2m.c  |  51 ++
 xen/arch/x86/mm/hap/hap.c |  37 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/mm-locks.h|   4 +-
 xen/arch/x86/mm/p2m-ept.c |  39 +++
 xen/arch/x86/mm/p2m.c | 106 ++--
 xen/common/monitor.c  |   1 +
 xen/include/asm-x86/altp2m.h  |  11 ++-
 xen/include/asm-x86/domain.h  |   6 +-
 xen/include/asm-x86/hvm/hvm.h |  29 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h |   3 +
 xen/include/asm-x86/p2m.h |  18 +++--
 14 files changed, 304 insertions(+), 187 deletions(-)

-- 
2.7.4


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

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Paulina Szubarczyk]

On 09/07/2016 10:56 PM, Stefano Stabellini wrote:

On Wed, 7 Sep 2016, Paulina Szubarczyk wrote:

Copy data operated on during request from/to local buffers to/from
the grant references.

Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.

A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.

Signed-off-by: Paulina Szubarczyk 
---
Changes since v5:
-added checking of every interface in the configure file. Based on
  the Roger's comment that xengnttab_map_grant_ref was added prior
  xengnttab_grant_copy, thus do not need to be check again here
  I dropped this check.



Thank you Paulina, the patch is good. Thanks for your work! Sorry for
coming in late in the review; I have a couple of minor suggestions
below.

It had not been possible without all the help I have got. I am very 
grateful for it.



In addition to Anthony's ack, it would be also nice to have Roger's ack
on this patch.



  configure   |  55 
  hw/block/xen_disk.c | 157 ++--
  include/hw/xen/xen_common.h |  14 
  3 files changed, 221 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 4b808f9..3f44d38 100755
--- a/configure
+++ b/configure
@@ -1956,6 +1956,61 @@ EOF
  /*
   * If we have stable libs the we don't want the libxc compat
   * layers, regardless of what CFLAGS we may have been given.
+ *
+ * Also, check if xengnttab_grant_copy_segment_t is defined and
+ * grant copy operation is implemented.
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+  xen_domain_handle_t handle;
+  xengnttab_grant_copy_segment_t* seg = NULL;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
+  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_grant_copy(xg, 0, seg);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+then
+xen_ctrl_version=480
+xen=yes
+  elif
+  cat > $TMPC <= 480


In general I prefer to avoid this kind of #ifdef in xen_disk.c, but I
see that Anthony suggested it for a good reason. The only alternartive I
can think of would be to introduce two static inline functions in
xen_common.h to set a xengnttab_grant_copy_segment_t seg. But this is
also OK.

The functions take as parameters pointers to struct ioreq defined in 
xen_disk.c which members are used to fill the 
xengnttab_grant_copy_segment_t. There would be some overhead to move the 
functions to the header.



+static void free_buffers(struct ioreq *ioreq)


Please name this function ioreq_free_copy_buffers to make it clearer
that has to do with the same buffers initialized below.



+{
+int i;
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = NULL;
+}
+
+qemu_vfree(ioreq->pages);
+}
+
+static int ioreq_init_copy_buffers(struct ioreq *ioreq)
+{
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
+ioreq->v.iov[i].iov_base = ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_copy(struct ioreq *ioreq)


Please name this function in a way that makes it clear that it has
something to do with grant copies. Like for example ioreq_grant_copy.

I will change the names of both functions and remove the blank line 
pointed below.



+{
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_grant_copy_segment_t segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count, rc;
+int64_t file_blk = ioreq->blkdev->file_blk;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = ioreq->v.niov;
+
+for (i = 0; i < count; i++) {
+
+if (ioreq->req.operation == BLKIF_OP_READ) {
+segs[i].flags = 

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Andrew Cooper]

On 07/09/2016 22:02, Stefano Stabellini wrote:
> On Wed, 7 Sep 2016, Meng Xu wrote:
>> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
>>  wrote:
>>> On Wed, 7 Sep 2016, Ian Jackson wrote:
> Technical
> =
> On the technical front, it would be good to understand whether
> a) This is a real threat and whether thus, we as a community need to
>take action
 It is unclear what action the Xen upstream community can usefully
 take, other than providing users with information.

 But, users with deployments on actual hardware ought to try to find
 out whether they are vulnerable.  If they are then they could seek
 replacement non-faulty hardware from their vendor, or take unpleasant
 migitation measures (like switching to HVM, perhaps).
>>> How difficult is to check for it?
>>>
>>> Is there a simple test, maybe a little executable, that users could use
>>> to find out whether their ram is vulnerable? That would be extremely
>>> valuable.
>> Google does have a github repo to do the rowhammer test:
>> https://github.com/google/rowhammer-test
> Nice! It would be good to document this in a Xen Project document
> somewhere.
>
> The code is small enough that we could even consider pulling it in Xen
> and running it at boot time (obviously it would be a kconfig option to
> compile and a xen command line option to run the test). In case of
> failure we could WARN the sysadmin and refuse to continue.

-10 for any code in the hypervisor.  That is a knee-jerk reaction.  By
the same logic, we should also embed memtest and run that during boot.

Documentation, and making a test easy to run is of course fine, but
noone will compile it in or use it in production.  In the best case, it
comes back quickly and identifies that you can't run untrusted guests,
and in the worse case runs forever.

It is very unfortunate that the very design and intention of the x86 PV
ABI makes it easier for most attackers than a typical user/kernel
interaction.  Hindsight is great, but there is no possible way that a
group of PHD students 15 years ago developing a mutually-cooperative
method of virtualisation could have predicted that in this modern day
and age, commercial DRAM is pushed too close to the limit to function
correctly in all cases software can provoke.

That said, there are both software and hardware mitigations which can be
used.  ECC RAM is a good start, and anyone running a production system
without it has already lost.  There is TRR as an optional DRAM mechanism
which I can see becoming de-facto standard (and likely non-optional in
DDR5).  More intellegent placement of guest memory could prevent it
performing rowhammer on anything but itself, and the proposed option to
move PV guests into an HVM stub container resolves the physical
information leakage which makes rowhammer particularly easy for PV guests.

~Andrew

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

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Stefano Stabellini]

On Wed, 7 Sep 2016, Meng Xu wrote:
> On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
>  wrote:
> >
> > On Wed, 7 Sep 2016, Ian Jackson wrote:
> > > > Technical
> > > > =
> > > > On the technical front, it would be good to understand whether
> > > > a) This is a real threat and whether thus, we as a community need to
> > > >take action
> > >
> > > It is unclear what action the Xen upstream community can usefully
> > > take, other than providing users with information.
> > >
> > > But, users with deployments on actual hardware ought to try to find
> > > out whether they are vulnerable.  If they are then they could seek
> > > replacement non-faulty hardware from their vendor, or take unpleasant
> > > migitation measures (like switching to HVM, perhaps).
> >
> > How difficult is to check for it?
> >
> > Is there a simple test, maybe a little executable, that users could use
> > to find out whether their ram is vulnerable? That would be extremely
> > valuable.
> 
> Google does have a github repo to do the rowhammer test:
> https://github.com/google/rowhammer-test

Nice! It would be good to document this in a Xen Project document
somewhere.

The code is small enough that we could even consider pulling it in Xen
and running it at boot time (obviously it would be a kconfig option to
compile and a xen command line option to run the test). In case of
failure we could WARN the sysadmin and refuse to continue.

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

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Stefano Stabellini]

On Wed, 7 Sep 2016, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
> 
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operation,
> first, the qemu device invokes the read operation on local buffers
> and on the completion grant copy is called and buffers are freed.
> For the 'write' operation grant copy is performed before invoking
> write by qemu device.
> 
> A new value 'feature_grant_copy' is added to recognize when the
> grant copy operation is supported by a guest.
> 
> Signed-off-by: Paulina Szubarczyk 
> ---
> Changes since v5:
> -added checking of every interface in the configure file. Based on
>  the Roger's comment that xengnttab_map_grant_ref was added prior
>  xengnttab_grant_copy, thus do not need to be check again here
>  I dropped this check.
>  

Thank you Paulina, the patch is good. Thanks for your work! Sorry for
coming in late in the review; I have a couple of minor suggestions
below.

In addition to Anthony's ack, it would be also nice to have Roger's ack
on this patch.


>  configure   |  55 
>  hw/block/xen_disk.c | 157 
> ++--
>  include/hw/xen/xen_common.h |  14 
>  3 files changed, 221 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index 4b808f9..3f44d38 100755
> --- a/configure
> +++ b/configure
> @@ -1956,6 +1956,61 @@ EOF
>  /*
>   * If we have stable libs the we don't want the libxc compat
>   * layers, regardless of what CFLAGS we may have been given.
> + *
> + * Also, check if xengnttab_grant_copy_segment_t is defined and
> + * grant copy operation is implemented.
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#if !defined(HVM_MAX_VCPUS)
> +# error HVM_MAX_VCPUS not defined
> +#endif
> +int main(void) {
> +  xc_interface *xc = NULL;
> +  xenforeignmemory_handle *xfmem;
> +  xenevtchn_handle *xe;
> +  xengnttab_handle *xg;
> +  xen_domain_handle_t handle;
> +  xengnttab_grant_copy_segment_t* seg = NULL;
> +
> +  xs_daemon_open();
> +
> +  xc = xc_interface_open(0, 0, 0);
> +  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
> +  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
> +  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
> +  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
> +  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
> +
> +  xe = xenevtchn_open(0, 0);
> +  xenevtchn_fd(xe);
> +
> +  xg = xengnttab_open(0, 0);
> +  xengnttab_grant_copy(xg, 0, seg);
> +
> +  return 0;
> +}
> +EOF
> +  compile_prog "" "$xen_libs $xen_stable_libs"
> +then
> +xen_ctrl_version=480
> +xen=yes
> +  elif
> +  cat > $TMPC < +/*
> + * If we have stable libs the we don't want the libxc compat
> + * layers, regardless of what CFLAGS we may have been given.
>   */
>  #undef XC_WANT_COMPAT_EVTCHN_API
>  #undef XC_WANT_COMPAT_GNTTAB_API
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 3b8ad33..3739e13 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -119,6 +119,9 @@ struct XenBlkDev {
>  unsigned intpersistent_gnt_count;
>  unsigned intmax_grants;
>  
> +/* Grant copy */
> +gbooleanfeature_grant_copy;
> +
>  /* qemu block driver */
>  DriveInfo   *dinfo;
>  BlockBackend*blk;
> @@ -489,6 +492,108 @@ static int ioreq_map(struct ioreq *ioreq)
>  return 0;
>  }
>  
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 480

In general I prefer to avoid this kind of #ifdef in xen_disk.c, but I
see that Anthony suggested it for a good reason. The only alternartive I
can think of would be to introduce two static inline functions in
xen_common.h to set a xengnttab_grant_copy_segment_t seg. But this is
also OK.


> +static void free_buffers(struct ioreq *ioreq)

Please name this function ioreq_free_copy_buffers to make it clearer
that has to do with the same buffers initialized below.


> +{
> +int i;
> +
> +for (i = 0; i < ioreq->v.niov; i++) {
> +ioreq->page[i] = NULL;
> +}
> +
> +qemu_vfree(ioreq->pages);
> +}
> +
> +static int ioreq_init_copy_buffers(struct ioreq *ioreq)
> +{
> +int i;
> +
> +if (ioreq->v.niov == 0) {
> +return 0;
> +}
> +
> +ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
> +
> +for (i = 0; i < ioreq->v.niov; i++) {
> +ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
> +ioreq->v.iov[i].iov_base = ioreq->page[i];
> +}
> +
> +return 0;
> +}
> +
> +static int ioreq_copy(struct ioreq *ioreq)

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Meng Xu]

On Wed, Sep 7, 2016 at 3:08 PM, Stefano Stabellini
 wrote:
>
> On Wed, 7 Sep 2016, Ian Jackson wrote:
> > > Technical
> > > =
> > > On the technical front, it would be good to understand whether
> > > a) This is a real threat and whether thus, we as a community need to
> > >take action
> >
> > It is unclear what action the Xen upstream community can usefully
> > take, other than providing users with information.
> >
> > But, users with deployments on actual hardware ought to try to find
> > out whether they are vulnerable.  If they are then they could seek
> > replacement non-faulty hardware from their vendor, or take unpleasant
> > migitation measures (like switching to HVM, perhaps).
>
> How difficult is to check for it?
>
> Is there a simple test, maybe a little executable, that users could use
> to find out whether their ram is vulnerable? That would be extremely
> valuable.

Google does have a github repo to do the rowhammer test:
https://github.com/google/rowhammer-test

Meng



---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v3 01/19] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Boris Ostrovsky]

Adding Lenovo.

On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
> ACPI builder is currently distributed under GPLv2 license.
>
> We plan to make the builder available to components other
> than the hvmloader (which is also GPLv2). Some of these
> components (such as libxl) may be distributed under LGPL-2.1
> so that they can be used by non-GPLv2 callers.  But this
> will not be possible if we incorporate the ACPI builder in
> those other components.
>
> To avoid this problem we are relicensing sources in ACPI
> bulder directory to the Lesser GNU Public License (LGPL)
> version 2.1
>
> Signed-off-by: Boris Ostrovsky 
> Acked-by: Daniel Kiper 
> Acked-by: Stefan Berger 
> Acked-by: Kouya Shimura 
> Acked-by: Jan Beulich 
> Acked-by: Kevin Tian 
> Acked-by: Keir Fraser 
> Acked-by: Simon Horman 
> Acked-by: Lars Kurth 
> Acked-by: Konrad Rzeszutek Wilk 
> ---
> CC: Daniel Kiper 
> CC: Stefan Berger 
> CC: Kouya Shimura 
> CC: Jan Beulich 
> CC: Kevin Tian 
> CC: Keir Fraser 
> CC: Simon Horman 
> CC: Lars Kurth 
> CC: Konrad Rzeszutek Wilk 
> ---
>
> * Stll missing Lenovo ACK for commit 801d469ad8b2b88f669326327df03d03200efbfb
>
>  tools/firmware/hvmloader/acpi/Makefile| 18 --
>  tools/firmware/hvmloader/acpi/acpi2_0.h   | 19 ---
>  tools/firmware/hvmloader/acpi/build.c | 18 --
>  tools/firmware/hvmloader/acpi/dsdt.asl| 18 --
>  tools/firmware/hvmloader/acpi/mk_dsdt.c   | 12 
>  tools/firmware/hvmloader/acpi/ssdt_pm.asl | 11 ---
>  tools/firmware/hvmloader/acpi/ssdt_s3.asl | 11 ---
>  tools/firmware/hvmloader/acpi/ssdt_s4.asl | 11 ---
>  tools/firmware/hvmloader/acpi/ssdt_tpm.asl| 18 --
>  tools/firmware/hvmloader/acpi/static_tables.c | 18 --
>  10 files changed, 72 insertions(+), 82 deletions(-)
>
> diff --git a/tools/firmware/hvmloader/acpi/Makefile 
> b/tools/firmware/hvmloader/acpi/Makefile
> index d3e882a..703d67b 100644
> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/firmware/hvmloader/acpi/Makefile
> @@ -1,17 +1,15 @@
>  #
>  # Copyright (c) 2004, Intel Corporation.
>  #
> -# This program is free software; you can redistribute it and/or modify it
> -# under the terms and conditions of the GNU General Public License,
> -# version 2, as published by the Free Software Foundation.
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU Lesser General Public License as published
> +# by the Free Software Foundation; version 2.1 only. with the special
> +# exception on linking described in file LICENSE.
>  #
> -# This program is distributed in the hope it will be useful, but WITHOUT
> -# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> -# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> -# more details.
> -#
> -# You should have received a copy of the GNU General Public License along 
> with
> -# this program; If not, see .
> +# 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
> +# NU Lesser General Public License for more details.
>  #
>  
>  XEN_ROOT = $(CURDIR)/../../../..
> diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h 
> b/tools/firmware/hvmloader/acpi/acpi2_0.h
> index 87a558a..775eb7a 100644
> --- a/tools/firmware/hvmloader/acpi/acpi2_0.h
> +++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
> @@ -1,18 +1,15 @@
>  /*
>   * Copyright (c) 2004, Intel Corporation.
>   *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms and conditions of the GNU General Public License,
> - * version 2, as published by the Free Software Foundation.
> - *
> - * This program is distributed in the hope it will be useful, but WITHOUT
> - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> - * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> - * more details.
> - *
> - * You should have received a copy of the GNU General Public License along 
> with
> - * this program; If not, see .
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License as published
> + * by the Free Software Foundation; version 2.1 only. with the special
> + * exception on linking described 

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Stefano Stabellini]

On Wed, 7 Sep 2016, Ian Jackson wrote:
> > Technical
> > =
> > On the technical front, it would be good to understand whether
> > a) This is a real threat and whether thus, we as a community need to 
> >take action 
> 
> It is unclear what action the Xen upstream community can usefully
> take, other than providing users with information.
> 
> But, users with deployments on actual hardware ought to try to find
> out whether they are vulnerable.  If they are then they could seek
> replacement non-faulty hardware from their vendor, or take unpleasant
> migitation measures (like switching to HVM, perhaps).

How difficult is to check for it?

Is there a simple test, maybe a little executable, that users could use
to find out whether their ram is vulnerable? That would be extremely
valuable.

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

[Xen-devel] [PATCH v3 14/19] libxc/libxl: Allow multiple ACPI modules

[Boris Ostrovsky]

Provide ability to load multiple ACPI modules. Thie feature is needed
by PVHv2 guests and will be used in subsequent patches.

We assume that PVHv2 guests do not load their ACPI modules specified
in the configuration file. We can extend support for that in the future
if desired.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Constified info parameter to hvm_build_set_xs_values()

 tools/libxc/include/xc_dom.h   |  5 +++--
 tools/libxc/xc_dom_hvmloader.c |  3 ++-
 tools/libxl/libxl_dom.c| 26 ++
 3 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index de7dca9..608cbc2 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -212,8 +212,9 @@ struct xc_dom_image {
 /* BIOS/Firmware passed to HVMLOADER */
 struct xc_hvm_firmware_module system_firmware_module;
 
-/* Extra ACPI tables passed to HVMLOADER */
-struct xc_hvm_firmware_module acpi_module;
+/* Extra ACPI tables */
+#define MAX_ACPI_MODULES4
+struct xc_hvm_firmware_module acpi_modules[MAX_ACPI_MODULES];
 
 /* Extra SMBIOS structures passed to HVMLOADER */
 struct xc_hvm_firmware_module smbios_module;
diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 6eb8516..59f94e5 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -172,7 +172,8 @@ static int modules_init(struct xc_dom_image *dom)
 rc = module_init_one(dom, >system_firmware_module,
  "System Firmware module");
 if ( rc ) goto err;
-rc = module_init_one(dom, >acpi_module, "ACPI module");
+/* Only one module can be added */
+rc = module_init_one(dom, >acpi_modules[0], "ACPI module");
 if ( rc ) goto err;
 rc = module_init_one(dom, >smbios_module, "SMBIOS module");
 if ( rc ) goto err;
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c895649..c4be916 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -818,7 +818,8 @@ static int hvm_build_set_params(xc_interface *handle, 
uint32_t domid,
 
 static int hvm_build_set_xs_values(libxl__gc *gc,
uint32_t domid,
-   struct xc_dom_image *dom)
+   struct xc_dom_image *dom,
+   const libxl_domain_build_info *info)
 {
 char *path = NULL;
 int ret = 0;
@@ -839,18 +840,20 @@ static int hvm_build_set_xs_values(libxl__gc *gc,
 goto err;
 }
 
-if (dom->acpi_module.guest_addr_out) {
+/* Only one module can be passed. PVHv2 guests do not support this. */
+if (dom->acpi_modules[0].guest_addr_out && 
+info->device_model_version !=LIBXL_DEVICE_MODEL_VERSION_NONE) {
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_ADDRESS, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%"PRIx64,
-   dom->acpi_module.guest_addr_out);
+   dom->acpi_modules[0].guest_addr_out);
 if (ret)
 goto err;
 
 path = GCSPRINTF("/local/domain/%d/"HVM_XS_ACPI_PT_LENGTH, domid);
 
 ret = libxl__xs_printf(gc, XBT_NULL, path, "0x%x",
-   dom->acpi_module.length);
+   dom->acpi_modules[0].length);
 if (ret)
 goto err;
 }
@@ -994,6 +997,13 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 
 if (info->u.hvm.acpi_firmware) {
+
+if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_NONE) {
+LOGE(ERROR, "PVH guests do not allow loading ACPI modules");
+rc = ERROR_FAIL;
+goto out;
+}
+
 data = NULL;
 e = libxl_read_file_contents(ctx, info->u.hvm.acpi_firmware,
  , );
@@ -1005,9 +1015,9 @@ static int libxl__domain_firmware(libxl__gc *gc,
 }
 libxl__ptr_add(gc, data);
 if (datalen) {
-/* Only accept non-empty files */
-dom->acpi_module.data = data;
-dom->acpi_module.length = (uint32_t)datalen;
+/* Only accept a non-empty file */
+dom->acpi_modules[0].data = data;
+dom->acpi_modules[0].length = (uint32_t)datalen;
 }
 }
 
@@ -1143,7 +1153,7 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 goto out;
 }
 
-rc = hvm_build_set_xs_values(gc, domid, dom);
+rc = hvm_build_set_xs_values(gc, domid, dom, info);
 if (rc != 0) {
 LOG(ERROR, "hvm build set xenstore values failed");
 goto out;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 04/19] acpi/hvmloader: Make providing IOAPIC in MADT optional

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 70 ++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 40 insertions(+), 33 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 80386b9..7e7c11f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -99,43 +99,49 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 madt->lapic_addr = LAPIC_BASE_ADDRESS;
 madt->flags  = ACPI_PCAT_COMPAT;
 
-intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
-for ( i = 0; i < 16; i++ )
-{
-memset(intsrcovr, 0, sizeof(*intsrcovr));
-intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
-intsrcovr->length = sizeof(*intsrcovr);
-intsrcovr->source = i;
-
-if ( i == 0 )
-{
-/* ISA IRQ0 routed to IOAPIC GSI 2. */
-intsrcovr->gsi= 2;
-intsrcovr->flags  = 0x0;
-}
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
-{
-/* PCI: active-low level-triggered. */
-intsrcovr->gsi= i;
-intsrcovr->flags  = 0xf;
-}
-else
+if ( config->table_flags & ACPI_HAS_IOAPIC )
+{ 
+intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
+for ( i = 0; i < 16; i++ )
 {
-/* No need for a INT source override structure. */
-continue;
+memset(intsrcovr, 0, sizeof(*intsrcovr));
+intsrcovr->type   = ACPI_INTERRUPT_SOURCE_OVERRIDE;
+intsrcovr->length = sizeof(*intsrcovr);
+intsrcovr->source = i;
+
+if ( i == 0 )
+{
+/* ISA IRQ0 routed to IOAPIC GSI 2. */
+intsrcovr->gsi= 2;
+intsrcovr->flags  = 0x0;
+}
+else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+{
+/* PCI: active-low level-triggered. */
+intsrcovr->gsi= i;
+intsrcovr->flags  = 0xf;
+}
+else
+{
+/* No need for a INT source override structure. */
+continue;
+}
+
+intsrcovr++;
 }
 
-intsrcovr++;
-}
+io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
+memset(io_apic, 0, sizeof(*io_apic));
+io_apic->type= ACPI_IO_APIC;
+io_apic->length  = sizeof(*io_apic);
+io_apic->ioapic_id   = IOAPIC_ID;
+io_apic->ioapic_addr = ioapic_base_address;
 
-io_apic = (struct acpi_20_madt_ioapic *)intsrcovr;
-memset(io_apic, 0, sizeof(*io_apic));
-io_apic->type= ACPI_IO_APIC;
-io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+}
+else
+lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index cc57a9c..b089cc5 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -30,6 +30,7 @@
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
+#define ACPI_HAS_IOAPIC  (1<<8)
 
 
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index 8875675..aa5fc20 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= ACPI_HAS_TCPA;
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 05/19] acpi/hvmloader: Build WAET optionally

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
Changes in v3:
* Broke "if ( !waet ) return -1;" line

 tools/firmware/hvmloader/acpi/build.c   | 10 +++---
 tools/firmware/hvmloader/acpi/libacpi.h |  1 +
 tools/firmware/hvmloader/util.c |  2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 7e7c11f..1ea146f 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -359,9 +359,13 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* WAET. */
-waet = construct_waet();
-if (!waet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+if ( config->table_flags & ACPI_HAS_WAET )
+{
+waet = construct_waet();
+if ( !waet )
+return -1;
+table_ptrs[nr_tables++] = (unsigned long)waet;
+}
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
 {
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index b089cc5..7a18d05 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -31,6 +31,7 @@
 #define ACPI_HAS_SSDT_S4 (1<<6)
 #define ACPI_HAS_TCPA(1<<7)
 #define ACPI_HAS_IOAPIC  (1<<8)
+#define ACPI_HAS_WAET(1<<9)
 
 
 struct acpi_numa {
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index aa5fc20..b345576 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,7 +919,7 @@ void hvmloader_acpi_build_tables(struct acpi_config *config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
-config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC);
+config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET);
 
 config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 11/19] x86: Allow LAPIC-only emulation_flags for HVM guests

[Boris Ostrovsky]

PVHv2 guests may request LAPIC emulation (and nothing else)

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/arch/x86/domain.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 7ca1b66..135a7ae 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 }
 else
 {
-if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
+uint32_t emflags;
+
+if ( is_hardware_domain(d) )
+config->emulation_flags |= XEN_X86_EMU_PIT;
+
+emflags = config->emulation_flags;
+if ( emflags & ~XEN_X86_EMU_ALL )
 {
 printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
-   d->domain_id, config->emulation_flags);
+   d->domain_id, emflags);
 return -EINVAL;
 }
-if ( is_hardware_domain(d) )
-config->emulation_flags |= XEN_X86_EMU_PIT;
-if ( config->emulation_flags != 0 &&
- (config->emulation_flags !=
-  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
+
+/* PVHv2 guests can request emulated APIC. */
+if ( emflags &&
+(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
+ (emflags != XEN_X86_EMU_LAPIC)) :
+(emflags != XEN_X86_EMU_PIT)) )
 {
 printk(XENLOG_G_ERR "d%d: Xen does not allow %s domain creation "
"with the current selection of emulators: %#x\n",
-   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV",
-   config->emulation_flags);
+   d->domain_id, is_hvm_domain(d) ? "HVM" : "PV", emflags);
 return -EOPNOTSUPP;
 }
-d->arch.emulation_flags = config->emulation_flags;
+d->arch.emulation_flags = emflags;
 }
 
 if ( has_hvm_container_domain(d) )
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 15/19] libxl/acpi: Add ACPI e820 entry

[Boris Ostrovsky]

Add entry for ACPI tables created for PVHv2 guests to e820 map.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* format adjustments

 tools/libxl/libxl_dom.c |  8 
 tools/libxl/libxl_x86.c | 15 +++
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index c4be916..7974302 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1134,16 +1134,16 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->vnode_to_pnode[i] = info->vnuma_nodes[i].pnode;
 }
 
+rc = libxl__build_dom(gc, domid, info, state, dom);
+if (rc != 0)
+goto out;
+
 rc = libxl__arch_domain_construct_memmap(gc, d_config, domid, dom);
 if (rc != 0) {
 LOG(ERROR, "setting domain memory map failed");
 goto out;
 }
 
-rc = libxl__build_dom(gc, domid, info, state, dom);
-if (rc != 0)
-goto out;
-
 rc = hvm_build_set_params(ctx->xch, domid, info, state->store_port,
>store_mfn, state->console_port,
>console_mfn, state->store_domid,
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 46cfafb..2b221aa 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -492,6 +492,7 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint64_t highmem_size =
 dom->highmem_end ? dom->highmem_end - (1ull << 32) : 0;
 uint32_t lowmem_start = dom->device_model ? GUEST_LOW_MEM_START_DEFAULT : 
0;
+unsigned page_size = XC_DOM_PAGE_SIZE(dom);
 
 /* Add all rdm entries. */
 for (i = 0; i < d_config->num_rdms; i++)
@@ -503,6 +504,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 if (highmem_size)
 e820_entries++;
 
+for (i = 0; i < MAX_ACPI_MODULES; i++)
+if (dom->acpi_modules[i].length)
+e820_entries++;
+
 if (e820_entries >= E820MAX) {
 LOG(ERROR, "Ooops! Too many entries in the memory map!");
 rc = ERROR_INVAL;
@@ -528,6 +533,16 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 nr++;
 }
 
+for (i = 0; i < MAX_ACPI_MODULES; i++) {
+if (dom->acpi_modules[i].length) {
+e820[nr].addr = dom->acpi_modules[i].guest_addr_out & ~(page_size 
- 1);
+e820[nr].size = dom->acpi_modules[i].length +
+(dom->acpi_modules[i].guest_addr_out & (page_size - 1));
+e820[nr].type = E820_ACPI;
+nr++;
+}
+}
+
 /* High memory */
 if (highmem_size) {
 e820[nr].addr = ((uint64_t)1 << 32);
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 16/19] libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Now that we don't have x86.h define LAPIC_BASE_ADDRESS in libxl_arch.h

 tools/libxl/Makefile |  2 ++
 tools/libxl/libxl_arch.h |  6 ++
 tools/libxl/libxl_dom.c  | 19 +++
 3 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 14a1a8e..1f3b40f 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -166,6 +166,8 @@ $(XL_OBJS) $(TEST_PROG_OBJS) _libxl.api-for-check: \
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
+libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+
 SAVE_HELPER_OBJS = libxl_save_helper.o _libxl_save_msgs_helper.o
 $(SAVE_HELPER_OBJS): CFLAGS += $(CFLAGS_libxenctrl) $(CFLAGS_libxenevtchn)
 
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 34a853c..253a037 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -62,4 +62,10 @@ int libxl__arch_domain_construct_memmap(libxl__gc *gc,
 uint32_t domid,
 struct xc_dom_image *dom);
 
+#if defined(__i386__) || defined(__x86_64__)
+
+#define LAPIC_BASE_ADDRESS  0xfee0
+
+#endif
+
 #endif
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 7974302..2924629 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1077,10 +1077,21 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->target_pages = mem_size >> XC_PAGE_SHIFT;
 if (dom->mmio_size == 0 && device_model)
 dom->mmio_size = HVM_BELOW_4G_MMIO_LENGTH;
-else if (dom->mmio_size == 0 && !device_model)
-dom->mmio_size = GB(4) -
-((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
-<< XC_PAGE_SHIFT);
+else if (dom->mmio_size == 0 && !device_model) {
+#if defined(__i386__) || defined(__x86_64__)
+if (libxl_defbool_val(info->u.hvm.apic)) {
+/* Make sure LAPIC_BASE_ADDRESS is below special pages */
+assert(X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+  << XC_PAGE_SHIFT) - LAPIC_BASE_ADDRESS)) >= 
XC_PAGE_SIZE);
+dom->mmio_size = GB(4) - LAPIC_BASE_ADDRESS;
+} else
+dom->mmio_size = GB(4) -
+((X86_HVM_END_SPECIAL_REGION - X86_HVM_NR_SPECIAL_PAGES)
+ << XC_PAGE_SHIFT);
+#else
+assert(1);
+#endif
+}
 lowmem_end = mem_size;
 highmem_end = 0;
 mmio_start = (1ull << 32) - dom->mmio_size;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 03/19] acpi/hvmloader: Set TIS header address in hvmloader

[Boris Ostrovsky]

Users other than hvmloader may provide TIS address as virtual.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c   | 9 -
 tools/firmware/hvmloader/acpi/libacpi.h | 3 +++
 tools/firmware/hvmloader/config.h   | 2 ++
 tools/firmware/hvmloader/util.c | 4 
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 5f5c5f0..80386b9 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -334,7 +334,6 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 struct acpi_20_tcpa *tcpa;
 unsigned char *ssdt;
 static const uint16_t tis_signature[] = {0x0001, 0x0001, 0x0001};
-uint16_t *tis_hdr;
 void *lasa;
 
 /* MADT. */
@@ -387,10 +386,10 @@ static int construct_secondary_tables(unsigned long 
*table_ptrs,
 }
 
 /* TPM TCPA and SSDT. */
-tis_hdr = (uint16_t *)0xFED40F00;
-if ( (tis_hdr[0] == tis_signature[0]) &&
- (tis_hdr[1] == tis_signature[1]) &&
- (tis_hdr[2] == tis_signature[2]) )
+if ( (config->table_flags & ACPI_HAS_TCPA) &&
+ (config->tis_hdr[0] == tis_signature[0]) &&
+ (config->tis_hdr[1] == tis_signature[1]) &&
+ (config->tis_hdr[2] == tis_signature[2]) )
 {
 ssdt = mem_alloc(sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
diff --git a/tools/firmware/hvmloader/acpi/libacpi.h 
b/tools/firmware/hvmloader/acpi/libacpi.h
index 78c3a1c..cc57a9c 100644
--- a/tools/firmware/hvmloader/acpi/libacpi.h
+++ b/tools/firmware/hvmloader/acpi/libacpi.h
@@ -29,6 +29,7 @@
 #define ACPI_HAS_SSDT_PM (1<<4)
 #define ACPI_HAS_SSDT_S3 (1<<5)
 #define ACPI_HAS_SSDT_S4 (1<<6)
+#define ACPI_HAS_TCPA(1<<7)
 
 
 struct acpi_numa {
@@ -62,6 +63,8 @@ struct acpi_config {
 struct acpi_numa numa;
 struct hvm_info_table *hvminfo;
 
+const uint16_t *tis_hdr;
+
 /*
  * Address where acpi_info should be placed.
  * This must match the OperationRegion(BIOS, SystemMemory, )
diff --git a/tools/firmware/hvmloader/config.h 
b/tools/firmware/hvmloader/config.h
index a4429f4..6e00413 100644
--- a/tools/firmware/hvmloader/config.h
+++ b/tools/firmware/hvmloader/config.h
@@ -56,6 +56,8 @@ extern uint8_t ioapic_version;
 /* MMIO hole: Hardcoded defaults, which can be dynamically expanded. */
 #define PCI_MEM_END 0xfc00
 
+#define ACPI_TIS_HDR_ADDRESS 0xFED40F00UL
+
 extern unsigned long pci_mem_start, pci_mem_end;
 extern uint64_t pci_hi_mem_start, pci_hi_mem_end;
 
diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index f37b16e..8875675 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -919,6 +919,10 @@ void hvmloader_acpi_build_tables(struct acpi_config 
*config,
 if ( !strncmp(xenstore_read("platform/acpi_s4", "1"), "1", 1)  )
 config->table_flags |= ACPI_HAS_SSDT_S4;
 
+config->table_flags |= ACPI_HAS_TCPA;
+
+config->tis_hdr = (uint16_t *)ACPI_TIS_HDR_ADDRESS;
+
 config->numa.nr_vmemranges = nr_vmemranges;
 config->numa.nr_vnodes = nr_vnodes;
 config->numa.vcpu_to_vnode = vcpu_to_vnode;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 17/19] ilibxl: Initialize domain build info before calling libxl__domain_make

[Boris Ostrovsky]

libxl__domain_make() may want to use b_info so we should set defaults
a little earlier.

Signed-off-by: Boris Ostrovsky 
---
 tools/libxl/libxl_create.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 04f8ae9..07b2b4b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -899,17 +899,6 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
-ret = libxl__domain_make(gc, d_config, , >config);
-if (ret) {
-LOG(ERROR, "cannot make domain: %d", ret);
-dcs->guest_domid = domid;
-ret = ERROR_FAIL;
-goto error_out;
-}
-
-dcs->guest_domid = domid;
-dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
-
 ret = libxl__domain_build_info_setdefault(gc, _config->b_info);
 if (ret) {
 LOG(ERROR, "Unable to set domain build info defaults");
@@ -923,6 +912,17 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+ret = libxl__domain_make(gc, d_config, , >config);
+if (ret) {
+LOG(ERROR, "cannot make domain: %d", ret);
+dcs->guest_domid = domid;
+ret = ERROR_FAIL;
+goto error_out;
+}
+
+dcs->guest_domid = domid;
+dcs->sdss.dm.guest_domid = 0; /* means we haven't spawned */
+
 /*
  * Set the dm version quite early so that libxl doesn't have to pass the
  * build info around just to know if the domain has a device model or not.
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 18/19] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Some constification of call parameters
* Format adjustments
* New acpi_mem_free hook (a nop)
* Changes in init_acpi_config() to deal with constified acpi_numa's
  pointers (initialize pointers as temp variabales)
* Add '-include acpi' directive in Makefile to make sure acpi
  target is built before build.o dependencies are processed
  (specifically, ssdt_*.h files need to exist)


 .gitignore   |  12 ++-
 tools/libacpi/build.c|   7 +-
 tools/libacpi/libacpi.h  |  15 ++-
 tools/libxl/Makefile |  18 +++-
 tools/libxl/libxl_arch.h |   3 +
 tools/libxl/libxl_x86.c  |  30 --
 tools/libxl/libxl_x86_acpi.c | 218 +++
 tools/libxl/libxl_x86_acpi.h |  35 +++
 8 files changed, 318 insertions(+), 20 deletions(-)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

diff --git a/.gitignore b/.gitignore
index 9b2c405..9f5bd8c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -173,15 +173,19 @@ tools/include/xen/*
 tools/include/xen-xsm/*
 tools/include/xen-foreign/*.(c|h|size)
 tools/include/xen-foreign/checker
-tools/libxl/libxlu_cfg_y.output
+tools/libxl/_libxl.api-for-check
+tools/libxl/*.api-ok
 tools/libxl/*.pc
 tools/libxl/*.pc.in
-tools/libxl/xl
+tools/libxl/dsdt*.c
+tools/libxl/dsdt_*.asl
+tools/libxl/libxlu_cfg_y.output
+tools/libxl/mk_dsdt
+tools/libxl/ssdt_*.h
 tools/libxl/testenum
 tools/libxl/testenum.c
 tools/libxl/tmp.*
-tools/libxl/_libxl.api-for-check
-tools/libxl/*.api-ok
+tools/libxl/xl
 tools/misc/cpuperf/cpuperf-perfcntr
 tools/misc/cpuperf/cpuperf-xen
 tools/misc/xc_shadow
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index 1cd640d..ee5f779 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -20,6 +20,7 @@
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
+#include 
 #include 
 #include 
 
@@ -495,7 +496,7 @@ static int new_vm_gid(struct acpi_ctxt *ctxt,
 return 1;
 }
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config)
 {
 struct acpi_info *acpi_info;
 struct acpi_20_rsdp *rsdp;
@@ -630,11 +631,11 @@ void acpi_build_tables(struct acpi_ctxt *ctxt, struct 
acpi_config *config)
 if ( !new_vm_gid(ctxt, config, acpi_info) )
 goto oom;
 
-return;
+return 0;
 
 oom:
 printf("unable to build ACPI tables: out of memory\n");
-
+return -1;
 }
 
 /*
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index d803139..b0ff5aa 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -48,6 +48,15 @@ struct acpi_ctxt {
 void (*free)(struct acpi_ctxt *ctxt, void *v, uint32_t size);
 unsigned long (*v2p)(struct acpi_ctxt *ctxt, void *v);
 } mem_ops;
+
+unsigned int page_size;
+unsigned int page_shift;
+
+/* Memory allocator */
+unsigned long alloc_base_paddr;
+unsigned long alloc_base_vaddr;
+unsigned long alloc_currp;
+unsigned long alloc_end;
 };
 
 struct acpi_config {
@@ -80,10 +89,10 @@ struct acpi_config {
  * This must match the OperationRegion(BIOS, SystemMemory, )
  * definition in the DSDT
  */
-unsigned int infop;
+unsigned long infop;
 
 /* RSDP address */
-unsigned int rsdp;
+unsigned long rsdp;
 
 /* x86-specific parameters */
 uint16_t (*lapic_id)(unsigned cpu);
@@ -93,7 +102,7 @@ struct acpi_config {
 uint8_t ioapic_id;
 };
 
-void acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
+int acpi_build_tables(struct acpi_ctxt *ctxt, struct acpi_config *config);
 
 #endif /* __LIBACPI_H__ */
 
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1f3b40f..ee32bc7 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -75,7 +75,21 @@ else
 LIBXL_OBJS-y += libxl_no_colo.o
 endif
 
-LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o
+ACPI_PATH  = $(XEN_ROOT)/tools/libacpi
+ACPI_FILES = dsdt_pvh.c
+ACPI_OBJS  = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_FILES): acpi
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/libxl_x86_acpi.h\"
+vpath build.c $(ACPI_PATH)/
+vpath static_tables.c $(ACPI_PATH)/
+LIBXL_OBJS-$(CONFIG_X86) += $(ACPI_OBJS)
+
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
+-include acpi
+
+LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
libxl_x86_acpi.o
 LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
 
 ifeq ($(CONFIG_NetBSD),y)
@@ -167,6 +181,7 @@ $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
 $(XL_OBJS): CFLAGS += -include $(XEN_ROOT)/tools/config.h # libxl_json.h needs 
it.
 
 libxl_dom.o: CFLAGS += -I$(XEN_ROOT)/tools  # include libacpi/x86.h
+libxl_x86_acpi.o: CFLAGS += -I$(XEN_ROOT)/tools
 
 SAVE_HELPER_OBJS = libxl_save_helper.o 

[Xen-devel] [PATCH v3 13/19] acpi: Makefile should better tolerate interrupts

[Boris Ostrovsky]

Intermediate stages of building a target should be made with
temporary files that are copied to final target in the end.

Signed-off-by: Boris Ostrovsky 
---
New in v3

 tools/libacpi/Makefile | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 12b081e..2d8a954 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -21,38 +21,45 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
+ifeq ($(subst all,,$(MAKECMDGOALS)),)
+TDIR := $(shell mktemp -d --tmpdir=$(TMPDIR) tmp_XX)
+endif
+
 vpath iasl $(PATH)
 all: $(C_SRC) $(H_SRC)
+   rm -fr $(TDIR)
 
 $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
-   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $<
-   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
-   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
+   iasl -vs -p $(TDIR)/$* -tc $<
+   sed -e 's/AmlCode/$*/g' $(TDIR)/$*.hex > $@
 
 $(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $(TDIR)/$(@F)
+   cat dsdt_acpi_info.asl >> $(TDIR)/$(@F)
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $(TDIR)/$(@F)
+   cp $(TDIR)/$(@F) $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
-   awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
+   awk 'NR > 1 {print s} {s=$$0}' $< > $(TDIR)/$(@F)
+   cat dsdt_acpi_info.asl >> $(TDIR)/$(@F)
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $(TDIR)/$(@F)
+   cp $(TDIR)/$(@F) $@
 
 $(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
-   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
-   cat dsdt_acpi_info.asl >> $@
-   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $(TDIR)/$(@F)
+   cat dsdt_acpi_info.asl >> $(TDIR)/$(@F)
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> 
$(TDIR)/$(@F)
+   cp $(TDIR)/$(@F) $@
 
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
-   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/$*.asl
-   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
-   echo "int $*_len=sizeof($*);" >>$@
-   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
+   iasl -vs -p $(TDIR)/$* -tc $(TDIR)/$*.asl
+   sed -e 's/AmlCode/$*/g' $(TDIR)/$*.hex > $(TDIR)/$(@F)
+   echo "int $*_len=sizeof($*);" >> $(TDIR)/$(@F)
+   cp $(TDIR)/$(@F) $@
 
 iasl:
@echo
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 10/19] acpi: Move ACPI code to tools/libacpi

[Boris Ostrovsky]

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 MAINTAINERS|  1 +
 tools/firmware/hvmloader/Makefile  | 14 --
 tools/firmware/hvmloader/ovmf.c|  2 +-
 tools/firmware/rombios/32bit/Makefile  |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/Makefile|  2 +-
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  0
 tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/build.c |  0
 tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c   |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl |  0
 tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl|  0
 tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c |  0
 17 files changed, 13 insertions(+), 10 deletions(-)
 rename tools/{firmware/hvmloader/acpi => libacpi}/Makefile (98%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_tpm.asl (100%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97720a8..07545f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,7 @@ S:  Supported
 F: xen/arch/x86/acpi/
 F: xen/drivers/acpi/
 F: xen/include/acpi/
+F: tools/libacpi/
 
 AMD IOMMU
 M: Suravee Suthikulpanit 
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 77e95f1..9fa9bcc 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,9 +20,6 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-export ACPI_BUILD_DIR=$(CURDIR)
-SUBDIRS := acpi
-
 # The HVM loader is started in 32-bit mode at the address below:
 LOADADDR = 0x10
 
@@ -67,16 +64,20 @@ ROMS += $(ROMBIOS_ROM) $(STDVGA_ROM) $(CIRRUSVGA_ROM) 
$(ETHERBOOT_ROMS)
 endif
 
 .PHONY: all
-all: subdirs-all
+all: acpi subdirs-all
$(MAKE) hvmloader
 
+.PHONY: acpi
+acpi:
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR)
+
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-ACPI_PATH = acpi
+ACPI_PATH = ../../libacpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"$(CURDIR)/util.h\"
 CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
@@ -118,6 +119,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) clean
 
 .PHONY: distclean
 distclean: clean
diff --git a/tools/firmware/hvmloader/ovmf.c b/tools/firmware/hvmloader/ovmf.c
index 0ac3416..4ff7f1d 100644
--- a/tools/firmware/hvmloader/ovmf.c
+++ b/tools/firmware/hvmloader/ovmf.c
@@ -23,7 +23,7 @@
 
 #include "config.h"
 #include "smbios_types.h"
-#include "acpi/libacpi.h"
+#include "libacpi.h"
 #include "apic_regs.h"
 #include "../rombios/config.h"
 #include "util.h"
diff --git a/tools/firmware/rombios/32bit/Makefile 
b/tools/firmware/rombios/32bit/Makefile
index 71399d2..b0583c9 100644
--- a/tools/firmware/rombios/32bit/Makefile
+++ b/tools/firmware/rombios/32bit/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET = 32bitbios_flat.h
 
-CFLAGS += $(CFLAGS_xeninclude) -I.. -I../../hvmloader/acpi
+CFLAGS += $(CFLAGS_xeninclude) -I.. -I../../../libacpi
 
 SUBDIRS = tcgbios
 
diff --git a/tools/firmware/rombios/32bit/tcgbios/Makefile 
b/tools/firmware/rombios/32bit/tcgbios/Makefile
index 6822027..f87d130 100644
--- a/tools/firmware/rombios/32bit/tcgbios/Makefile
+++ b/tools/firmware/rombios/32bit/tcgbios/Makefile
@@ -3,7 +3,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 
 TARGET  = 

[Xen-devel] [PATCH v3 19/19] libxc/xc_dom_core: Copy ACPI tables to guest space

[Boris Ostrovsky]

Load ACPI modules into guest space

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Use more macros in first_high_idx intilalization.
* Format adjustments

 tools/libxc/xc_dom_core.c | 93 +++
 1 file changed, 93 insertions(+)

diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index ebada89..3817eb8 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -1040,6 +1040,95 @@ static int xc_dom_build_ramdisk(struct xc_dom_image *dom)
 return -1;
 }
 
+static int populate_acpi_pages(struct xc_dom_image *dom,
+   xen_pfn_t *extents,
+   unsigned int num_pages)
+{
+int rc;
+xc_interface *xch = dom->xch;
+uint32_t domid = dom->guest_domid;
+unsigned long idx;
+unsigned int first_high_idx = (4 << 30) >> PAGE_SHIFT; /* 4GB */
+
+for ( ; num_pages; num_pages--, extents++ )
+{
+
+if ( xc_domain_populate_physmap(xch, domid, 1, 0, 0, extents) == 1 )
+continue;
+
+if (dom->highmem_end)
+{
+idx = --dom->highmem_end;
+if ( idx == first_high_idx )
+dom->highmem_end = 0;
+}
+else
+idx = --dom->lowmem_end;
+
+rc = xc_domain_add_to_physmap(xch, domid,
+  XENMAPSPACE_gmfn,
+  idx, *extents);
+if (rc)
+return rc;
+}
+
+return 0;
+}
+
+static int xc_dom_load_acpi(struct xc_dom_image *dom)
+{
+int j, i = 0;
+unsigned num_pages;
+xen_pfn_t *extents, base;
+void *ptr;
+
+while ( (i < MAX_ACPI_MODULES) && dom->acpi_modules[i].length )
+{
+DOMPRINTF("%s: %d bytes at address %" PRIx64 "\n", __FUNCTION__,
+  dom->acpi_modules[i].length,
+  dom->acpi_modules[i].guest_addr_out);
+
+num_pages = (dom->acpi_modules[i].length + (XC_PAGE_SIZE - 1)) >>
+   XC_PAGE_SHIFT;
+extents = malloc(num_pages * sizeof(*extents));
+if ( !extents )
+{
+DOMPRINTF("%s: Out of memory", __FUNCTION__);
+goto err;
+}
+
+base = dom->acpi_modules[i].guest_addr_out >> XC_PAGE_SHIFT;
+for (j=0; jxch, dom->guest_domid,
+  XC_PAGE_SIZE * num_pages,
+  PROT_READ | PROT_WRITE, base);
+if ( !ptr )
+{
+DOMPRINTF("%s: Can't map %d pages at 0x%lx",
+  __FUNCTION__, num_pages, base);
+goto err;
+}
+
+memcpy(ptr, dom->acpi_modules[i].data, dom->acpi_modules[i].length);
+
+free(extents);
+i++;
+}
+
+return 0;
+
+err:
+free(extents);
+return -1;
+}
+
 int xc_dom_build_image(struct xc_dom_image *dom)
 {
 unsigned int page_size;
@@ -1097,6 +1186,10 @@ int xc_dom_build_image(struct xc_dom_image *dom)
 memcpy(devicetreemap, dom->devicetree_blob, dom->devicetree_size);
 }
 
+/* load ACPI tables */
+if ( xc_dom_load_acpi(dom) != 0 )
+goto err;
+
 /* allocate other pages */
 if ( !dom->arch_hooks->p2m_base_supported ||
  dom->parms.p2m_base >= dom->parms.virt_base ||
-- 
1.8.3.1


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

[Xen-devel] [PATCH v3 02/19] acpi/hvmloader: Collect processor and NUMA info in hvmloader

[Boris Ostrovsky]

No need for ACPI code to rely on hvm_info variable.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Constified acpi_numa's pointers
* Constified acpi_config call parameter where possible

 tools/firmware/hvmloader/acpi/build.c   | 51 +
 tools/firmware/hvmloader/acpi/libacpi.h | 13 +
 tools/firmware/hvmloader/util.c |  9 ++
 3 files changed, 49 insertions(+), 24 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index de56f1f..5f5c5f0 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -70,18 +70,20 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(struct acpi_info *info)
+static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+   struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
 struct acpi_20_madt_ioapic*io_apic;
 struct acpi_20_madt_lapic *lapic;
+struct hvm_info_table *hvminfo = config->hvminfo;
 int i, sz;
 
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvm_info->nr_vcpus;
+sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
 madt = mem_alloc(sz, 16);
 if (!madt) return NULL;
@@ -134,9 +136,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 io_apic->ioapic_addr = ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
-info->nr_cpus = hvm_info->nr_vcpus;
+info->nr_cpus = hvminfo->nr_vcpus;
 info->madt_lapic0_addr = (uint32_t)lapic;
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
 lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
@@ -144,7 +146,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_info 
*info)
 /* Processor ID must match processor-object IDs in the DSDT. */
 lapic->acpi_processor_id = i;
 lapic->apic_id = LAPIC_ID(i);
-lapic->flags = (test_bit(i, hvm_info->vcpu_online)
+lapic->flags = (test_bit(i, hvminfo->vcpu_online)
 ? ACPI_LOCAL_APIC_ENABLED : 0);
 lapic++;
 }
@@ -195,7 +197,7 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(void)
+static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -204,8 +206,8 @@ static struct acpi_20_srat *construct_srat(void)
 void *p;
 unsigned int i;
 
-size = sizeof(*srat) + sizeof(*processor) * hvm_info->nr_vcpus +
-   sizeof(*memory) * nr_vmemranges;
+size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
+   sizeof(*memory) * config->numa.nr_vmemranges;
 
 p = mem_alloc(size, 16);
 if ( !p )
@@ -222,25 +224,26 @@ static struct acpi_20_srat *construct_srat(void)
 srat->table_revision  = ACPI_SRAT_TABLE_REVISION;
 
 processor = (struct acpi_20_srat_processor *)(srat + 1);
-for ( i = 0; i < hvm_info->nr_vcpus; i++ )
+for ( i = 0; i < config->hvminfo->nr_vcpus; i++ )
 {
 processor->type = ACPI_PROCESSOR_AFFINITY;
 processor->length   = sizeof(*processor);
-processor->domain   = vcpu_to_vnode[i];
+processor->domain   = config->numa.vcpu_to_vnode[i];
 processor->apic_id  = LAPIC_ID(i);
 processor->flags= ACPI_LOCAL_APIC_AFFIN_ENABLED;
 processor++;
 }
 
 memory = (struct acpi_20_srat_memory *)processor;
-for ( i = 0; i < nr_vmemranges; i++ )
+for ( i = 0; i < config->numa.nr_vmemranges; i++ )
 {
 memory->type  = ACPI_MEMORY_AFFINITY;
 memory->length= sizeof(*memory);
-memory->domain= vmemrange[i].nid;
+memory->domain= config->numa.vmemrange[i].nid;
 memory->flags = ACPI_MEM_AFFIN_ENABLED;
-memory->base_address  = vmemrange[i].start;
-memory->mem_length= vmemrange[i].end - vmemrange[i].start;
+memory->base_address  = config->numa.vmemrange[i].start;
+memory->mem_length= config->numa.vmemrange[i].end -
+config->numa.vmemrange[i].start;
 memory++;
 }
 
@@ -252,12 +255,12 @@ static struct acpi_20_srat *construct_srat(void)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(void)
+static struct acpi_20_slit *construct_slit(const struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
 
-num = nr_vnodes * 

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

[Boris Ostrovsky]

PVH guests require DSDT with only ACPI INFO (Xen-specific) and Processor
objects. We separate ASL's ACPI INFO definition into dsdt_acpi_info.asl so
that it can be included in ASLs for both HVM and PVH2.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Added comment to dsdt_acpi_info.asl indicating that the structure
  there must match struct acpi_info
* Use QEMU_NONE in mk_dsdt.c
* Makefile tweaks

 tools/libacpi/Makefile   | 13 ++---
 tools/libacpi/dsdt.asl   | 20 
 tools/libacpi/dsdt_acpi_info.asl | 26 ++
 tools/libacpi/mk_dsdt.c  |  8 
 4 files changed, 44 insertions(+), 23 deletions(-)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl

diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 6325cd0..12b081e 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -18,7 +18,7 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
 # Sources to be generated
-C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c)
+C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
@@ -32,15 +32,22 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
 $(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
+   cat dsdt_acpi_info.asl >> $@
$(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
+$(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
+   printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 5, \"Xen\", \"HVM\", 
0)\n{" > $@
+   cat dsdt_acpi_info.asl >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu any --dm-version none >> $@
+
 $(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/$*.asl
sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
diff --git a/tools/libacpi/dsdt.asl b/tools/libacpi/dsdt.asl
index 895a8e5..715bd7a 100644
--- a/tools/libacpi/dsdt.asl
+++ b/tools/libacpi/dsdt.asl
@@ -41,26 +41,6 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2, "Xen", "HVM", 0)
 
 Scope (\_SB)
 {
-   /* ACPI_INFO_PHYSICAL_ADDRESS == 0xFC00 */
-   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
-   Field(BIOS, ByteAcc, NoLock, Preserve) {
-   UAR1, 1,
-   UAR2, 1,
-   LTP1, 1,
-   HPET, 1,
-   Offset(2),
-   NCPU, 16,
-   PMIN, 32,
-   PLEN, 32,
-   MSUA, 32, /* MADT checksum address */
-   MAPA, 32, /* MADT LAPIC0 address */
-   VGIA, 32, /* VM generation id address */
-   LMIN, 32,
-   HMIN, 32,
-   LLEN, 32,
-   HLEN, 32
-   }
-
 /* Fix HCT test for 0x400 pci memory:
  * - need to report low 640 MB mem as motherboard resource
  */
diff --git a/tools/libacpi/dsdt_acpi_info.asl b/tools/libacpi/dsdt_acpi_info.asl
new file mode 100644
index 000..29e962a
--- /dev/null
+++ b/tools/libacpi/dsdt_acpi_info.asl
@@ -0,0 +1,26 @@
+
+Scope (\_SB)
+{
+   /*
+* BIOS region must match struct acpi_info in build.c and
+   * be located at ACPI_INFO_PHYSICAL_ADDRESS = 0xFC00
+   */
+   OperationRegion(BIOS, SystemMemory, 0xFC00, 40)
+   Field(BIOS, ByteAcc, NoLock, Preserve) {
+   UAR1, 1,
+   UAR2, 1,
+   LTP1, 1,
+   HPET, 1,
+   Offset(2),
+   NCPU, 16,
+   PMIN, 32,
+   PLEN, 32,
+   MSUA, 32, /* MADT checksum address */
+   MAPA, 32, /* MADT LAPIC0 address */
+   VGIA, 32, /* VM generation id address */
+   LMIN, 32,
+   HMIN, 32,
+   LLEN, 32,
+   HLEN, 32
+   }
+}
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index bc414bf..30477fd 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -23,6 +23,7 @@ static unsigned int indent_level;
 static bool debug = false;
 
 typedef enum dm_version {
+QEMU_NONE,
 QEMU_XEN_TRADITIONAL,
 QEMU_XEN,
 } dm_version;
@@ -135,6 +136,8 @@ int main(int argc, char **argv)
 dm_version = QEMU_XEN;
 } else if (strcmp(optarg, "qemu-xen-traditional") == 0) {
 

[Xen-devel] [PATCH v3 01/19] acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1

[Boris Ostrovsky]

ACPI builder is currently distributed under GPLv2 license.

We plan to make the builder available to components other
than the hvmloader (which is also GPLv2). Some of these
components (such as libxl) may be distributed under LGPL-2.1
so that they can be used by non-GPLv2 callers.  But this
will not be possible if we incorporate the ACPI builder in
those other components.

To avoid this problem we are relicensing sources in ACPI
bulder directory to the Lesser GNU Public License (LGPL)
version 2.1

Signed-off-by: Boris Ostrovsky 
Acked-by: Daniel Kiper 
Acked-by: Stefan Berger 
Acked-by: Kouya Shimura 
Acked-by: Jan Beulich 
Acked-by: Kevin Tian 
Acked-by: Keir Fraser 
Acked-by: Simon Horman 
Acked-by: Lars Kurth 
Acked-by: Konrad Rzeszutek Wilk 
---
CC: Daniel Kiper 
CC: Stefan Berger 
CC: Kouya Shimura 
CC: Jan Beulich 
CC: Kevin Tian 
CC: Keir Fraser 
CC: Simon Horman 
CC: Lars Kurth 
CC: Konrad Rzeszutek Wilk 
---

* Stll missing Lenovo ACK for commit 801d469ad8b2b88f669326327df03d03200efbfb

 tools/firmware/hvmloader/acpi/Makefile| 18 --
 tools/firmware/hvmloader/acpi/acpi2_0.h   | 19 ---
 tools/firmware/hvmloader/acpi/build.c | 18 --
 tools/firmware/hvmloader/acpi/dsdt.asl| 18 --
 tools/firmware/hvmloader/acpi/mk_dsdt.c   | 12 
 tools/firmware/hvmloader/acpi/ssdt_pm.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_s3.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_s4.asl | 11 ---
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl| 18 --
 tools/firmware/hvmloader/acpi/static_tables.c | 18 --
 10 files changed, 72 insertions(+), 82 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index d3e882a..703d67b 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -1,17 +1,15 @@
 #
 # Copyright (c) 2004, Intel Corporation.
 #
-# This program is free software; you can redistribute it and/or modify it
-# under the terms and conditions of the GNU General Public License,
-# version 2, as published by the Free Software Foundation.
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License as published
+# by the Free Software Foundation; version 2.1 only. with the special
+# exception on linking described in file LICENSE.
 #
-# This program is distributed in the hope it will be useful, but WITHOUT
-# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
-# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
-# more details.
-#
-# You should have received a copy of the GNU General Public License along with
-# this program; If not, see .
+# 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
+# NU Lesser General Public License for more details.
 #
 
 XEN_ROOT = $(CURDIR)/../../../..
diff --git a/tools/firmware/hvmloader/acpi/acpi2_0.h 
b/tools/firmware/hvmloader/acpi/acpi2_0.h
index 87a558a..775eb7a 100644
--- a/tools/firmware/hvmloader/acpi/acpi2_0.h
+++ b/tools/firmware/hvmloader/acpi/acpi2_0.h
@@ -1,18 +1,15 @@
 /*
  * Copyright (c) 2004, Intel Corporation.
  *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program; If not, see .
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
  *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more 

[Xen-devel] [PATCH v3 07/19] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables

[Boris Ostrovsky]

Non-hvmloader users may be building tables in virtual address space
and therefore we need to make sure that values that end up in tables
are physical addresses.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 tools/firmware/hvmloader/acpi/build.c | 47 ++-
 1 file changed, 24 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 9c4a0a0..2098920 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -144,7 +144,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 lapic = (struct acpi_20_madt_lapic *)(madt + 1);
 
 info->nr_cpus = hvminfo->nr_vcpus;
-info->madt_lapic0_addr = (uint32_t)lapic;
+info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
 memset(lapic, 0, sizeof(*lapic));
@@ -161,7 +161,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.length = (unsigned char *)lapic - (unsigned char *)madt;
 set_checksum(madt, offsetof(struct acpi_header, checksum),
  madt->header.length);
-info->madt_csum_addr = (uint32_t)>header.checksum;
+info->madt_csum_addr =
+ctxt->mem_ops.v2p(ctxt, >header.checksum);
 
 return madt;
 }
@@ -327,7 +328,7 @@ static int construct_passthrough_tables(struct acpi_ctxt 
*ctxt,
 break;
 memcpy(buffer, header, header->length);
 
-table_ptrs[nr_tables++] = (unsigned long)buffer;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, buffer);
 total += header->length;
 pt_addr += header->length;
 }
@@ -354,7 +355,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 madt = construct_madt(ctxt, config, info);
 if (!madt) return -1;
-table_ptrs[nr_tables++] = (unsigned long)madt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, madt);
 }
 
 /* HPET. */
@@ -362,7 +363,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 {
 hpet = construct_hpet(ctxt, config);
 if (!hpet) return -1;
-table_ptrs[nr_tables++] = (unsigned long)hpet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, hpet);
 }
 
 /* WAET. */
@@ -371,7 +372,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 waet = construct_waet(ctxt, config);
 if ( !waet )
 return -1;
-table_ptrs[nr_tables++] = (unsigned long)waet;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, waet);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_PM )
@@ -379,7 +380,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_pm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_pm, sizeof(ssdt_pm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 }
 
 if ( config->table_flags & ACPI_HAS_SSDT_S3 )
@@ -387,7 +388,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s3), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s3, sizeof(ssdt_s3));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S3 disabled\n");
 }
@@ -397,7 +398,7 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_s4), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_s4, sizeof(ssdt_s4));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 } else {
 printf("S4 disabled\n");
 }
@@ -411,12 +412,12 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 ssdt = ctxt->mem_ops.alloc(ctxt, sizeof(ssdt_tpm), 16);
 if (!ssdt) return -1;
 memcpy(ssdt, ssdt_tpm, sizeof(ssdt_tpm));
-table_ptrs[nr_tables++] = (unsigned long)ssdt;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, ssdt);
 
 tcpa = ctxt->mem_ops.alloc(ctxt, sizeof(struct acpi_20_tcpa), 16);
 if (!tcpa) return -1;
 memset(tcpa, 0, sizeof(*tcpa));
-table_ptrs[nr_tables++] = (unsigned long)tcpa;
+table_ptrs[nr_tables++] = ctxt->mem_ops.v2p(ctxt, tcpa);
 
 tcpa->header.signature = ACPI_2_0_TCPA_SIGNATURE;
 tcpa->header.length= sizeof(*tcpa);
@@ -444,11 +445,11 @@ static int construct_secondary_tables(struct acpi_ctxt 
*ctxt,
 struct acpi_20_slit *slit = construct_slit(ctxt, config);
 
 if ( srat )
-table_ptrs[nr_tables++] = (unsigned long)srat;
+

[Xen-devel] [PATCH v3 08/19] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

ACPI sources will be available to various component which will build
them according to their own rules. ACPI's Makefile will only generate
necessary source files.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Replace '(shell pwd) with CURDIR
* More use of addprefix

 .gitignore |  8 +++
 tools/firmware/hvmloader/Makefile  | 11 -
 tools/firmware/hvmloader/acpi/Makefile | 43 +++---
 3 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/.gitignore b/.gitignore
index 43c6f93..9b2c405 100644
--- a/.gitignore
+++ b/.gitignore
@@ -127,13 +127,13 @@ tools/firmware/*bios/*bios*.txt
 tools/firmware/etherboot/gpxe/*
 tools/firmware/extboot/extboot.img
 tools/firmware/extboot/signrom
-tools/firmware/hvmloader/acpi/mk_dsdt
-tools/firmware/hvmloader/acpi/dsdt*.c
-tools/firmware/hvmloader/acpi/dsdt_*.asl
-tools/firmware/hvmloader/acpi/ssdt_*.h
+tools/firmware/hvmloader/dsdt*.c
+tools/firmware/hvmloader/dsdt_*.asl
 tools/firmware/hvmloader/hvmloader
+tools/firmware/hvmloader/mk_dsdt
 tools/firmware/hvmloader/roms.h
 tools/firmware/hvmloader/roms.inc
+tools/firmware/hvmloader/ssdt_*.h
 tools/firmware/rombios/BIOS-bochs-[^/]*
 tools/firmware/rombios/_rombios[^/]*_.c
 tools/firmware/rombios/rombios[^/]*.s
diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index 9f7357f..b6c5b83 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,7 @@
 XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
+export ACPI_BUILD_DIR=$(CURDIR)
 SUBDIRS := acpi
 
 # The HVM loader is started in 32-bit mode at the address below:
@@ -72,7 +73,15 @@ all: subdirs-all
 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 
-hvmloader: $(OBJS) acpi/acpi.a
+ACPI_PATH = acpi
+ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
+ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
+$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+vpath build.c $(ACPI_PATH)
+vpath static_tables.c $(ACPI_PATH)
+OBJS += $(ACPI_OBJS)
+
+hvmloader: $(OBJS)
$(LD) $(LDFLAGS_DIRECT) -N -Ttext $(LOADADDR) -o hvmloader.tmp $^
$(OBJCOPY) hvmloader.tmp hvmloader
rm -f hvmloader.tmp
diff --git a/tools/firmware/hvmloader/acpi/Makefile 
b/tools/firmware/hvmloader/acpi/Makefile
index 703d67b..f635f18 100644
--- a/tools/firmware/hvmloader/acpi/Makefile
+++ b/tools/firmware/hvmloader/acpi/Makefile
@@ -15,36 +15,37 @@
 XEN_ROOT = $(CURDIR)/../../../..
 include $(XEN_ROOT)/tools/firmware/Rules.mk
 
-C_SRC = build.c dsdt_anycpu.c dsdt_15cpu.c static_tables.c 
dsdt_anycpu_qemu_xen.c
-OBJS  = $(patsubst %.c,%.o,$(C_SRC))
+MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
 
-CFLAGS += $(CFLAGS_xeninclude)
+# Sources to be generated
+C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
dsdt_anycpu_qemu_xen.c)
+H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
ssdt_tpm.h)
 
 vpath iasl $(PATH)
-all: acpi.a
+all: $(C_SRC) $(H_SRC)
 
-ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h: %.h: %.asl iasl
-   iasl -vs -p $* -tc $<
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
-   rm -f $*.hex $*.aml
+$(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $<
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
+   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
 
-mk_dsdt: mk_dsdt.c
+$(MK_DSDT): mk_dsdt.c
$(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
 
-dsdt_anycpu_qemu_xen.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --dm-version qemu-xen >> $@
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $@
 
 # NB. awk invocation is a portable alternative to 'head -n -1'
-dsdt_%cpu.asl: dsdt.asl mk_dsdt
+$(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $@
-   ./mk_dsdt --debug=$(debug) --maxcpu $*  >> $@
+   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $@
 
-$(filter dsdt_%.c,$(C_SRC)): %.c: iasl %.asl
-   iasl -vs -p $* -tc $*.asl
-   sed -e 's/AmlCode/$*/g' $*.hex >$@
+$(C_SRC): $(ACPI_BUILD_DIR)/%.c: iasl $(ACPI_BUILD_DIR)/%.asl
+   iasl -vs -p $(ACPI_BUILD_DIR)/$* -tc $(ACPI_BUILD_DIR)/$*.asl
+   sed -e 's/AmlCode/$*/g' $(ACPI_BUILD_DIR)/$*.hex >$@
echo "int $*_len=sizeof($*);" >>$@
-   rm -f $*.aml $*.hex
+   rm -f $(addprefix $(ACPI_BUILD_DIR)/, $*.aml $*.hex)
 
 iasl:
@echo
@@ -54,14 +55,8 @@ iasl:
@echo 
@exit 1
 
-build.o: ssdt_s3.h ssdt_s4.h ssdt_pm.h ssdt_tpm.h
-
-acpi.a: $(OBJS)
-   $(AR) rc $@ $(OBJS)
-
 clean:
-   rm -rf *.a *.o $(IASL_VER) $(IASL_VER).tar.gz $(DEPS)
-   rm -rf ssdt_*.h dsdt*.c *~ *.aml *.hex mk_dsdt dsdt_*.asl
+   rm -fr $(C_SRC) $(H_SRC) 

[Xen-devel] [PATCH v3 06/19] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops

[Boris Ostrovsky]

Components that wish to use ACPI builder will need to provide their own
mem_alloc() and virt_to_phys() routines. Pointers to these routines will
be passed to the builder as memory ops.

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Constified more function call parameters
* Added a free() nop hook in util.c

 tools/firmware/hvmloader/acpi/build.c   | 95 ++---
 tools/firmware/hvmloader/acpi/libacpi.h | 10 +++-
 tools/firmware/hvmloader/util.c | 23 +++-
 3 files changed, 83 insertions(+), 45 deletions(-)

diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 1ea146f..9c4a0a0 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -70,7 +70,8 @@ static void set_checksum(
 p[checksum_offset] = -sum;
 }
 
-static struct acpi_20_madt *construct_madt(const struct acpi_config *config,
+static struct acpi_20_madt *construct_madt(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config,
struct acpi_info *info)
 {
 struct acpi_20_madt   *madt;
@@ -85,7 +86,7 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 sz += sizeof(struct acpi_20_madt_ioapic);
 sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
 
-madt = mem_alloc(sz, 16);
+madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
 
 memset(madt, 0, sizeof(*madt));
@@ -165,11 +166,12 @@ static struct acpi_20_madt *construct_madt(const struct 
acpi_config *config,
 return madt;
 }
 
-static struct acpi_20_hpet *construct_hpet(void)
+static struct acpi_20_hpet *construct_hpet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_hpet *hpet;
 
-hpet = mem_alloc(sizeof(*hpet), 16);
+hpet = ctxt->mem_ops.alloc(ctxt, sizeof(*hpet), 16);
 if (!hpet) return NULL;
 
 memset(hpet, 0, sizeof(*hpet));
@@ -188,11 +190,12 @@ static struct acpi_20_hpet *construct_hpet(void)
 return hpet;
 }
 
-static struct acpi_20_waet *construct_waet(void)
+static struct acpi_20_waet *construct_waet(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_waet *waet;
 
-waet = mem_alloc(sizeof(*waet), 16);
+waet = ctxt->mem_ops.alloc(ctxt, sizeof(*waet), 16);
 if (!waet) return NULL;
 
 memcpy(waet, , sizeof(*waet));
@@ -203,7 +206,8 @@ static struct acpi_20_waet *construct_waet(void)
 return waet;
 }
 
-static struct acpi_20_srat *construct_srat(const struct acpi_config *config)
+static struct acpi_20_srat *construct_srat(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_srat *srat;
 struct acpi_20_srat_processor *processor;
@@ -215,7 +219,7 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 size = sizeof(*srat) + sizeof(*processor) * config->hvminfo->nr_vcpus +
sizeof(*memory) * config->numa.nr_vmemranges;
 
-p = mem_alloc(size, 16);
+p = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !p )
 return NULL;
 
@@ -261,7 +265,8 @@ static struct acpi_20_srat *construct_srat(const struct 
acpi_config *config)
 return srat;
 }
 
-static struct acpi_20_slit *construct_slit(const struct acpi_config *config)
+static struct acpi_20_slit *construct_slit(struct acpi_ctxt *ctxt,
+   const struct acpi_config *config)
 {
 struct acpi_20_slit *slit;
 unsigned int i, num, size;
@@ -269,7 +274,7 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 num = config->numa.nr_vnodes * config->numa.nr_vnodes;
 size = sizeof(*slit) + num * sizeof(uint8_t);
 
-slit = mem_alloc(size, 16);
+slit = ctxt->mem_ops.alloc(ctxt, size, 16);
 if ( !slit )
 return NULL;
 
@@ -293,7 +298,8 @@ static struct acpi_20_slit *construct_slit(const struct 
acpi_config *config)
 return slit;
 }
 
-static int construct_passthrough_tables(unsigned long *table_ptrs,
+static int construct_passthrough_tables(struct acpi_ctxt *ctxt,
+unsigned long *table_ptrs,
 int nr_tables,
 struct acpi_config *config)
 {
@@ -316,7 +322,7 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 
 header = (struct acpi_header*)pt_addr;
 
-buffer = mem_alloc(header->length, 16);
+buffer = ctxt->mem_ops.alloc(ctxt, header->length, 16);
 if ( buffer == NULL )
 break;
 memcpy(buffer, header, header->length);
@@ -329,7 +335,8 @@ static int construct_passthrough_tables(unsigned long 
*table_ptrs,
 return nr_added;
 }

[Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

The goal here is to build ACPI tables for PVHv2/HVMlite guests while reusing 
existing
hvmloader's ACPI builder code. The builder is provided as a library in 
tools/libacpi.

This is version 3 of the series, see individual patches for changes. It can
be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3

The series is probably still gated by lack of an ACK from Lenovo for the
relicensing patch (included here as patch 1).

Boris Ostrovsky (19):
  acpi: Re-license ACPI builder files from GPLv2 to LGPLv2.1
  acpi/hvmloader: Collect processor and NUMA info in hvmloader
  acpi/hvmloader: Set TIS header address in hvmloader
  acpi/hvmloader: Make providing IOAPIC in MADT optional
  acpi/hvmloader: Build WAET optionally
  acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops
  acpi/hvmloader: Translate all addresses when assigning addresses in
ACPI tables
  acpi/hvmloader: Link ACPI object files directly
  acpi/hvmloader: Include file/paths adjustments
  acpi: Move ACPI code to tools/libacpi
  x86: Allow LAPIC-only emulation_flags for HVM guests
  libacpi: Build DSDT for PVH guests
  acpi: Makefile should better tolerate interrupts
  libxc/libxl: Allow multiple ACPI modules
  libxl/acpi: Add ACPI e820 entry
  libxl/pvhv2: Include APIC page in MMIO hole for PVHv2 guests
  ilibxl: Initialize domain build info before calling libxl__domain_make
  libxl/acpi: Build ACPI tables for HVMlite guests
  libxc/xc_dom_core: Copy ACPI tables to guest space

 .gitignore |  20 +-
 MAINTAINERS|   1 +
 tools/firmware/hvmloader/Makefile  |  20 +-
 tools/firmware/hvmloader/acpi/Makefile |  72 -
 tools/firmware/hvmloader/acpi/ssdt_tpm.asl |  30 --
 tools/firmware/hvmloader/config.h  |   2 +
 tools/firmware/hvmloader/hvmloader.c   |   2 +-
 tools/firmware/hvmloader/ovmf.c|   2 +-
 tools/firmware/hvmloader/rombios.c |   2 +-
 tools/firmware/hvmloader/seabios.c |   5 +-
 tools/firmware/hvmloader/util.c|  51 +++-
 tools/firmware/rombios/32bit/Makefile  |   2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile  |   2 +-
 tools/firmware/rombios/32bit/util.h|   2 +-
 tools/libacpi/Makefile |  79 ++
 tools/{firmware/hvmloader/acpi => libacpi}/README  |  16 +-
 .../{firmware/hvmloader/acpi => libacpi}/acpi2_0.h |  19 +-
 tools/{firmware/hvmloader/acpi => libacpi}/build.c | 302 +++--
 .../{firmware/hvmloader/acpi => libacpi}/dsdt.asl  |  38 +--
 tools/libacpi/dsdt_acpi_info.asl   |  26 ++
 .../{firmware/hvmloader/acpi => libacpi}/libacpi.h |  48 +++-
 .../{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c |  20 ++
 .../hvmloader/acpi => libacpi}/ssdt_pm.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s3.asl |  11 +-
 .../hvmloader/acpi => libacpi}/ssdt_s4.asl |  11 +-
 tools/libacpi/ssdt_tpm.asl |  28 ++
 .../hvmloader/acpi => libacpi}/static_tables.c |  18 +-
 tools/libxc/include/xc_dom.h   |   5 +-
 tools/libxc/xc_dom_core.c  |  93 +++
 tools/libxc/xc_dom_hvmloader.c |   3 +-
 tools/libxl/Makefile   |  20 +-
 tools/libxl/libxl_arch.h   |   9 +
 tools/libxl/libxl_create.c |  22 +-
 tools/libxl/libxl_dom.c|  53 ++--
 tools/libxl/libxl_x86.c|  45 ++-
 tools/libxl/libxl_x86_acpi.c   | 218 +++
 tools/libxl/libxl_x86_acpi.h   |  35 +++
 xen/arch/x86/domain.c  |  26 +-
 38 files changed, 975 insertions(+), 394 deletions(-)
 delete mode 100644 tools/firmware/hvmloader/acpi/Makefile
 delete mode 100644 tools/firmware/hvmloader/acpi/ssdt_tpm.asl
 create mode 100644 tools/libacpi/Makefile
 rename tools/{firmware/hvmloader/acpi => libacpi}/README (60%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/acpi2_0.h (95%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/build.c (63%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/dsdt.asl (93%)
 create mode 100644 tools/libacpi/dsdt_acpi_info.asl
 rename tools/{firmware/hvmloader/acpi => libacpi}/libacpi.h (59%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/mk_dsdt.c (95%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_pm.asl (97%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s3.asl (62%)
 rename tools/{firmware/hvmloader/acpi => libacpi}/ssdt_s4.asl (62%)
 create mode 100644 tools/libacpi/ssdt_tpm.asl
 rename tools/{firmware/hvmloader/acpi => libacpi}/static_tables.c (90%)
 create mode 100644 tools/libxl/libxl_x86_acpi.c
 create mode 100644 tools/libxl/libxl_x86_acpi.h

-- 
1.8.3.1

[Xen-devel] [PATCH v3 09/19] acpi/hvmloader: Include file/paths adjustments

[Boris Ostrovsky]

In prepearation to moving acpi sources into generally available
libacpi:

1. Pass IOAPIC/LAPIC/PCI mask values via struct acpi_config
2. Modify include files search paths to point to acpi directory
3. Macro-ise include file for build.c that defines various
   utilities used by that file. Users of libacpi will be expected
   to define this macro when compiling build.c

Signed-off-by: Boris Ostrovsky 
---
Changes in v3:
* Instead of adding x86.h pass APIC/IOAPIC info via acpi_config parameter.
* Use <> instead of "" for include directive


 tools/firmware/hvmloader/Makefile |  3 ++-
 tools/firmware/hvmloader/acpi/README  | 16 
 tools/firmware/hvmloader/acpi/build.c | 19 ++-
 tools/firmware/hvmloader/acpi/libacpi.h   |  7 +++
 tools/firmware/hvmloader/hvmloader.c  |  2 +-
 tools/firmware/hvmloader/rombios.c|  2 +-
 tools/firmware/hvmloader/seabios.c|  5 +++--
 tools/firmware/hvmloader/util.c   | 15 +--
 tools/firmware/rombios/32bit/Makefile |  2 +-
 tools/firmware/rombios/32bit/tcgbios/Makefile |  2 +-
 tools/firmware/rombios/32bit/util.h   |  2 +-
 11 files changed, 52 insertions(+), 23 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile 
b/tools/firmware/hvmloader/Makefile
index b6c5b83..77e95f1 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -76,7 +76,8 @@ smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
 ACPI_PATH = acpi
 ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c
 ACPI_OBJS = $(patsubst %.c,%.o,$(ACPI_FILES)) build.o static_tables.o
-$(ACPI_OBJS): CFLAGS += -I$(ACPI_PATH) -I.
+$(ACPI_OBJS): CFLAGS += -I. -DLIBACPI_STDUTILS=\"../util.h\"
+CFLAGS += -I$(ACPI_PATH)
 vpath build.c $(ACPI_PATH)
 vpath static_tables.c $(ACPI_PATH)
 OBJS += $(ACPI_OBJS)
diff --git a/tools/firmware/hvmloader/acpi/README 
b/tools/firmware/hvmloader/acpi/README
index 210d5ba..2b9d6e1 100644
--- a/tools/firmware/hvmloader/acpi/README
+++ b/tools/firmware/hvmloader/acpi/README
@@ -1,11 +1,19 @@
-ACPI Table for domain firmware
+ACPI builder for domain firmware
 
 
-INSTALL
+BUILDING ACPI
 -
-Simply make is OK.
-# make 
+Users of ACPI builder are expected to provide an include file that makes 
available
+the following:
+* strncpy
+* printf
+* NULL
+* test_bit
+* offsetof
 
+When compiling build.c, the name of this include file should be given to
+compiler as -DLIBACPI_STDUTILS=\"\". See 
tools/firmware/hvmloader/Makefile
+for an example.
 
 Note on DSDT Table
 --
diff --git a/tools/firmware/hvmloader/acpi/build.c 
b/tools/firmware/hvmloader/acpi/build.c
index 2098920..1cd640d 100644
--- a/tools/firmware/hvmloader/acpi/build.c
+++ b/tools/firmware/hvmloader/acpi/build.c
@@ -13,15 +13,13 @@
  * GNU Lesser General Public License for more details.
  */
 
+#include LIBACPI_STDUTILS
 #include "acpi2_0.h"
 #include "libacpi.h"
 #include "ssdt_s3.h"
 #include "ssdt_s4.h"
 #include "ssdt_tpm.h"
 #include "ssdt_pm.h"
-#include "../config.h"
-#include "../util.h"
-#include "../vnuma.h"
 #include 
 #include 
 
@@ -81,6 +79,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 struct hvm_info_table *hvminfo = config->hvminfo;
 int i, sz;
 
+if ( config->lapic_id == NULL )
+return NULL;
+
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
@@ -97,7 +98,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->header.oem_revision = ACPI_OEM_REVISION;
 madt->header.creator_id   = ACPI_CREATOR_ID;
 madt->header.creator_revision = ACPI_CREATOR_REVISION;
-madt->lapic_addr = LAPIC_BASE_ADDRESS;
+madt->lapic_addr = config->lapic_base_address;
 madt->flags  = ACPI_PCAT_COMPAT;
 
 if ( config->table_flags & ACPI_HAS_IOAPIC )
@@ -116,7 +117,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 intsrcovr->gsi= 2;
 intsrcovr->flags  = 0x0;
 }
-else if ( PCI_ISA_IRQ_MASK & (1U << i) )
+else if ( config->pci_isa_irq_mask & (1U << i) )
 {
 /* PCI: active-low level-triggered. */
 intsrcovr->gsi= i;
@@ -135,8 +136,8 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 memset(io_apic, 0, sizeof(*io_apic));
 io_apic->type= ACPI_IO_APIC;
 io_apic->length  = sizeof(*io_apic);
-io_apic->ioapic_id   = IOAPIC_ID;
-io_apic->ioapic_addr = ioapic_base_address;
+io_apic->ioapic_id   = config->ioapic_id;
+io_apic->ioapic_addr = config->ioapic_base_address;
 
 lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
 }
@@ -152,7 +153,7 @@ static struct acpi_20_madt 

[Xen-devel] [qemu-mainline test] 100780: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 100756

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

Tests which did not succeed, but are not blocking:
 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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuu2926375cffce464fde6b4dabaed1e133d549af39
baseline version:
 qemuue87d397e5ef66276ccc49b829527d605ca07d0ad

Last test of basis   100756  2016-09-05 11:15:15 Z2 days
Failing since100772  2016-09-06 13:10:59 Z1 days2 attempts
Testing same since   100780  2016-09-07 03:51:51 Z0 days1 attempts


People who touched revisions under test:
  Christian Borntraeger 
  Cornelia Huck 
  David Hildenbrand 
  Denis V. Lunev 
  Eduardo Habkost 
  Eric Blake 
  Igor Mammedov 
  Juergen Gross 
  Kevin Wolf 
  Lluís Vilanova 
  Luwei Kang 
  Michael Mueller 
  Paul Durrant 
  Pavel Butsykin 
  Peter Maydell 
  Stefan Hajnoczi 
  Stefano Stabellini 
  Yi Min Zhao 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ec68dc28557925e0708d5676288ad140651a3851
baseline version:
 ovmf 96c13c011766a950247c743887705cc035a15497

Last test of basis   100774  2016-09-06 13:14:08 Z1 days
Testing same since   100783  2016-09-07 05:09:53 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=ec68dc28557925e0708d5676288ad140651a3851
+ . ./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 
ec68dc28557925e0708d5676288ad140651a3851
+ branch=ovmf
+ revision=ec68dc28557925e0708d5676288ad140651a3851
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xec68dc28557925e0708d5676288ad140651a3851 = 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/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : 

[Xen-devel] [libvirt test] 100782: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  cbbaa17faf2e8dd92455d69daaa05178be4dce05
baseline version:
 libvirt  bae660869de0612bee2a740083fb494c27e3f80c

Last test of basis   100744  2016-09-03 04:20:01 Z4 days
Testing same since   100782  2016-09-07 04:20:15 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel P. Berrange 
  Jiri Denemark 
  Michal Privoznik 
  Nishith Shah 
  Peter Krempa 
  Roman Bogorodskiy 
  Roman Mohr 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=cbbaa17faf2e8dd92455d69daaa05178be4dce05
+ . ./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
++ 

[Xen-devel] [PATCH v2 0/2] Convert to new CPU hotplug framework

[Boris Ostrovsky]

New CPU hotplug framework was introduced recently. These patches convert Xen
CPU hotplug code to this infrastructure.

The patches (patch 1 specifically) will apply on top of
  https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg00562.html

v2: Changes in patch 1 suggested by Sebastian

Boris Ostrovsky (2):
  xen/x86: Convert to hotplug state machine
  xen/events: Convert to hotplug state machine

 arch/x86/xen/enlighten.c | 115 ++-
 drivers/xen/events/events_fifo.c |  34 
 include/linux/cpuhotplug.h   |   2 +
 3 files changed, 79 insertions(+), 72 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v2 2/2] xen/events: Convert to hotplug state machine

[Boris Ostrovsky]

From: Sebastian Andrzej Siewior 

Install the callbacks via the state machine.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Boris Ostrovsky 
---
 drivers/xen/events/events_fifo.c | 34 --
 include/linux/cpuhotplug.h   |  1 +
 2 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/xen/events/events_fifo.c b/drivers/xen/events/events_fifo.c
index 266c2c7..7ef27c6 100644
--- a/drivers/xen/events/events_fifo.c
+++ b/drivers/xen/events/events_fifo.c
@@ -418,30 +418,18 @@ static int evtchn_fifo_alloc_control_block(unsigned cpu)
return ret;
 }
 
-static int evtchn_fifo_cpu_notification(struct notifier_block *self,
- unsigned long action,
- void *hcpu)
+static int xen_evtchn_cpu_prepare(unsigned int cpu)
 {
-   int cpu = (long)hcpu;
-   int ret = 0;
-
-   switch (action) {
-   case CPU_UP_PREPARE:
-   if (!per_cpu(cpu_control_block, cpu))
-   ret = evtchn_fifo_alloc_control_block(cpu);
-   break;
-   case CPU_DEAD:
-   __evtchn_fifo_handle_events(cpu, true);
-   break;
-   default:
-   break;
-   }
-   return ret < 0 ? NOTIFY_BAD : NOTIFY_OK;
+   if (!per_cpu(cpu_control_block, cpu))
+   return evtchn_fifo_alloc_control_block(cpu);
+   return 0;
 }
 
-static struct notifier_block evtchn_fifo_cpu_notifier = {
-   .notifier_call  = evtchn_fifo_cpu_notification,
-};
+static int xen_evtchn_cpu_dead(unsigned int cpu)
+{
+   __evtchn_fifo_handle_events(cpu, true);
+   return 0;
+}
 
 int __init xen_evtchn_fifo_init(void)
 {
@@ -456,7 +444,9 @@ int __init xen_evtchn_fifo_init(void)
 
evtchn_ops = _ops_fifo;
 
-   register_cpu_notifier(_fifo_cpu_notifier);
+   cpuhp_setup_state_nocalls(CPUHP_XEN_EVTCHN_PREPARE,
+ "CPUHP_XEN_EVTCHN_PREPARE",
+ xen_evtchn_cpu_prepare, xen_evtchn_cpu_dead);
 out:
put_cpu();
return ret;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 33d352f..5f60316 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -22,6 +22,7 @@ enum cpuhp_state {
CPUHP_SMPCFD_PREPARE,
CPUHP_RCUTREE_PREP,
CPUHP_XEN_PREPARE,
+   CPUHP_XEN_EVTCHN_PREPARE,
CPUHP_NOTIFY_PREPARE,
CPUHP_TIMERS_DEAD,
CPUHP_BRINGUP_CPU,
-- 
2.7.4


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

[Xen-devel] [PATCH v2 1/2] xen/x86: Convert to hotplug state machine

[Boris Ostrovsky]

Switch to new CPU hotplug infrastructure.

Signed-off-by: Boris Ostrovsky 
Suggested-by: Sebastian Andrzej Siewior 
---
Changes in v2:
* Replace xen_cpu_up_cancel with xen_cpu_dead
* Use existing CPUHP_AP_ONLINE_DYN instead of introducing new state
* Be more careful with return value of cpuhp_setup_state_nocalls()
  as it may return a positive (non-error) number. (Which suggests
  that comment on top of __cpuhp_setup_state() is probably incorrect)

 arch/x86/xen/enlighten.c   | 115 +
 include/linux/cpuhotplug.h |   1 +
 2 files changed, 66 insertions(+), 50 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 78e1d06..e4c3399 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -140,7 +140,9 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
-static struct notifier_block xen_cpu_notifier;
+static int xen_cpu_up_prepare(unsigned int cpu);
+static int xen_cpu_up_online(unsigned int cpu);
+static int xen_cpu_dead(unsigned int cpu);
 
 /*
  * Point at some empty memory to start with. We map the real shared_info
@@ -1541,6 +1543,24 @@ static void __init xen_dom0_set_legacy_features(void)
x86_platform.legacy.rtc = 1;
 }
 
+static int xen_cpuhp_setup(void)
+{
+   int rc;
+
+   rc = cpuhp_setup_state_nocalls(CPUHP_XEN_PREPARE,
+  "XEN_HVM_GUEST_PREPARE",
+  xen_cpu_up_prepare, xen_cpu_dead);
+   if (rc >= 0) {
+   rc = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
+  "XEN_HVM_GUEST_ONLINE",
+  xen_cpu_up_online, NULL);
+   if (rc < 0)
+   cpuhp_remove_state_nocalls(CPUHP_XEN_PREPARE);
+   }
+
+   return rc >= 0 ? 0 : rc;
+}
+
 /* First C function to be called on Xen boot */
 asmlinkage __visible void __init xen_start_kernel(void)
 {
@@ -1629,7 +1649,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_initial_gdt = _cpu(gdt_page, 0);
 
xen_smp_init();
-   register_cpu_notifier(_cpu_notifier);
+   WARN_ON(xen_cpuhp_setup());
 
 #ifdef CONFIG_ACPI_NUMA
/*
@@ -1823,63 +1843,58 @@ static void __init init_hvm_pv_info(void)
xen_domain_type = XEN_HVM_DOMAIN;
 }
 
-static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
-void *hcpu)
+static int xen_cpu_up_prepare(unsigned int cpu)
 {
-   int cpu = (long)hcpu;
int rc;
 
-   switch (action) {
-   case CPU_UP_PREPARE:
-   if (xen_hvm_domain()) {
-   /*
-* This can happen if CPU was offlined earlier and
-* offlining timed out in common_cpu_die().
-*/
-   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
-   xen_smp_intr_free(cpu);
-   xen_uninit_lock_cpu(cpu);
-   }
-
-   if (cpu_acpi_id(cpu) != U32_MAX)
-   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
-   else
-   per_cpu(xen_vcpu_id, cpu) = cpu;
-   xen_vcpu_setup(cpu);
+   if (xen_hvm_domain()) {
+   /*
+* This can happen if CPU was offlined earlier and
+* offlining timed out in common_cpu_die().
+*/
+   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
}
 
-   if (xen_pv_domain() ||
-   (xen_have_vector_callback &&
-xen_feature(XENFEAT_hvm_safe_pvclock)))
-   xen_setup_timer(cpu);
+   if (cpu_acpi_id(cpu) != U32_MAX)
+   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+   else
+   per_cpu(xen_vcpu_id, cpu) = cpu;
+   xen_vcpu_setup(cpu);
+   }
 
-   rc = xen_smp_intr_init(cpu);
-   if (rc) {
-   WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
-cpu, rc);
-   return NOTIFY_BAD;
-   }
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
+   xen_setup_timer(cpu);
 
-   break;
-   case CPU_ONLINE:
-   xen_init_lock_cpu(cpu);
-   break;
-   case CPU_UP_CANCELED:
-   xen_smp_intr_free(cpu);
-   if (xen_pv_domain() ||
-   

Re: [Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Anthony PERARD]

On Wed, Sep 07, 2016 at 12:41:00PM +0200, Paulina Szubarczyk wrote:
> Copy data operated on during request from/to local buffers to/from
> the grant references.
> 
> Before grant copy operation local buffers must be allocated what is
> done by calling ioreq_init_copy_buffers. For the 'read' operation,
> first, the qemu device invokes the read operation on local buffers
> and on the completion grant copy is called and buffers are freed.
> For the 'write' operation grant copy is performed before invoking
> write by qemu device.
> 
> A new value 'feature_grant_copy' is added to recognize when the
> grant copy operation is supported by a guest.
> 
> Signed-off-by: Paulina Szubarczyk 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[George Dunlap]

On 07/09/16 16:33, Ian Jackson wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security 
> Vulnerability Process"):
>> A few years ago it was discovered that much of the RAM shipped in our
>> computers contains flaws which allow "leakage" across rows; effectively
>> allowing programs to use access to one bit of memory to flip bits in
>> other parts of memory to which they have been specifically denied
>> access.  This has attack on faulty hardware has been dubbed "rowhammer" 
>> [1].
> ...
> 
>> From my perspective, there are a number of differing goals we are trying 
>> to achieve with the process
> ...
>> b) If already public (or at disclosure time), ensure that our users have 
>>all the information to make the right choices
> 
> This is my concern.
> 
> From my POV XSAs are a convenient established format and process.
> 
> However, I don't think this necessarily needs to be dealt with by
> issuing an actual XSA, particularly if there are other reasons for
> doing things differently.  We could brief our users by writing some
> other kind of message, perhaps posted on xen-announce.
> 
> Indeed several aspects of the XSA process are not really applicable.
> 
> One main reason for issuing an XSA for an ordinary software bug is
> that it allows the issue, and its fix, to be tracked in a standardised
> way.  CVEs perform the same function, with a more general scope.
> 
> But, we would not expect to get a CVE for what really amounts to a
> hardware quality issue.  And where there can be little useful way of
> avoiding a hardware bug by adding workarounds to the software
> (specifically, in our case, by modifying Xen), there is no need to
> track whether any particular codebase has the mitigation.
> 
> So there is little benefit in assigning a number.
> 
> Unlike with software bugs, there is also relatively little benefit in
> having rowhammer listed on a web page alongside software bugs.
> 
> The XSA advisory template format does not lend itself well to this
> issue, as I found when I tried to write a draft.  While does have the
> benefit of being in a format which is familiar to users, user response
> will have to be quite different.  And the level of uncertainty and
> hardware-dependence means that the usual questions such as `Impact'
> and `Vulnerable systems' have unsatisfactory non-answers, in such a
> bulletin.
> 
> We did issue XSA-3 for a mitigationless hardware design problem.  But
> that was in a very different environment: the XSA process was not as
> formally established as it is now, and the publicity implications were
> different.

What's the conclusion here -- are you inclined to say that we shouldn't
issue an XSA, but perhaps do some other sort of announcement?

 -George


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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Jan Beulich]

>>> On 07.09.16 at 11:12,  wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be to set each page in turn, using a userspace-HV
> roundtrip for each call, and triggering a TLB flush per page set.
> 
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 

Hypervisor parts (without ARM and x86/mm)
Acked-by: Jan Beulich 

albeit I spotted one more cosmetic issue (which I guess could be
fixed up during commit, if no other reason for a v5 arises):

> @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>  }
>  
>  case XENMEM_access_op:
> -return mem_access_memop(cmd,
> -guest_handle_cast(compat,
> -  xen_mem_access_op_t));
> +{
> +if ( copy_from_guest(, compat, 1) )
> +return -EFAULT;
> +
> +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
> +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
> +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
> +guest_from_compat_handle((_d_)->access_list, (_s_)->access_list)
> +
> +XLAT_mem_access_op(nat.mao, );
> +
> +#undef XLAT_mem_access_op_HNDL_pfn_list
> +#undef XLAT_mem_access_op_HNDL_access_list
> +
> +break;
> +}

There are no local variables declared here, so I don't see the need
for the braces.

Jan


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

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[George Dunlap]

On 07/09/16 16:33, Ian Jackson wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security 
> Vulnerability Process"):
>> A few years ago it was discovered that much of the RAM shipped in our
>> computers contains flaws which allow "leakage" across rows; effectively
>> allowing programs to use access to one bit of memory to flip bits in
>> other parts of memory to which they have been specifically denied
>> access.  This has attack on faulty hardware has been dubbed "rowhammer" 
>> [1].
> ...
> 
>> From my perspective, there are a number of differing goals we are trying 
>> to achieve with the process
> ...
>> b) If already public (or at disclosure time), ensure that our users have 
>>all the information to make the right choices
> 
> This is my concern.
> 
> From my POV XSAs are a convenient established format and process.
> 
> However, I don't think this necessarily needs to be dealt with by
> issuing an actual XSA, particularly if there are other reasons for
> doing things differently.  We could brief our users by writing some
> other kind of message, perhaps posted on xen-announce.
> 
> Indeed several aspects of the XSA process are not really applicable.
> 
> One main reason for issuing an XSA for an ordinary software bug is
> that it allows the issue, and its fix, to be tracked in a standardised
> way.  CVEs perform the same function, with a more general scope.
> 
> But, we would not expect to get a CVE for what really amounts to a
> hardware quality issue.  And where there can be little useful way of
> avoiding a hardware bug by adding workarounds to the software
> (specifically, in our case, by modifying Xen), there is no need to
> track whether any particular codebase has the mitigation.
> 
> So there is little benefit in assigning a number.
> 
> Unlike with software bugs, there is also relatively little benefit in
> having rowhammer listed on a web page alongside software bugs.
> 
> The XSA advisory template format does not lend itself well to this
> issue, as I found when I tried to write a draft.  While does have the
> benefit of being in a format which is familiar to users, user response
> will have to be quite different.  And the level of uncertainty and
> hardware-dependence means that the usual questions such as `Impact'
> and `Vulnerable systems' have unsatisfactory non-answers, in such a
> bulletin.
> 
> We did issue XSA-3 for a mitigationless hardware design problem.  But
> that was in a very different environment: the XSA process was not as
> formally established as it is now, and the publicity implications were
> different.
> 
>> Technical
>> =
>> On the technical front, it would be good to understand whether
>> a) This is a real threat and whether thus, we as a community need to 
>>take action 
> 
> It is unclear what action the Xen upstream community can usefully
> take, other than providing users with information.
> 
> But, users with deployments on actual hardware ought to try to find
> out whether they are vulnerable.  If they are then they could seek
> replacement non-faulty hardware from their vendor, or take unpleasant
> migitation measures (like switching to HVM, perhaps).
> 
>> b) Whether the technique described in [3] is serious on big iron with 
>>different core/cache properties compared to some of the machines this 
>>was tested on
> 
> This is a big question.
> 
>> c) Whether there is any mitigation that we can develop, if necessary
> 
> AIUI there is little to be done.  But, I look forward to being proven
> wrong.

The attack described in [4] relies on the fact that the attacker knows
the mfn of the L2 pagetables being used by the hardware.  Using shadows
for the L2+ pagetables would thwart that particular attack, and
shouldn't in theory cause too much overhead.

But that would only thwart a particular attack.  Other attacks are
certain to develop; we can only strongly advise all our users that if
they expect to have determined adversaries inside their guests, that
they should make every effort to use RAM which is not vulnerable to
rowhammer attacks.

 -George

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

[Xen-devel] [PATCH] tools: fix vif-route add|remove

[Charles Arnold]

From 2b4e942ad75f4a4546c417d8bd1116e3af368daf Mon Sep 17 00:00:00 2001
From: Charles Arnold 
Date: Wed, 7 Sep 2016 09:48:18 -0600
Subject: [PATCH] tools: fix vif-route add|remove

vif-route is called twice. First for the vif interface and
second for the vif-emu interface. vif-route takes 4 parameters,

(add|remove|online|offline)

When called with 'online|offline' then 'ipcmd' is set. When called
with 'add|remove' then 'ipcmd' is empty ('') and the command,

${cmdprefix} ip route ${ipcmd} ${addr} dev ${dev} src ${main_ip}

will fail.

Signed-off-by: Charles Arnold 
---
 tools/hotplug/Linux/vif-route | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/vif-route b/tools/hotplug/Linux/vif-route
index c149ffc..d49eb20 100644
--- a/tools/hotplug/Linux/vif-route
+++ b/tools/hotplug/Linux/vif-route
@@ -35,7 +35,7 @@ case "${command}" in
 ;;
 esac
 
-if [ "${ip}" ] ; then
+if [ "${ip}" ] && [ "${ipcmd}" ] ; then
 # If we've been given a list of IP addresses, then add routes from dom0 to
 # the guest using those addresses.
 for addr in ${ip} ; do
-- 
1.8.5.6




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

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Jan Beulich]

>>> On 07.09.16 at 17:33,  wrote:
> Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security 
> Vulnerability Process"):
>> c) Whether there is any mitigation that we can develop, if necessary
> 
> AIUI there is little to be done.  But, I look forward to being proven
> wrong.

Well, I think David's PV-with-stub-Xen-in-a-HVM-container outlined
on the last hackathon would be a possible aid, albeit presumably
one requiring quite a bit of work.

Jan


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

[Xen-devel] [xen-4.6-testing test] 100779: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3 17 guest-start/win.repeat fail in 100771 
pass in 100779
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 100771

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 100630
 test-armhf-armhf-xl-rtds 11 guest-start fail in 100771 like 100630
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100630
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100630
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100630
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100630

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

version targeted for testing:
 xen  4627e5e5f10bf8cdebaf45b66a476c4adb104f6d
baseline version:
 xen  a00a0f9139c4b3a9db8e74aca0ac0808e6f7d65b

Last test of basis   100630  2016-08-26 08:43:05 Z   12 days
Testing same since   100771  2016-09-06 13:10:38 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  George Dunlap 
  Jan Beulich 
  Razvan Cojocaru 

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

Re: [Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Ian Jackson]

Lars Kurth writes ("Impact of HW vulnerabilities & Implications on Security 
Vulnerability Process"):
> A few years ago it was discovered that much of the RAM shipped in our
> computers contains flaws which allow "leakage" across rows; effectively
> allowing programs to use access to one bit of memory to flip bits in
> other parts of memory to which they have been specifically denied
> access.  This has attack on faulty hardware has been dubbed "rowhammer" 
> [1].
...

> From my perspective, there are a number of differing goals we are trying 
> to achieve with the process
...
> b) If already public (or at disclosure time), ensure that our users have 
>all the information to make the right choices

This is my concern.

From my POV XSAs are a convenient established format and process.

However, I don't think this necessarily needs to be dealt with by
issuing an actual XSA, particularly if there are other reasons for
doing things differently.  We could brief our users by writing some
other kind of message, perhaps posted on xen-announce.

Indeed several aspects of the XSA process are not really applicable.

One main reason for issuing an XSA for an ordinary software bug is
that it allows the issue, and its fix, to be tracked in a standardised
way.  CVEs perform the same function, with a more general scope.

But, we would not expect to get a CVE for what really amounts to a
hardware quality issue.  And where there can be little useful way of
avoiding a hardware bug by adding workarounds to the software
(specifically, in our case, by modifying Xen), there is no need to
track whether any particular codebase has the mitigation.

So there is little benefit in assigning a number.

Unlike with software bugs, there is also relatively little benefit in
having rowhammer listed on a web page alongside software bugs.

The XSA advisory template format does not lend itself well to this
issue, as I found when I tried to write a draft.  While does have the
benefit of being in a format which is familiar to users, user response
will have to be quite different.  And the level of uncertainty and
hardware-dependence means that the usual questions such as `Impact'
and `Vulnerable systems' have unsatisfactory non-answers, in such a
bulletin.

We did issue XSA-3 for a mitigationless hardware design problem.  But
that was in a very different environment: the XSA process was not as
formally established as it is now, and the publicity implications were
different.

> Technical
> =
> On the technical front, it would be good to understand whether
> a) This is a real threat and whether thus, we as a community need to 
>take action 

It is unclear what action the Xen upstream community can usefully
take, other than providing users with information.

But, users with deployments on actual hardware ought to try to find
out whether they are vulnerable.  If they are then they could seek
replacement non-faulty hardware from their vendor, or take unpleasant
migitation measures (like switching to HVM, perhaps).

> b) Whether the technique described in [3] is serious on big iron with 
>different core/cache properties compared to some of the machines this 
>was tested on

This is a big question.

> c) Whether there is any mitigation that we can develop, if necessary

AIUI there is little to be done.  But, I look forward to being proven
wrong.

Ian.

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

Re: [Xen-devel] [PATCH v2 13/20] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

On Wed, Sep 07, 2016 at 11:43:27AM +0100, Julien Grall wrote:
> 
> 
> On 07/09/2016 04:33, Konrad Rzeszutek Wilk wrote:
> > > ...snip..
> > > > > +case R_AARCH64_ABS32:
> > > > > +ovf = reloc_data(RELOC_OP_ABS, dest, val, 32);
> > > > > +break;
> > > > 
> > > > I have noticed that not all the relocations are implemented (e.g
> > > > R_AARCH64_ABS16, R_AARCH64_MOVW_*...). I don't think there is anything
> > > > preventing the compiler to use them. So is there any particular reasons 
> > > > to
> > > > not include them?
> > > 
> > > I followed the same principle Ross did on x86 - only implement the ones 
> > > that
> > > the compiler has generated. And that is what I initially had in the v1, 
> > > but expanded
> > > it per request.
> > > 
> > > I can include more, but at what point should I stop?
> 
> Good question. My question was more, would it ever be possible to be
> generated by the same compiler when applying a patch?

If the hypervisor did not have them, then the payload will most likely not have
them either.

And vice-versa - if hypervisor does have them, then the payload will most likely
have them.

Either way I think we are debating academics as I already added all that code 
in :-)
> 
> > 
> > 
> >  xen/arch/arm/arm64/livepatch.c   |  140 +++
> >  xen/include/xen/elfstructs.h |   23 ++
> > 
> > lines later and I added them all in.
> > 
> 
> -- 
> Julien Grall

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

[Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Lars Kurth]

Dear community members,

A few years ago it was discovered that much of the RAM shipped in our
computers contains flaws which allow "leakage" across rows; effectively
allowing programs to use access to one bit of memory to flip bits in
other parts of memory to which they have been specifically denied
access.  This has attack on faulty hardware has been dubbed "rowhammer" 
[1].

As time has gone on, researchers have continued to refine rowhammer
techniques and attacks, increasing the probability and speed of finding
rowhammer vulnerabilities, their effectiveness at making unauthorized
changes to memory, and the methods of using these changes in order to
escalate privilege.  Last year Google published demonstrated an attack
on Linux [2]; and a recent Usenix conference had three papers containing
rowhammer attacks, one of which demonstrated an attack on KVM [3], and
one of which demonstrated an attack on Xen PV guests [4].  It is only to
be expected that the techniques will continue to advance over time.

[1] http://users.ece.cmu.edu/%7Eyoonguk/papers/kim-isca14.pdf
[2] 
http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[3] 
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
[4] http://web.cse.ohio-state.edu/~yinqian/papers/sec16.pdf

The underlying bug is clearly not a software bug, which raises a number of 
technical as well as process questions:
* Process: whether we should handle such vulnerabilities as XSAs
* Technical: to which degree is rowhammer (or similar HW   
  vulnerabilities) affecting Xen, is the threat theoretical or real 
  and are there any technical mitigations we could implement other than 
  not using PV (using the rowhammer example)

I am starting this discussion, as the information is already in the public 
domain. 

Process
===
From a process perspective, these new class of hardware vulnerabilities 
raise the question whether the project should treat them as XSAs (even 
if just informational purposes), or not. My understanding of the issue 
is that this is a hardware bug, which cannot be fixed by a Xen software 
patch (please correct me if wrong).

Looking at the process 
[5] https://www.xenproject.org/security-policy.html
the scope of the process currently is "vulnerability in Xen Project software" - 
see bullet 1 

A general observation in [5] is that the "Introduction" and "Scope of 
this process" sections are a little unclear and could probably be 
improved. In particular with a view of how we deal with vulnerabilities 
in upstreams such as QEMU, Linux, ...), vulnerabilities in experimental/preview 
code, and HW vulnerabilities, ...

From my perspective, there are a number of differing goals we are trying 
to achieve with the process

a) Ensuring that pre-disclosure members can deploy patches before 
   information becomes public

b) If already public (or at disclosure time), ensure that our users have 
   all the information to make the right choices

In this case, a) does not apply as there are no patches that can be 
applied, but b) would.

However, we are also other considerations/trade-offs

c) Widening the scope of the process, obviously creates more work-load   
   for the security team
   We had some issues with upstream vulnerabilities in QEMU in the past:
   for a while we did not have a clear policy, which led to a growing
   influx of upstream vulnerabilities being reported
   to security@xenproject instead of the upstream projects. This 
   eventually forced us to tighten our criteria to only cover 
   vulnerabilities of upstream that affect supported configurations.

d) Also, XSAs are monitored by the tech press, and frequently result in 
   media coverage.
   The coverage is not always fair, and often technically incorrect. 
   Treating HW vulnerabilities like XSAs carries the risk that 
   vulnerabilities like rowhammer will be closely linked with
   Xen, due to mistakes by reporters, and ultimately damage the 
   reputation of the project. This would in particular be true if 
   competing projects/commercial products, do not treat Hardware 
   issues in the same way. 

As an aside, there has already been ample coverage on rowhammer/Flip 
Feng Shui attacks, but none of the stories published were Xen specific. 
If we were to publish an XSA, that would VERY LIKELY change. 

Technical
=
On the technical front, it would be good to understand whether
a) This is a real threat and whether thus, we as a community need to 
   take action 
b) Whether the technique described in [3] is serious on big iron with 
   different core/cache properties compared to some of the machines this 
   was tested on
c) Whether there is any mitigation that we can develop, if necessary

In any case, it is probably a new type of attack vector, that we need to 
consider and keep in mind, when developing new features.

Best Regards
Lars
___
Xen-devel mailing list

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Tamas K Lengyel]

On Wed, Sep 7, 2016 at 3:12 AM, Razvan Cojocaru
 wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be to set each page in turn, using a userspace-HV
> roundtrip for each call, and triggering a TLB flush per page set.
>
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 

Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH v2] libelf: drop pointless uses of __FUNCTION__

[Ian Jackson]

Jan Beulich writes ("[PATCH v2] libelf: drop pointless uses of __FUNCTION__"):
> Non-debugging message text should be (and is in the cases here, albeit
> often only with the addition of an ELF: prefix) distinguishable without
> also logging function names.
> 
> In the messages touched at once use %#x (or variants thereof) in favor
> of 0x%x.
> ---
> v2: Add a missing ELF: prefix. Further disambiguate note related
> messages. Also take care of one instance of __func__.

Acked-by: Ian Jackson 

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: alternative: Clean-up __apply_alternatives

[Julien Grall]

Hi Konrad,

On 07/09/2016 15:13, Konrad Rzeszutek Wilk wrote:

On Wed, Sep 07, 2016 at 01:50:43PM +0100, Julien Grall wrote:

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..0ca97b9 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -99,21 +99,21 @@ static int __apply_alternatives(const struct alt_region 
*region)
 const struct alt_instr *alt;
 const u32 *origptr, *replptr;
 u32 *writeptr, *writemap;
-mfn_t text_mfn = _mfn(virt_to_mfn(_stext));
-unsigned int text_order = get_order_from_bytes(_end - _start);
+mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+unsigned int xen_order = get_order_from_bytes(_end - _start);

 printk(XENLOG_INFO "alternatives: Patching kernel code\n");

 /*
- * The text section is read-only. So re-map Xen to be able to patch
- * the code.
+ * The text and inittext section are read-only. So re-map Xen to be
+ * able to patch the code.
  */
-writemap = __vmap(_mfn, 1 << text_order, 1, 1, PAGE_HYPERVISOR,
+writemap = __vmap(_mfn, 1 << xen_order, 1, 1, PAGE_HYPERVISOR,


Do you want to make it 1U? (You pointed that out in my patchset so perhaps you
want it here?)


Good point, I used 1U whilst moving the code in patch #2 but forgot here.

I will update the patch and resend it.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/2] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Konrad Rzeszutek Wilk]

On Wed, Sep 07, 2016 at 01:50:44PM +0100, Julien Grall wrote:
> With livepatch the alternatives that should be patched are outside of
> the Xen hypervisor _start -> _end. The current code is assuming that
> only Xen could be patched and therefore will explode when a payload
> contains alternatives.
> 
> Given that alt_instr contains a relative offset, the function
> __apply_alternatives could directly take in parameter the virtual
> address of the alt_instr set of the re-mapped region. So we can mandate
> the callers of __apply_alternatives to provide use with a region that has
> read-write access.
> 
> The only caller that will patch directly the Xen binary is the function
> __apply_alternatives_multi_stop. The other caller apply_alternatives
> will work on the payload which will still have read-write access at that
> time.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Cc: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: alternative: Clean-up __apply_alternatives

[Konrad Rzeszutek Wilk]

On Wed, Sep 07, 2016 at 01:50:43PM +0100, Julien Grall wrote:
> This patch contains only renaming and comment update. There are no
> functional changes:
> - Don't mix _start and _stext, they both point to the same address
> but the former makes more sense (we are mapping the Xen binary, not
> only the text section).
> - s/text_mfn/xen_mfn/ and s/text_order/xen_order/ to make clear that
> we map the Xen binary.
> - Mention about inittext as alternative may patch this section.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> Signed-off-by: Julien Grall 
> 
> ---
> Konrad, I added your signed-off by because I squashed your patch [1]
> in it. Let me know if there is any issue for that.

No issues. Albeit it may be odd for me to review my own patch :-)

See below

> 
> [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02890.html
> 
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/alternative.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> index 8ee5a11..0ca97b9 100644
> --- a/xen/arch/arm/alternative.c
> +++ b/xen/arch/arm/alternative.c
> @@ -99,21 +99,21 @@ static int __apply_alternatives(const struct alt_region 
> *region)
>  const struct alt_instr *alt;
>  const u32 *origptr, *replptr;
>  u32 *writeptr, *writemap;
> -mfn_t text_mfn = _mfn(virt_to_mfn(_stext));
> -unsigned int text_order = get_order_from_bytes(_end - _start);
> +mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
> +unsigned int xen_order = get_order_from_bytes(_end - _start);
>  
>  printk(XENLOG_INFO "alternatives: Patching kernel code\n");
>  
>  /*
> - * The text section is read-only. So re-map Xen to be able to patch
> - * the code.
> + * The text and inittext section are read-only. So re-map Xen to be
> + * able to patch the code.
>   */
> -writemap = __vmap(_mfn, 1 << text_order, 1, 1, PAGE_HYPERVISOR,
> +writemap = __vmap(_mfn, 1 << xen_order, 1, 1, PAGE_HYPERVISOR,

Do you want to make it 1U? (You pointed that out in my patchset so perhaps you
want it here?)

>VMAP_DEFAULT);
>  if ( !writemap )
>  {
>  printk(XENLOG_ERR "alternatives: Unable to map the text section 
> (size %u)\n",
> -   1 << text_order);
> +   1 << xen_order);
>  return -ENOMEM;
>  }
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH v2] libelf: drop pointless uses of __FUNCTION__

[Jan Beulich]

>>> On 07.09.16 at 09:59,  wrote:
> Non-debugging message text should be (and is in the cases here, albeit
> often only with the addition of an ELF: prefix) distinguishable without
> also logging function names.
> 
> In the messages touched at once use %#x (or variants thereof) in favor
> of 0x%x.

(Obviously)
Signed-off-by: Jan Beulich 

> ---
> v2: Add a missing ELF: prefix. Further disambiguate note related
> messages. Also take care of one instance of __func__.
> 
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -131,8 +131,7 @@ elf_errorstatus elf_xen_parse_note(struc
>  if ( (type >= sizeof(note_desc) / sizeof(note_desc[0])) ||
>   (note_desc[type].name == NULL) )
>  {
> -elf_msg(elf, "%s: unknown xen elf note (0x%x)\n",
> -__FUNCTION__, type);
> +elf_msg(elf, "ELF: note: unknown (%#x)\n", type);
>  return 0;
>  }
>  
> @@ -142,16 +141,14 @@ elf_errorstatus elf_xen_parse_note(struc
>  if (str == NULL)
>  /* elf_strval will mark elf broken if it fails so no need to 
> log */
>  return 0;
> -elf_msg(elf, "%s: %s = \"%s\"\n", __FUNCTION__,
> -note_desc[type].name, str);
> +elf_msg(elf, "ELF: note: %s = \"%s\"\n", note_desc[type].name, 
> str);
>  parms->elf_notes[type].type = XEN_ENT_STR;
>  parms->elf_notes[type].data.str = str;
>  }
>  else
>  {
>  val = elf_note_numeric(elf, note);
> -elf_msg(elf, "%s: %s = 0x%" PRIx64 "\n", __FUNCTION__,
> -note_desc[type].name, val);
> +elf_msg(elf, "ELF: note: %s = %#" PRIx64 "\n", 
> note_desc[type].name, val);
>  parms->elf_notes[type].type = XEN_ENT_LONG;
>  parms->elf_notes[type].data.num = val;
>  }
> @@ -310,7 +307,7 @@ elf_errorstatus elf_xen_parse_guest_info
>  }
>  name[len] = STAR(h);
>  }
> -elf_msg(elf, "%s: %s=\"%s\"\n", __FUNCTION__, name, value);
> +elf_msg(elf, "ELF: %s=\"%s\"\n", name, value);
>  
>  /* strings */
>  if ( !strcmp(name, "LOADER") )
> @@ -363,9 +360,8 @@ static elf_errorstatus elf_xen_note_chec
>  unsigned machine = elf_uval(elf, elf->ehdr, e_machine);
>  if ( (machine == EM_386) || (machine == EM_X86_64) )
>  {
> -elf_err(elf, "%s: ERROR: Not a Xen-ELF image: "
> -"No ELF notes or '__xen_guest' section found.\n",
> -__FUNCTION__);
> +elf_err(elf, "ERROR: Not a Xen-ELF image: "
> +"No ELF notes or '__xen_guest' section found\n");
>  return -1;
>  }
>  return 0;
> @@ -373,7 +369,7 @@ static elf_errorstatus elf_xen_note_chec
>  
>  if ( elf_uval(elf, elf->ehdr, e_machine) == EM_ARM )
>  {
> - elf_msg(elf, "%s: Not bothering with notes on ARM\n", 
> __FUNCTION__);
> + elf_msg(elf, "ELF: Not bothering with notes on ARM\n");
>   return 0;
>  }
>  
> @@ -383,9 +379,10 @@ static elf_errorstatus elf_xen_note_chec
>   ((strlen(parms->guest_os) == 0) ||
>strncmp(parms->guest_os, "linux", 5)) )
>  {
> -elf_err(elf, "%s: ERROR: Will only load images built for the generic 
> "
> -"loader or Linux images (Not '%.*s' and '%.*s')\n",
> -__FUNCTION__, (int)sizeof(parms->loader), parms->loader,
> +elf_err(elf,
> +"ERROR: Will only load images built for the generic loader 
> or Linux images"
> +" (Not '%.*s' and '%.*s')\n",
> +(int)sizeof(parms->loader), parms->loader,
>  (int)sizeof(parms->guest_os), parms->guest_os);
>  return -1;
>  }
> @@ -393,8 +390,8 @@ static elf_errorstatus elf_xen_note_chec
>  if ( (strlen(parms->xen_ver) == 0) ||
>   strncmp(parms->xen_ver, "xen-3.0", 7) )
>  {
> -elf_err(elf, "%s: ERROR: Xen will only load images built "
> -"for Xen v3.0 (Not '%.*s')\n", __FUNCTION__,
> +elf_err(elf, "ERROR: Xen will only load images built for Xen v3.0 "
> +"(Not '%.*s')\n",
>  (int)sizeof(parms->xen_ver), parms->xen_ver);
>  return -1;
>  }
> @@ -409,8 +406,7 @@ static elf_errorstatus elf_xen_addr_calc
>  if ( (parms->elf_paddr_offset != UNSET_ADDR) &&
>   (parms->virt_base == UNSET_ADDR) )
>  {
> -elf_err(elf, "%s: ERROR: ELF_PADDR_OFFSET set, VIRT_BASE unset\n",
> -__FUNCTION__);
> +elf_err(elf, "ERROR: ELF_PADDR_OFFSET set, VIRT_BASE unset\n");
>  return -1;
>  }
>  
> @@ -418,8 +414,8 @@ static elf_errorstatus elf_xen_addr_calc
>  if ( parms->virt_base == UNSET_ADDR )
>  {
>  parms->virt_base = 0;
> -elf_msg(elf, "%s: VIRT_BASE unset, using 0x%" PRIx64 "\n",
> -__FUNCTION__, 

Re: [Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator

[Jan Beulich]

>>> On 07.09.16 at 14:05,  wrote:
> On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
>> >>> On 20.08.16 at 00:43,  wrote:
>> > +static char __initdata *ebmalloc_free = NULL;
>> > +
>> > +/* EFI boot allocator. */
>> > +static void __init *ebmalloc(size_t size)
>> > +{
>> > +void *ptr;
>> > +
>> > +/*
>> > + * Init ebmalloc_free on runtime. Static initialization
>> > + * will not work because it puts virtual address there.
>> > + */
>>
>> I don't understand this static allocation comment: We have this issue
>> elsewhere (and use bootsym() as needed), and we do not have this
>> issue at all in xen.efi (which this code also gets built for). So I think at
>> the very least the comment needs improvement. And then, if static
>> initialization indeed can't be used, then a static symbol's initializer of
>> NULL is pointless and hence should be omitted.
> 
> You have to remember that xen/arch/x86/efi/efi-boot.h stuff is build
> into xen.efi and xen.gz. Of course xen.efi with
> 
> static char __initdata *ebmalloc_free = ebmalloc_mem;
> 
> works, however, xen.gz does not. Sadly, I have not found simpler
> solution for that issue, so, I do initialization during runtime.

Which all is in line with my request of improving the comment.

>> > +if ( ebmalloc_free == NULL )
>> > +ebmalloc_free = ebmalloc_mem;
>> > +
>> > +ptr = ebmalloc_free;
>> > +
>> > +ebmalloc_free += size;
>>
>> No minimal (at least pointer size) alignment getting enforced
>> somewhere here?
> 
> For what?

To avoid the penalty unaligned accesses incur? And that's alongside
the fact that it's simply bad practice to knowingly but without actual
need cause unaligned accesses even if they work fine.

>> And then - wouldn't this better go into xen/common/efi/boot.c,
>> even if ARM64 does not have a use for it right away? The code
>> certainly isn't really x86-specific.
> 
> Sure thing. However, if it is not used by ARM64 then I think ebmalloc
> stuff should not be moved to xen/common/efi/boot.c.

Being architecture independent it has all reasons to be moved
there. Agreed there may be compiler warnings for these then
being unused static functions, but I'd rather see this code get
#ifdef-ed out for ARM for the time being than it needing to be
moved over later on. And of course a question to be asked first
is whether in fact there is something in common or ARM specific
code that could benefit from using this new allocator, if you
already introduce it.

Jan


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

Re: [Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

[Dario Faggioli]

On Wed, 2016-09-07 at 14:24 +0100, anshul makkar wrote:
> On 05/09/16 15:55, Dario Faggioli wrote:
> > On Thu, 2016-09-01 at 11:52 +0100, anshul makkar wrote:
> > So, yes, we know already that it's running in a cpu at least from
> > its
> > hard affinity, what is it exactly that you are not understanding?
> If I put it simply ,  can  (X being a vcpu)
> x {soft affinity pcpus} Intersect x { hard affinity pcpu} -> be Null
> or 
> disjoint set ?
> and
> 
The user can setup things such that:

 soft-affinity{X} intersection hard-affinity{X} = O

but this, here inside the scheduler, is considered like X does not have
any soft-affinity at all, i.e., only X's hard-affinity is considered,
and all the balancing steps and operations and consideration related to
soft-affinity are ignored/skipped.

That's because it's absolutely pointless to try figure out where to
execute X, among the set of the pCPUs it prefers to run on, if it
_can't_ actually run on any pCPU from that same set.

So the answer to your question is: "it seems to be possible for the
intersection to be void, but in practise, it is not." :-)

> x{runnable pcpu} intersect (x{hard affinity pcpu} union x{soft
> affinity 
> pcpu} ) -> be null or disjoint ??
> 
I still don't get this. In particular, I'm not sure what
'x{runnable pcpu}' is. Also the union of a vcpu's soft and hard
affinity is never done (it's, as explained above, the intersection that
counts).

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



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

Re: [Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

[anshul makkar]

On 05/09/16 15:55, Dario Faggioli wrote:

On Thu, 2016-09-01 at 11:52 +0100, anshul makkar wrote:

On 17/08/16 18:19, Dario Faggioli wrote:


+/*
+ * We're doing soft-affinity, and we know that the current
vcpu on cpu
+ * has a soft affinity. We now want to know whether cpu itself
is in

Please can you explain the above statment. If the vcpu has soft
affinity
and its currently executing, doesn;t it always means that its running
on
one of the pcpu which is there in its soft affinity or hard affinity?


A vcpu will always run on a pcpu from its own hard-affinity (that's the
definition of hard-affinity).

On the other hand, a vcpu will, most of the time, run on a cpu from its
own soft affinity, but can run on a cpu that is in its hard-affinity,
but *IS NOT* in its soft-affinity.

That's the definition of soft-affinity: the scheduler will try to run
it there, but it that can't happen, it will run it will run it outside
of it (but still within its hard-affinity, of course).

So, yes, we know already that it's running in a cpu at least from its
hard affinity, what is it exactly that you are not understanding?


If I put it simply ,  can  (X being a vcpu)
x {soft affinity pcpus} Intersect x { hard affinity pcpu} -> be Null or 
disjoint set ?

and

x{runnable pcpu} intersect (x{hard affinity pcpu} union x{soft affinity 
pcpu} ) -> be null or disjoint ??





+ * such affinity. In fact, since we now that new (in
runq_tickle()) is

Typo:   * such affinity. In fact, since now we know that new (in
runq_tickle()) is


Thanks. :-)



+ */



Regards,
Dario


Anshul Makkar

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6e0815a8d75f1cb90f84894346f9261814d7453a
baseline version:
 xen  d6be2cfccfffd6d5ff1da68277ec3ab13e595368

Last test of basis   100785  2016-09-07 07:01:10 Z0 days
Testing same since   100791  2016-09-07 11:02:14 Z0 days1 attempts


People who touched revisions under test:
  "Rockosov, Dmitry" 
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Tamas K Lengyel 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Julien Grall]

Hi Vitaly,

On 07/09/2016 12:23, Vitaly Kuznetsov wrote:

BTW, were you able to try the patch I suggested? In my opinion it would
be preferable to fix the immediate SMP issue now and play with MPIDR
info later.


Not yet sorry. I will see if I can try to today or tomorrow.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

[anshul makkar]

On 05/09/16 14:26, Dario Faggioli wrote:

On Thu, 2016-09-01 at 12:08 +0100, anshul makkar wrote:

On 17/08/16 18:19, Dario Faggioli wrote:



Can't we
just read their workload or we can change the locktype to allow
reading ?


Reading without taking the lock would race against the load value being
updated. And updating the load is done by __update_runq_load(), which,
with all it's shifts and maths, by no means is an atomic operation.

So it's not just a matter of risking to read a slightly outdated value,
which, I agree, may not be that bad, it's that we risk reading
something inconsistent. :-/


Ok. Got it and agree.

About "changing the locktype", I guess you mean that we can turn also
the runqueue lock into an rw-lock? If yes, that's indeed interesting,
and I've also thought about it, but, for now, always deferred trying to
actually do that.

Yes.


It's technically non trivial, as it would involve changing
schedule_data->schedule_lock and all the {v,p}cpu_schedule_lock*()
functions. Also, it's a lock that will almost all the times be taken
for writing, which usually means what you want is a proper spinlock.

So, IMO, before embarking in doing something like that, it'd be good to
figure out how frequently we actually fail to take the remote runqueue
lock, and what's the real impact of having to deal the consequence of
that.


Ok. Lets discuss on that to finalize the approach.

I'm not saying it's not worth a try, but I'm saying that's it's
something at high risk of being a lot of work for a very small gain,
and that there are more important things to focus on.


+ * we pick, in order of decreasing preference:
+ *  1) svc's current pcpu, if it is part of svc's soft affinity;
+ *  2) a pcpu in svc's current runqueue that is also in svc's soft
affinity;

svc's current runqueue. Do you mean the runq in which svc is
currently
queued ?


I mean the runqueue to which svc is currently assigned (again, as per
runq_assign()/runq_deassing()), which in turns mean that, if svc is
queued in a runqueue, it's queues there (so, I guess the short answer
to your question is "yes" :-D).


Ok.

Regards,
Dario


Anshul


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

[Xen-devel] [PATCH v2 0/2] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Julien Grall]

Hi,

The first patch is a clean-up added in this new version. The second contains the
meat of this series.

Yours sincerely,

Julien Grall (2):
  xen/arm: alternative: Clean-up __apply_alternatives
  xen/arm: alternative: Make it possible to patch outside of the
hypervisor

 xen/arch/arm/alternative.c | 65 ++
 1 file changed, 37 insertions(+), 28 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v2 2/2] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Julien Grall]

With livepatch the alternatives that should be patched are outside of
the Xen hypervisor _start -> _end. The current code is assuming that
only Xen could be patched and therefore will explode when a payload
contains alternatives.

Given that alt_instr contains a relative offset, the function
__apply_alternatives could directly take in parameter the virtual
address of the alt_instr set of the re-mapped region. So we can mandate
the callers of __apply_alternatives to provide use with a region that has
read-write access.

The only caller that will patch directly the Xen binary is the function
__apply_alternatives_multi_stop. The other caller apply_alternatives
will work on the payload which will still have read-write access at that
time.

Signed-off-by: Julien Grall 

---
Cc: Konrad Rzeszutek Wilk 

This is an alternative of the patch suggested by Konrad [1] to fix
alternatives patching with livepatching.

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02880.html

Changes in v2:
- Fix typoes
- Add a comment to details how __apply_alternative should be
called
- Clean-up the casting for region.begin and region.end
---
 xen/arch/arm/alternative.c | 65 ++
 1 file changed, 37 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 0ca97b9..7203bae 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -94,28 +94,18 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 return insn;
 }
 
+/*
+ * The region patched should be read-write to allow __apply_alternatives
+ * to replacing the instructions when necessary.
+ */
 static int __apply_alternatives(const struct alt_region *region)
 {
 const struct alt_instr *alt;
-const u32 *origptr, *replptr;
-u32 *writeptr, *writemap;
-mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
-unsigned int xen_order = get_order_from_bytes(_end - _start);
+const u32 *replptr;
+u32 *origptr;
 
-printk(XENLOG_INFO "alternatives: Patching kernel code\n");
-
-/*
- * The text and inittext section are read-only. So re-map Xen to be
- * able to patch the code.
- */
-writemap = __vmap(_mfn, 1 << xen_order, 1, 1, PAGE_HYPERVISOR,
-  VMAP_DEFAULT);
-if ( !writemap )
-{
-printk(XENLOG_ERR "alternatives: Unable to map the text section (size 
%u)\n",
-   1 << xen_order);
-return -ENOMEM;
-}
+printk(XENLOG_INFO "alternatives: Patching with alt table %p -> %p\n",
+   region->begin, region->end);
 
 for ( alt = region->begin; alt < region->end; alt++ )
 {
@@ -128,7 +118,6 @@ static int __apply_alternatives(const struct alt_region 
*region)
 BUG_ON(alt->alt_len != alt->orig_len);
 
 origptr = ALT_ORIG_PTR(alt);
-writeptr = origptr - (u32 *)_start + writemap;
 replptr = ALT_REPL_PTR(alt);
 
 nr_inst = alt->alt_len / sizeof(insn);
@@ -136,19 +125,17 @@ static int __apply_alternatives(const struct alt_region 
*region)
 for ( i = 0; i < nr_inst; i++ )
 {
 insn = get_alt_insn(alt, origptr + i, replptr + i);
-*(writeptr + i) = cpu_to_le32(insn);
+*(origptr + i) = cpu_to_le32(insn);
 }
 
 /* Ensure the new instructions reached the memory and nuke */
-clean_and_invalidate_dcache_va_range(writeptr,
- (sizeof (*writeptr) * nr_inst));
+clean_and_invalidate_dcache_va_range(origptr,
+ (sizeof (*origptr) * nr_inst));
 }
 
 /* Nuke the instruction cache */
 invalidate_icache();
 
-vunmap(writemap);
-
 return 0;
 }
 
@@ -159,10 +146,6 @@ static int __apply_alternatives(const struct alt_region 
*region)
 static int __apply_alternatives_multi_stop(void *unused)
 {
 static int patched = 0;
-const struct alt_region region = {
-.begin = __alt_instructions,
-.end = __alt_instructions_end,
-};
 
 /* We always have a CPU 0 at this point (__init) */
 if ( smp_processor_id() )
@@ -174,12 +157,38 @@ static int __apply_alternatives_multi_stop(void *unused)
 else
 {
 int ret;
+struct alt_region region;
+mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+unsigned int xen_order = get_order_from_bytes(_end - _start);
+void *xenmap;
 
 BUG_ON(patched);
+
+/*
+ * The text and inittext section are read-only. So re-map Xen to
+ * be able to patch the code.
+ */
+xenmap = __vmap(_mfn, 1U << xen_order, 1, 1, PAGE_HYPERVISOR,
+VMAP_DEFAULT);
+/* Re-mapping Xen is not expected to fail during boot. */
+BUG_ON(!xenmap);
+
+/*
+ * Find the virtual address of the alternative region in 

[Xen-devel] [PATCH v2 1/2] xen/arm: alternative: Clean-up __apply_alternatives

[Julien Grall]

This patch contains only renaming and comment update. There are no
functional changes:
- Don't mix _start and _stext, they both point to the same address
but the former makes more sense (we are mapping the Xen binary, not
only the text section).
- s/text_mfn/xen_mfn/ and s/text_order/xen_order/ to make clear that
we map the Xen binary.
- Mention about inittext as alternative may patch this section.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Julien Grall 

---
Konrad, I added your signed-off by because I squashed your patch [1]
in it. Let me know if there is any issue for that.

[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg02890.html

Changes in v2:
- Patch added
---
 xen/arch/arm/alternative.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..0ca97b9 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -99,21 +99,21 @@ static int __apply_alternatives(const struct alt_region 
*region)
 const struct alt_instr *alt;
 const u32 *origptr, *replptr;
 u32 *writeptr, *writemap;
-mfn_t text_mfn = _mfn(virt_to_mfn(_stext));
-unsigned int text_order = get_order_from_bytes(_end - _start);
+mfn_t xen_mfn = _mfn(virt_to_mfn(_start));
+unsigned int xen_order = get_order_from_bytes(_end - _start);
 
 printk(XENLOG_INFO "alternatives: Patching kernel code\n");
 
 /*
- * The text section is read-only. So re-map Xen to be able to patch
- * the code.
+ * The text and inittext section are read-only. So re-map Xen to be
+ * able to patch the code.
  */
-writemap = __vmap(_mfn, 1 << text_order, 1, 1, PAGE_HYPERVISOR,
+writemap = __vmap(_mfn, 1 << xen_order, 1, 1, PAGE_HYPERVISOR,
   VMAP_DEFAULT);
 if ( !writemap )
 {
 printk(XENLOG_ERR "alternatives: Unable to map the text section (size 
%u)\n",
-   1 << text_order);
+   1 << xen_order);
 return -ENOMEM;
 }
 
-- 
1.9.1


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

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

[anshul makkar]

On 05/09/16 14:47, Dario Faggioli wrote:

On Wed, 2016-08-31 at 18:10 +0100, anshul makkar wrote:

On 17/08/16 18:18, Dario Faggioli wrote:


@@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler
*ops, struct vcpu *vc, void *dd)
   ASSERT(svc->sdom != NULL);
   svc->credit = CSCHED2_CREDIT_INIT;
   svc->weight = svc->sdom->weight;
+svc->tickled_cpu = -1;
   /* Starting load of 50% */
   svc->avgload = 1ULL << (CSCHED2_PRIV(ops)-

load_precision_shift - 1);

   svc->load_last_update = NOW() >>
LOADAVG_GRANULARITY_SHIFT;
@@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct scheduler
*ops, struct vcpu *vc, void *dd)
   else
   {
   ASSERT(svc->sdom == NULL);
+svc->tickled_cpu = svc->vcpu->vcpu_id;

If I understood correctly, tickled_cpu refers to pcpu and not a
vcpu.
Saving vcpu_id in tickled_cpu looks wrong.


Yes, and in fact, as you can see in the previous hunk, for pretty much
all vcpus, tickled_cpu is initialized to -1.

Here, we are dealing with the vcpus of the idle domain. And for vcpus
of the idle domain, their vcpu id is the same as the id of the pcpu
they're associated to.

Ah, that makes it clear .


I agree it looks a little bit weird, but it's both correct, and the
easiest and cleanest way for initializing this.

I guess I can add a comment...

That will be useful.


Thanks and Regards,
Dario


Thanks
Anshul

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

Re: [Xen-devel] [PATCH v5 12/16] x86/efi: create new early memory allocator

[Daniel Kiper]

On Mon, Sep 05, 2016 at 06:33:57AM -0600, Jan Beulich wrote:
> >>> On 20.08.16 at 00:43,  wrote:

[...]

> > +static char __initdata *ebmalloc_free = NULL;
> > +
> > +/* EFI boot allocator. */
> > +static void __init *ebmalloc(size_t size)
> > +{
> > +void *ptr;
> > +
> > +/*
> > + * Init ebmalloc_free on runtime. Static initialization
> > + * will not work because it puts virtual address there.
> > + */
>
> I don't understand this static allocation comment: We have this issue
> elsewhere (and use bootsym() as needed), and we do not have this
> issue at all in xen.efi (which this code also gets built for). So I think at
> the very least the comment needs improvement. And then, if static
> initialization indeed can't be used, then a static symbol's initializer of
> NULL is pointless and hence should be omitted.

You have to remember that xen/arch/x86/efi/efi-boot.h stuff is build
into xen.efi and xen.gz. Of course xen.efi with

static char __initdata *ebmalloc_free = ebmalloc_mem;

works, however, xen.gz does not. Sadly, I have not found simpler
solution for that issue, so, I do initialization during runtime.

> > +if ( ebmalloc_free == NULL )
> > +ebmalloc_free = ebmalloc_mem;
> > +
> > +ptr = ebmalloc_free;
> > +
> > +ebmalloc_free += size;
>
> No minimal (at least pointer size) alignment getting enforced
> somewhere here?

For what?

> > +void __init free_ebmalloc_unused_mem(void)
> > +{
> > +unsigned long start, end;
> > +
> > +if ( ebmalloc_free )
> > +{
> > +start = (unsigned long)ebmalloc_free - xen_phys_start;
> > +start = PAGE_ALIGN(start + XEN_VIRT_START);
> > +}
> > +else
> > +start = (unsigned long)ebmalloc_mem;
> > +
> > +end = (unsigned long)ebmalloc_mem + sizeof(ebmalloc_mem);
> > +
> > +destroy_xen_mappings(start, end);
> > +init_xenheap_pages(__pa(start), __pa(end));
> > +
> > +printk("Freed %lukB unused BSS memory\n", (end - start) >> 10);
>
> XENLOG_INFO

OK.

> And then - wouldn't this better go into xen/common/efi/boot.c,
> even if ARM64 does not have a use for it right away? The code
> certainly isn't really x86-specific.

Sure thing. However, if it is not used by ARM64 then I think ebmalloc
stuff should not be moved to xen/common/efi/boot.c.

Daniel

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt 3 host-install(3) broken in 100770 pass in 100777
 test-amd64-amd64-i386-pvgrub 9 debian-di-install fail in 100770 pass in 100777
 test-amd64-amd64-qemuu-nested-intel 12 xen-install/l1 fail in 100770 pass in 
100777
 test-amd64-i386-qemuu-rhel6hvm-amd 11 guest-start/redhat.repeat fail in 100770 
pass in 100777
 test-amd64-i386-xl-qemut-winxpsp3 15 guest-localmigrate/x10 fail in 100770 
pass in 100777
 test-amd64-i386-xl-raw 18 guest-start/debian.repeat fail in 100770 pass in 
100777
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
100770 pass in 100777
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail pass in 100770
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat  fail pass in 100770

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

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

version targeted for testing:
 xen  dbeb5da648b146339ec49375f2759263fe7ccdc2
baseline version:
 xen  80bc4350bbd13b6c34371f4ff8b8199674906df6

Last test of basis   100635  2016-08-26 14:15:15 Z   11 days
Testing same since   100770  2016-09-06 13:09:07 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Feng Wu 

Re: [Xen-devel] [PATCH] xen/arm: alternative: Make it possible to patch outside of the hypervisor

[Julien Grall]

Hi Konrad,

On 07/09/2016 04:06, Konrad Rzeszutek Wilk wrote:

---
 xen/arch/arm/alternative.c | 58 +-
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..db4bd0f 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -97,26 +97,11 @@ static u32 get_alt_insn(const struct alt_instr *alt,
 static int __apply_alternatives(const struct alt_region *region)
 {
 const struct alt_instr *alt;
-const u32 *origptr, *replptr;
-u32 *writeptr, *writemap;
-mfn_t text_mfn = _mfn(virt_to_mfn(_stext));
-unsigned int text_order = get_order_from_bytes(_end - _start);
+const u32 *replptr;
+u32 *origptr;

 printk(XENLOG_INFO "alternatives: Patching kernel code\n");


This is still there. Should it be "Patching %p->%p code" instead?


I will replace by
printk(XENLOG_INFO "alternatives: alt table %p -> %p", region->begin, 
region->end);


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Vitaly Kuznetsov]

Julien Grall  writes:

> Hi Vitaly,
>
> On 07/09/2016 10:07, Vitaly Kuznetsov wrote:
>> Stefano Stabellini  writes:
>>> I don't know that much about cpuid, but the virtual MPIDR is constructed
>>> from the vcpu id right now:
>>>
>>> v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);
>>>
>>> [...]
>>>
>>> static inline register_t vcpuid_to_vaffinity(unsigned int vcpuid)
>>> {
>>> register_t vaff;
>>>
>>> vaff = (vcpuid & 0x0f) << MPIDR_LEVEL_SHIFT(0);
>>> vaff |= ((vcpuid >> 4) & MPIDR_LEVEL_MASK) << MPIDR_LEVEL_SHIFT(1);
>>>
>>> return vaff;
>>> }
>>
>> This could work but only in case there is a way to get MPIDR for _other_
>> cpu (e.g. CPU0 needs to get MPIDR of CPU1 when CPU1 is not yet runnning)
>> or we'll have to change the machinery of how we bring up secondary CPUs
>> - e.g. CPUn starts, writes its id somewhere and 'hangs' waiting for CPU0
>> to set up event channels.
>
> You can get the MPIDR from both the device tree and ACPI. The firmware
> table is parsed at boot time and the value is stored in
> cpu_logical_map().

Good,

in this case we can easily do the same trick we did for x86 and we
don't need to change the way secondary CPUs are strarted.

BTW, were you able to try the patch I suggested? In my opinion it would
be preferable to fix the immediate SMP issue now and play with MPIDR
info later.

>
> Regards,

-- 
  Vitaly

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

Re: [Xen-devel] missing unplug of SCSI devices in HVM guest

[Paul Durrant]

> -Original Message-
> From: Olaf Hering [mailto:o...@aepfle.de]
> Sent: 07 September 2016 11:49
> To: Paul Durrant ; George Dunlap
> 
> Cc: xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] missing unplug of SCSI devices in HVM guest
> 
> Am 7. September 2016 12:38:09 MESZ, schrieb Paul Durrant
> :
> 
> >I would have thought option #1 is the most logical and desirable in the
> >long run, but #2 could perhaps be used (by means of a configuration
> >option to qemu) in the meantime. In practice I doubt there is anything
> >out there that would use emulated SCSI as well as PV storage.
> 
> The qemu changes I sent earlier this month implement #2. And my testing
> shows there will be no loss.
> 

Ok. I guess #1 could be implemented later if it proves necessary in some 
circumstances.

  Paul

> Emulated SCSI has the benefit that loading kernel+initrd is faster.
> 

With seabios I'd certainly believe it. The IDE emulation is PIO only (unless 
you hack the config ... which I tend to do).

  Paul

> Olaf

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

Re: [Xen-devel] missing unplug of SCSI devices in HVM guest

[Olaf Hering]

Am 7. September 2016 12:38:09 MESZ, schrieb Paul Durrant 
:

>I would have thought option #1 is the most logical and desirable in the
>long run, but #2 could perhaps be used (by means of a configuration
>option to qemu) in the meantime. In practice I doubt there is anything
>out there that would use emulated SCSI as well as PV storage.

The qemu changes I sent earlier this month implement #2. And my testing shows 
there will be no loss.

Emulated SCSI has the benefit that loading kernel+initrd is faster.

Olaf 


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

Re: [Xen-devel] [PATCH v2 13/20] livepatch: Initial ARM64 support.

[Julien Grall]

On 07/09/2016 04:33, Konrad Rzeszutek Wilk wrote:

...snip..

+case R_AARCH64_ABS32:
+ovf = reloc_data(RELOC_OP_ABS, dest, val, 32);
+break;


I have noticed that not all the relocations are implemented (e.g
R_AARCH64_ABS16, R_AARCH64_MOVW_*...). I don't think there is anything
preventing the compiler to use them. So is there any particular reasons to
not include them?


I followed the same principle Ross did on x86 - only implement the ones that
the compiler has generated. And that is what I initially had in the v1, but 
expanded
it per request.

I can include more, but at what point should I stop?


Good question. My question was more, would it ever be possible to be 
generated by the same compiler when applying a patch?





 xen/arch/arm/arm64/livepatch.c   |  140 +++
 xen/include/xen/elfstructs.h |   23 ++

lines later and I added them all in.



--
Julien Grall

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

[Xen-devel] [PATCH v6 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Paulina Szubarczyk]

Copy data operated on during request from/to local buffers to/from
the grant references.

Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.

A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.

Signed-off-by: Paulina Szubarczyk 
---
Changes since v5:
-added checking of every interface in the configure file. Based on
 the Roger's comment that xengnttab_map_grant_ref was added prior
 xengnttab_grant_copy, thus do not need to be check again here
 I dropped this check.
 
---
 configure   |  55 
 hw/block/xen_disk.c | 157 ++--
 include/hw/xen/xen_common.h |  14 
 3 files changed, 221 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 4b808f9..3f44d38 100755
--- a/configure
+++ b/configure
@@ -1956,6 +1956,61 @@ EOF
 /*
  * If we have stable libs the we don't want the libxc compat
  * layers, regardless of what CFLAGS we may have been given.
+ *
+ * Also, check if xengnttab_grant_copy_segment_t is defined and
+ * grant copy operation is implemented.
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
+int main(void) {
+  xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
+  xen_domain_handle_t handle;
+  xengnttab_grant_copy_segment_t* seg = NULL;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
+  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_grant_copy(xg, 0, seg);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs $xen_stable_libs"
+then
+xen_ctrl_version=480
+xen=yes
+  elif
+  cat > $TMPC <= 480
+
+static void free_buffers(struct ioreq *ioreq)
+{
+int i;
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = NULL;
+}
+
+qemu_vfree(ioreq->pages);
+}
+
+static int ioreq_init_copy_buffers(struct ioreq *ioreq)
+{
+int i;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+ioreq->pages = qemu_memalign(XC_PAGE_SIZE, ioreq->v.niov * XC_PAGE_SIZE);
+
+for (i = 0; i < ioreq->v.niov; i++) {
+ioreq->page[i] = ioreq->pages + i * XC_PAGE_SIZE;
+ioreq->v.iov[i].iov_base = ioreq->page[i];
+}
+
+return 0;
+}
+
+static int ioreq_copy(struct ioreq *ioreq)
+{
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_grant_copy_segment_t segs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
+int i, count, rc;
+int64_t file_blk = ioreq->blkdev->file_blk;
+
+if (ioreq->v.niov == 0) {
+return 0;
+}
+
+count = ioreq->v.niov;
+
+for (i = 0; i < count; i++) {
+
+if (ioreq->req.operation == BLKIF_OP_READ) {
+segs[i].flags = GNTCOPY_dest_gref;
+segs[i].dest.foreign.ref = ioreq->refs[i];
+segs[i].dest.foreign.domid = ioreq->domids[i];
+segs[i].dest.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].source.virt = ioreq->v.iov[i].iov_base;
+} else {
+segs[i].flags = GNTCOPY_source_gref;
+segs[i].source.foreign.ref = ioreq->refs[i];
+segs[i].source.foreign.domid = ioreq->domids[i];
+segs[i].source.foreign.offset = ioreq->req.seg[i].first_sect * 
file_blk;
+segs[i].dest.virt = ioreq->v.iov[i].iov_base;
+}
+segs[i].len = (ioreq->req.seg[i].last_sect
+   - ioreq->req.seg[i].first_sect + 1) * file_blk;
+
+}
+
+rc = xengnttab_grant_copy(gnt, count, segs);
+
+if (rc) {
+xen_be_printf(>blkdev->xendev, 0,
+  "failed to copy data %d\n", rc);
+ioreq->aio_errors++;
+return -1;
+}
+
+for (i = 0; i < count; i++) {
+if (segs[i].status != GNTST_okay) {
+xen_be_printf(>blkdev->xendev, 3,
+  "failed to copy data %d for gref %d, domid %d\n",
+  segs[i].status, ioreq->refs[i], ioreq->domids[i]);
+ioreq->aio_errors++;
+   

Re: [Xen-devel] [PATCH v2 13/20] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 07/09/2016 01:31, Konrad Rzeszutek Wilk wrote:

+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+/* Save old one. */
+old_ptr = func->old_addr;
+memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);


I don't see any value to use a temporary variable (old_ptr) to hold
func->old_addr here.


+
+if ( func->new_addr )
+insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
+   (unsigned long)func->new_addr,
+   AARCH64_INSN_BRANCH_NOLINK);
+else
+insn = aarch64_insn_gen_nop();
+
+ASSERT(insn != AARCH64_BREAK_FAULT);


Could you document in the code what prevents aarch64_insn_gen_branch_imm to
not generate a break fault instruction?


In the excitment of getting ARM32 implementation working - forgot
to write the code that would have done the check for all the platforms
(32MB for ARM, 128MB for ARM64, and 2GB on x86).

It will be an followup patch, like so (compile tested):

From 508157d81eaacab7ff621a84d7d885fb1bf689cc Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Tue, 6 Sep 2016 20:14:18 -0400
Subject: [PATCH] livepatch: ARM/x86: Check range of old_addr between new_addr

If the distance is too great we are in trouble - as our relocation
distance can surely be clipped, or still have a valid width - but
cause an overflow of distance.

On various architectures the maximum displacement for a branch/jump
varies. ARM32 is +/- 32MB, ARM64 is +/- 128MB while x86 for 32-bit
relocations is +/- 2G.


It would be worth noting that the ARM64 and ARM32 displacement are only 
valid for unconditional branch (conditional one supports a smaller 
displacement). And livepatch is only using unconditional branch.




[Note: On x86 we could use the 64-bit jmpq instruction which
would provide much bigger displacement to do a jump, but we would
still have issues with the new function not being able to reach
any of the old functions (as all the relocations would assume 32-bit
displacement)].

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v3: New submission.
---
 xen/arch/arm/arm64/livepatch.c  |  1 +
 xen/common/livepatch.c  |  4 
 xen/include/asm-arm/livepatch.h |  8 
 xen/include/asm-x86/livepatch.h | 23 +++
 xen/include/xen/livepatch.h | 18 +-
 5 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/asm-x86/livepatch.h

diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index e4d2926..27a68ab 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -35,6 +35,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 else
 insn = aarch64_insn_gen_nop();

+/* Verified in arch_livepatch_verify_distance. */
 ASSERT(insn != AARCH64_BREAK_FAULT);
 new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 86232b8..1ba6ca9 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -587,6 +587,10 @@ static int prepare_payload(struct payload *payload,
 rc = resolve_old_address(f, elf);
 if ( rc )
 return rc;
+
+rc = arch_livepatch_verify_distance(f);
+if ( rc )
+return rc;
 }

 sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
diff --git a/xen/include/asm-arm/livepatch.h b/xen/include/asm-arm/livepatch.h
index 8c8d625..b1806d0 100644
--- a/xen/include/asm-arm/livepatch.h
+++ b/xen/include/asm-arm/livepatch.h
@@ -6,6 +6,8 @@
 #ifndef __XEN_ARM_LIVEPATCH_H__
 #define __XEN_ARM_LIVEPATCH_H__

+#include  /* For SZ_* macros. */
+
 /* On ARM32,64 instructions are always 4 bytes long. */
 #define PATCH_INSN_SIZE 4

@@ -15,6 +17,12 @@
  */
 extern void *vmap_of_xen_text;

+#ifdef CONFIG_ARM_32
+#define LIVEPATCH_ARCH_RANGE SZ_32M
+#else
+#define LIVEPATCH_ARCH_RANGE SZ_128M
+#endif


Sorry for been picky, can you document where these values come from:

- ARM32: A4.3 IN ARM DDI 0406C.j and we are using only ARM instruction 
in Xen.

- ARM64: C1.3.2 in ARM DDI 0487A.j

It might also be worth to mention that this is only valid for 
unconditional branch.


The rest looks good to me.


+
 #endif /* __XEN_ARM_LIVEPATCH_H__ */



Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable-coverity test] 100788: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  d6be2cfccfffd6d5ff1da68277ec3ab13e595368
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100750  2016-09-04 09:19:37 Z3 days
Testing same since   100788  2016-09-07 09:19:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  George Dunlap 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Luwei Kang 
  Marek Marczykowski-Górecki 
  Olaf Hering 
  Razvan Cojocaru 
  Stefano Stabellini 
  Tamas K Lengyel 
  Wei Liu 

jobs:
 coverity-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=xen-unstable-coverity
+ revision=d6be2cfccfffd6d5ff1da68277ec3ab13e595368
+ . ./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-coverity d6be2cfccfffd6d5ff1da68277ec3ab13e595368
+ branch=xen-unstable-coverity
+ revision=d6be2cfccfffd6d5ff1da68277ec3ab13e595368
+ . ./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-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' xd6be2cfccfffd6d5ff1da68277ec3ab13e595368 = 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/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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git

[Xen-devel] [PATCH v6 1/2] libs/gnttab: introduce grant copy interface

[Paulina Szubarczyk]

In a linux part an ioctl(gntdev, IOCTL_GNTDEV_GRANT_COPY, ..)
system call is invoked. In mini-os the operation is yet not
implemented. For the OSs that does not implement gnttab the
call of the grant copy operation causes abort.

Signed-off-by: Paulina Szubarczyk 
Reviewed-by: David Vrabel 

---
 tools/include/xen-sys/Linux/gntdev.h  | 21 ++
 tools/libs/gnttab/Makefile|  2 +-
 tools/libs/gnttab/gnttab_core.c   |  6 +++
 tools/libs/gnttab/gnttab_unimp.c  |  6 +++
 tools/libs/gnttab/include/xengnttab.h | 28 +
 tools/libs/gnttab/libxengnttab.map|  5 +++
 tools/libs/gnttab/linux.c | 77 +++
 tools/libs/gnttab/minios.c|  6 +++
 tools/libs/gnttab/private.h   |  4 ++
 9 files changed, 154 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/gntdev.h 
b/tools/include/xen-sys/Linux/gntdev.h
index caf6fb4..0ca07c9 100644
--- a/tools/include/xen-sys/Linux/gntdev.h
+++ b/tools/include/xen-sys/Linux/gntdev.h
@@ -147,4 +147,25 @@ struct ioctl_gntdev_unmap_notify {
 /* Send an interrupt on the indicated event channel */
 #define UNMAP_NOTIFY_SEND_EVENT 0x2
 
+struct ioctl_gntdev_grant_copy_segment {
+union {
+void *virt;
+struct {
+uint32_t ref;
+uint16_t offset;
+uint16_t domid;
+} foreign;
+} source, dest;
+uint16_t len;
+uint16_t flags;
+int16_t status;
+};
+
+#define IOCTL_GNTDEV_GRANT_COPY \
+_IOC(_IOC_NONE, 'G', 8, sizeof(struct ioctl_gntdev_grant_copy))
+struct ioctl_gntdev_grant_copy {
+unsigned int count;
+struct ioctl_gntdev_grant_copy_segment *segments;
+};
+
 #endif /* __LINUX_PUBLIC_GNTDEV_H__ */
diff --git a/tools/libs/gnttab/Makefile b/tools/libs/gnttab/Makefile
index af64542..95c2cd8 100644
--- a/tools/libs/gnttab/Makefile
+++ b/tools/libs/gnttab/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 0
+MINOR= 1
 SHLIB_LDFLAGS += -Wl,--version-script=libxengnttab.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/gnttab/gnttab_core.c b/tools/libs/gnttab/gnttab_core.c
index 5d0474d..968c833 100644
--- a/tools/libs/gnttab/gnttab_core.c
+++ b/tools/libs/gnttab/gnttab_core.c
@@ -113,6 +113,12 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count)
 return osdep_gnttab_unmap(xgt, start_address, count);
 }
 
+int xengnttab_grant_copy(xengnttab_handle *xgt,
+ uint32_t count,
+ xengnttab_grant_copy_segment_t *segs)
+{
+return osdep_gnttab_grant_copy(xgt, count, segs);
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/gnttab/gnttab_unimp.c b/tools/libs/gnttab/gnttab_unimp.c
index b3a4a20..829eced 100644
--- a/tools/libs/gnttab/gnttab_unimp.c
+++ b/tools/libs/gnttab/gnttab_unimp.c
@@ -78,6 +78,12 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count)
 abort();
 }
 
+int xengnttab_copy_grant(xengnttab_handle *xgt,
+ uint32_t count,
+ xengnttab_copy_grant_segment_t *segs)
+{
+abort();
+}
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/gnttab/include/xengnttab.h 
b/tools/libs/gnttab/include/xengnttab.h
index 0431dcf..35be6c1 100644
--- a/tools/libs/gnttab/include/xengnttab.h
+++ b/tools/libs/gnttab/include/xengnttab.h
@@ -258,6 +258,34 @@ int xengnttab_unmap(xengnttab_handle *xgt, void 
*start_address, uint32_t count);
 int xengnttab_set_max_grants(xengnttab_handle *xgt,
  uint32_t nr_grants);
 
+struct xengnttab_grant_copy_segment {
+union xengnttab_copy_ptr {
+void *virt;
+struct {
+uint32_t ref;
+uint16_t offset;
+uint16_t domid;
+} foreign;
+} source, dest;
+uint16_t len;
+uint16_t flags;
+int16_t status;
+};
+
+typedef struct xengnttab_grant_copy_segment xengnttab_grant_copy_segment_t;
+
+/**
+ * Copy memory from or to grant references. The information of each operations
+ * are contained in 'xengnttab_grant_copy_segment_t'. The @flag value indicate
+ * the direction of an operation (GNTCOPY_source_gref\GNTCOPY_dest_gref).
+ *
+ * For each segment, @virt may cross a page boundary but @offset + @len
+ * must not exceed XEN_PAGE_SIZE.
+ */
+int xengnttab_grant_copy(xengnttab_handle *xgt,
+ uint32_t count,
+ xengnttab_grant_copy_segment_t *segs);
+
 /*
  * Grant Sharing Interface (allocating and granting pages to others)
  */
diff --git a/tools/libs/gnttab/libxengnttab.map 
b/tools/libs/gnttab/libxengnttab.map
index dc737ac..f78da22 100644
--- a/tools/libs/gnttab/libxengnttab.map
+++ b/tools/libs/gnttab/libxengnttab.map
@@ -21,3 +21,8 @@ VERS_1.0 {
xengntshr_unshare;
local: *; /* Do not expose 

[Xen-devel] [PATCH v6 0/2] qemu-qdisk: Implementation of grant copy operation.

[Paulina Szubarczyk]

Hi,

It is a proposition for implementation of grant copy operation in qemu-qdisk 
and interface in libxc/libs. 

Changes since v5:
-added checking of every interface in the configure file. Based on
 the Roger's comment that xengnttab_map_grant_ref was added prior
 xengnttab_grant_copy, thus do not need to be check again here
 I dropped this check.

Changes since v4:
Interface:
- changed the subject line
- changed the comment in libs/gnttab/include/xengnttab.h according
  to the David's suggestion.
- removed unnecessary braces.

qemu-qdisk:
- in the configure file check only if xengnttab_grant_copy is
  implemented to verify 480 version of Xen.
- remove r variable and initialization of count to 0 in
  ioreq_copy.

- surround free_buffers, ioreq_init_copy_buffers and ioreq_copy
  by "#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 480" abort in else
  path because the function should not be called in that case.
- replace the definition of struct xengnttab_grant_copy_segment
  and a typedef to it with
  'typedef void* xengnttab_grant_copy_segment_t'.
- moved the new code in the xen_common.h to the end of the file.

Changes since v3:
Interface:
- revert to cast from xengnttab_grant_copy_segment_t
  to ioctl_gntdev_grant_copy.
- added compile-time check to compare the libs
  xengnttab_grant_copy_segment_t with the ioctl structure.
  The patch relies on Wei patch introducing XENGNTTAB_BUILD_BUG_ON in 
libs/gnttab.

qemu-qdisk:
- qemu_memalign/qemu_free is used instead function allocating
  memory from xc.
- removed the get_buffer function instead there is a direct call
  to qemu_memalign.
- moved ioreq_copy for write operation to ioreq_runio_qemu_aio.
- added struct xengnttab_grant_copy_segment_t and stub in
  xen_common.h for version of Xen earlier then 480.
- added checking for version 480 to configure. The test repeats
  all the operation that are required for version < 480 and
  checks if xengnttab_grant_copy() is implemented.

Changes since v2:
Interface:
- dropped the changes in libxc/include/xenctrl_compat
- changed the MINOR version in Makefile
- replaced 'return -1' -> 'abort()'in libs/gnttab/gnttab_unimp.c
- moved the struct 'xengnttab_copy_grant_segment' to 
  libs/gnttab/include/xengnttab.h
- added explicit assingment to ioctl_gntdev_grant_copy_segment 
  to the linux part

qemu-qdisk:
- to use the xengnttab_* function directly added -lxengnttab to configure
  and include  in include/hw/xen/xen_common.h
- in ioreq_copy removed an out path, changed a log level, made explicit 
  assignement to 'xengnttab_copy_grant_segment'
* I did not change the way of testing if grant_copy operation is implemented.
  As far as I understand if the code from gnttab_unimp.c is used then the 
gnttab 
  device is unavailable and the handler to gntdev would be invalid. But 
  if the handler is valid then the ioctl should return operation unimplemented 
  if the gntdev does not implement the operation.


Changes since v1:
Interface:
- changed the interface to call grant copy operation to match ioctl
int xengnttab_grant_copy(xengnttab_handle *xgt,
 uint32_t count,
 xengnttab_grant_copy_segment_t* segs)

- added a struct 'xengnttab_copy_grant_segment' definition to tools/libs
  /gnttab/private.h, tools/libxc/include/xenctrl_compat.h

- changed the function 'osdep_gnttab_grant_copy' which right now just
  call the ioctl

- added a new VER1.1 to tools/libs/gnttab/libxengnttab.map 

qemu-qdisk:
- removed the 'ioreq_write','ioreq_read_init','ioreq_read' functions 
- implemented 'ioreq_init_copy_buffers', 'ioreq_copy' 
- reverted the removal of grant map and introduced conditional invoking
  grant copy or grant map
- resigned from caching the local buffers on behalf of allocating the 
  required amount of pages at once. The cached structure would require 
  to have an lock guard and I suppose that the performance improvement 
  would degraded. 
 

For the functional test I attached the device with a qdisk backend to the 
guest, mounted, performed some reads and writes.

I run fio tests[1] with different iodepth and size of the block. The test can 
be 
accessed on my github[2] but mainly after the warm up I run for 60 seconds:
fio --time_based \
--clocksource=clock_gettime \
--rw=randread \
--random_distribution=pareto:0.9 \
--size=10g \
--direct='1' \
--ioengine=libaio \
--filename=$DEV \
--iodepth=$IODEPTH \
--bs=$BS \
--name=$NAME \
--runtime=$RUNTIME >> $FILENAME
The test were repeated at least three times. 

[1] 
https://docs.google.com/spreadsheets/d/1E6AMiB8ceJpExL6jWpH9u2yy6DZxzhmDUyFf-eUuJ0c/edit?usp=sharing

[2] https://github.com/paulina-szubarczyk/xen-benchmark
- multitest_with_iodepth.sh


Thanks and regards, 
Paulina

___

Re: [Xen-devel] missing unplug of SCSI devices in HVM guest

[Paul Durrant]

> -Original Message-
> From: dunl...@gmail.com [mailto:dunl...@gmail.com] On Behalf Of
> George Dunlap
> Sent: 06 September 2016 17:42
> To: Olaf Hering ; Paul Durrant 
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] missing unplug of SCSI devices in HVM guest
> 
> On Wed, Aug 24, 2016 at 10:24 AM, Olaf Hering  wrote:
> > Does anyone remember why the the vbd frontend drivers also claim the
> > SCSI disks, but the vbd backend in qemu has no unplug support for SCSI?
> >
> > The current situation for qemu-xen and qemu-xen-traditional is that
> > both will create an emulated LSI controller with disk=[vdev=sda]. The
> > xenlinux and pvops frontend drivers will claim the disk, but the
> > sym53c8xx will see and claim it as well. As a result each disk is
> > visible twice. One has to blacklist the sym53c8xx driver to avoid that.
> >
> > What should be done to fix this?
> > #1 new unplug protocol for SCSI, but old guests dont know about it
> > #2 reuse IDE flag to also unplug SCSI. This would cover pvops and guests
> >where xenlinux based xen-platform-pci.ko is loaded before
> >sym53c8xx.ko. It would break guests with frontend drivers that do not
> >claim SCSI disks, the SCSI disk would disappear (if such frontends
> >really exist).
> > #3 do not provide SCSI if guest has PV drivers
> 
> I think #3 was has been done in practice, but obviously not enforced by the
> toolstack -- i.e., "Doctor, it hurts when I do this  motion>."  "Then don't do that."
> 
> The problem with enforcing #3 is that there's no real way for the toolstack to
> know if the guest will have PV drivers before booting.
> 
> There's also #4: Do not provide a PV backend for SCSI disks.  Not sure that's
> actually possible, as libxl has historically used the PV backend as the 
> canonical
> place for listing disks associated with a domain (although that may have
> changed since XSA-whatever which resulted in libxl having its own local copy
> of the backend information).
> 
> Paul, do you have any thoughts?
> 

I agree that #3 is not practical.

I would have thought option #1 is the most logical and desirable in the long 
run, but #2 could perhaps be used (by means of a configuration option to qemu) 
in the meantime. In practice I doubt there is anything out there that would use 
emulated SCSI as well as PV storage.

  Paul

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

Re: [Xen-devel] Failed vm entry with heavy use of emulator

[Jan Beulich]

>>> On 07.09.16 at 07:59,  wrote:
> On 09/07/16 02:31, Tamas K Lengyel wrote:
>> Just a quick update on this issue, I also now see the following
>> emulation error when I use xen-access with the emulation response for
>> the exec case. The issue previously reported with the failed vm entry
>> seem to happen only when emulating in response to the write-access.
>> 
>> (XEN) Mem event emulation failed: d5v1 32bit @ 0008:826c602c -> 0f 21
>> c0 89 82 dc 02 00 00 0f 21 c8 89 82 e0 02
>> (XEN) Mem event emulation failed: d5v0 32bit @ 0008:82678caa -> cf 90
>> f7 45 70 00 00 02 00 75 09 f7 45 6c 01 00
>> (XEN) d5v1 Triple fault - invoking HVM shutdown action
>> (XEN) *** Dumping Dom5 vcpu#1 state: ***
>> (XEN) [ Xen-4.7.0  x86_64  debug=n  Not tainted ]
>> (XEN) CPU:6
>> (XEN) RIP:0008:[<827194f8>]
>> (XEN) RFLAGS: 00014292   CONTEXT: hvm guest (d5v1)
>> (XEN) rax: badb10cc   rbx: 807c1534   rcx: 
>> (XEN) rdx:    rsi: 8271957f   rdi: badb10cc
>> (XEN) rbp: 807c10e4   rsp: 807c0d30   r8:  
>> (XEN) r9:     r10:    r11: 
>> (XEN) r12:    r13:    r14: 
>> (XEN) r15:    cr0: 8001003b   cr4: 000406f9
>> (XEN) cr3: 00185000   cr2: 807c0d2c
>> (XEN) ds: 0023   es: 0023   fs: 0030   gs:    ss: 0010   cs: 0008
> 
> I see that there were two failed emulation attempts previously (most
> likely there's no support in the emulator for the listed instructions).

The first one would have support in the emulator (it's a DR0 access),
if the read_dr() hook was set (which it looks like isn't the case, but
should be easy to fix).

The second one (IRET) currently gets handled by the emulator only
when the guest is in real mode.

Jan


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

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Julien Grall]

Hi Vitaly,

On 07/09/2016 10:07, Vitaly Kuznetsov wrote:

Stefano Stabellini  writes:

I don't know that much about cpuid, but the virtual MPIDR is constructed
from the vcpu id right now:

v->arch.vmpidr = MPIDR_SMP | vcpuid_to_vaffinity(v->vcpu_id);

[...]

static inline register_t vcpuid_to_vaffinity(unsigned int vcpuid)
{
register_t vaff;

vaff = (vcpuid & 0x0f) << MPIDR_LEVEL_SHIFT(0);
vaff |= ((vcpuid >> 4) & MPIDR_LEVEL_MASK) << MPIDR_LEVEL_SHIFT(1);

return vaff;
}


This could work but only in case there is a way to get MPIDR for _other_
cpu (e.g. CPU0 needs to get MPIDR of CPU1 when CPU1 is not yet runnning)
or we'll have to change the machinery of how we bring up secondary CPUs
- e.g. CPUn starts, writes its id somewhere and 'hangs' waiting for CPU0
to set up event channels.


You can get the MPIDR from both the device tree and ACPI. The firmware 
table is parsed at boot time and the value is stored in cpu_logical_map().


Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100738
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100751
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100751
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100751
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100751
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100751

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

version targeted for testing:
 xen  343f84be135e6f9e681960a9e235296eae159fc8
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100751  2016-09-05 01:59:33 Z2 days
Testing same since   100766  2016-09-05 17:18:59 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  He Chen 
  Ian Jackson 
  Jan Beulich 
  Luwei Kang 
  Marek Marczykowski-Górecki 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 1/1] xen: move TLB-flush filtering out into populate_physmap

[Jan Beulich]

>>> On 07.09.16 at 10:28,  wrote:
> On Wed, Sep 07, 2016 at 12:02:33AM -0700, Dongli Zhang wrote:
>> > But since what Dongli cares about at the moment is domain creation, it
>> > certainly won't hurt to limit this optimization to domain creation time;
>> > then we can discuss enabling it for ballooning when someone finds it to
>> > be an issue.
>> 
>> Thank you all very much for the feedback. The current limitation only
>> impacts vm creation time unless someone would balloon 100+GB memory.
>> 
>> To limit this optimization to domain creation time, how do you think if we
>> add the following rules to xen and toolstack? Are the rules reasonable?
>> 
>> Rule 1. It is toolstack's responsibility to set the "MEMF_no_tlbflush" bit
>> in memflags. The toolstack developers should be careful that
>> "MEMF_no_tlbflush" should never be used after vm creation is finished.
>> 
> 
> Is it possible to have a safety catch for this in the hypervisor? In
> general IMHO we should avoid providing an interface that is possible to
> create a security problem.
> 
>> Rule 2. xen should check at hypervisor level that MEMF_no_tlbflush is
>> allowed to be set only when current populate_physmap operation is initiated
>> by dom0.  Otherwise, MEMF_no_tlbflush should be masked in memflags if ( d
>> == curr_d && d->domain_id != 0 ). Therefore, this patch would not impact
>> the security of memory ballooning operations.
>> 
> 
> Really this reads as some sort of (incomplete) safety check.
> 
> We don't need Rule 1 if the hypervisor knows when or who is allowed to
> use that flag. I understand there might be difficulty in achieving that
> though.

We could set a flag on a domain the first time it gets scheduled.

>> @@ -150,6 +152,11 @@ static void populate_physmap(struct memop_args *a)
>>  max_order(curr_d)) )
>>  return;
>>  
>> +/* MEMF_no_tlbflush is masked out if current populate_physmap operation 
>> is
>> + * not initiated by dom0 */
>> +if ( d == curr_d && d->domain_id != 0 )
>> +a->memflags &= ~MEMF_no_tlbflush;
>> +
> 
> This check is incomplete. Please take into account a scenario in which a
> domain builder domain is used.

Nor is it okay for Dom0 to use it on itself.

Jan


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

Re: [Xen-devel] [PATCH v4 1/9] livepatch: Clear .bss when payload is reverted

[Jan Beulich]

>>> On 06.09.16 at 18:51,  wrote:
> --- a/xen/common/livepatch_elf.c
> +++ b/xen/common/livepatch_elf.c
> @@ -86,7 +86,16 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
> const void *data)
>  delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
> end");
>  return -EINVAL;
>  }
> -
> +else if ( !(sec[i].sec->sh_flags & SHF_EXECINSTR) &&
> +  (sec[i].sec->sh_flags & SHF_WRITE) &&
> +  sec[i].sec->sh_type == SHT_NOBITS &&
> +  sec[i].sec->sh_size > MB(2) )

What good do the two sh_flags checks do here?

Jan


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

[Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for each call, and triggering a TLB flush per page set.

Signed-off-by: Razvan Cojocaru 
Acked-by: Wei Liu 

---
Changes since V3:
 - Fixed ARM compilation (replaced ENOTSUP with EOPNOTSUPP, which is
   #defined in the in-tree errno.h). The multi code remains
   unimplemented for ARM (it depends on " [RFC 21/22] xen/arm: p2m:
   Re-implement p2m_set_mem_access using p2m_{set, get}_entry", and
   Julien Grall has gracefully accepted to defer implementation
   until after both patches go in).
 - Reordered the xen/guest_access.h #include in p2m.c.
 - Now passing a gfn_t to set_mem_access() instead of unsigned long.
 - Removed the p2m prefix from p2m_xenmem_access_to_p2m_access().
 - Switched from bool_t to bool.
 - Moved the XENMEM_access_op case up with the other do-nothing
   XENMEM_* cases.
---
 tools/libxc/include/xenctrl.h |   9 +++
 tools/libxc/xc_mem_access.c   |  38 +++
 xen/arch/arm/p2m.c|  10 +++
 xen/arch/x86/mm/p2m.c | 150 --
 xen/common/compat/memory.c|  23 +--
 xen/common/mem_access.c   |  11 
 xen/include/public/memory.h   |  14 +++-
 xen/include/xen/p2m-common.h  |   6 ++
 xen/include/xlat.lst  |   2 +-
 9 files changed, 224 insertions(+), 39 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..5e685a6 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2126,6 +2126,15 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
   uint32_t nr);
 
 /*
+ * Set an array of pages to their respective access in the access array.
+ * The nr parameter specifies the size of the pages and access arrays.
+ * The same allowed access types as for xc_set_mem_access() apply.
+ */
+int xc_set_mem_access_multi(xc_interface *xch, domid_t domain_id,
+uint8_t *access, uint64_t *pages,
+uint32_t nr);
+
+/*
  * Gets the mem access for the given page (returned in access on success)
  */
 int xc_get_mem_access(xc_interface *xch, domid_t domain_id,
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index eee088c..9536635 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -41,6 +41,44 @@ int xc_set_mem_access(xc_interface *xch,
 return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
 }
 
+int xc_set_mem_access_multi(xc_interface *xch,
+domid_t domain_id,
+uint8_t *access,
+uint64_t *pages,
+uint32_t nr)
+{
+DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+int rc;
+
+xen_mem_access_op_t mao =
+{
+.op   = XENMEM_access_op_set_access_multi,
+.domid= domain_id,
+.access   = XENMEM_access_default + 1, /* Invalid value */
+.pfn  = ~0UL, /* Invalid GFN */
+.nr   = nr,
+};
+
+if ( xc_hypercall_bounce_pre(xch, pages) ||
+ xc_hypercall_bounce_pre(xch, access) )
+{
+PERROR("Could not bounce memory for 
XENMEM_access_op_set_access_multi");
+return -1;
+}
+
+set_xen_guest_handle(mao.pfn_list, pages);
+set_xen_guest_handle(mao.access_list, access);
+
+rc = do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
+
+xc_hypercall_bounce_post(xch, access);
+xc_hypercall_bounce_post(xch, pages);
+
+return rc;
+}
+
 int xc_get_mem_access(xc_interface *xch,
   domid_t domain_id,
   uint64_t pfn,
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b648a9d..5c5049f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1836,6 +1836,16 @@ long p2m_set_mem_access(struct domain *d, gfn_t gfn, 
uint32_t nr,
 return 0;
 }
 
+long p2m_set_mem_access_multi(struct domain *d,
+  const XEN_GUEST_HANDLE(const_uint64) pfn_list,
+  const XEN_GUEST_HANDLE(const_uint8) access_list,
+  uint32_t nr, uint32_t start, uint32_t mask,
+  unsigned int altp2m_idx)
+{
+/* Not yet implemented on ARM. */
+return -EOPNOTSUPP;
+}
+
 int p2m_get_mem_access(struct domain *d, gfn_t gfn,
xenmem_access_t *access)
 {
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 27f9d26..97c7cfd 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[David Vrabel]

On 07/09/16 10:07, Vitaly Kuznetsov wrote:
> Stefano Stabellini  writes:
> 
>> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>>> Stefano Stabellini  writes:
>>>
 On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
> Julien Grall  writes:
>
>> Hi Vitaly,
>>
>> On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>>> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>>> particular, when we crash on a secondary vCPU we may want to do kdump
>>> and unlike plain kexec where we do migrate_to_reboot_cpu() we try 
>>> booting
>>> on the vCPU which crashed. This doesn't work very well for PVHVM guests 
>>> as
>>> we have a number of hypercalls where we pass vCPU id as a parameter. 
>>> These
>>> hypercalls either fail or do something unexpected. To solve the issue
>>> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct 
>>> mapping
>>> for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
>>> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>>> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>>> instead.
>>>
>>> Signed-off-by: Vitaly Kuznetsov 
>>> ---
>>> Changes since v2:
>>> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>>>
>>> Changes since v1:
>>> - Introduce xen_vcpu_nr() helper [David Vrabel]
>>> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>>> ---
>>>  arch/arm/xen/enlighten.c | 10 ++
>>>  arch/x86/xen/enlighten.c | 23 ++-
>>>  include/xen/xen-ops.h|  6 ++
>>>  3 files changed, 38 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>>> index 75cd734..fe32267 100644
>>> --- a/arch/arm/xen/enlighten.c
>>> +++ b/arch/arm/xen/enlighten.c
>>> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>>> *)_dummy_shared_info;
>>>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>>>  static struct vcpu_info __percpu *xen_vcpu_info;
>>>
>>> +/* Linux <-> Xen vCPU id mapping */
>>> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>>> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>>> +
>>>  /* These are unused until we support booting "pre-ballooned" */
>>>  unsigned long xen_released_pages;
>>>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>>> __initdata;
>>> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>>> pr_info("Xen: initializing cpu%d\n", cpu);
>>> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>>>
>>> +   /* Direct vCPU id mapping for ARM guests. */
>>> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>>> +
>>
>> We did some internal testing on ARM64 with the latest Linux kernel
>> (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
>> for noticing the issue that late.
>
> Sorry for the breakage :-(
>
>>
>> This function is called on the running CPU whilst some code (e.g
>> init_control_block in drivers/xen/events/events_fifo.c) is executed
>> whilst preparing the CPU on the boot CPU.
>>
>> So xen_vcpu_nr(cpu) will always return 0 in this case and
>> init_control_block will fail to execute.
>>
>
> I see,
>
> CPU_UP_PREPARE event happens before xen_starting_cpu() is called.
>
>
>> I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id,
>> *) in xen_guest_init. Any opinions?
>
> As we're not doing kexec on ARM we can fix the immediate issue. I don't
> know much about ARM and unfortunatelly I don't have a setup to test but
> it seems there is no early_per_cpu* infrastructure for ARM so we may fix
> it with the following:
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 3d2cef6..f193414 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
> pr_info("Xen: initializing cpu%d\n", cpu);
> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>  
> -   /* Direct vCPU id mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, cpu) = cpu;
> -
> info.mfn = virt_to_gfn(vcpup);
> info.offset = xen_offset_in_page(vcpup);
>  
> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>  {
> struct xen_add_to_physmap xatp;
> struct shared_info *shared_info_page = NULL;
> +   int cpu;
>  
> if (!xen_domain())
> return 0;
> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
> return -ENOMEM;
>  
> /* Direct vCPU id 

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Vitaly Kuznetsov]

Stefano Stabellini  writes:

> On Tue, 6 Sep 2016, Vitaly Kuznetsov wrote:
>> Stefano Stabellini  writes:
>> 
>> > On Mon, 5 Sep 2016, Vitaly Kuznetsov wrote:
>> >> Julien Grall  writes:
>> >> 
>> >> > Hi Vitaly,
>> >> >
>> >> > On 26/07/16 13:30, Vitaly Kuznetsov wrote:
>> >> >> It may happen that Xen's and Linux's ideas of vCPU id diverge. In
>> >> >> particular, when we crash on a secondary vCPU we may want to do kdump
>> >> >> and unlike plain kexec where we do migrate_to_reboot_cpu() we try 
>> >> >> booting
>> >> >> on the vCPU which crashed. This doesn't work very well for PVHVM 
>> >> >> guests as
>> >> >> we have a number of hypercalls where we pass vCPU id as a parameter. 
>> >> >> These
>> >> >> hypercalls either fail or do something unexpected. To solve the issue
>> >> >> introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct 
>> >> >> mapping
>> >> >> for now. Boot CPU for PVHVM guest gets its id from CPUID. With 
>> >> >> secondary
>> >> >> CPUs it is a bit more trickier. Currently, we initialize IPI vectors
>> >> >> before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
>> >> >> instead.
>> >> >>
>> >> >> Signed-off-by: Vitaly Kuznetsov 
>> >> >> ---
>> >> >> Changes since v2:
>> >> >> - Use uint32_t for xen_vcpu_id mapping [Julien Grall]
>> >> >>
>> >> >> Changes since v1:
>> >> >> - Introduce xen_vcpu_nr() helper [David Vrabel]
>> >> >> - Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
>> >> >> ---
>> >> >>  arch/arm/xen/enlighten.c | 10 ++
>> >> >>  arch/x86/xen/enlighten.c | 23 ++-
>> >> >>  include/xen/xen-ops.h|  6 ++
>> >> >>  3 files changed, 38 insertions(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> >> index 75cd734..fe32267 100644
>> >> >> --- a/arch/arm/xen/enlighten.c
>> >> >> +++ b/arch/arm/xen/enlighten.c
>> >> >> @@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
>> >> >> *)_dummy_shared_info;
>> >> >>  DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
>> >> >>  static struct vcpu_info __percpu *xen_vcpu_info;
>> >> >>
>> >> >> +/* Linux <-> Xen vCPU id mapping */
>> >> >> +DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
>> >> >> +EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
>> >> >> +
>> >> >>  /* These are unused until we support booting "pre-ballooned" */
>> >> >>  unsigned long xen_released_pages;
>> >> >>  struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] 
>> >> >> __initdata;
>> >> >> @@ -179,6 +183,9 @@ static void xen_percpu_init(void)
>> >> >>pr_info("Xen: initializing cpu%d\n", cpu);
>> >> >>vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>> >> >>
>> >> >> +  /* Direct vCPU id mapping for ARM guests. */
>> >> >> +  per_cpu(xen_vcpu_id, cpu) = cpu;
>> >> >> +
>> >> >
>> >> > We did some internal testing on ARM64 with the latest Linux kernel
>> >> > (4.8-rc4) and noticed that this patch is breaking SMP support. Sorry
>> >> > for noticing the issue that late.
>> >> 
>> >> Sorry for the breakage :-(
>> >> 
>> >> >
>> >> > This function is called on the running CPU whilst some code (e.g
>> >> > init_control_block in drivers/xen/events/events_fifo.c) is executed
>> >> > whilst preparing the CPU on the boot CPU.
>> >> >
>> >> > So xen_vcpu_nr(cpu) will always return 0 in this case and
>> >> > init_control_block will fail to execute.
>> >> >
>> >> 
>> >> I see,
>> >> 
>> >> CPU_UP_PREPARE event happens before xen_starting_cpu() is called.
>> >> 
>> >> 
>> >> > I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id,
>> >> > *) in xen_guest_init. Any opinions?
>> >> 
>> >> As we're not doing kexec on ARM we can fix the immediate issue. I don't
>> >> know much about ARM and unfortunatelly I don't have a setup to test but
>> >> it seems there is no early_per_cpu* infrastructure for ARM so we may fix
>> >> it with the following:
>> >> 
>> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> >> index 3d2cef6..f193414 100644
>> >> --- a/arch/arm/xen/enlighten.c
>> >> +++ b/arch/arm/xen/enlighten.c
>> >> @@ -170,9 +170,6 @@ static int xen_starting_cpu(unsigned int cpu)
>> >> pr_info("Xen: initializing cpu%d\n", cpu);
>> >> vcpup = per_cpu_ptr(xen_vcpu_info, cpu);
>> >>  
>> >> -   /* Direct vCPU id mapping for ARM guests. */
>> >> -   per_cpu(xen_vcpu_id, cpu) = cpu;
>> >> -
>> >> info.mfn = virt_to_gfn(vcpup);
>> >> info.offset = xen_offset_in_page(vcpup);
>> >>  
>> >> @@ -330,6 +327,7 @@ static int __init xen_guest_init(void)
>> >>  {
>> >> struct xen_add_to_physmap xatp;
>> >> struct shared_info *shared_info_page = NULL;
>> >> +   int cpu;
>> >>  
>> >> if (!xen_domain())
>> >> return 0;
>> >> @@ -380,7 +378,8 @@ static int __init xen_guest_init(void)
>> >> return -ENOMEM;
>> >> 

Re: [Xen-devel] [PATCH 2/3] x86: add support for L2 CAT in hypervisor.

[Jan Beulich]

>>> On 07.09.16 at 09:13,  wrote:
> On 16-09-06 01:43:22, Jan Beulich wrote:
>> >>> On 25.08.16 at 07:22,  wrote:
>> 
>> Please extend the comments given for patch 1 to this one. Just one
>> extra thing:
>> 
>> > @@ -743,7 +744,7 @@ struct xen_sysctl_psr_cat_op {
>> >  uint32_t cos_max;   /* OUT: Maximum COS */
>> >  #define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
>> >  uint32_t flags; /* OUT: CAT flags */
>> > -} l3_info;
>> > +} info;
>> 
>> Such an adjustment breaks the tools build, i.e. can't come without
>> also minimally adjusting libxc.
>> 
>> Jan
> I thought 4.8 will also make tools version upgrade but not considered
> to be compatible with old tools. Sorry for that.
> 
> Considering the compatibility and to support future feature, I want to
> add a general structure in union, like below. How do you think? Thanks!

No, you don't need to be compatible with old tools. But you need to
avoid build breakage between patches 2 and 3. Please always
remember that (a) patch series may not get applied in one go and
(b) even if they do any intermediate build breakage will hinder
bisection attempts.

Jan


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

Re: [Xen-devel] [PATCH 1/3] x86: refactor psr implementation in hypervisor.

[Jan Beulich]

>> >>> On 25.08.16 at 07:22,  wrote:
>> > + struct psr_socket_alloc_info *info);
>> > +/*
>> > + * get_old_set_new is used in set value process to get all features'
>> > + * COS registers values according to original cos id of the domain.
>> > + * Then, assemble them into an mask array as feature list order.
>> 
>> This sentence in particular doesn't make any sense to me. What
>> follows below also looks like it is in need of improvement.
>> 
> Do you mean the comments are not accurate?

I simply wasn't able to tell, because of not being able to interpret
the sentence.

> How about below description?
>  
> get_old_set_new will traverse all features in list. It is used to do below two
> things:
> 1. get old_cos register value of all supported features and
> 2. set the new value for appointed feature.
> 
> All the values are set into mask array according the traversal order, meaning
> the same order of feature list members.

Sounds reasonable. I suppose the example that you gave right
next wasn't meant to go into the comment.

>> > +/*
>> > + * exceed_range is used to check if the input cos id exceeds the
>> > + * feature's cos_max and if the input mask value is not the default 
>> > one.
>> > + * Even if the associated cos exceeds the cos_max, HW can work as 
>> > default
>> > + * value. That is the reason we need check is mask value is default 
>> > one.
>> > + * If both criteria are fulfilled, that means the input exceeds the
>> > + * range.
>> > + */
>> > +unsigned int (*exceed_range)(uint64_t *mask, struct feat_list *pFeat,
>> > + unsigned int cos);
>> 
>> According to the comment this is kind of a predicate, which seems
>> unlikely to return an unsigned value. In fact without a word on the
>> return value I'd expect such to return bool. And I'd also expect the
>> name to reflect the purpose, i.e. "exceeds_name()". Plus just like
>> for compare above I wonder whether come or all of the parameters
>> should be pointers to const (please go over the entire patch and do
>> constification wherever possible/sensible).
>> 
> Yes, you are right. I will change the function type to bool and add const
> for not changed input pointers.
> 
> This function is used to check if the input cos id exceeds the cos_max. If yes
> and the set value is not default value, we should return error. So, I think
> to change the function name to exceed_cos_max(). How do you think?

Okay, except that I continue to think you mean "exceeds".
"exceed_cos_max" to me is kind of a directive, not a predicate.

>> > +#define MAX_FEAT_INFO_SIZE 8
>> > +#define MAX_COS_REG_NUM  128
>> 
>> Are these numbers arbitrary, or based on something?
>> 
> MAX_FEAT_INFO_SIZE is got from the sizeof(struct psr_cat_lvl_info) and
> consider the extension for future feature.

In that case please use that sizeof() in the expression here.

> MAX_COS_REG_NUM is got from spec that the max COS registers number is 128
> for all PSR features so far.

"So far" makes me still wonder: Is this an architectural limit or one
resulting from current (hardware) implementations. In the former
case I don't think a comment is strictly needed, but in the latter
case the choice should be explained.

>> > +struct psr_socket_alloc_info {
>> 
>> I've yet to see whether the "alloc" in the name really makes sense.

And btw., having seen the entire patch I don't think this alloc_ infix
is warranted both here and in the variable name.

>> > +/* Common functions for supporting feature callback functions. */
>> > +static void add_feature(struct feat_list *pHead, struct feat_list *pTmp)
>> > +{
>> > +if ( NULL == pHead || NULL == pTmp )
>> > +return;
>> > +
>> > +while ( pHead->pNext )
>> > +pHead = pHead->pNext;
>> > +
>> > +pHead->pNext = pTmp;
>> > +}
>> 
>> Do you really need custom list management here?
>> 
> It seems xen list interfaces require the input list be a double linked list 
> but
> my list is a single linked list. Furthermore, I only need simple add to tail
> function and free function. So I create custom list management functions.

Unless there's a strong need, I'd like you to go with what is there,
or introduce _generic_ singly linked list management.

>> > +static void free_feature(struct psr_socket_alloc_info *info)
>> > +{
>> > +struct feat_list *pTmp;
>> > +struct feat_list *pPrev;
>> > +
>> > +if ( NULL == info )
>> > +return;
>> > +
>> > +if ( NULL == info->pFeat )
>> > +return;
>> > +
>> > +pTmp = info->pFeat->pNext;
>> > +while ( pTmp )
>> > +{
>> > +pPrev = pTmp;
>> > +pTmp = pTmp->pNext;
>> > +clear_bit(pPrev->feature, &(info->features));
>> > +xfree(pPrev);
>> > +pPrev = NULL;
>> > +}
>> > +}
>> 
>> Why does info->pFeat not get freed here?
>> 
> The info->pFeat is a redundant list head to facilitate list operations.

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  d6be2cfccfffd6d5ff1da68277ec3ab13e595368
baseline version:
 xen  5c7716379ee2a9711cc842f39de7d5a94ff6f765

Last test of basis   100775  2016-09-06 14:02:32 Z0 days
Testing same since   100785  2016-09-07 07:01:10 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Olaf Hering 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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