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

[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 memflag to indicate
whether TLB-flush should be done in alloc_heap_pages or its caller
populate_physmap.  Once this bit is set in memflag, alloc_heap_pages will
ignore TLB-flush.

Signed-off-by: Dongli Zhang 
---
 xen/common/memory.c | 26 ++
 xen/common/page_alloc.c |  3 ++-
 xen/include/xen/mm.h|  2 ++
 3 files changed, 30 insertions(+), 1 deletion(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index f34dd56..14ec5fa 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) )
@@ -149,6 +151,8 @@ static void populate_physmap(struct memop_args *a)
 if ( a->extent_order > (a->memflags & MEMF_populate_on_demand ? MAX_ORDER :
 max_order(curr_d)) )
 return;
+   
+   a->memflags |= MEMF_no_tlbflush;
 
 for ( i = a->nr_done; i < a->nr_extents; i++ )
 {
@@ -213,6 +217,18 @@ static void populate_physmap(struct memop_args *a)
  i, a->nr_extents);
 goto out;
 }
+   
+   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 +248,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(&mask) )
+   {
+   perfc_incr(need_flush_tlb_flush);
+   flush_tlb_mask(&mask);
+   }
+   }
 a->nr_done = i;
 }
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 18ff6cf..79f633b 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/include/xen/mm.h b/xen/include/xen/mm.h
index 58bc0b8..880ca88 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -221,6 +221,8 @@ struct npfec {
 #define  MEMF_exact_node  (1U<<_MEMF_exact_node)
 #define _MEMF_no_owner5
 #define  MEMF_no_owner(1U<<_MEMF_no_owner)
+#define _MEMF_no_tlbflush 6
+#define  MEMF_no_tlbflush (1U<<_MEMF_no_tlbflush)
 #define _MEMF_node8
 #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
 #define  MEMF_node(n) n) + 1) & MEMF_node_mask) << _MEMF_node)
-- 
1.9.1


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

[Xen-devel] [qemu-mainline baseline-only test] 67642: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67642 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67642/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67633
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67633

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

version targeted for testing:
 qemuue87d397e5ef66276ccc49b829527d605ca07d0ad
baseline version:
 qemuu1dc33ed90bf1fe1c2014dffa0d9e863c520d953a

Last test of basis67633  2016-09-03 06:46:35 Z2 days
Testing same since67642  2016-09-05 20:20:13 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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-am

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 14 guest-saverestore.2 fail 
REGR. vs. 100751

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot fail REGR. vs. 100751
 build-amd64-rumpuserxen   6 xen-buildfail  like 100751
 build-i386-rumpuserxen6 xen-buildfail  like 100751
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100751
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100751
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100751
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100751
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100751

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 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-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  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

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

Last test of basis   100751  2016-09-05 01:59:33 Z1 days
Testing same since   100766  2016-09-05 17:18:59 Z0 days1 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   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pas

Re: [Xen-devel] [RFC 18/22] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> The ARM architecture mandates to use of a break-before-make sequence
> when changing translation entries if the page table is shared between
> multiple CPUs whenever a valid entry is replaced by another valid entry
> (see D4.7.1 in ARM DDI 0487A.j for more details).
> 
> The break-before-make sequence can be divided in the following steps:
> 1) Invalidate the old entry in the page table
> 2) Issue a TLB invalidation instruction for the address associated
> to this entry
> 3) Write the new entry
> 
> The current P2M code implemented in apply_one_level does not respect
> this sequence and may result to break coherency on some processors.
> 
> Adapting the current implementation to use the break-before-make
> sequence would imply some code duplication and more TLBs invalidation
> than necessary. For instance, if we are replacing a 4KB page and the
> current mapping in the P2M is using a 1GB superpage, the following steps
> will happen:
> 1) Shatter the 1GB superpage into a series of 2MB superpages
> 2) Shatter the 2MB superpage into a series of 4KB pages
> 3) Replace the 4KB page
> 
> As the current implementation is shattering while descending and install
> the mapping, Xen would need to issue 3 TLB invalidation instructions
> which is clearly inefficient.
> 
> Furthermore, all the operations which modify the page table are using
> the same skeleton. It is more complicated to maintain different code paths
> than having a generic function that set an entry and take care of the
> break-before-make sequence.
> 
> The new implementation is based on the x86 EPT one which, I think,
> fits quite well for the break-before-make sequence whilst keeping
> the code simple.
> 
> The main function of the new implementation is __p2m_get_entry. It will
> only work on mapping that are aligned to a block entry in the page table
> (i.e 1GB, 2MB, 4KB when using a 4KB granularity).
> 
> Another function, p2m_get_entry, is provided to break down is region
> into mapping that is aligned to a block entry.
> 
> Note that to keep this patch "small", there are no caller of those
> functions added in this patch (they will be added in follow-up patches).
> 
> Signed-off-by: Julien Grall 
> 
> ---
> I need to find the impact of this new implementation on ARM32 because
> the domheap is not always mapped. This means that Xen needs to map/unmap
> everytime the page associated to the page table. It might be possible
> to re-use some caching structure as the current implementation does
> or rework the way a domheap is mapped/unmapped.
> 
> Also, this code still contain few TODOs mostly to add sanity
> checks and few optimization. The IOMMU is not yet supported.
> ---
>  xen/arch/arm/p2m.c | 335 
> +
>  1 file changed, 335 insertions(+)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index c93e554..297b176 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -750,6 +750,341 @@ static void p2m_put_l3_page(mfn_t mfn, p2m_type_t type)
>  }
>  }
>  
> +#if 0
> +/* Free lpae sub-tree behind an entry */
> +static void p2m_free_entry(struct p2m_domain *p2m,
> +   lpae_t entry, unsigned int level)
> +{
> +unsigned int i;
> +lpae_t *table;
> +mfn_t mfn;
> +
> +/* Nothing to do if the entry is invalid or a super-page */

Why are we not freeing superpages? It looks like this function could be
correctly called on a superpage (with level == target).


> +if ( !p2m_valid(entry) || p2m_is_superpage(entry, level) )
> +return;
> +
> +if ( level == 3 )
> +{
> +p2m_put_l3_page(_mfn(entry.p2m.base), entry.p2m.type);
> +return;
> +}
> +
> +table = map_domain_page(_mfn(entry.p2m.base));
> +for ( i = 0; i < LPAE_ENTRIES; i++ )
> +p2m_free_entry(p2m, *(table + i), level + 1);
> +
> +unmap_domain_page(table);
> +
> +/*
> + * Make sure all the references in the TLB have been removed before
> + * freing the intermediate page table.
> + * XXX: Should we defer the free of the page table to avoid the
> + * flush?

Yes, I would probably move the p2m flush out of this function.


> + */
> +if ( p2m->need_flush )
> +p2m_flush_tlb_sync(p2m);
> +
> +mfn = _mfn(entry.p2m.base);
> +ASSERT(mfn_valid(mfn_x(mfn)));
> +
> +free_domheap_page(mfn_to_page(mfn_x(mfn)));
> +}
> +
> +static bool p2m_split_superpage(struct p2m_domain *p2m, lpae_t *entry,
> +unsigned int level, unsigned int target,
> +const unsigned int *offsets)
> +{
> +struct page_info *page;
> +unsigned int i;
> +lpae_t pte, *table;
> +bool rv = true;
> +
> +/* Convenience aliases */
> +p2m_type_t t = entry->p2m.type;
> +mfn_t mfn = _mfn(entry->p2m.base);
> +
> +/* Convenience aliases */
> +unsigned in

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf bc54e50e0fe03c570014f363b547426913e92449
baseline version:
 ovmf 3d20524af09243e3b2e3e832d1c62975e84a5dcd

Last test of basis   100754  2016-09-05 10:46:12 Z0 days
Testing same since   100764  2016-09-05 15:45:29 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=bc54e50e0fe03c570014f363b547426913e92449
+ . ./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 
bc54e50e0fe03c570014f363b547426913e92449
+ branch=ovmf
+ revision=bc54e50e0fe03c570014f363b547426913e92449
+ . ./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
+ '[' xbc54e50e0fe03c570014f363b547426913e92449 = 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/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cach

[Xen-devel] [linux-4.1 baseline-only test] 67638: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67638 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67638/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  11 guest-start   fail REGR. vs. 67584
 test-armhf-armhf-xl-midway   18 leak-check/check  fail REGR. vs. 67584
 test-amd64-i386-xl-raw   15 guest-saverestore.2   fail REGR. vs. 67584
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 67584

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 67584
 build-i386-rumpuserxen6 xen-buildfail   like 67584
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67584
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67584
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67584
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 67584
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67584
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-install fail like 67584
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67584

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

version targeted for testing:
 linux3b60b86aec06fbae1142ccc4e55b39b529ae2a25
baseline version:
 linux99f614a3bb23603a947be2e95b78507112c484e5

Last test of basis67584  2016-08-23 16:49:45 Z   13 days
Testing same since67638  2016-09-05 15:17:10 Z0 days1 attempts


People who touched revisions under test:
  Agrawal, Nitesh-kumar 
  Alan Stern 
  Alex Deucher 
  Alexey Klimov 
  Andrej Krutak 
  Andrew Donnellan 
  Andrew Morton 
  Andrey Ryabinin 
  Artem Bityutskiy 
  Bart Van Assche 
  Benjamin Coddington 
  Bjorn Helgaas 
  Bruno Wolff III 
  Chen-Yu Tsai 
  Christian König 
  Christoph Huber 
  Daniel Lezcano 
  Daniel Mentz 
  Dani

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3d20524af09243e3b2e3e832d1c62975e84a5dcd
baseline version:
 ovmf 11eaa7affb8b325b3e00bbe9e4357705ce3b2b08

Last test of basis67636  2016-09-04 07:48:42 Z1 days
Testing same since67639  2016-09-05 15:46:17 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

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



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

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

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


Push not applicable.


commit 3d20524af09243e3b2e3e832d1c62975e84a5dcd
Author: Star Zeng 
Date:   Mon Aug 8 18:20:58 2016 +0800

MdeModulePkg PiDxeS3BootScriptLib: Support multiple PCI segment

Support multiple PCI segment for PCI_CONFIG2 opcodes.

PiDxeS3BootScriptLib needs to be updated to consume PciSegmentLib
instead of PciLib. That means platforms need to add PciSegmentLib
declaration like below in platform dsc if the PciSegmentLib was
not declared in platform dsc before.

PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf

For platforms only have one segment,
MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended
to be used and declared in platform dsc for PiDxeS3BootScriptLib to have
equivalent functionality with before.

Cc: Jiewen Yao 
Cc: Michael D Kinney 
Cc: Amy Chan 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Michael Kinney 
Tested-by: Laszlo Ersek 

commit 3a03e95edaa617625feaf575f58a24d2add990ba
Author: Star Zeng 
Date:   Wed Aug 17 16:51:55 2016 +0800

MdeModulePkg PiDxeS3BootScriptLib: Remove the trailing white spaces

Cc: Jiewen Yao 
Cc: Michael D Kinney 
Cc: Amy Chan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Michael Kinney 
Tested-by: Laszlo Ersek 

commit ed14533cbc707fee850fd2c69ae5ce0f0d4a2f34
Author: Star Zeng 
Date:   Fri Aug 19 15:30:36 2016 +0800

SecurityPkg/SecurityPkg.dsc: Declare PciSegmentLib

PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.

Cc: Jiewen Yao 
Cc: Michael D Kinney 
Cc: Amy Chan 
Cc: Chao Zhang 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Michael Kinney 

commit df67c686efe76cfef4cda3da24d38b8d48bbc968
Author: Star Zeng 
Date:   Fri Aug 19 15:06:58 2016 +0800

QuarkSocPkg/QuarkSocPkg.dsc: Declare PciSegmentLib

PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.

Cc: Jiewen Yao 
Cc: Michael D Kinney 
Cc: Amy Chan 
Cc: Kelly Steele 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Michael Kinney 

commit 627dea2ac921ad40c932b756dfc54722e40e4e0c
Author: Star Zeng 
Date:   Fri Aug 19 15:05:48 2016 +0800

QuarkPlatformPkg: Declare PciSegmentLib in platform dsc

PiDxeS3BootScriptLib will be updated to consume PciSegmentLib
instead of PciLib to support multiple PCI segment.
That means platforms need to add PciSegmentLib
declaration in platform dsc if the PciSegmentLib was
not declared in platform dsc before.

For platforms only have one segment,
MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended
to be used and declared in platform dsc fo

Re: [Xen-devel] [RFC 17/22] xen/arm: p2m: Introduce a helper to check if an entry is a superpage

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> Use the level and the entry to know whether an entry is a superpage.
> A superpage can only happen below level 3.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/p2m.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index ca2f1b0..c93e554 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -57,6 +57,11 @@ static inline bool_t p2m_mapping(lpae_t pte)
>  return p2m_valid(pte) && !pte.p2m.table;
>  }
>  
> +static inline bool_t p2m_is_superpage(lpae_t pte, unsigned int level)
> +{
> +return (level < 3) && p2m_mapping(pte);
> +}
>
>  static inline void p2m_write_lock(struct p2m_domain *p2m)
>  {
>  write_lock(&p2m->lock);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC 16/22] xen/arm: p2m: Make p2m_{valid, table, mapping} helpers inline

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> Those helpers are very small and often used. Let know the compiler they
> can be inlined.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/p2m.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index d0aba5b..ca2f1b0 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -39,7 +39,7 @@ static const unsigned int level_shifts[] =
>  static const unsigned int level_orders[] =
>  { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>  
> -static bool_t p2m_valid(lpae_t pte)
> +static inline bool_t p2m_valid(lpae_t pte)
>  {
>  return pte.p2m.valid;
>  }
> @@ -48,11 +48,11 @@ static bool_t p2m_valid(lpae_t pte)
>   * the table bit and therefore these would return the opposite to what
>   * you would expect.
>   */
> -static bool_t p2m_table(lpae_t pte)
> +static inline bool_t p2m_table(lpae_t pte)
>  {
>  return p2m_valid(pte) && pte.p2m.table;
>  }
> -static bool_t p2m_mapping(lpae_t pte)
> +static inline bool_t p2m_mapping(lpae_t pte)
>  {
>  return p2m_valid(pte) && !pte.p2m.table;
>  }
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [RFC 15/22] xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_get_entry

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> The current implementation of relinquish_p2m_mapping is modifying the
> page table to erase the entry one by one. However, this is not necessary
> because the domain is not running anymore and therefore will speed up
> the domain destruction.

Could you please elaborate on this? Who is going to remove the p2m
entries if not this function?


> The function relinquish_p2m_mapping can be re-implemented using
> p2m_get_entry by iterating over the range mapped and using the mapping
> order given by the callee.
> 
> Given that the preemption was chosen arbitrarily, it is no done on every
  ^ now?

> 512 iterations. Meaning that Xen may check more often if the function is
> preempted when there are no mappings.
> 
> Finally drop the operation RELINQUISH in apply_* as nobody is using it
> anymore. Note that the functions could have been dropped in one go at
> the end, however I find easier to drop the operations one by one
> avoiding a big deletion in the patch that remove the last operation.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Further investigation needs to be done before applying this patch to
> check if someone could take advantage of this change (such
> modifying an entry which was relinquished).
> ---
>  xen/arch/arm/p2m.c | 70 
> --
>  1 file changed, 52 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index e7697bb..d0aba5b 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -721,7 +721,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
> *p2m, gfn_t gfn,
>  enum p2m_operation {
>  INSERT,
>  REMOVE,
> -RELINQUISH,
>  MEMACCESS,
>  };
>  
> @@ -908,7 +907,6 @@ static int apply_one_level(struct domain *d,
>  
>  break;
>  
> -case RELINQUISH:
>  case REMOVE:
>  if ( !p2m_valid(orig_pte) )
>  {
> @@ -1092,17 +1090,6 @@ static int apply_p2m_changes(struct domain *d,
>  {
>  switch ( op )
>  {
> -case RELINQUISH:
> -/*
> - * Arbitrarily, preempt every 512 operations or 8192 nops.
> - * 512*P2M_ONE_PROGRESS == 8192*P2M_ONE_PROGRESS_NOP == 
> 0x2000
> - * This is set in preempt_count_limit.
> - *
> - */
> -p2m->lowest_mapped_gfn = _gfn(addr >> PAGE_SHIFT);
> -rc = -ERESTART;
> -goto out;
> -
>  case MEMACCESS:
>  {
>  /*
> @@ -1508,16 +1495,63 @@ int p2m_init(struct domain *d)
>  return rc;
>  }
>  
> +/*
> + * The function will go through the p2m and remove page reference when it
> + * is required.
> + * The mapping are left intact in the p2m. This is fine because the
> + * domain will never run at that point.
> + *
> + * XXX: Check what does it mean for other part (such as lookup)
> + */
>  int relinquish_p2m_mapping(struct domain *d)
>  {
>  struct p2m_domain *p2m = &d->arch.p2m;
> -unsigned long nr;
> +unsigned long count = 0;
> +p2m_type_t t;
> +int rc = 0;
> +unsigned int order;
> +
> +/* Convenience alias */
> +gfn_t start = p2m->lowest_mapped_gfn;
> +gfn_t end = p2m->max_mapped_gfn;
>  
> -nr = gfn_x(p2m->max_mapped_gfn) - gfn_x(p2m->lowest_mapped_gfn);
> +p2m_write_lock(p2m);
>  
> -return apply_p2m_changes(d, RELINQUISH, p2m->lowest_mapped_gfn, nr,
> - INVALID_MFN, 0, p2m_invalid,
> - d->arch.p2m.default_access);
> +for ( ; gfn_x(start) < gfn_x(end); start = gfn_add(start, 1UL << order) )
> +{
> +mfn_t mfn = p2m_get_entry(p2m, start, &t, NULL, &order);
> +
> +count++;
> +/*
> + * Arbitrarily preempt every 512 iterations.
> + */
> +if ( !(count % 512) && hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +break;
> +}
> +
> +/* Skip hole and any superpage */
> +if ( mfn_eq(mfn, INVALID_MFN) || order != 0 )
> +/*
> + * The order corresponds to the order of the mapping in the
> + * page table. So we need to align the GFN before
> + * incrementing.
> + */
> +start = _gfn(gfn_x(start) & ~((1UL << order) - 1));
> +else
> +p2m_put_l3_page(mfn, t);
> +}
> +
> +/*
> + * Update lowest_mapped_gfn so on the next call we still start where
> + * we stopped.
> + */
> +p2m->lowest_mapped_gfn = start;
> +
> +p2m_write_unlock(p2m);
> +
> +return rc;
>  }
>  
>  int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)

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

Re: [Xen-devel] [RFC 14/22] xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> The function p2m_cache_flush can be re-implemented using the generic
> function p2m_get_entry by iterating over the range and using the mapping
> order given by the callee.
> 
> As the current implementation, no preemption is implemented, although
> the comment in the current code claimed it. As the function is called by
> a DOMCTL with a region of 1GB maximum, I think the preemption can be
> left unimplemented for now.
> 
> Finally drop the operation CACHEFLUSH in apply_one_level as nobody is
> using it anymore. Note that the function could have been dropped in one
> go at the end, however I find easier to drop the operations one by one
> avoiding a big deletion in the patch that convert the last operation.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> The loop pattern will be very for the reliquish function. It might
> be possible to extract it in a separate function.
> ---
>  xen/arch/arm/p2m.c | 67 
> +++---
>  1 file changed, 34 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 9a9c85c..e7697bb 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -722,7 +722,6 @@ enum p2m_operation {
>  INSERT,
>  REMOVE,
>  RELINQUISH,
> -CACHEFLUSH,
>  MEMACCESS,
>  };
>  
> @@ -978,36 +977,6 @@ static int apply_one_level(struct domain *d,
>   */
>  return P2M_ONE_PROGRESS;
>  
> -case CACHEFLUSH:
> -if ( !p2m_valid(orig_pte) )
> -{
> -*addr = (*addr + level_size) & level_mask;
> -return P2M_ONE_PROGRESS_NOP;
> -}
> -
> -if ( level < 3 && p2m_table(orig_pte) )
> -return P2M_ONE_DESCEND;
> -
> -/*
> - * could flush up to the next superpage boundary, but would
> - * need to be careful about preemption, so just do one 4K page
> - * now and return P2M_ONE_PROGRESS{,_NOP} so that the caller will
> - * continue to loop over the rest of the range.
> - */
> -if ( p2m_is_ram(orig_pte.p2m.type) )
> -{
> -unsigned long offset = paddr_to_pfn(*addr & ~level_mask);
> -flush_page_to_ram(orig_pte.p2m.base + offset);
> -
> -*addr += PAGE_SIZE;
> -return P2M_ONE_PROGRESS;
> -}
> -else
> -{
> -*addr += PAGE_SIZE;
> -return P2M_ONE_PROGRESS_NOP;
> -}
> -
>  case MEMACCESS:
>  if ( level < 3 )
>  {
> @@ -1555,12 +1524,44 @@ int p2m_cache_flush(struct domain *d, gfn_t start, 
> unsigned long nr)
>  {
>  struct p2m_domain *p2m = &d->arch.p2m;
>  gfn_t end = gfn_add(start, nr);
> +p2m_type_t t;
> +unsigned int order;
>  
>  start = gfn_max(start, p2m->lowest_mapped_gfn);
>  end = gfn_min(end, p2m->max_mapped_gfn);
>  
> -return apply_p2m_changes(d, CACHEFLUSH, start, nr, INVALID_MFN,
> - 0, p2m_invalid, d->arch.p2m.default_access);
> +/* XXX: Should we use write lock here? */

Good question. As the p2m is left unchanged by this function, I think
that the read lock is sufficient.


> +p2m_read_lock(p2m);
> +
> +for ( ; gfn_x(start) < gfn_x(end); start = gfn_add(start, 1UL << order) )
> +{
> +mfn_t mfn = p2m_get_entry(p2m, start, &t, NULL, &order);
> +
> +/* Skip hole and non-RAM page */
> +if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_ram(t) )
> +{
> +/*
> + * the order corresponds to the order of the mapping in the
> + * page table. so we need to align the gfn before
> + * incrementing.
> + */
> +start = _gfn(gfn_x(start) & ~((1UL << order) - 1));
> +continue;
> +}
> +
> +/*
> + * Could flush up to the next superpage boundary, but we would
> + * need to be careful about preemption, so just do one 4K page
> + * now.

I think that even without preemption you should implement flushing up to
the next superpage boundary (but not beyond "end"). You can still do it
4K at a time, but only call p2m_get_entry once per "order". Could be a
decent performance improvement as cacheflush is a performance critical
hypercall.


> + * XXX: Implement preemption.
> + */
> +flush_page_to_ram(mfn_x(mfn));
> +order = 0;
> +}
> +
> +p2m_read_unlock(p2m);
> +
> +return 0;
>  }
>  
>  mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
> -- 
> 1.9.1
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100597
 build-i386-rumpuserxen6 xen-buildfail  like 100597
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100597
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100597
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100597
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100597

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

version targeted for testing:
 linuxe9e1b43e9f912ee8aad24534584a6257d2b43aba
baseline version:
 linuxd45da77ced2a983edc2cd55d26e7693b1f3613dd

Last test of basis   100597  2016-08-23 06:54:31 Z   13 days
Testing same since   100752  2016-09-05 06:44:05 Z0 days2 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexey Klimov 
  Andrew Donnellan 
  Andrew Morton 
  Artem Bityutskiy 
  Bjorn Helgaas 
  Bruno Wolff III 
  Chen-Yu Tsai 
  Christian König 
  Daniel Lezcano 
  Daniel Mentz 
  Daniel Vetter 
  Daniel Vetter 
  Daniele Palmas 
  Dave Airlie 
  Dave Carroll 
  David S. Miller 
  David Vrabel 
  Dmitry Torokhov 
  Eric Dumazet 
  Eric Wheeler 
  Eric Wheeler 
  Felipe Balbi 
  Felix Fietkau 
  Gavin Li 
  Gavin Shan 
  Greg Kroah-Hartman 
  Helge Deller 
  Herbert Xu 
  Hubert Feurstein 
  Ingo Molnar 
  Jan Beulich 
  Jani Nikula 
  Jason S. McMullan 
  Jim Lin 
  Johan Hovold 
  Johannes Berg 
  John Stultz 
  Kent Overstreet 
  Laxman Dewangan 
  Liav Rehana 
  Linus Torvalds 
  Linus Walleij 
  Lu Baolu 
  Lubomir Rintel 
  Martin K. Petersen 
  Martin Schwidefsky 
  Masahiro Yamada 
  Mathias Nyman 
  Matthew Auld 
  Maxime Ripard 
  Michael Ellerman 
  Michal Hocko 
  Mike Snitzer 
  Neal Cardwell 
  Oleg

Re: [Xen-devel] [RFC 13/22] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

[Stefano Stabellini]

On Thu, 28 Jul 2016, Julien Grall wrote:
> __p2m_lookup is just a wrapper to p2m_get_entry.
> 
> Signed-off-by: Julien Grall 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 

Acked-by: Stefano Stabellini 


> ---
> It might be possible to rework the memaccess code to take advantage
> of all the parameters. I will defer this to the memaccess folks.
> ---
>  xen/arch/arm/p2m.c | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 8676b9d..9a9c85c 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -398,24 +398,13 @@ out:
>  return mfn;
>  }
>  
> -/*
> - * Lookup the MFN corresponding to a domain's GFN.
> - *
> - * There are no processor functions to do a stage 2 only lookup therefore we
> - * do a a software walk.
> - */
> -static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
> -{
> -return p2m_get_entry(&d->arch.p2m, gfn, t, NULL, NULL);
> -}
> -
>  mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
>  {
>  mfn_t ret;
>  struct p2m_domain *p2m = &d->arch.p2m;
>  
>  p2m_read_lock(p2m);
> -ret = __p2m_lookup(d, gfn, t);
> +ret = p2m_get_entry(p2m, gfn, t, NULL, NULL);
>  p2m_read_unlock(p2m);
>  
>  return ret;
> @@ -679,7 +668,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t 
> gfn,
>   * No setting was found in the Radix tree. Check if the
>   * entry exists in the page-tables.
>   */
> -mfn_t mfn = __p2m_lookup(d, gfn, NULL);
> +mfn_t mfn = p2m_get_entry(p2m, gfn, NULL, NULL, NULL);
>  
>  if ( mfn_eq(mfn, INVALID_MFN) )
>  return -ESRCH;
> @@ -1595,6 +1584,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>  xenmem_access_t xma;
>  p2m_type_t t;
>  struct page_info *page = NULL;
> +struct p2m_domain *p2m = ¤t->domain->arch.p2m;
>  
>  rc = gva_to_ipa(gva, &ipa, flag);
>  if ( rc < 0 )
> @@ -1655,7 +1645,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
> long flag)
>   * We had a mem_access permission limiting the access, but the page type
>   * could also be limiting, so we need to check that as well.
>   */
> -mfn = __p2m_lookup(current->domain, gfn, &t);
> +mfn = p2m_get_entry(p2m, gfn, &t, NULL, NULL);
>  if ( mfn_eq(mfn, INVALID_MFN) )
>  goto err;
>  
> -- 
> 1.9.1
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 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-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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  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-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-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:
 qemuue87d397e5ef66276ccc49b829527d605ca07d0ad
baseline version:
 qemuu1dc33ed90bf1fe1c2014dffa0d9e863c520d953a

Last test of basis   100741  2016-09-02 23:19:09 Z2 days
Testing same since   100756  2016-09-05 11:15:15 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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  

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

[Stefano Stabellini]

On Wed, 3 Aug 2016, Tamas K Lengyel wrote:
> The two functions monitor_traps and mem_access_send_req duplicate some of the
> same functionality. The mem_access_send_req however leaves a lot of the
> standard vm_event fields to be filled by other functions.
> 
> Remove mem_access_send_req() completely, making use of monitor_traps() to put
> requests into the monitor ring.  This in turn causes some cleanup around the
> old callsites of mem_access_send_req(). We also update monitor_traps to now
> include setting the common vcpu_id field so that all other call-sites can 
> ommit
> this step.
> 
> Finally, this change identifies that errors from mem_access_send_req() were
> never checked.  As errors constitute a problem with the monitor ring,
> crashing the domain is the most appropriate action to take.
> 
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 
> Acked-by: Razvan Cojocaru 

The ARM bits:

Acked-by: Stefano Stabellini 


> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: George Dunlap 
> 
> v3: reduce the code movement and sanitization performed to a minimum
> ---
>  xen/arch/arm/p2m.c   | 15 ---
>  xen/arch/x86/hvm/hvm.c   | 18 --
>  xen/arch/x86/hvm/monitor.c   |  5 -
>  xen/arch/x86/mm/p2m.c| 26 +-
>  xen/common/mem_access.c  | 11 ---
>  xen/common/monitor.c |  2 ++
>  xen/include/asm-x86/p2m.h| 13 -
>  xen/include/xen/mem_access.h |  7 ---
>  8 files changed, 31 insertions(+), 66 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 40a0b80..a3f05b4 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,7 +5,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1740,10 +1740,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  {
>  req->reason = VM_EVENT_REASON_MEM_ACCESS;
>  
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
> -
>  /* Send request to mem access subscriber */
>  req->u.mem_access.gfn = gpa >> PAGE_SHIFT;
>  req->u.mem_access.offset =  gpa & ((1 << PAGE_SHIFT) - 1);
> @@ -1760,16 +1756,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
> -req->vcpu_id = v->vcpu_id;
>  
> -mem_access_send_req(v->domain, req);
> +if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
> +domain_crash(v->domain);
> +
>  xfree(req);
>  }
>  
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -vm_event_vcpu_pause(v);
> -
>  return false;
>  }
>  
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index daaee1d..42f163e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  int rc, fall_through = 0, paged = 0;
>  int sharing_enomem = 0;
>  vm_event_request_t *req_ptr = NULL;
> -bool_t ap2m_active;
> +bool_t ap2m_active, sync = 0;
>  
>  /* On Nested Virtualization, walk the guest page table.
>   * If this succeeds, all is fine.
> @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  }
>  }
>  
> -if ( p2m_mem_access_check(gpa, gla, npfec, &req_ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, &req_ptr);
> +
> +if ( !sync )
>  fall_through = 1;
> -} else {
> -/* Rights not promoted, vcpu paused, work here is done */
> +else
> +{
> +/*
> + * Rights not promoted (aka. sync event), work here is done
> + */
>  rc = 1;
>  goto out_put_gfn;
>  }
> @@ -1956,7 +1960,9 @@ out:
>  }
>  if ( req_ptr )
>  {
> -mem_access_send_req(currd, req_ptr);
> +if ( monitor_traps(curr, sync, req_ptr) < 0 )
> +rc = 0;
> +
>  xfree(req_ptr);
>  }
>  return rc;
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 7277c12..0f6ef96 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ b/xen/arch/x86/hvm/monitor.c
> @@ -44,7 +44,6 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
> value, unsigned long old
>  
>  vm_event_request_t req = {
>  .reason = VM_EVENT_REASON_WRITE_CTRLREG,
> -.vcpu_id = curr->vcpu_id,
> 

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Stefano Stabellini]

On Fri, 2 Sep 2016, Julien Grall wrote:
> On 02/09/2016 18:45, Andrew Cooper wrote:
> > On 02/09/16 18:37, Tamas K Lengyel wrote:
> > > On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
> > >  wrote:
> > > > On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
> > > > > Add support for getting/setting registers through vm_event on ARM.
> > > > > Only
> > > > > TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
> > > > > set
> > > > > as part of a response. The set of registers can be expanded in the
> > > > > future to
> > > > > include other registers as well if necessary.
> > > > > 
> > > > > Signed-off-by: Tamas K Lengyel 
> > > > > Reviewed-by: Andrew Cooper 
> > > > Acked-by: Razvan Cojocaru 
> > > Patch ping.
> > 
> > Requires an ARM ack.
> 
> I don't think it requires an ack from Stefano and I, it touches only the
> vm_event subsystem.
> 
> If you still want an ARM ack, then I will defer to Stefano.

Acked-by: Stefano Stabellini 

___
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

[Stefano Stabellini]

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 
> >> *)&xen_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 mapping for ARM guests. */
> -   per_cpu(xen_vcpu_id, 0) = 0;
> +   for_each_possible_cpu(cpu)
> +   per_cpu(xen_vcpu_id, cpu) = cpu;
>  
> xen_auto_xlat_grant_frames.count = gnttab_max_grant_frames();
> if (xen_xlate_map_ballooned_pages(&xen_auto_xlat_grant_frames.pfn,
> 
> (not tested, if we can't use for_each_possible_cpu() that early we'll
> have to check against NR_CPUS instead).

Kind of defeat the purpose of xen_vcpu_id, but I guess it should work.


> But unfortunatelly we'll have to get back to this in future. Turns out
> we need to know Xen's idea of vCPU id _before_ this vCPU starts
> executing code.

Why?


> On x86 we

Re: [Xen-devel] [MINIOS PATCH] Add travis.yml and travis-build script

[Samuel Thibault]

Wei Liu, on Mon 05 Sep 2016 15:43:21 +0100, wrote:
> Signed-off-by: Wei Liu 

Acked-by: Samuel Thibault 

> ---
> See:
> https://travis-ci.org/liuw/mini-os/builds/157653746
> 
> Cc: Samuel Thibault 
> Cc: Juergen Gross 
> Cc: Doug Goldstein 
> 
> IRC notification is not yet set up.
> 
> Doug, can we mirror mini-os.git to github/xen-project as well? I think
> it would also be a good idea to post notification to #xentest.
> ---
>  .travis.yml  | 25 +
>  scripts/travis-build |  5 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 .travis.yml
>  create mode 100755 scripts/travis-build
> 
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000..9aa69a5
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,25 @@
> +language: c
> +dist: trusty
> +sudo: required
> +# don't test stable branches
> +branches:
> +except:
> +- /^stable-.*/
> +matrix:
> +include:
> +- compiler: gcc
> +addons:
> +apt:
> +sources:
> +- ubuntu-toolchain-r-test
> +packages:
> +- libc6-dev-i386
> +- gcc-5
> +- g++-5
> +# we must set CXX manually instead of using 'language: cpp' due to
> +# travis-ci/travis-ci#3871
> +before_script:
> +- export CXX=${CC/cc/++}
> +- export CXX=${CXX/clang/clang++}
> +script:
> +- ./scripts/travis-build
> diff --git a/scripts/travis-build b/scripts/travis-build
> new file mode 100755
> index 000..9480a9d
> --- /dev/null
> +++ b/scripts/travis-build
> @@ -0,0 +1,5 @@
> +#!/bin/bash -ex
> +
> +$CC --version
> +
> +make testbuild
> -- 
> 2.1.4
> 

-- 
Samuel
 ben oui ce serait idiot, mais osb
  -+- m'en fous de faire un truc débile ! -+-

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

[Xen-devel] [PULL 1/1] xen: use native disk xenbus protocol if possible

[Stefano Stabellini]

From: Juergen Gross 

The qdisk implementation is using the native xenbus protocol only in
case of no protocol specified at all. As using the explicit 32- or
64-bit protocol is slower than the native one due to copying requests
not by memcpy but element for element, this is not optimal.

Correct this by using the native protocol in case word sizes of
frontend and backend match.

Signed-off-by: Juergen Gross 
Reviewed-by: Anthony PERARD 
Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 3b8ad33..3428689 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -976,14 +976,16 @@ static int blk_connect(struct XenDevice *xendev)
 blkdev->feature_persistent = !!pers;
 }
 
-blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
-if (blkdev->xendev.protocol) {
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_32;
-}
-if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
-blkdev->protocol = BLKIF_PROTOCOL_X86_64;
-}
+if (!blkdev->xendev.protocol) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_NATIVE) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_32) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_32;
+} else if (strcmp(blkdev->xendev.protocol, XEN_IO_PROTO_ABI_X86_64) == 0) {
+blkdev->protocol = BLKIF_PROTOCOL_X86_64;
+} else {
+blkdev->protocol = BLKIF_PROTOCOL_NATIVE;
 }
 
 blkdev->sring = xengnttab_map_grant_ref(blkdev->xendev.gnttabdev,
-- 
1.9.1


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

[Xen-devel] [PULL 0/1] xen-20160905

[Stefano Stabellini]

The following changes since commit 12d2c4184c5ab60be3428b2bdea5ae66e8d5d960:

  Update version for v2.7.0-rc5 release (2016-08-30 20:39:45 +0100)

are available in the git repository at:

  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160905

for you to fetch changes up to 4ada797b05a52ac824a710c67216b37739026a64:

  xen: use native disk xenbus protocol if possible (2016-08-30 15:01:01 -0700)


Xen 2016/09/05


Juergen Gross (1):
  xen: use native disk xenbus protocol if possible

 hw/block/xen_disk.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

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

Re: [Xen-devel] [OSSTEST PATCH 0/7] Apropos of XTF: Improve failed step selection

[Wei Liu]

On 
> On Thu, Aug 11, 2016 at 05:17:56PM +0100, Ian Jackson wrote:
> > Running XTF in osstest is likely to produce failures where multiple
> > steps fail interestingly.  We would like to prefer to report, and
> > bisect, earlier steps.
> > 
> > This series does that.
> > 
> > Wei, NB, this has a conflict with the XTF pre series that you have
> > taken over.  The conflict is not trivial, but easy.  The conflicting
> > patch is:
> >   Executive: Previous duration estimator: use overall time, not sum of steps
> > 
> 
> The rebased patch is as followed, please check.
> 
> ---8<---
> From bbdc727965b4d4280bac670823f013d078a54b93 Mon Sep 17 00:00:00 2001
> From: Ian Jackson 
> Date: Fri, 8 Jul 2016 19:30:58 +0100
> Subject: [OSSTEST PATCH] Executive: Previous duration estimator: use overall
>  time, not sum of steps
> Cc: ian.jack...@eu.citrix.com
> 
> Some jobs runs steps in parallel.  Do not add up all the insividual
> step durations.  Instead, calculate the duration as the time between
> first step start and last step finish.
> 
> Signed-off-by: Ian Jackson 
> [ wei: rebase and fix conflict ]
> Signed-off-by: Wei Liu 
> ---
>  Osstest/Executive.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
> index 7e31b35..2187a73 100644
> --- a/Osstest/Executive.pm
> +++ b/Osstest/Executive.pm
> @@ -1068,7 +1068,7 @@ END
>FROM steps
>   WHERE flight=? AND job=?
>  )
> -SELECT sum(finished-started)
> +SELECT sum(max(finished)-min(started))
>  AS duration
>FROM tsteps
>   WHERE step != 'ts-hosts-allocate'
> -- 
> 2.1.4
> 


Hmm... there seems to be a problem with this patch.

http://osstest.xs.citrite.net/~osstest/testlogs/logs/67641/build-amd64-xtf/2.ts-hosts-allocate.log

2016-09-05 17:51:48 Z allocating hosts: host 
DBD::Pg::st execute failed: ERROR:  aggregate function calls cannot be nested
LINE 7: SELECT sum(max(finished)-min(started))
   ^ [for Statement "WITH tsteps AS 
(
SELECT *
  FROM steps
 WHERE flight=? AND job=?
)
SELECT sum(max(finished)-min(started))
AS duration
  FROM tsteps
 WHERE step != 'ts-hosts-allocate'
" with ParamValues: 1='67640', 2='build-amd64-xtf'] at Osstest/Executive.pm 
line 1127,  line 10.
resourcecall DBD::Pg::st execute failed: ERROR:  aggregate function calls 
cannot be nested
LINE 7: SELECT sum(max(finished)-min(started))
   ^ [for Statement "WITH tsteps AS 
(
SELECT *
  FROM steps
 WHERE flight=? AND job=?
)
SELECT sum(max(finished)-min(started))
AS duration
  FROM tsteps
 WHERE step != 'ts-hosts-allocate'
" with ParamValues: 1='67640', 2='build-amd64-xtf'] at Osstest/Executive.pm 
line 1127,  line 10.
Died at Osstest/Executive.pm line 903,  line 10.
+ rc=255
+ date -u +%Y-%m-%d %H:%M:%S Z exit status 255
2016-09-05 17:51:49 Z exit status 255
+ exit 255

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

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 02/09/16 11:47, Yu Zhang wrote:
> A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
> let one ioreq server claim/disclaim its responsibility for the
> handling of guest pages with p2m type p2m_ioreq_server. Users
> of this HVMOP can specify which kind of operation is supposed
> to be emulated in a parameter named flags. Currently, this HVMOP
> only support the emulation of write operations. And it can be
> further extended to support the emulation of read ones if an
> ioreq server has such requirement in the future.
> 
> For now, we only support one ioreq server for this p2m type, so
> once an ioreq server has claimed its ownership, subsequent calls
> of the HVMOP_map_mem_type_to_ioreq_server will fail. Users can also
> disclaim the ownership of guest ram pages with p2m_ioreq_server, by
> triggering this new HVMOP, with ioreq server id set to the current
> owner's and flags parameter set to 0.
> 
> Note both HVMOP_map_mem_type_to_ioreq_server and p2m_ioreq_server
> are only supported for HVMs with HAP enabled.
> 
> Also note that only after one ioreq server claims its ownership
> of p2m_ioreq_server, will the p2m type change to p2m_ioreq_server
> be allowed.
> 
> Signed-off-by: Paul Durrant 
> Signed-off-by: Yu Zhang 
> Acked-by: Tim Deegan 
> ---
> Cc: Paul Durrant 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Tim Deegan 
> 
> changes in v6: 
>   - Clarify logic in hvmemul_do_io().
>   - Use recursive lock for ioreq server lock.
>   - Remove debug print when mapping ioreq server.
>   - Clarify code in ept_p2m_type_to_flags() for consistency.
>   - Remove definition of P2M_IOREQ_HANDLE_WRITE_ACCESS.
>   - Add comments for HVMMEM_ioreq_server to note only changes
> to/from HVMMEM_ram_rw are permitted.
>   - Add domain_pause/unpause() in hvm_map_mem_type_to_ioreq_server()
> to avoid the race condition when a vm exit happens on a write-
> protected page, just to find the ioreq server has been unmapped
> already.

Why do we need to do this?  Won't the default case just DTRT if it finds
that the ioreq server has been unmapped?

 -George

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

Re: [Xen-devel] [PATCH v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[George Dunlap]

On 05/09/16 14:31, Jan Beulich wrote:
 On 02.09.16 at 12:47,  wrote:
>> @@ -178,8 +179,27 @@ static int hvmemul_do_io(
>>  break;
>>  case X86EMUL_UNHANDLEABLE:
>>  {
>> -struct hvm_ioreq_server *s =
>> -hvm_select_ioreq_server(curr->domain, &p);
>> +struct hvm_ioreq_server *s = NULL;
>> +p2m_type_t p2mt = p2m_invalid;
>> +
>> +if ( is_mmio )
>> +{
>> +unsigned long gmfn = paddr_to_pfn(addr);
>> +
>> +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
>> +
>> +if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE )
>> +{
>> +unsigned int flags;
>> +
>> +s = p2m_get_ioreq_server(currd, &flags);
>> +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
>> +s = NULL;
>> +}
>> +}
>> +
>> +if ( !s && p2mt != p2m_ioreq_server )
>> +s = hvm_select_ioreq_server(currd, &p);
> 
> What I recall is that we had agreed on p2m_ioreq_server pages
> to be treated as ordinary RAM ones as long as no server can be
> found. The type check here contradicts that. Is there a reason?

I think it must be a confusion as to what "treated like ordinary RAM
ones" means.  p2m_ram_rw types that gets here will go through
hvm_select_ioreq_server(), and (therefore) potentially be treated as
MMIO accesses, which is not how "ordinary RAM" would behave.  If what
you meant was that you want p2m_ioreq_server to behave like p2m_ram_rw
(and be treated as MMIO if it matches an iorange) then yes.  If what you
want is for p2m_ioreq_server to actually act like RAM, then probably
something more needs to happen here.

 -George

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

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

[osstest service owner]

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

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  343f84be135e6f9e681960a9e235296eae159fc8
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z3 days
Failing since100755  2016-09-05 11:01:49 Z0 days3 attempts
Testing same since   100763  2016-09-05 15:02:12 Z0 days1 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  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=343f84be135e6f9e681960a9e235296eae159fc8
+ . ./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 
343f84be135e6f9e681960a9e235296eae159fc8
+ branch=xen-unstable-smoke
+ revision=343f84be135e6f9e681960a9e235296eae159fc8
+ . ./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
+ '[' x343f84be135e6f9e681960a9e235296eae159fc8 = 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/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;

Re: [Xen-devel] [PATCH v2] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 05/09/16 16:26, Jan Beulich wrote:
> Another place where we should try to behave sufficiently close to how
> real hardware does; see the code comments.
>
> Signed-off-by: Jan Beulich 

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

Re: [Xen-devel] Xen 4.8 Development Update

[Dario Faggioli]

On Wed, 2016-08-31 at 10:21 -0400, Konrad Rzeszutek Wilk wrote:
> > 
> > *  Per-cpu tasklet
> >   -  Konrad Rzeszutek Wilk
> Waiting for review and hopefully test results from Intel.
>
I've just seen it (came back today from vacations)... Interesting bit
of work.

I'll try to have a deep look at the patches ASAP (I'm no maintainer, of
course, but I've played with tasklets a bit, and I at last hope to be
able to be of some help :-P)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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

[Xen-devel] [PATCH v2] x86: correct CPUID output for out of bounds input

[Jan Beulich]

Another place where we should try to behave sufficiently close to how
real hardware does; see the code comments.

Signed-off-by: Jan Beulich 
---
v2: Uniformly return zero for out of range leaves. Only consider basic
and extended groups as valid. Avoid recursion in hvm_cpuid().

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3364,6 +3364,27 @@ void hvm_cpuid(unsigned int input, unsig
 if ( cpuid_hypervisor_leaves(input, count, eax, ebx, ecx, edx) )
 return;
 
+if ( input & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit;
+
+domain_cpuid(d, (input >> 16) != 0x8000 ? 0 : 0x8000, 0,
+ &limit, &dummy, &dummy, &dummy);
+if ( input > limit )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+}
+
 domain_cpuid(d, input, count, eax, ebx, ecx, edx);
 
 switch ( input )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -952,6 +952,29 @@ void pv_cpuid(struct cpu_user_regs *regs
 if ( cpuid_hypervisor_leaves(leaf, subleaf, &a, &b, &c, &d) )
 goto out;
 
+if ( leaf & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit = (leaf >> 16) != 0x8000 ? 0 : 0x8000, dummy;
+
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, limit, 0, &limit, &dummy, &dummy, &dummy);
+else
+limit = cpuid_eax(limit);
+if ( leaf > limit )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+}
+
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
 domain_cpuid(currd, leaf, subleaf, &a, &b, &c, &d);
 else



x86: correct CPUID output for out of bounds input

Another place where we should try to behave sufficiently close to how
real hardware does; see the code comments.

Signed-off-by: Jan Beulich 
---
v2: Uniformly return zero for out of range leaves. Only consider basic
and extended groups as valid. Avoid recursion in hvm_cpuid().

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3364,6 +3364,27 @@ void hvm_cpuid(unsigned int input, unsig
 if ( cpuid_hypervisor_leaves(input, count, eax, ebx, ecx, edx) )
 return;
 
+if ( input & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit;
+
+domain_cpuid(d, (input >> 16) != 0x8000 ? 0 : 0x8000, 0,
+ &limit, &dummy, &dummy, &dummy);
+if ( input > limit )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+}
+
 domain_cpuid(d, input, count, eax, ebx, ecx, edx);
 
 switch ( input )
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -952,6 +952,29 @@ void pv_cpuid(struct cpu_user_regs *regs
 if ( cpuid_hypervisor_leaves(leaf, subleaf, &a, &b, &c, &d) )
 goto out;
 
+if ( leaf & 0x7fff )
+{
+/*
+ * Requests outside the supported leaf ranges return zero on AMD
+ * and the highest basic leaf output on Intel. Uniformly follow
+ * the AMD model as the more sane one.
+ */
+unsigned int limit = (leaf >> 16) != 0x8000 ? 0 : 0x8000, dummy;
+
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, limit, 0, &limit, &dummy, &dummy, &dummy);
+else
+limit = cpuid_eax(limit);
+if ( leaf > limit )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+}
+
 if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
 domain_cpuid(currd, leaf, subleaf, &a, &b, &c, &d);
 else
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 3d20524af09243e3b2e3e832d1c62975e84a5dcd
baseline version:
 ovmf 11eaa7affb8b325b3e00bbe9e4357705ce3b2b08

Last test of basis   100749  2016-09-04 05:45:45 Z1 days
Testing same since   100754  2016-09-05 10:46:12 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=3d20524af09243e3b2e3e832d1c62975e84a5dcd
+ . ./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 
3d20524af09243e3b2e3e832d1c62975e84a5dcd
+ branch=ovmf
+ revision=3d20524af09243e3b2e3e832d1c62975e84a5dcd
+ . ./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
+ '[' x3d20524af09243e3b2e3e832d1c62975e84a5dcd = 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/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 

Re: [Xen-devel] [PATCH 2/2] x86/HVM: adjust feature checking in MSR intercept handling

[Andrew Cooper]

On 02/09/16 11:21, Jan Beulich wrote:
> 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 

:( Yet more overhead from extra hvm_cpuid() calls.  I really need to get
on with fixing it.

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

Re: [Xen-devel] [PATCH 1/2] VMX: correct feature checks for MPX and XSAVES

[Andrew Cooper]

On 02/09/16 11:21, Jan Beulich wrote:
> Their VMCS fields aren't tied to the respective base CPU feature flags
> but instead to VMX specific ones.
>
> Note that while the VMCS GUEST_BNDCFGS field exists if either of the
> two respective features is available, MPX continues to get exposed to
> guests only with both features present.
>
> Also add the so far missing handling of
> - GUEST_BNDCFGS in construct_vmcs()
> - MSR_IA32_BNDCFGS in vmx_msr_{read,write}_intercept()
> and mirror the extra correctness checks during MSR write to
> vmx_load_msr().
>
> Reported-by: "Rockosov, Dmitry" 
> Signed-off-by: Jan Beulich 
> Tested-by: "Rockosov, Dmitry" 

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

[Xen-devel] [linux-4.1 test] 100753: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 100587
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 100587
 build-amd64-rumpuserxen   6 xen-buildfail  like 100594
 build-i386-rumpuserxen6 xen-buildfail  like 100594
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeatfail  like 100594
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 100594
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100594
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100594
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100594
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100594
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 100594
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100594

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-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-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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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:
 linux3b60b86aec06fbae1142ccc4e55b39b529ae2a25
baseline version:
 linux99f614a3bb23603a947be2e95b78507112c484e5

Last test of basis   100594  2016-08-23 05:03:57 Z   13 days
Testing same since   100753  2016-09-05 06:44:50 Z0 days1 attempts


People who touched revisions under test:
  Agrawal, Nitesh-kumar 
  Alan Stern 
  Alex Deucher 
  Alexey Klimov 
  Andrej Krutak 
  Andrew Donnellan 
  Andrew Morton 
  Andrey Ryabinin 
  Artem Bityutskiy 
  Bart Van Assche 
  Benjamin Coddington 
  Bjorn Helgaas 
  Bruno Wolff III 
  Chen-Yu Tsai 
  Christian König 
  Christoph Huber 
  Daniel Lezcano 
  Daniel Mentz 
  Daniel Vetter 
  Daniel Vetter 
  Daniele Palmas 
  Dave Airlie 
  Dave Carroll 
  David S. Miller 
  David Vrabel 
  Dmitry Torokhov 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric Wheeler 
  Eric Wheeler 
  Felipe Balbi 
  Felipe Balbi 
  Felix Fietkau 
  Gavin Li 
  Gavin Shan 
  Greg Kroah-Hartman 
  Heikki Krogerus 
  Helge Deller 
  Herbert Xu 
  Ingo Molnar 
  Jan Beulich 
  Jani N

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

[Dario Faggioli]

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?

> > + * 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. :-)

> > + *  - if cpu is not in cur's soft-affinity, we should indeed
> > check to
> > + *see whether new should preempt cur. If that will be the
> > case, that
> > + *would be an improvement wrt respecting soft affinity;
> > + *  - if cpu is in cur's soft-affinity, we leave it alone and
> > (in
> > + *runq_tickle()) move on to another cpu. In fact, we don't
> > want to
> > + *be too harsh with someone which is running within its
> > soft-affinity.
> > + *This is safe because later, if we don't fine anyone else
> > during the
> > + *soft-affinity step, we will check cpu for preemption
> > anyway, when
> > + *doing hard-affinity.
> > + */
>
Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 v6 4/4] x86/ioreq server: Reset outstanding p2m_ioreq_server entries when an ioreq server unmaps.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> @@ -5551,7 +5553,35 @@ static int hvmop_map_mem_type_to_ioreq_server(
>  if ( rc != 0 )
>  goto out;
>  
> -rc = hvm_map_mem_type_to_ioreq_server(d, op.id, op.type, op.flags);
> +if ( gfn == 0 )
> +rc = hvm_map_mem_type_to_ioreq_server(d, op.id, op.type, op.flags);
> +
> +/*
> + * Iterate p2m table when an ioreq server unmaps from p2m_ioreq_server,
> + * and reset the remaining p2m_ioreq_server entries back to p2m_ram_rw.
> + */
> +if ( op.flags == 0 && rc == 0 )
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +
> +while ( read_atomic(&p2m->ioreq.entry_count) &&
> +gfn <= p2m->max_mapped_pfn )
> +{
> +unsigned long gfn_end = gfn + HVMOP_op_mask;
> +
> +p2m_finish_type_change(d, gfn, gfn_end,
> +   p2m_ioreq_server, p2m_ram_rw);
> +
> +/* Check for continuation if it's not the last iteration. */
> +if ( ++gfn_end <= p2m->max_mapped_pfn &&
> +hypercall_preempt_check() )
> +{
> +rc = -ERESTART;
> +*iter = gfn_end;
> +goto out;
> +}
> +}

"gfn" doesn't get updated, so if no preemption happens here, the
same GFN range will get acted on a second time (and so on, until
eventually preemption becomes necessary).

Also when you don't really need to use "goto", please try to avoid
it - here you could easily use just "break" instead.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -545,6 +545,9 @@ static int resolve_misconfig(struct p2m_domain *p2m, 
> unsigned long gfn)
>  e.ipat = ipat;
>  if ( e.recalc && p2m_is_changeable(e.sa_p2mt) )
>  {
> + if ( e.sa_p2mt == p2m_ioreq_server )
> + p2m->ioreq.entry_count--;

ISTR that George had asked you to put this accounting elsewhere.

And then I'd really like you to add assertions making sure this
count doesn't underflow.

> @@ -965,7 +968,8 @@ static mfn_t ept_get_entry(struct p2m_domain *p2m,
>  if ( is_epte_valid(ept_entry) )
>  {
>  if ( (recalc || ept_entry->recalc) &&
> - p2m_is_changeable(ept_entry->sa_p2mt) )
> + p2m_is_changeable(ept_entry->sa_p2mt) &&
> + (ept_entry->sa_p2mt != p2m_ioreq_server) )
>  *t = p2m_is_logdirty_range(p2m, gfn, gfn) ? p2m_ram_logdirty
>: p2m_ram_rw;
>  else

Considering this (and at least one more similar adjustment further
down), is it really appropriate to include p2m_ioreq_server in the
set of "changeable" types?

> +void p2m_finish_type_change(struct domain *d,
> +   unsigned long start, unsigned long end,
> +   p2m_type_t ot, p2m_type_t nt)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +p2m_type_t t;
> +unsigned long gfn = start;
> +
> +ASSERT(start <= end);
> +ASSERT(ot != nt);
> +ASSERT(p2m_is_changeable(ot) && p2m_is_changeable(nt));
> +
> +p2m_lock(p2m);
> +
> +end = (end > p2m->max_mapped_pfn) ? p2m->max_mapped_pfn : end;

min() or an if() without else.

> +while ( gfn <= end )
> +{
> +get_gfn_query_unlocked(d, gfn, &t);
> +
> +if ( t == ot )
> +p2m_change_type_one(d, gfn, t, nt);
> +
> +gfn++;
> +}
> +
> +p2m_unlock(p2m);
> +}

And then I wonder why p2m_change_type_range() can't be used
instead of adding this new function.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 100759: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  6 xen-boot fail REGR. vs. 100736
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 100736

Tests which did not succeed, but are not blocking:
 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  7539772a65b044f326ebf9528bd40e7c6a78c540
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z2 days
Testing same since   100755  2016-09-05 11:01:49 Z0 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  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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


Not pushing.


commit 7539772a65b044f326ebf9528bd40e7c6a78c540
Author: Marek Marczykowski-Górecki 
Date:   Mon Sep 5 11:26:04 2016 +0200

libxl: do not assume Dom0 backend while getting nic info

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Wei Liu 

commit b2f2ced591060588a45cdc7881a7335ba42b9cc5
Author: Wei Liu 
Date:   Mon Sep 5 11:36:45 2016 +0100

tools/firmware: Rename bios.bin to seabios.bin

bios.bin as a name is far too generic.  Rename it to seabios.bin.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
[ wei: fix up conflict, rerun autogen.sh ]
Signed-off-by: Wei Liu 

commit eb502cb30cc5af309ed824da024014afca1d0fcf
Author: Wei Liu 
Date:   Mon Sep 5 10:21:28 2016 +0100

libxl: update flex output files for DSA 3653-2

We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 5fdea6577098eda065c794c79e1ae23f33f103af
Author: He Chen 
Date:   Mon Sep 5 12:49:43 2016 +0200

x86: allow disabling sm{e,a}p for Xen itself

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.

This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He Chen 
[jbeulich: doc and style adjustments]
Reviewed-by: Jan Beulich 

commit 698d0f377d72fdc8d4e247e76b6508090c366187
Author: Razvan Cojocaru 
Date:   Mon Sep 5 12:47:46 2016 +0200

have __DEFINE_COMPAT_HANDLE() generate const versions

Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE()
each produce both const and non-const handles,
only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE()
does not). This patch has __DEFINE_COMPAT_HANDLE() also
produce a const handle.

Suggested-by: Jan Be

[Xen-devel] [MINIOS PATCH] Add travis.yml and travis-build script

[Wei Liu]

Signed-off-by: Wei Liu 
---
See:
https://travis-ci.org/liuw/mini-os/builds/157653746

Cc: Samuel Thibault 
Cc: Juergen Gross 
Cc: Doug Goldstein 

IRC notification is not yet set up.

Doug, can we mirror mini-os.git to github/xen-project as well? I think
it would also be a good idea to post notification to #xentest.
---
 .travis.yml  | 25 +
 scripts/travis-build |  5 +
 2 files changed, 30 insertions(+)
 create mode 100644 .travis.yml
 create mode 100755 scripts/travis-build

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..9aa69a5
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,25 @@
+language: c
+dist: trusty
+sudo: required
+# don't test stable branches
+branches:
+except:
+- /^stable-.*/
+matrix:
+include:
+- compiler: gcc
+addons:
+apt:
+sources:
+- ubuntu-toolchain-r-test
+packages:
+- libc6-dev-i386
+- gcc-5
+- g++-5
+# we must set CXX manually instead of using 'language: cpp' due to
+# travis-ci/travis-ci#3871
+before_script:
+- export CXX=${CC/cc/++}
+- export CXX=${CXX/clang/clang++}
+script:
+- ./scripts/travis-build
diff --git a/scripts/travis-build b/scripts/travis-build
new file mode 100755
index 000..9480a9d
--- /dev/null
+++ b/scripts/travis-build
@@ -0,0 +1,5 @@
+#!/bin/bash -ex
+
+$CC --version
+
+make testbuild
-- 
2.1.4


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

[Xen-devel] [PATCH v2] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

Add a new xl command "qemu-monitor-command" to issue arbitrary commands
to a domain's device model. Syntax is:

xl qemu-monitor-command  

The command is issued via qmp human-monitor-command command. Any
information returned by the command is printed to stdout.

Signed-off-by: Juergen Gross 
---
 docs/man/xl.pod.1.in   | 36 
 tools/libxl/libxl.h| 14 ++
 tools/libxl/libxl_colo_qdisk.c |  2 +-
 tools/libxl/libxl_internal.h   |  3 ++-
 tools/libxl/libxl_qmp.c| 38 --
 tools/libxl/xl.h   |  1 +
 tools/libxl/xl_cmdimpl.c   | 27 +++
 tools/libxl/xl_cmdtable.c  |  5 +
 8 files changed, 122 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 1adf322..a2be541 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1516,6 +1516,42 @@ List pass-through usb devices for a domain.
 
 =back
 
+=head1 DEVICE-MODEL CONTROL
+
+=over 4
+
+=item B I I
+
+Issue a monitor command to the device model of the domain specified by
+I. I can be any valid command qemu understands. This
+can be e.g. used to add non-standard devices or devices with non-standard
+parameters to a domain. The output of the command is printed to stdout.
+
+B This qemu monitor access is provided for convenience when
+debugging, troubleshooting, and experimenting.  Its use is not
+supported by the Xen Project.
+
+Specifically, not all information printed by the qemu monitor will
+necessarily be accurate or complete, because in a Xen system qemu
+does not have a complete view of the guest.
+
+Furthermore, modifying the guest's setup via the qemu monitor may
+conflict with the Xen toolstack's assumptions.  Resulting problems
+may include, but are not limited to: guest crashes; toolstack error
+messages; inability to migrate the guest; and security
+vulnerabilities which are not covered by the Xen Project security
+response policy.
+
+B
+
+Obtain information of USB devices connected as such via the device model
+(only!) to a domain:
+
+ xl qemu-monitor-command vm1 'info usb'
+  Device 0.2, Port 5, Speed 480 Mb/s, Product Mass Storage
+
+=back
+
 =head1 TMEM
 
 =over 4
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index e4c25c4..7cfa540 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -275,6 +275,12 @@
 #define LIBXL_HAVE_BUILD_ID 1
 
 /*
+ * LIBXL_HAVE_QEMU_MONITOR_COMMAND indiactes the availability of the
+ * libxl_qemu_monitor_command() function.
+ */
+#define LIBXL_HAVE_QEMU_MONITOR_COMMAND 1
+
+/*
  * libxl ABI compatibility
  *
  * The only guarantee which libxl makes regarding ABI compatibility
@@ -2152,6 +2158,14 @@ void libxl_psr_cat_info_list_free(libxl_psr_cat_info 
*list, int nr);
 int libxl_fd_set_cloexec(libxl_ctx *ctx, int fd, int cloexec);
 int libxl_fd_set_nonblock(libxl_ctx *ctx, int fd, int nonblock);
 
+/*
+ * Issue a qmp monitor command to the device model of the specified domain.
+ * The function returns the output of the command in a new allocated buffer
+ * via output.
+ */
+int libxl_qemu_monitor_command(libxl_ctx *ctx, uint32_t domid,
+   const char *command_line, char **output);
+
 #include 
 
 #endif /* LIBXL_H */
diff --git a/tools/libxl/libxl_colo_qdisk.c b/tools/libxl/libxl_colo_qdisk.c
index c23b81b..d271d1f 100644
--- a/tools/libxl/libxl_colo_qdisk.c
+++ b/tools/libxl/libxl_colo_qdisk.c
@@ -173,7 +173,7 @@ static void colo_qdisk_save_preresume(libxl__egc *egc,
 "file.driver=nbd,file.host=%s,file.port=%d,"
 "file.export=%s,node-name=%s,if=none",
 host, port, export_name, node);
-ret = libxl__qmp_hmp(gc, domid, cmd);
+ret = libxl__qmp_hmp(gc, domid, cmd, NULL);
 if (ret)
 rc = ERROR_FAIL;
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ce8e17a..9f534c4 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1818,7 +1818,8 @@ _hidden int libxl__qmp_x_blockdev_change(libxl__gc *gc, 
int domid,
  const char *parant,
  const char *child, const char *node);
 /* run a hmp command in qmp mode */
-_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line);
+_hidden int libxl__qmp_hmp(libxl__gc *gc, int domid, const char *command_line,
+   char **out);
 /* close and free the QMP handler */
 _hidden void libxl__qmp_close(libxl__qmp_handler *qmp);
 /* remove the socket file, if the file has already been removed,
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 63c49c5..33883b8 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1103,14 +1103,48 @@ int libxl__qmp_x_blockdev_change(libxl__gc *gc, int 
domid, const char *parent,
 return qmp_run_command(gc, domid, "x-blockdev-change", args, NU

Re: [Xen-devel] [PATCH v6 3/4] x86/ioreq server: Handle read-modify-write cases for p2m_ioreq_server pages.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -95,6 +95,41 @@ static const struct hvm_io_handler null_handler = {
>  .ops = &null_ops
>  };
>  
> +static int mem_read(const struct hvm_io_handler *io_handler,
> +uint64_t addr,
> +uint32_t size,
> +uint64_t *data)
> +{
> +struct domain *currd = current->domain;
> +unsigned long gmfn = paddr_to_pfn(addr);
> +unsigned long offset = addr & ~PAGE_MASK;
> +struct page_info *page = get_page_from_gfn(currd, gmfn, NULL, 
> P2M_UNSHARE);
> +uint8_t *p;

const (and preferably also void)

> +ASSERT(offset + size < PAGE_SIZE);

Surely <= ?

> +if ( !page )
> +return X86EMUL_UNHANDLEABLE;
> +
> +p = __map_domain_page(page);
> +p += offset;
> +memcpy(data, p, size);
> +
> +unmap_domain_page(p);
> +put_page(page);

But anyway - I think rather than all this open coding you would
better call hvm_copy_from_guest_phys().

> +static const struct hvm_io_ops mem_ops = {
> +.read = mem_read,
> +.write = null_write
> +};
> +
> +static const struct hvm_io_handler mem_handler = {
> +.ops = &mem_ops
> +};

I think the mem_ prefix for both objects is a bad one, considering
that this isn't suitable for general memory handling.

> @@ -204,7 +239,15 @@ static int hvmemul_do_io(
>  /* If there is no suitable backing DM, just ignore accesses */
>  if ( !s )
>  {
> -rc = hvm_process_io_intercept(&null_handler, &p);
> +/*
> + * For p2m_ioreq_server pages accessed with read-modify-write
> + * instructions, we provide a read handler to copy the data to
> + * the buffer.
> + */
> +if ( p2mt == p2m_ioreq_server )

Please add unlikely() here, or aid the compiler in avoiding any
branch by ...

> +rc = hvm_process_io_intercept(&mem_handler, &p);
> +else
> +rc = hvm_process_io_intercept(&null_handler, &p);

... using a conditional expression for the first function argument.

And the comment ahead of the if() now also needs adjustment
(perhaps you want to merge the one you add into that one).

Jan


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

[Xen-devel] [OSSTEST PATCH 04/26] rumprun: Rename all `rumpuserxen' to `rumprun'

[Ian Jackson]

The names have changed upstream.

Since upstream is no longer compatible and these tests have been
failing since then, we are going to treat this as an entirely new test
series.

In this patch we rename everything mechanically.  More interesting
changes will come later.

git-mv -f ts-rumpuserxen-build ts-rumprun-build
git-mv -f ts-rumpuserxen-demo-setup ts-rumprun-demo-setup
git-mv -f ts-rumpuserxen-demo-xenstorels ts-rumprun-demo-xenstorels

git-ls-files | xargs perl -i~ -pe 's/rumpuserxen/rumprun/g'
git-ls-files | xargs perl -i~ -pe 's/(_|\b)rumpuserxen(_|\b)/$1rumprun$2/g'

Signed-off-by: Ian Jackson 
---
 allow.all  |   4 +-
 allow.rumpuserxen  |   2 +-
 ap-common  |  16 +++---
 ap-fetch-version   |   6 +-
 ap-fetch-version-old   |   8 +--
 ap-print-url   |   4 +-
 ap-push|   8 +--
 cr-daily-branch|  12 ++--
 cri-common |   2 +-
 crontab|   4 +-
 make-flight|  14 ++---
 mfi-common |  16 +++---
 sg-run-job |  18 +++---
 ts-rumprun-build   | 126 +
 ts-rumprun-demo-setup  |  92 ++
 ts-rumprun-demo-xenstorels | 124 
 ts-rumpuserxen-build   | 126 -
 ts-rumpuserxen-demo-setup  |  92 --
 ts-rumpuserxen-demo-xenstorels | 124 
 19 files changed, 399 insertions(+), 399 deletions(-)
 create mode 100755 ts-rumprun-build
 create mode 100755 ts-rumprun-demo-setup
 create mode 100755 ts-rumprun-demo-xenstorels
 delete mode 100755 ts-rumpuserxen-build
 delete mode 100755 ts-rumpuserxen-demo-setup
 delete mode 100755 ts-rumpuserxen-demo-xenstorels

diff --git a/allow.all b/allow.all
index 785d0b2..c4a2854 100644
--- a/allow.all
+++ b/allow.all
@@ -2,6 +2,6 @@ test-@@-rtds@@
 build-@@logs-capture@@
 test-@@-pcipt@@
 test-@@-qemuu-@@   guest-localmigrate
-test-@@-rumpuserxen@@  rumpuserxen-demo-xenstorels/xenstorels
+test-@@-rumprun@@  rumprun-demo-xenstorels/xenstorels
 test-@@-win7-@@guest-stop
-test-@@-rumpuserxen-@@ rumpuserxen-demo-xenstorels/xenstorels.repeat
+test-@@-rumprun-@@ rumprun-demo-xenstorels/xenstorels.repeat
diff --git a/allow.rumpuserxen b/allow.rumpuserxen
index d9034a2..436417b 100644
--- a/allow.rumpuserxen
+++ b/allow.rumpuserxen
@@ -1 +1 @@
-!test-@@-rumpuserxen-@@
rumpuserxen-demo-xenstorels/xenstorels.repeat
+!test-@@-rumprun-@@rumprun-demo-xenstorels/xenstorels.repeat
diff --git a/ap-common b/ap-common
index 19c7580..6fe3b78 100644
--- a/ap-common
+++ b/ap-common
@@ -37,15 +37,15 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_RUMPUSERXEN:=https://github.com/rumpkernel/rumprun-xen}
-: ${TREEVCS_RUMPUSERXEN:=git}
-: ${BASE_TREE_RUMPUSERXEN:=git://xenbits.xen.org/rumpuser-xen.git}
-: ${PUSH_TREE_RUMPUSERXEN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
+: ${TREE_RUMPRUN:=https://github.com/rumpkernel/rumprun-xen}
+: ${TREEVCS_RUMPRUN:=git}
+: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
+: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
 
-: ${TREE_RUMPUSERXEN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
-: ${TREEVCS_RUMPUSERXEN_RUMPSRC:=git}
+: ${TREE_RUMPRUN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
+: ${TREEVCS_RUMPRUN_RUMPSRC:=git}
 # rumpsrc-related runvars needed only for old rumpuser-xen
-# (ie ones which need $bodges=1 in ts-rumpuserxen-build)
+# (ie ones which need $bodges=1 in ts-rumprun-build)
 
 : ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
 : ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
@@ -79,7 +79,7 @@ fi
 : ${LOCALREV_XEN:=daily-cron.$branch}
 : ${LOCALREV_LINUX:=daily-cron.$branch}
 : ${LOCALREV_LIBVIRT:=daily-cron.$branch}
-: ${LOCALREV_RUMPUSERXEN:=daily-cron.$branch}
+: ${LOCALREV_RUMPRUN:=daily-cron.$branch}
 : ${LOCALREV_SEABIOS:=daily-cron.$branch}
 : ${LOCALREV_OVMF:=daily-cron.$branch}
 
diff --git a/ap-fetch-version b/ap-fetch-version
index f26d60a..8562159 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -90,9 +90,9 @@ libvirt)
repo_tree_rev_fetch_git libvirt \
$TREE_LIBVIRT master $LOCALREV_LIBVIRT
;;
-rumpuserxen)
-   repo_tree_rev_fetch_git rumpuserxen \
-   $TREE_RUMPUSERXEN master $LOCALREV_RUMPUSERXEN
+rumprun)
+   repo_tree_rev_fetch_git rumprun \
+   $TREE_RUMPRUN master $LOCALREV_RUMPRUN
;;
 seabios)
repo_tree_rev_fetch_git seabios \
diff --git a/ap-fetch

[Xen-devel] [OSSTEST PATCH 24/26] rumprun: xenstorels: Do not attempt to edit the config file

[Ian Jackson]

There is no config file any more, so this function now crashes due to
passing undef to target_editfile_root.

We do not need to edit it to set on_poweroff to preserve because this
is the default for rumprun.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index 47aa289..a40110a 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -30,20 +30,6 @@ our $domid;
 
 our $gn = $gho->{Guest};
 
-sub arrangepreserve () {
-target_editfile_root($ho,$r{"$gho->{Guest}_cfgpath"}, sub {
-   while () {
-   if (m/^\s*on_poweroff\s*=/) {
-   target_editfile_cancel("already configured to preserve")
-   if m/\bpreserve\b/;
-   next;
-   }
-   print EO or die $!;
-   }
-   print EO "\n","on_poweroff='preserve'\n" or die $!;
-});
-}
-
 sub start () {
 rumprun_guest_create($gho);
 
@@ -118,7 +104,6 @@ sub check_output () {
 }
 }
 
-arrangepreserve();
 start();
 await_end();
 check_output();
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 18/26] rumprun: ts-rumprun-build: set up ccache

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 24e54e1..26f2f2c 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -54,6 +54,7 @@ END
 
 my $bindir;
 my $gnutriplet;
+my $ccachedir;
 
 sub findtools() {
 my $gcc = target_cmd_output($ho, "echo $rux/rumprun/bin/*-gcc");
@@ -63,8 +64,19 @@ sub findtools() {
 $gnutriplet = $2;
 }
 
+sub setupccache() {
+$ccachedir = "$bindir.ccache";
+target_cmd_build($ho, 600, $rux, 

[Xen-devel] [OSSTEST PATCH 26/26] rumprun: xenstorels: Improve an error message slightly

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index 831c58a..3d29c46 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -83,7 +83,7 @@ sub their_xenstorels () {
$output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or
$output{theirs} =~ m{\n=== ERROR: _exit\((\d+)\) called ===\n} or die;
$output{theirs} = $`;
-   die "$1 ?" if $1 ne '0';
+   die "EXIT STATUS $1 ?" if $1 ne '0';
$output{theirs} =~ s{^STUB \`\`\w+'' called\n}{}mg;
 }, 

[Xen-devel] [OSSTEST PATCH 19/26] Xen built versions: Move list of subtrees to BuildSupport

[Ian Jackson]

Turn the adhoc list of tree names and subdirectories in
collect_xen_built_versions into a hash, which we iterate over.

Doing this in a data-driven way allows us to provide this information
to callers of collect_xen_built_versions, which is going to be helpful
in a moment.

Signed-off-by: Ian Jackson 
---
 Osstest/BuildSupport.pm | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/Osstest/BuildSupport.pm b/Osstest/BuildSupport.pm
index a183546..d59eace 100644
--- a/Osstest/BuildSupport.pm
+++ b/Osstest/BuildSupport.pm
@@ -42,7 +42,7 @@ BEGIN {
 
   xendist
   $xendist
-  collect_xen_built_versions
+  collect_xen_built_versions %xensubtrees
 
   submodulefixup submodule_have submodule_find
 
@@ -85,15 +85,21 @@ sub xendist () {
($ho, 'xendist', '', $r{"buildjob"});
 }
 
+our %xensubtrees = qw(
+qemu   tools/ioemu-dir
+qemu   tools/qemu-xen-traditional-dir
+qemuu  tools/qemu-xen-dir
+seabiostools/firmware/seabios-dir
+ovmf   tools/firmware/ovmf-dir
+minios extras/mini-os
+);
+
 sub collect_xen_built_versions () {
-my $tools="$builddir/xen/tools";
-my $extras="$builddir/xen/extras";
-store_revision($ho, 'qemu', "$tools/ioemu-dir", 1);
-store_revision($ho, 'qemu', "$tools/qemu-xen-traditional-dir", 1);
-store_revision($ho, 'qemuu', "$tools/qemu-xen-dir", 1);
-store_revision($ho, 'seabios', "$tools/firmware/seabios-dir", 1);
-store_revision($ho, 'ovmf', "$tools/firmware/ovmf-dir", 1);
-store_revision($ho, 'minios', "$extras/mini-os", 1);
+my $xendir = "$builddir/xen";
+foreach my $subtree (sort keys %xensubtrees) {
+   my $subdir = $xendir.'/'.$xensubtrees{$subtree};
+   store_revision($ho, $subtree, "$subdir", 1);
+}
 }
 
 #- submodules -
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 02/26] Executive: Allow out-of-order manipulations of flights intended play

[Ian Jackson]

Flights being operated on by a developer hacking about with the code,
which were created with intended blessing `play', are usually blessed
`running' or `broken' or something.  So the safety catch bypass needs
to look at the intended blessing too.

Signed-off-by: Ian Jackson 
---
 Osstest/JobDB/Executive.pm | 6 +++---
 README.dev | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 51c1ebb..c21eba7 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -102,14 +102,14 @@ sub dbfl_check ($$) { #method
 }
 die unless ref($flok) eq 'ARRAY';
 
-my ($bless) = $dbh_tests->selectrow_array(

[Xen-devel] [OSSTEST PATCH 25/26] rumprun: xenstorels: New regexps for finding output

[Ian Jackson]

The framing output in rumprun upstream has changed.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-demo-xenstorels | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ts-rumprun-demo-xenstorels b/ts-rumprun-demo-xenstorels
index a40110a..831c58a 100755
--- a/ts-rumprun-demo-xenstorels
+++ b/ts-rumprun-demo-xenstorels
@@ -77,10 +77,11 @@ END
 sub their_xenstorels () {
 some_xenstorels('theirs', sub {
$output{theirs} =~ s{\r\n}{\n}g;
-   while ($output{theirs} =~ m{\n=== calling main\(\) ===\n\n}) {
+   while ($output{theirs} =~ m{\n=== calling ".*" main\(\) ===\n\n}) {
$output{theirs} = $'; #';
}
-   $output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or die;
+   $output{theirs} =~ m{\n=== main\(\) returned (\d+) ===\n} or
+   $output{theirs} =~ m{\n=== ERROR: _exit\((\d+)\) called ===\n} or die;
$output{theirs} = $`;
die "$1 ?" if $1 ne '0';
$output{theirs} =~ s{^STUB \`\`\w+'' called\n}{}mg;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 16/26] rumprun: Do not run xen/Kconfig

[Ian Jackson]

We aren't going to cross-build a Xen hypervisor for the rump
environment.  So don't configure it.

Signed-off-by: Ian Jackson 
---
 sg-run-job | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sg-run-job b/sg-run-job
index 0c7835e..eb3df26 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -477,7 +477,7 @@ proc run-job/build-libvirt {} {
 
 proc run-job/build-rumprun {} {
 run-ts . = ts-rumprun-build
-run-ts . = ts-xen-build + host tools
+run-ts . = ts-xen-build + host --no-kconfig tools
 }
 
 proc prepare-build-host {} {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 13/26] rumprun: ts-rumprun-build: Update for new rumprun bin location

[Ian Jackson]

The compiler wrappers are in a different location in the new rumprun
build tree.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index cb91d5c..7184f9d 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -53,7 +53,7 @@ END
 }
 
 sub recordtools() {
-my $gcc = target_cmd_output($ho, "echo $rux/bin/*-gcc");
+my $gcc = target_cmd_output($ho, "echo $rux/rumprun/bin/*-gcc");
 chomp $gcc;
 die "$gcc ?" if $gcc =~ m/\S/;
 my $prefix = "CC=$gcc ";
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 20/26] Xen built versions: ts-xen-build: check versions of Xen subtrees, only

[Ian Jackson]

ts-xen-build has a check that the actually-built versions of the
various subtrees are right.  This allows it to spot if the machinery
for specifying the subtree revision hasn't worked.

However, this machinery is troublesome: it assumes that the value
specified in the revision_TREE runvar is a commit id, just like the
value specified in built_revision_TREE.  This is, currently, true in
flights created by cr-daily-branch and cs-try-bisect.

But it is not necessarily true for flights created other ways.  In
principle it would be possible to look into each checked out subtree,
and use git-rev-parse (and its equivalent for nother VCSs) to check
whether the specified revision is right (by comparing it to
origin/, not , I guess).  This is quite
fiddly.

The reason this is causing trouble now is that some of the ad-hoc rump
kernel flights I'm currently making contain non-git-revison-id values
for the revision_TREE for parts of the rumprun build.

So for now, limiting this check to TREEs which are actually Xen
subtrees will fix the problem for me (and this will be necessary for
the fuller fix, which I describe above).  So do that.

Specifically:
 * Add a new WHERE clause to the query statement, so that it selects
   only the row for one specific tree
 * Run the query once for each tree in %xensubtrees

This leaves the query overly-complicated, but this doesn't matter,
because if and when we make a fuller fix we'll throw this entire query
away.  So it is easier to put off rewriting it in the hope that this
will never been needed.

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ts-xen-build b/ts-xen-build
index f5cff8b..cc171ef 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -217,10 +217,13 @@ sub checkversions () {
  WHERE reqd.flight=? and reqd.job=?
AND built.flight=? and built.job=?
AND built.name = 'built_' || reqd.name
+   AND reqd.name = ?
 END
-$chk->execute($flight,$job,$flight,$job);
 my $mismatches= 0;
-while (my $row= $chk->fetchrow_arrayref()) {
+foreach my $subtree (sort keys %xensubtrees) {
+   $chk->execute($flight,$job,$flight,$job,$subtree);
+   my $row= $chk->fetchrow_arrayref();
+   next unless $row;
 my ($tree, $reqd, $built) = @$row;
 next unless defined $reqd && defined $built;
 $reqd =~ s/^.*://;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 23/26] rumprun: `rumpbake' our executables and run them with `rumprun'

[Ian Jackson]

(Well, our one executable: xenstore-ls)

Modern rumprun requires the output of the linker to be `baked' (second
link phase, where the complete unikernel is assembled).

This has to be done as part of the build, because it needs all the
rumpkernel libraries.  It generates a single image file - there is no
longer any disk image or config file produced by the rump ecosystem.

The baked file needs to be provided in a dist.  We have
ts-rumprun-bake take command line argument specifying which things to
bake.  It reads the runvars for the source executables and creates a
single dist output containing the images.  There are now `executables'
and `images'.

Furthermore modern rumprun requires the image to be run with
`rumprun'.  One underlying reason is that it wants to pass the command
line and some other config parameters to the guest via xenstore, in
/local/domain/GUEST/rumprun/cfg.  To do this outside xl requires the
domain to be created paused.  Another is to abstract away details of
the actual execution environment (compared to other unikernel
execution models).

rumprun has a mode (-D -T) in which it would be possible to fish the
configuration and the desired json object (for the cfg) out of the
tempfile it creates.  It might also be possible for osstest to
construct these out of whole cloth.

However, this would be undesirable because it would break if rumprun
changed (in particular, if the interface to the domain creation
changed).

And because of the cfg wrinkle it still wouldn't let us construct a
domain config file which could be passed to
toolstack($ho)->guest_create.

So instead we invent Osstest::Rumprun::rumprun_guest_create, which
invokes rumprun.  rumprun implicitly invokes xl.

The config editing which was previously done by ts-rumprun-demo-setup
is now done by passing appropriate options to rumprun.

Signed-off-by: Ian Jackson 
---
 Osstest/RumpRun.pm | 67 ++
 make-flight|  2 +-
 sg-run-job |  2 ++
 ts-rumprun-bake| 89 ++
 ts-rumprun-demo-setup  | 52 ---
 ts-rumprun-demo-xenstorels |  3 +-
 6 files changed, 167 insertions(+), 48 deletions(-)
 create mode 100644 Osstest/RumpRun.pm
 create mode 100755 ts-rumprun-bake

diff --git a/Osstest/RumpRun.pm b/Osstest/RumpRun.pm
new file mode 100644
index 000..0582bd2
--- /dev/null
+++ b/Osstest/RumpRun.pm
@@ -0,0 +1,67 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2013 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+package Osstest::RumpRun;
+
+use strict;
+use warnings;
+
+use Osstest::TestSupport;
+
+BEGIN {
+use Exporter ();
+our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+$VERSION = 1.00;
+@ISA = qw(Exporter);
+@EXPORT  = qw(
+ rumprun_guest_create
+   );
+%EXPORT_TAGS = ( );
+
+@EXPORT_OK   = qw();
+}
+
+sub rumprun_guest_create ($) {
+my ($gho) = @_;
+my $ho = $gho->{Host};
+my $gn = $gho->{Guest};
+guest_prepare_disk($gho);
+
+my $rumprun = target_var($gho, 'rumprun_path');
+if (!$rumprun) {
+   logm("finding rumprun to use for $gho->{Name} on $ho->{Name}");
+   my $buildjob = $r{guests_rumprunbuildjob} // # todo: eliminate this
+   target_var($gho, 'rumprunbuildjob');
+   my $rumprundist = target_extract_jobdistpath_subdir
+   ($ho, "rumprun-rumprun-g-$gho->{Name}", "rumprun", $buildjob);
+   $rumprun = "$rumprundist/rumprun";
+   store_runvar("${gn}_rumprun_path", $rumprun);
+}
+
+my $imagepath = $r{"${gn}_imagepath"};
+my $cmdline = guest_var($gho, 'cmdline', undef);
+
+my $cmd = "$rumprun xen";
+$cmd .= " -N $gn";
+$cmd .= " -IIFTAG,IFBASENAME,mac=$gho->{Ether}";
+$cmd .= " $imagepath";
+$cmd .= " $cmdline";
+
+target_cmd_root($ho, $cmd, 100);
+}
+
+1;
diff --git a/make-flight b/make-flight
index 906bf2b..c94dfa4 100755
--- a/make-flight
+++ b/make-flight
@@ -203,7 +203,7 @@ do_rumpkernel_tests () {
 guests_rumprunbuildjob=build-$rumparch-rumprun   \
  rump_builtimage=rumprun:/usr/local/lib/xen/rump-kernel/rump-kernel \
 rump_cmdline=3   \
-xenstore

[Xen-devel] [OSSTEST PATCH 05/26] rumprun: Fetch source from new upstream

[Ian Jackson]

Also, update for the current set of submodules.

Signed-off-by: Ian Jackson 
---
 ap-common| 2 +-
 ts-rumprun-build | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/ap-common b/ap-common
index 6fe3b78..14cc25a 100644
--- a/ap-common
+++ b/ap-common
@@ -37,7 +37,7 @@
 : ${PUSH_TREE_LIBVIRT:=$XENBITS:/home/xen/git/libvirt.git}
 : ${BASE_TREE_LIBVIRT:=git://xenbits.xen.org/libvirt.git}
 
-: ${TREE_RUMPRUN:=https://github.com/rumpkernel/rumprun-xen}
+: ${TREE_RUMPRUN:=http://repo.rumpkernel.org/rumprun}
 : ${TREEVCS_RUMPRUN:=git}
 : ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
 : ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
diff --git a/ts-rumprun-build b/ts-rumprun-build
index 574781f..abc1f7d 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -25,9 +25,8 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 builddirsprops();
 
-our %submodmap = qw(nblibs nblibs
-buildrump.sh buildrumpsh
-rumpsrc netbsdsrc);
+our %submodmap = qw(buildrump.sh buildrumpsh
+src-netbsd netbsdsrc);
 
 our ($rux, $bodges);
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 06/26] rumprun: Move xenbits tree to osstest subdir

[Ian Jackson]

Move our tested tree to /home/xen/git/osstest, where these kind of
things live nowadays.

Signed-off-by: Ian Jackson 
---
 ap-common | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ap-common b/ap-common
index 14cc25a..212da18 100644
--- a/ap-common
+++ b/ap-common
@@ -39,8 +39,8 @@
 
 : ${TREE_RUMPRUN:=http://repo.rumpkernel.org/rumprun}
 : ${TREEVCS_RUMPRUN:=git}
-: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/rumpuser-xen.git}
-: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/rumpuser-xen.git}
+: ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/osstest/rumprun.git}
+: ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/osstest/rumprun.git}
 
 : ${TREE_RUMPRUN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
 : ${TREEVCS_RUMPRUN_RUMPSRC:=git}
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 03/26] TestSupport: Produce stack trace for undef tfileex

[Ian Jackson]

Use `confess' to see where an undef $rfile came from.  I think there
will probably be lots more of this pattern.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d0d6ef3..a6ab18f 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -31,6 +31,7 @@ use Osstest::Logtailer;
 use File::Copy;
 use File::Basename;
 use IO::Handle;
+use Carp;
 
 BEGIN {
 use Exporter ();
@@ -523,6 +524,8 @@ sub teditfileex {
 my $code= pop @_;
 my ($ho,$rfile,$lleaf,$rdest) = @_;
 
+confess unless defined $rfile;
+
 if (!defined $rdest) {
 $rdest= $rfile;
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 15/26] rumprun: Drop old rumpuserxen demo

[Ian Jackson]

The WOPR demo is gone from rumpkernel upstream.

Sadly this leaves us without a test that the rump environment's
networking is functional.

Signed-off-by: Ian Jackson 
---
 sg-run-job | 4 
 1 file changed, 4 deletions(-)

diff --git a/sg-run-job b/sg-run-job
index 31a5589..0c7835e 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -443,10 +443,6 @@ proc test-guest-nomigr {g} {
 
 proc need-hosts/test-rumprun {} { return host }
 proc run-job/test-rumprun {} {
-set g rump
-run-ts . =   ts-rumprun-demo-setup + host $g
-run-ts . =   ts-guest-start+ host $g
-run-ts . =   ts-guest-destroy  + host $g
 set g xenstorels
 run-ts . =   ts-rumprun-demo-setup  + host + $g
 run-ts . =   ts-rumprun-demo-xenstorels + host + $g
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 08/26] rumprun: ts-rumprun-build: Build new rumprun properly, ship the output

[Ian Jackson]

The command is `build-rr.sh' nowadays.  The output longer includes
test domain image and configuration.  The output is in `rumprun'.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 55420f0..93c34d1 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -46,7 +46,7 @@ sub massage() {
 sub build() {
 target_cmd_build($ho, 7200, $rux, 

[Xen-devel] [OSSTEST PATCH 09/26] rumprun: ts-rumprun-build: Adjust command prefixes for new rumprun

[Ian Jackson]

Nowadays the expected use pattern is
   CC=<...rumprun...>-gcc ./configure
etc.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 93c34d1..cb91d5c 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -53,14 +53,12 @@ END
 }
 
 sub recordtools() {
-foreach my $stem (qw(rumprun-xen rumpxen-app)) {
-   my $apptool = "$rux/app-tools/$stem";
-   next unless target_file_exists($ho, "$apptool-configure");
-   store_runvar('cmdprefix_configure', "$apptool-configure");
-   store_runvar('cmdprefix_make',  "$apptool-make");
-   return;
-}
-die "app-tools not found ($rux)";
+my $gcc = target_cmd_output($ho, "echo $rux/bin/*-gcc");
+chomp $gcc;
+die "$gcc ?" if $gcc =~ m/\S/;
+my $prefix = "CC=$gcc ";
+store_runvar('cmdprefix_configure', $prefix);
+store_runvar('cmdprefix_make',  $prefix);
 }
 
 sub install() {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 01/26] Executive: Do update flights_harness_touched for play flights

[Ian Jackson]

Have \bplay\b simply bypass the blessing check, but not the harness
revision update which follows.

Signed-off-by: Ian Jackson 
---
 Osstest/JobDB/Executive.pm | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index c0af21c..51c1ebb 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -108,9 +108,11 @@ END
 
 die "modifying flight $fl but flight not found\n"
 unless defined $bless;
-return if $bless =~ m/\bplay\b/;
-die "modifying flight $fl blessing $bless expected @$flok\n"
-unless grep { $_ eq $bless } @$flok;
+
+unless ($bless =~ m/\bplay\b/) {
+   die "modifying flight $fl blessing $bless expected @$flok\n"
+   unless grep { $_ eq $bless } @$flok;
+}
 
 my $rev = get_harness_rev();
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 17/26] rumprun: Break out findtools

[Ian Jackson]

This makes room for setting up ccache.

No functional change yet.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 98c8efc..24e54e1 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -52,12 +52,18 @@ sub build() {
 END
 }
 
-sub recordtools() {
+my $bindir;
+my $gnutriplet;
+
+sub findtools() {
 my $gcc = target_cmd_output($ho, "echo $rux/rumprun/bin/*-gcc");
 chomp $gcc;
 die "$gcc ?" unless $gcc =~ m#^(\S+)/([^/ \t]+)-g?cc$#;
-my $bindir = $1;
-my $gnutriplet = $2;
+$bindir = $1;
+$gnutriplet = $2;
+}
+
+sub recordtools() {
 my $prefix = "PATH=$bindir:\$PATH ";
 $prefix .= "CROSS_COMPILE=$gnutriplet- HOSTCC=gcc ";
 store_runvar('cmdprefix_configure', $prefix);
@@ -74,6 +80,7 @@ sub install() {
 checkout();
 massage();
 build();
+findtools();
 recordtools();
 install();
 built_stash($ho, $builddir, 'rumprun', 'rumprundist');
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 12/26] ts-xen-build: Support --no-kconfig

[Ian Jackson]

Nothing passes this yet, so no functional change.

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/ts-xen-build b/ts-xen-build
index 4f06419..f5cff8b 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -25,7 +25,20 @@ use Osstest::BuildSupport;
 
 tsreadconfig();
 selectbuildhost(\@ARGV);
+
+our $dokconfig = 1;
+
+while (@ARGV && $ARGV[0] =~ m/^-/) {
+$_ = shift @ARGV;
+last if m/^--$/;
+if (m/^--no-kconfig$/) {
+   $dokconfig = 0;
+} else {
+   die "$_ ?";
+}
+}
 # remaining arguments are passed as targets to "make"
+
 builddirsprops();
 
 my $enable_xsm = ($r{enable_xsm}//'false') =~ m/true/ ? 1 : 0;
@@ -127,7 +140,7 @@ END
 END
 #/;
 
-buildcmd_stamped_logged(600, 'kconfig', '',

[Xen-devel] [OSSTEST PATCH 21/26] rumprun: Do not stash whole build tree

[Ian Jackson]

Build steps all need the whole build tree in the same location, so
have to be part of this job.

Test jobs need only rumprun.

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 26f2f2c..1913f29 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -96,4 +96,4 @@ findtools();
 setupccache();
 recordtools();
 install();
-built_stash($ho, $builddir, 'rumprun', 'rumprundist');
+built_stash($ho, $builddir, 'rumprun/rumprun/bin', 'rumprundist');
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 10/26] ts-xen-build: Separate out kconfig from main build step

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ts-xen-build b/ts-xen-build
index 5933dd4..60ce9ee 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -125,10 +125,14 @@ END
 fi
 END
 #/;
-buildcmd_stamped_logged(9000, 'build', '',

[Xen-devel] [OSSTEST PATCH 00/26] rump kernels: Fix build

[Ian Jackson]

This series fixes the rump kernel build, and the test plumbing.  The
tests still fail because they xenbus driver in rump kernel upstream
has rotted.  I'm working on that...

Ian.

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

[Xen-devel] [OSSTEST PATCH 11/26] ts-xen-build: Support $r{cmdsuffix_configure}

[Ian Jackson]

Nothing sets this yet, so no functional change.

Signed-off-by: Ian Jackson 
---
 ts-xen-build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-xen-build b/ts-xen-build
index 60ce9ee..4f06419 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -109,6 +109,7 @@ sub build () {
 my $ovmf_opt= $r{enable_ovmf} =~ m/true/ ? "--enable-ovmf" : 
"--disable-ovmf";
 
 my $configure_prefix = $r{cmdprefix_configure} // '';
+my $configure_suffix = $r{cmdsuffix_configure} // '';
 my $make_prefix =  $r{cmdprefix_make}  // '';
 
 buildcmd_stamped_logged(600, 'configure', 

[Xen-devel] [OSSTEST PATCH 14/26] rumprun: ts-rumprun-build: Update for newer Xen

[Ian Jackson]

Newer Xen needs more work to make it cross compile for rump.

* Pass --host=TARGET to configure.  This is needed so that configure
  knows that we are deliberately cross compiling.  (Otherwise it
  tries to run target binaries on the host, and crashes when that fails.)

* Pass CROSS_COMPILE in the environment.  This arranges for the Xen
  Makefiles to run the right compiler, ie $(CROSS_COMPILE)-gcc.

* Put the rump compiler directory on PATH, so that the Xen Makefiles
  can find it.

* Pass HOSTCC=gcc in the environment; otherwise it tries to use the
  default CC (which is $(CROSS_COMPILE)gcc), when building
  build-system-internal tools which are to be run on the host as part
  of the build.

  The need for this could be avoided by setting XEN_TARGET_ARCH to the
  rump architecture, but then we would have to provide a Xen arch
  config file for that architecture, which would be meaningless since
  we are not actually building a hypervisor, and would have to contain
  various dummy information.

NB in this commit message I use Xen terminology for cross arch names:

 Xen  GCC/GNUMeaning   Example for
 terminology  terminology  rump cross build

 host build  Native architecture of i586-linux-gnu
 the environment in which
 we are running the build.

 target   host   Foreign architecture oni486-rumprun-netbsdelf
 which the objects etc.
 which we are now building
 will eventually be run.

 n/a  target Used only when building a "Canadian"
 cross compiler: the 2nd foreign
 architecture for which the compiler which
 we are now building (on the `build(gnu)'
 arch) will, when we run it, produce
 binaries (when it is run on the
 `host(gnu)' arch).

Signed-off-by: Ian Jackson 
---
 ts-rumprun-build | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/ts-rumprun-build b/ts-rumprun-build
index 7184f9d..98c8efc 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -55,10 +55,17 @@ END
 sub recordtools() {
 my $gcc = target_cmd_output($ho, "echo $rux/rumprun/bin/*-gcc");
 chomp $gcc;
-die "$gcc ?" if $gcc =~ m/\S/;
-my $prefix = "CC=$gcc ";
+die "$gcc ?" unless $gcc =~ m#^(\S+)/([^/ \t]+)-g?cc$#;
+my $bindir = $1;
+my $gnutriplet = $2;
+my $prefix = "PATH=$bindir:\$PATH ";
+$prefix .= "CROSS_COMPILE=$gnutriplet- HOSTCC=gcc ";
 store_runvar('cmdprefix_configure', $prefix);
 store_runvar('cmdprefix_make',  $prefix);
+store_runvar('cmdsuffix_configure', " --host=$gnutriplet");
+# "host" is daft GCC/GNU terminology for the target architecture of
+# a cross-compile, ie in our case the rump environemnt architecture
+# for which the rump compilers are going to generate code.
 }
 
 sub install() {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 22/26] TestSupport: guest_prepare_disk: cope with no disk

[Ian Jackson]

If the guest has no runvars specifying any kind of disk, do not
attempt to mess about with unmounting it etc.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a6ab18f..7eb7bc4 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1580,7 +1580,7 @@ sub guest_prepare_disk ($) {
 
 guest_umount_lv($gho->{Host}, $gho);
 
-return if $gho->{Diskfmt} eq "none";
+return if ($gho->{Diskfmt} // 'none') eq "none";
 
 target_cmd_root($gho->{Host}, <{Diskmnt}
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 07/26] rumprun: ts-rumprun-build: Remove $bodges

[Ian Jackson]

This is very obsolete.

Signed-off-by: Ian Jackson 
---
 ap-common|  5 -
 ts-rumprun-build | 46 +-
 2 files changed, 1 insertion(+), 50 deletions(-)

diff --git a/ap-common b/ap-common
index 212da18..62d2e4f 100644
--- a/ap-common
+++ b/ap-common
@@ -42,11 +42,6 @@
 : ${BASE_TREE_RUMPRUN:=git://xenbits.xen.org/osstest/rumprun.git}
 : ${PUSH_TREE_RUMPRUN:=$XENBITS:/home/xen/git/osstest/rumprun.git}
 
-: ${TREE_RUMPRUN_RUMPSRC:=$(besteffort_repo 
https://github.com/rumpkernel/rumpkernel-netbsd-src)}
-: ${TREEVCS_RUMPRUN_RUMPSRC:=git}
-# rumpsrc-related runvars needed only for old rumpuser-xen
-# (ie ones which need $bodges=1 in ts-rumprun-build)
-
 : ${TREE_SEABIOS_UPSTREAM:=git://git.seabios.org/seabios.git}
 : ${PUSH_TREE_SEABIOS:=$XENBITS:/home/xen/git/osstest/seabios.git}
 : ${BASE_TREE_SEABIOS:=git://xenbits.xen.org/osstest/seabios.git}
diff --git a/ts-rumprun-build b/ts-rumprun-build
index abc1f7d..55420f0 100755
--- a/ts-rumprun-build
+++ b/ts-rumprun-build
@@ -28,7 +28,7 @@ builddirsprops();
 our %submodmap = qw(buildrump.sh buildrumpsh
 src-netbsd netbsdsrc);
 
-our ($rux, $bodges);
+our ($rux);
 
 sub checkout () {
 prepbuilddirs();
@@ -38,53 +38,9 @@ sub checkout () {
 my $submodules =
submodulefixup($ho, 'rumprun', 'rumprun', \%submodmap);
 $rux = "$builddir/rumprun";
-
-$bodges = submodule_have($submodules,'nblibs')
- && !submodule_have($submodules,'netbsdsrc');
-
-if ($bodges) {
-   my $rumpsrcgitrevr = "$rux/buildrump.sh/.srcgitrev";
-   my $rumpsrcgitrevl = "buildrump-srcgitrev";
-   my $rev = $r{revision_rumprun_rumpsrc};
-   if (length $rev) {
-   target_putfilecontents_stash($ho,30,
-"$r{revision_rumprun_rumpsrc}\n",
-$rumpsrcgitrevr, $rumpsrcgitrevl);
-   } else {
-   target_getfile($ho,30,$rumpsrcgitrevr,"$stash/$rumpsrcgitrevl");
-   $rev = get_filecontents("$stash/$rumpsrcgitrevl");
-   chomp $rev or die;
-   $rev =~ m/^[0-9a-f]+$/ or die;
-   store_runvar('revision_rumprun_rumpsrc', $rev);
-   }
-
-   build_clone($ho, "rumprun_rumpsrc", $builddir,
-   "rumprun/rumpsrc");
-   store_vcs_revision('rumprun_rumpsrc', $rev, 'git');
-}
 }
 
 sub massage() {
-return unless $bodges;
-
-# Very poor
-target_editfile($ho, "$rux/buildxen.sh", undef,
-   "$rux/grievous-bodge-nblibs", sub {
-while () {
-   next unless m/^\Qif [ ! -d rumpsrc ]; then\E/..m/^fi/;
-   next unless m/cp -Rp nblibs/;
-   print EO or die $!;
-   }
-});
-target_cmd_build($ho, 2000, $rux, "bash -x grievous-bodge-nblibs");
-
-# Rather poor
-target_editfile($ho, "$rux/Config.mk", sub {
-while () {
-   s/^XEN_HEADERS=/XEN_HEADERS?=/;
-   print EO or die $!;
-   }
-});
 }
 
 sub build() {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 14/24] libxl: allow to set the ratelimit value online for Credit2

[Dario Faggioli]

On Mon, 2016-08-22 at 10:21 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("[PATCH 14/24] libxl: allow to set the
> ratelimit value online for Credit2"):
> > 
> > This is the remaining part of the plumbing (the libxl
> > one) necessary to be able to change the value of the
> > ratelimit_us parameter online, for Credit2 (like it is
> > already for Credit1).
>
> I think this should have a HAVE #define.
> 
Ah, sure. Sorry I've forgotten, I'll add it in v2.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 v6 2/4] x86/ioreq server: Release the p2m lock after mmio is handled.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> Routine hvmemul_do_io() may need to peek the p2m type of a gfn to
> select the ioreq server. For example, operations on gfns with
> p2m_ioreq_server type will be delivered to a corresponding ioreq
> server, and this requires that the p2m type not be switched back
> to p2m_ram_rw during the emulation process. To avoid this race
> condition, we delay the release of p2m lock in hvm_hap_nested_page_fault()
> until mmio is handled.
> 
> Note: previously in hvm_hap_nested_page_fault(), put_gfn() was moved
> before the handling of mmio, due to a deadlock risk between the p2m
> lock and the event lock(in commit 77b8dfe). Later, a per-event channel
> lock was introduced in commit de6acb7, to send events. So we do not
> need to worry about the deadlock issue.
> 
> Signed-off-by: Yu Zhang 

Reviewed-by: Jan Beulich 

However, shouldn't this go _before_ what is now patch 1?

Jan


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

Re: [Xen-devel] [PATCH] mini-os: add comments in Config.mk regarding new config options

[Wei Liu]

On Mon, Sep 05, 2016 at 03:23:10PM +0200, Samuel Thibault wrote:
> Juergen Gross, on Mon 05 Sep 2016 13:43:30 +0200, wrote:
> > Add some comment in Config.mk what to do in case of adding new config
> > options.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Samuel Thibault 
> 

Pushed.

___
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

[Dario Faggioli]

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

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

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...

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 v6 1/4] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

[Jan Beulich]

>>> On 02.09.16 at 12:47,  wrote:
> @@ -178,8 +179,27 @@ static int hvmemul_do_io(
>  break;
>  case X86EMUL_UNHANDLEABLE:
>  {
> -struct hvm_ioreq_server *s =
> -hvm_select_ioreq_server(curr->domain, &p);
> +struct hvm_ioreq_server *s = NULL;
> +p2m_type_t p2mt = p2m_invalid;
> +
> +if ( is_mmio )
> +{
> +unsigned long gmfn = paddr_to_pfn(addr);
> +
> +(void) get_gfn_query_unlocked(currd, gmfn, &p2mt);
> +
> +if ( p2mt == p2m_ioreq_server && dir == IOREQ_WRITE )
> +{
> +unsigned int flags;
> +
> +s = p2m_get_ioreq_server(currd, &flags);
> +if ( !(flags & XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> +s = NULL;
> +}
> +}
> +
> +if ( !s && p2mt != p2m_ioreq_server )
> +s = hvm_select_ioreq_server(currd, &p);

What I recall is that we had agreed on p2m_ioreq_server pages
to be treated as ordinary RAM ones as long as no server can be
found. The type check here contradicts that. Is there a reason?

> +static int hvmop_map_mem_type_to_ioreq_server(
> +XEN_GUEST_HANDLE_PARAM(xen_hvm_map_mem_type_to_ioreq_server_t) uop)
> +{
> +xen_hvm_map_mem_type_to_ioreq_server_t op;
> +struct domain *d;
> +int rc;
> +
> +if ( copy_from_guest(&op, uop, 1) )
> +return -EFAULT;
> +
> +rc = rcu_lock_remote_domain_by_id(op.domid, &d);
> +if ( rc != 0 )
> +return rc;
> +
> +rc = -EINVAL;
> +if ( !is_hvm_domain(d) )
> +goto out;
> +
> +if ( op.pad != 0 )
> +goto out;

This, I think, should be done first thing after having copied in the
structure. No need to lookup domain or anything if this is not zero.

> +int hvm_map_mem_type_to_ioreq_server(struct domain *d, ioservid_t id,
> + uint32_t type, uint32_t flags)
> +{
> +struct hvm_ioreq_server *s;
> +int rc;
> +
> +/* For now, only HVMMEM_ioreq_server is supported. */
> +if ( type != HVMMEM_ioreq_server )
> +return -EINVAL;
> +
> +/* For now, only write emulation is supported. */
> +if ( flags & ~(XEN_HVMOP_IOREQ_MEM_ACCESS_WRITE) )
> +return -EINVAL;
> +
> +domain_pause(d);
> +spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
> +
> +rc = -ENOENT;
> +list_for_each_entry ( s,
> +  &d->arch.hvm_domain.ioreq_server.list,
> +  list_entry )
> +{
> +if ( s == d->arch.hvm_domain.default_ioreq_server )
> +continue;
> +
> +if ( s->id == id )
> +{
> +rc = p2m_set_ioreq_server(d, flags, s);
> +break;
> +}
> +}
> +
> +spin_unlock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
> +domain_unpause(d);
> +return rc;
> +}

Blank line before final return statement of a function please.

> +int p2m_set_ioreq_server(struct domain *d,
> + unsigned int flags,
> + struct hvm_ioreq_server *s)
> +{
> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
> +int rc;
> +
> +/*
> + * Use lock to prevent concurrent setting requirements
> + * from multiple ioreq serers.
> + */

"Concurrent setting requirements"? DYM "attempts"?

Jan


___
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()

[Dario Faggioli]

On Thu, 2016-09-01 at 12:08 +0100, anshul makkar wrote:
> On 17/08/16 18:19, Dario Faggioli wrote:
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > 
> > @@ -506,34 +506,68 @@ void smt_idle_mask_clear(unsigned int cpu,
> > cpumask_t *mask)
> >   }
> > 
> >   /*
> > - * When a hard affinity change occurs, we may not be able to check
> > some
> > - * (any!) of the other runqueues, when looking for the best new
> > processor
> > - * for svc (as trylock-s in csched2_cpu_pick() can fail). If that
> > happens, we
> > - * pick, in order of decreasing preference:
> > - *  - svc's current pcpu;
> > - *  - another pcpu from svc's current runq;
> > - *  - any cpu.
> > + * In csched2_cpu_pick(), it may not be possible to actually look
> > at remote
> > + * runqueues (the trylock-s on their spinlocks can fail!). If that
> > happens,
> With remote runqueues , do you mean runqs on remote socket ? 
>
I mean runqueues different from the runq the vcpu is currently assigned
to (as per runq_assign()/runq_deassing()).

If you have runqueues configured to be per-socket, yes, it will try to
lock runqueues in which there are pcpus that are on a different socket
wrt svc->vcpu->processor.

> 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. :-/

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.

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.

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).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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] mini-os: add comments in Config.mk regarding new config options

[Samuel Thibault]

Juergen Gross, on Mon 05 Sep 2016 13:43:30 +0200, wrote:
> Add some comment in Config.mk what to do in case of adding new config
> options.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  Config.mk | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Config.mk b/Config.mk
> index 0e405bf..0baedd1 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -152,6 +152,11 @@ CFLAGS += -flto
>  LDFLAGS-$(clang) += -plugin LLVMgold.so
>  endif
>  
> +# When adding a new CONFIG_ option please make sure the test configurations
> +# under arch/*/testbuild/ are updated accordingly. Especially
> +# arch/*/testbuild/*-yes and arch/*/testbuild/*-no should set ALL possible
> +# CONFIG_ variables.
> +
>  # Configuration defaults
>  ifeq ($(TARGET_ARCH_FAM),x86)
>  CONFIG_PARAVIRT ?= y
> -- 
> 2.6.6
> 

-- 
Samuel
+#if defined(__alpha__) && defined(CONFIG_PCI)
+   /*
+* The meaning of life, the universe, and everything. Plus
+* this makes the year come out right.
+*/
+   year -= 42;
+#endif
(From the patch for 1.3.2: (kernel/time.c), submitted by Marcus Meissner)

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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[George Dunlap]

On Tue, Aug 9, 2016 at 11:40 AM, Jan Beulich  wrote:
> This doesn't cover all of them, just the ones that I think would most
> obviously better be -EINVAL or -EOPNOTSUPP.
>
> Signed-off-by: Jan Beulich 

FWIW:

Reviewed-by: George Dunlap 

>
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -440,7 +440,7 @@ int unmmap_broken_page(struct domain *d,
>  return -EINVAL;
>
>  if ( !has_hvm_container_domain(d) || !paging_mode_hap(d) )
> -return -ENOSYS;
> +return -EOPNOTSUPP;
>
>  rc = -1;
>  r_mfn = get_gfn_query(d, gfn, &pt);
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
> printk(KERN_WARNING
>"mtrr: your processor doesn't support 
> write-combining\n");
> -   return -ENOSYS;
> +   return -EOPNOTSUPP;
> }
>
> if (!size) {
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5592,7 +5592,7 @@ long do_hvm_op(unsigned long op, XEN_GUE
>  break;
>
>  case HVMOP_flush_tlbs:
> -rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -ENOSYS;
> +rc = guest_handle_is_null(arg) ? hvmop_flush_tlb_all() : -EINVAL;
>  break;
>
>  case HVMOP_track_dirty_vram:
> @@ -5832,7 +5832,7 @@ int hvm_debug_op(struct vcpu *v, int32_t
>  {
>  case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_ON:
>  case XEN_DOMCTL_DEBUG_OP_SINGLE_STEP_OFF:
> -rc = -ENOSYS;
> +rc = -EOPNOTSUPP;
>  if ( !cpu_has_monitor_trap_flag )
>  break;
>  rc = 0;
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3565,7 +3565,7 @@ long do_mmuext_op(
>  if ( !opt_allow_superpage )
>  {
>  MEM_LOG("Superpages disallowed");
> -rc = -ENOSYS;
> +rc = -EOPNOTSUPP;
>  }
>  else if ( unlikely(d != pg_owner) )
>  rc = -EPERM;
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -353,7 +353,7 @@ int compat_memory_op(unsigned int cmd, X
>  struct get_reserved_device_memory grdm;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(&grdm.map, compat, 1) ||
>   !compat_handle_okay(grdm.map.buffer, grdm.map.nr_entries) )
> --- a/xen/common/event_fifo.c
> +++ b/xen/common/event_fifo.c
> @@ -621,7 +621,7 @@ int evtchn_fifo_expand_array(const struc
>  int rc;
>
>  if ( !d->evtchn_fifo )
> -return -ENOSYS;
> +return -EOPNOTSUPP;
>
>  spin_lock(&d->event_lock);
>  rc = add_page_to_event_array(d, expand_array->array_gfn);
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3025,7 +3025,7 @@ do_grant_table_op(
>  return -EINVAL;
>
>  if ( (cmd &= GNTTABOP_CMD_MASK) != GNTTABOP_cache_flush && opaque_in )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = -EFAULT;
>  switch ( cmd )
> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -937,14 +937,14 @@ long do_memory_op(unsigned long cmd, XEN
>
>  case XENMEM_exchange:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = memory_exchange(guest_handle_cast(arg, xen_memory_exchange_t));
>  break;
>
>  case XENMEM_maximum_ram_page:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  rc = max_page;
>  break;
> @@ -953,7 +953,7 @@ long do_memory_op(unsigned long cmd, XEN
>  case XENMEM_maximum_reservation:
>  case XENMEM_maximum_gpfn:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(&domid, arg, 1) )
>  return -EFAULT;
> @@ -1077,7 +1077,7 @@ long do_memory_op(unsigned long cmd, XEN
>  struct page_info *page;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(&xrfp, arg, 1) )
>  return -EFAULT;
> @@ -1114,7 +1114,7 @@ long do_memory_op(unsigned long cmd, XEN
>
>  case XENMEM_claim_pages:
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  if ( copy_from_guest(&reservation, arg, 1) )
>  return -EFAULT;
> @@ -1148,7 +1148,7 @@ long do_memory_op(unsigned long cmd, XEN
>  struct vnuma_info tmp;
>
>  if ( unlikely(start_extent) )
> -return -ENOSYS;
> +return -EINVAL;
>
>  /*
>   * Guest passes nr_vnodes, number of regions and nr_vcpus thus
> @@ -1280,7 +1280,7 @@ long do_

Re: [Xen-devel] [PATCH v6] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[Jan Beulich]

>>> On 05.09.16 at 07:17,  wrote:
> @@ -1403,12 +1451,16 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> -if ( cpu_has_smep )
> +else if ( opt_smep == 1 )
> +__set_bit(X86_FEATURE_XEN_SMEP, boot_cpu_data.x86_capability);
> +if ( boot_cpu_has(X86_FEATURE_XEN_SMEP) )
>  set_in_cr4(X86_CR4_SMEP);
>  
>  if ( !opt_smap )
>  setup_clear_cpu_cap(X86_FEATURE_SMAP);
> -if ( cpu_has_smap )
> +else if ( opt_smap == 1 )
> +__set_bit(X86_FEATURE_XEN_SMAP, boot_cpu_data.x86_capability);
> +if ( boot_cpu_has(X86_FEATURE_XEN_SMAP) )
>  set_in_cr4(X86_CR4_SMAP);

This is still wrong, as spotted by osstest's smoke test: It in particular
doesn't work on a system which doesn't have SMEP and/or SMAP.
Please fix this while incorporating the other adjustments I did while
committing; I've reverted the patch until then.

Jan


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

Re: [Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

[Dario Faggioli]

On Fri, 2016-09-02 at 13:38 +0100, anshul makkar wrote:
> On 17/08/16 18:20, Dario Faggioli wrote:
> > 
> > diff --git a/xen/common/sched_credit2.c
> > b/xen/common/sched_credit2.c
> > 
> > @@ -1102,13 +1110,26 @@ runq_tickle(const struct scheduler *ops, 
> >   for_each_cpu(i, &mask)
> >   {
> > -/* Already looked at this one above */
> > -if ( i == cpu )
> > +/*
> > + * Already looked at these ones above, either because
> > it's the
> > + * cpu where new was running before, or because we are
> > at the
> > + * hard-affinity step, and we checked this during the
> > + * soft-affinity one
> > + */
> Sorry for my naiveness here,
>
NP.

>  but can we be sure that situation has not 
> changed since we checked during soft-affinity step. ?
>
Yes we can, since we're holding the runqueue lock.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 19/24] xen: credit2: soft-affinity awareness in load balancing

[Dario Faggioli]

On Fri, 2016-09-02 at 12:46 +0100, anshul makkar wrote:

Hey, Anshul,

Thanks for having a look at the patch!

> On 17/08/16 18:19, Dario Faggioli wrote:
> > 
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > 
> > + * Basically, if a soft-affinity is defined, the work done by a
> > vcpu on a
> > + * runq to which it has higher degree of soft-affinity, is
> > considered
> > + * 'lighter' than the same work done by the same vcpu on a runq to
> > which it
> > + * has smaller degree of soft-affinity (degree of soft affinity is
> > <= 1). In
> > + * fact, if soft-affinity is used to achieve NUMA-aware
> > scheduling, the higher
> > + * the degree of soft-affinity of the vcpu to a runq, the greater
> > the probability
> > + * of accessing local memory, when running on such runq. And that
> > is certainly\
> > + * 'lighter' than having to fetch memory from remote NUMA nodes.
> Do we ensure that while defining soft-affinity for a vcpu, NUMA 
> architecture is considered. If not, then this whole calculation can
> go 
> wrong and have negative impact on performance.
> 
Defining soft-affinity after topology is what we do by default, just
not here in Xen: we do it in toolstack (in libxl, to be precise).

NUMA aware scheduling is indeed the most obvious use case for all this
--and, in fact that's why we configure things in such a way in higher
layers-- but the mechanism is, at the Xen level, flexible enough to be
used for any purpose that the user may find interesting.

> Degree of affinity to runq will give good result if the affinity to 
> pcpus has been chosen after due consideration ..
>
At this level, 'good result' means 'making sure that a vcpu runs for as
much time as possible on a pcpu to which it has soft-affinity'. Whether
that is good or not for performance (or for any other aspect or
metric), it's not this algorithm's job to determine.

Note that things are exactly the same for hard-affinity/pinning, or for
weights. In fact, Xen won't stop one to, say, pin 128 vcpu all to pcpu
3. This will deeply suck, but it's the higher layers' will (fault?) and
Xen should just comply to that.

> > + * If there is no soft-affinity, load_balance() (actually,
> > consider()) acts
> > + * as follows:
> > + *
> > + *  - D = abs(Li - Lj)
> If we are consider absolute of Li -Lj, how will we know which runq
> has 
> less workload which, I think, is an essential parameter for load 
> balancing. Am I missing something here ?
>
What we are aiming for is making the queues more balanced, which means
we want the difference between their load to be smaller than how it is
when the balancing start. As far as that happens, we don't care which
loads goes down and which one goes up, as far as the final result is a
smaller load delta.

> > + *  - consider pushing v from I to J:
> > + * - D' = abs(Li - lv - (Lj + lv))   (from now, abs(x) == |x|)
> > + * - if (D' < D) { push }
> > + *  - consider pulling k from J to I:
> > + * - D' = |Li + lk - (Lj - lk)|
> > + * - if (D' < D) { pull }
> For both push and pull we are checking (D` < D) ?
>
Indeed. And that's because of the abs(). :-)


Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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

[Xen-devel] [xen-unstable-smoke test] 100755: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386  6 xen-boot fail REGR. vs. 100736
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 100736

Tests which did not succeed, but are not blocking:
 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  7539772a65b044f326ebf9528bd40e7c6a78c540
baseline version:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922

Last test of basis   100736  2016-09-02 16:03:32 Z2 days
Testing same since   100755  2016-09-05 11:01:49 Z0 days1 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  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt fail



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

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

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

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


Not pushing.


commit 7539772a65b044f326ebf9528bd40e7c6a78c540
Author: Marek Marczykowski-Górecki 
Date:   Mon Sep 5 11:26:04 2016 +0200

libxl: do not assume Dom0 backend while getting nic info

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
Acked-by: Wei Liu 

commit b2f2ced591060588a45cdc7881a7335ba42b9cc5
Author: Wei Liu 
Date:   Mon Sep 5 11:36:45 2016 +0100

tools/firmware: Rename bios.bin to seabios.bin

bios.bin as a name is far too generic.  Rename it to seabios.bin.

Signed-off-by: Andrew Cooper 
Acked-by: Wei Liu 
[ wei: fix up conflict, rerun autogen.sh ]
Signed-off-by: Wei Liu 

commit eb502cb30cc5af309ed824da024014afca1d0fcf
Author: Wei Liu 
Date:   Mon Sep 5 10:21:28 2016 +0100

libxl: update flex output files for DSA 3653-2

We updated flex output files in 4b314c89 ("libxl: update flex output
files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
discovered the fix to flex was incomplete and issued DSA 3653-2. We need
to update our flex output files accordingly.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 5fdea6577098eda065c794c79e1ae23f33f103af
Author: He Chen 
Date:   Mon Sep 5 12:49:43 2016 +0200

x86: allow disabling sm{e,a}p for Xen itself

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.

This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He Chen 
[jbeulich: doc and style adjustments]
Reviewed-by: Jan Beulich 

commit 698d0f377d72fdc8d4e247e76b6508090c366187
Author: Razvan Cojocaru 
Date:   Mon Sep 5 12:47:46 2016 +0200

have __DEFINE_COMPAT_HANDLE() generate const versions

Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE()
each produce both const and non-const handles,
only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE()
does not). This patch has __DEFINE_COMPAT_HANDLE() also
produce a const handle.

Suggested-by: Jan Be

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

[Jan Beulich]

>>> On 20.08.16 at 00:43,  wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -103,9 +103,56 @@ static void __init relocate_trampoline(unsigned long 
> phys)
>  *(u16 *)(*trampoline_ptr + (long)trampoline_ptr) = phys >> 4;
>  }
>  
> +#define EBMALLOC_SIZEMB(1)
> +
> +static char __section(".bss.page_aligned") ebmalloc_mem[EBMALLOC_SIZE];

You need to specify the alignment of the object (using the relatively
new __aligned() construct).

> +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.

> +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?

> +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

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.

Jan


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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

On 05/09/16 14:18, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH] libxl: add "xl qemu-monitor-command""):
>> On 05/09/16 12:32, Ian Jackson wrote:
>>> The rest of the documentation will need adjusting.  As an example of
>>> the incompleteness I am talking about I think the example shows only
>>> some of the USB devices presented to the guest.
>>
>> Hmm, I think the statement:
>>
>> +Obtain information of USB devices connected via the device model to a
>> +domain:
>>
>> is absolutely correct. Which USB devices connected via the device model
>> won't be shown?
> 
> Well, technically the statement is true.  But it's a bear trap for the
> incautious (or hurried) reader.  Perhaps add `(only!)' after `device
> model' ?

Sure, I can do that. And perhaps I should say:

Obtain information of USB devices connected as such via the device
model (only!) to a domain.

Just in case somebody connects e.g. a USB stick as a disk...


Juergen

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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH] libxl: add "xl qemu-monitor-command""):
> On 05/09/16 12:32, Ian Jackson wrote:
> > The rest of the documentation will need adjusting.  As an example of
> > the incompleteness I am talking about I think the example shows only
> > some of the USB devices presented to the guest.
> 
> Hmm, I think the statement:
> 
> +Obtain information of USB devices connected via the device model to a
> +domain:
> 
> is absolutely correct. Which USB devices connected via the device model
> won't be shown?

Well, technically the statement is true.  But it's a bear trap for the
incautious (or hurried) reader.  Perhaps add `(only!)' after `device
model' ?

Ian.

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-09-05 13:43, Jan Beulich wrote:

On 05.09.16 at 13:19,  wrote:

On 2016-09-05 12:25, Jan Beulich wrote:

Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).


I just tried that and without shadow paging code the guest boots fine,
so that's interesting.


Indeed. Was that try with plain staging/master, or with much of
the reverts in place (from the bisection)? It seems to me that
investigating this odd difference would perhaps be a better
route than trying to guess what's wrong with said commit.

Jan


It was a try with a tree at the culprit commit and editted 
xen/arch/x86/Rules.mk to disable the shadow paging code from being 
build.


Now just tried with unstable and using Kconfig, but with that build the 
guest doesn't boot.

So
or the KConfig option doesn't work
or the reliability isn't 100% afterall (but i should have noticed that 
earlier on i would say)

or there is something else (semantics around the disabling changed ?)

*sigh*, seems it's not going to be an easy one :-\

My /boot/xen-4.8-unstable.config gives:
#
# Architecture Features
#
CONFIG_NR_CPUS=256
# CONFIG_SHADOW_PAGING is not set
# CONFIG_BIGMEM is not set
CONFIG_HVM_FEP=y
CONFIG_TBOOT=y

So it should be off i guess.

--
Sander

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

[Xen-devel] [linux-3.18 test] 100752: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start fail REGR. vs. 100597
 test-armhf-armhf-xl-xsm   6 xen-boot fail REGR. vs. 100597

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

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

version targeted for testing:
 linuxe9e1b43e9f912ee8aad24534584a6257d2b43aba
baseline version:
 linuxd45da77ced2a983edc2cd55d26e7693b1f3613dd

Last test of basis   100597  2016-08-23 06:54:31 Z   13 days
Testing same since   100752  2016-09-05 06:44:05 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexey Klimov 
  Andrew Donnellan 
  Andrew Morton 
  Artem Bityutskiy 
  Bjorn Helgaas 
  Bruno Wolff III 
  Chen-Yu Tsai 
  Christian König 
  Daniel Lezcano 
  Daniel Mentz 
  Daniel Vetter 
  Daniel Vetter 
  Daniele Palmas 
  Dave Airlie 
  Dave Carroll 
  David S. Miller 
  David Vrabel 
  Dmitry Torokhov 
  Eric Dumazet 
  Eric Wheeler 
  Eric Wheeler 
  Felipe Balbi 
  Felix Fietkau 
  Gavin Li 
  Gavin Shan 
  Greg Kroah-Hartman 
  Helge Deller 
  Herbert Xu 
  Hubert Feurstein 
  Ingo Molnar 
  Jan Beulich 
  Jani Nikula 
  Jason S. McMullan 
  Jim Lin 
  Johan Hovold 
  Johannes Berg 
  John Stultz 
  Kent Overstreet 
  Laxman Dewangan 
  Liav Rehana 
  Linus Torvalds 
  Linus Walleij 
  Lu Baolu 
  Lubomir Rintel 
  Martin K. Petersen 
  Martin Schwidefsky 
  Masahiro Yamada 
  Mathias Nyman 
  Matthew Auld 
  Maxime Ripard 
  Michael Ellerman 
  Michal Hocko 
  Mike Snitzer 
  Neal Cardwell 
  Oleg Nesterov 
  Oliver Neukum 
  Richard Schütz 
  Richard Weinberger 
  Robert Delien 
  Robert Deliën 
  Russell King 
  Sasha Levin 
  Sheng-Hui J. Chu 
  Simon Horman 

[Xen-devel] [PATCH] mini-os: add comments in Config.mk regarding new config options

[Juergen Gross]

Add some comment in Config.mk what to do in case of adding new config
options.

Signed-off-by: Juergen Gross 
---
 Config.mk | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Config.mk b/Config.mk
index 0e405bf..0baedd1 100644
--- a/Config.mk
+++ b/Config.mk
@@ -152,6 +152,11 @@ CFLAGS += -flto
 LDFLAGS-$(clang) += -plugin LLVMgold.so
 endif
 
+# When adding a new CONFIG_ option please make sure the test configurations
+# under arch/*/testbuild/ are updated accordingly. Especially
+# arch/*/testbuild/*-yes and arch/*/testbuild/*-no should set ALL possible
+# CONFIG_ variables.
+
 # Configuration defaults
 ifeq ($(TARGET_ARCH_FAM),x86)
 CONFIG_PARAVIRT ?= y
-- 
2.6.6


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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Jan Beulich]

>>> On 05.09.16 at 13:19,  wrote:
> On 2016-09-05 12:25, Jan Beulich wrote:
>> Anyway - with you quite clearly having used HAP before, I can't
>> see how this commit would matter for you at all. In case you want
>> to double check you could try with a hypervisor built without
>> shadow paging code (which we've been allowing for quite a
>> while).
> 
> I just tried that and without shadow paging code the guest boots fine, 
> so that's interesting.

Indeed. Was that try with plain staging/master, or with much of
the reverts in place (from the bisection)? It seems to me that
investigating this odd difference would perhaps be a better
route than trying to guess what's wrong with said commit.

Jan


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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Juergen Gross]

On 05/09/16 12:32, Ian Jackson wrote:
> Juergen Gross writes ("[PATCH] libxl: add "xl qemu-monitor-command""):
>> Add a new xl command "qemu-monitor-command" to issue arbitrary commands
>> to a domain's device model. Syntax is:
>>
>> xl qemu-monitor-command  
>>
>> The command is issued via qmp human-monitor-command command. Any
>> information returned by the command is printed to stdout.
> ...
>> +=item B I I
>> +
>> +Issue a monitor command to the device model of the domain specified by
>> +I. I can be any valid command qemu understands. This
>> +can be e.g. used to add non-standard devices or devices with non-standard
>> +parameters to a domain. The output of the command is printed to stdout.
> 
> This needs some kind of health warning.  Something like:
> 
>  Warning: This qemu monitor access is provided for convenience when
>  debugging, troubleshooting, and experimenting.  Its use is not
>  supported by the Xen Project.
> 
>  Specifically, not all information printed by the qemu monitor will
>  necessarily be accurate or complete, because in a Xen system qemu
>  does not have a complete view of the guest.
> 
>  Furthermore, modifying the guest's setup via the qemu monitor may
>  conflict with the Xen toolstack's assumptions.  Resulting problems
>  may include, but are not limited to: guest crashes; toolstack error
>  messages; inability to migrate the guest; and security
>  vulnerabilities which are not covered by the Xen Project security
>  response policy.

Thanks for the complete text! I'll add it to the man page.

> The rest of the documentation will need adjusting.  As an example of
> the incompleteness I am talking about I think the example shows only
> some of the USB devices presented to the guest.

Hmm, I think the statement:

+Obtain information of USB devices connected via the device model to a
+domain:

is absolutely correct. Which USB devices connected via the device model
won't be shown?


Juergen

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

[Xen-devel] Test Meetup at Developer Summit

[Lars Kurth]

== Attendees ==
Lars Kurth
George Dunlap
Doug Goldstein
Andrew Cooper
Paul Durrant

There were a few others, which I may have missed

I tried to transcribe from a recording we had at lunch, but due to background 
noise I didn't get everything. Please add/correct, if I got something wrong. 
There was a bit of discussion, but I tried to capture the key points only (e.g. 
I omitted clarifying questions)

== Discussion: Travis Improvements ==

Doug, wanted to discuss changes to the project's Travis set-up
* Reconfiguring Travis set-up such that it launches docker containers to do 
very basic smoke testing of individual commits on a number of different build 
configurations
* Right now this would require running a script running inside a script
* The key question is what matrix to support: e.g. which compiler versions, 
whether it should cover deb builds, ...
* It is basically just a build test, with a very basic run-test within an 
emulated qemu environment to check whether we boot. Aka booting a small image 
that is cross-compiled against various environments that produces "Hello World" 
on the first available serial-port
* If "Hello World" was produced, then Travis would decide the build was 
successful

George: over OSSTEST what value would this add? 
Doug: feedback about 7-8 minutes after a push with some confidence that a build 
was not broken, faster than OSSTEST does now. Obviously this would not replace 
OSSTEST, but should reduce the number of build-related issues in OSSTEST
Andrew: This should help quite a lot with avoiding spotting build related 
issues earlier
Doug: Would help avoid unnecessary manual build testing
George: Should help committers also 
Lars: Are there any extra requirements for people to use?
Andrew: Needs an account and set-up on GitHub

In summary: such a set-up would not compete with OSSTEST, but should decrease 
the number of build related OSSTEST failures, wasting fewer people's time if 
there are build related failures and increases OSSTEST throughput

Andrew, is not 100% sure how much extra confidence the "Hello World" test part 
will actually provide. However, Andrew also states that he does boot-testing 
before committing a major series. 

Random boot-tests on random config's (e.g. KConfigs) may also be valuable. But 
the challenge is what to test against, in OSSTEST, and how to know which test 
would succeed for which config. 

Paul: couldn't we build in something into XTF? ... there was a bit of 
discussion around this, but the audio was very hard to understand ... there was 
a discussion around skipping tests, but not quite knowing which ones should 
legitimately fail in a given configuration, or whether a skip was wrongly 
configured, or a git time-out. We would need to have more information about the 
"intent" of an OSSTEST to better help with random config tests. Andrew: thinks 
that for random build config tests, Travis CI may be more suitable than OSSTEST 
and require fewer plumbing changes, due to the faster turn-around and less 
complexity and scope for infrastructure related time-outs, etc. That is not to 
say that we shouldn't look are OSSTEST for functional config tests.

Andy: suggested a "presence test" in XTF for testing whether a specific config 
exists in a given binary, which could be used as a building block in OSSTEST 
for functional config tests. 

ASIDE: I would say that Doug and other participants, fill out this section, as 
I lost a lot of it, and may have misrepresented. 

Summary: In summary, we discussed
- Improvements to the Travis setup in particular for various build configs
- Possible improvements to OSSTEST / XTF for (random) config tests 
- There was no major objection

== Discussion: GitHub vs. GitLab for Travis ==
The second set of topics was to move from GitHub to GitLab for Build-testing 
due to the code availability issues with GitHub. Doug uses GitLab internally 
and is also more functional that GitHub. 

GitLab can be used hosted (for free projects) or host it locally on a VM

Doug: would probably require taking the github yaml and rewrite as gitlab yam. 
There are a number of advantages on OS support and docker integration, which 
makes set-up a lot easier compared to github.

Andy: if we were going to do this, the project should probably get a support 
license

Summary:
- Gather community input on GitHub vs. GitLab
- GitLab code is public, and thus should address 

There was also a bit of discussion about the review work-flow functionality in 
GitLab: just to clarify, we were not discussing any changes in this area. 
Merely to use GitLab as framework for Travis / Build testing and addressing 
some of the past issues that were raised around GitHub code availability.

== Supported / Unsupported / Preview / Experimental / ... ==

We should have some minimum tests and requirements for testing and 
configuration.

Andy: example - Intel MPX support is currently broken, because it was added 
when there was no available support. Because it

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[linux]

On 2016-09-05 12:25, Jan Beulich wrote:

On 05.09.16 at 12:02,  wrote:

On 2016-09-05 11:46, Jan Beulich wrote:

On 05.09.16 at 11:20,  wrote:
Hmm it seems my thread was kind of hijacked and i was dropped from 
the

CC.

I had some time and bisected the issue and it resulted in:

5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
Author: Jan Beulich 
Date:   Wed Oct 21 10:56:31 2015 +0200

 x86/shadow: drop stray name tags from
sh_{guest_get,map}_eff_l1e()


Hmm, as Wei already indicated - that's rather odd. The commit isn't
really supposed to have any effect on functionality (and going
through it again I also can't spot any now). And are you indeed
using shadow mode, and if so does your problem not occur when
you use HAP instead?

In any event, if there was some hidden (and unintended) change
in functionality here, then the most likely result would seem to be
a crash, yet from the log fragment you posted it doesn't look like
there's _any_ relevant hypervisor output.


Hmm i was already afraid of that.
Attached is the output of xl dmesg, HAP is supported and should be
enabled by default (and i didn't disable it explicitly in my 
guest.cfg).


I just tried the opposite and specified hap=0 in my guest.cfg and this
case leads to 2 lines of additional output:

XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): 
can't

find all mappings of mfn 471b69: c=8003 t=7401
(XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings():
can't find all mappings of mfn 471b68: c=8003
t=7401


And these two messages are relevant here? I.e. do they go away
when you use a commit ahead of the one your bisect spotted?


Just double checked with a build one commit ahead of the culprit the 
bisection reported and hap=0,

and those messages are there as well and the guest boots fine now.
So they don't seem to be relevant.


Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).


I just tried that and without shadow paging code the guest boots fine, 
so that's

interesting.


Is it possible that the reproduction of the issue isn't 100% reliable?


Nope it seems 100% reliable.


I.e. did you verify with a couple of runs each that it really is this
commit, and not just some spurious effect? If it is, then from all I
know so far I'd suspect an effect from code / data arrangement
rather than the commit itself to be the actual culprit.


Well at least there is one other independent user running into the same 
issue,

so it doesn't seem specifically related to my machine or my builds.

It also happens when running all my guests (and this is the last to 
start) and with only this guest.



Which reminds
me of another possible way of double checking: If said commit
reverts reasonably cleanly at the tip of staging or master, maybe
you could try with just this change reverted, instead of with
everything subsequent to it reverted too?


Nope it tried that already and it didn't revert cleanly (and i didn't 
see how to correctly fix it up).


--
Sander


Jan


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

Re: [Xen-devel] [PATCH 0/3] mini-os: test and document config variations

[Wei Liu]

On Fri, Sep 02, 2016 at 10:56:44AM +0200, Juergen Gross wrote:
> Add a "testbuild" target to Makefile which builds various configurations.
> Repair some minor issues uncovered by those test builds.
> Document the config framework.
> 
> Juergen Gross (3):
>   mini-os: fix builds with uncommon config settings
>   mini-os: add testbuild target to Makefile
>   mini-os: update README to reflect recent changes
> 

Series pushed. Thank you both.

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

[Xen-devel] Two new x86 boxes in Mass colo (nobling[01])

[Ian Jackson]

FYI

Dell and us have now finished the exchange of the two problematic test
machines oseleta* with two new machines nobling0 and nobling1.

I have finished running commissioning tests and they are mostly
looking good.  However, I am going to hold off putting them into
service, because they expose a bug in current released versions of the
Debian installer kernel.

I see a crash in identify_boot_cpu / identify_cpu, from d-i inside a
PV guest.  It's reproducible, but affects only 32-bit PV guests.

Andrew Cooper helpfully looked at my stack trace and observed that the
bug was very likely lack of 581b7f158fe0383b492acd1ce3fb4e99d4e57808
in Debian's kernel.  The Debian kernel in question has version
3.16.7-ckt20-1+deb8u2 and the fix is in 3.16.7-ckt22.

Debian intend to do a stable point release on the 17th of September,
and I observe that jessie-proposed-updates contains linux
3.16.7-ckt25-2+deb8u2.  So I think the Debian point release will fix
it.

Ian.

This mail is partly a note to myself :-).

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

Re: [Xen-devel] [PATCH] tools/firmware: Rename bios.bin to seabios.bin

[Wei Liu]

On Mon, Sep 05, 2016 at 10:31:21AM +0100, Wei Liu wrote:
> On Mon, Sep 05, 2016 at 10:28:25AM +0100, Andrew Cooper wrote:
> > On 05/09/16 09:09, Anthony PERARD wrote:
> > > On Mon, Aug 22, 2016 at 11:24:05AM +0100, Wei Liu wrote:
> > >> On Fri, Aug 19, 2016 at 03:26:23PM +0100, Andrew Cooper wrote:
> > >>> bios.bin as a name is far too generic.  Rename it to seabios.bin.
> > >>>
> > >>> Signed-off-by: Andrew Cooper 
> > >> Hmm... I remember the first few versions of that series had it named
> > >> seabios.bin and I acked that.
> > >>
> > >> Anyway, I think I will give Anthony a chance to clarify why he changed
> > >> the name.
> > > I've changed it because someone ask for it:
> > > https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02371.html
> > 
> > It was admittedly lacking a question mark, but that was a question not a
> > statement.
> > 
> > The answer is "because there are a load of other bios binaries stored in
> > the same directory".
> > 
> > > It was to match how seabios is installed by default.
> > 
> > This is not relevant.  The version of seabios built by Xen should fit
> > into the Xen expectations.  If this means renaming it to make it clear
> > which bios it it, then so be it.
> 
> I think renaming it to seabios.bin is better.
> 
> Acked-by: Wei Liu 
> 

Fixed up conflict and pushed.

Wei.

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

Re: [Xen-devel] [PATCH] libxl: update flex output files for DSA 3653-2

[Wei Liu]

On Mon, Sep 05, 2016 at 11:24:45AM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH] libxl: update flex output files for DSA 3653-2"):
> > We updated flex output files in 4b314c89 ("libxl: update flex output
> > files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
> > discovered the fix to flex was incomplete and issued DSA 3653-2. We need
> > to update our flex output files accordingly.
> 
> *sigh*
> 
> Acked-by: Ian Jackson 

Pushed. Thanks.

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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Wei Liu]

On Mon, Sep 05, 2016 at 11:39:22AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] libxl: do not assume Dom0 backend while getting 
> nic info"):
> > On Mon, Sep 05, 2016 at 11:44:46AM +0200, Marek Marczykowski-Górecki wrote:
> > > Yes, certainly. If you want I can send a 4.7 version (function is in
> > > libxl.c there).
> 
> Thanks for the backport.
> 
> Wei, can you mail me here (or tell me on irc) when the unstable fix
> goes into staging ?
> 

This patch is now in staging.

Wei.

> Thanks,
> Ian.

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

Re: [Xen-devel] [PATCH v5] x86/cpuid: AVX-512 Feature Detection

[Andrew Cooper]

On 23/08/16 02:54, Luwei Kang wrote:
> AVX512 is an extention of AVX2. Its spec can be found at:
> https://software.intel.com/sites/default/files/managed/b4/3a/319433-024.pdf
> This patch detects AVX512 features by CPUID.
>
> Signed-off-by: Luwei Kang 

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

Re: [Xen-devel] [PATCH] libxl: do not assume Dom0 backend while getting nic info

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] libxl: do not assume Dom0 backend while getting 
nic info"):
> On Mon, Sep 05, 2016 at 11:44:46AM +0200, Marek Marczykowski-Górecki wrote:
> > Yes, certainly. If you want I can send a 4.7 version (function is in
> > libxl.c there).

Thanks for the backport.

Wei, can you mail me here (or tell me on irc) when the unstable fix
goes into staging ?

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] libxl: add "xl qemu-monitor-command"

[Ian Jackson]

Juergen Gross writes ("[PATCH] libxl: add "xl qemu-monitor-command""):
> Add a new xl command "qemu-monitor-command" to issue arbitrary commands
> to a domain's device model. Syntax is:
> 
> xl qemu-monitor-command  
> 
> The command is issued via qmp human-monitor-command command. Any
> information returned by the command is printed to stdout.
...
> +=item B I I
> +
> +Issue a monitor command to the device model of the domain specified by
> +I. I can be any valid command qemu understands. This
> +can be e.g. used to add non-standard devices or devices with non-standard
> +parameters to a domain. The output of the command is printed to stdout.

This needs some kind of health warning.  Something like:

 Warning: This qemu monitor access is provided for convenience when
 debugging, troubleshooting, and experimenting.  Its use is not
 supported by the Xen Project.

 Specifically, not all information printed by the qemu monitor will
 necessarily be accurate or complete, because in a Xen system qemu
 does not have a complete view of the guest.

 Furthermore, modifying the guest's setup via the qemu monitor may
 conflict with the Xen toolstack's assumptions.  Resulting problems
 may include, but are not limited to: guest crashes; toolstack error
 messages; inability to migrate the guest; and security
 vulnerabilities which are not covered by the Xen Project security
 response policy.

The rest of the documentation will need adjusting.  As an example of
the incompleteness I am talking about I think the example shows only
some of the USB devices presented to the guest.

Ian.

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

Re: [Xen-devel] Regression between Xen 4.6.0 and 4.7.0, Direct kernel boot on a qemu-xen and seabios HVM guest doesn't work anymore.

[Jan Beulich]

>>> On 05.09.16 at 12:02,  wrote:
> On 2016-09-05 11:46, Jan Beulich wrote:
> On 05.09.16 at 11:20,  wrote:
>>> Hmm it seems my thread was kind of hijacked and i was dropped from the
>>> CC.
>>> 
>>> I had some time and bisected the issue and it resulted in:
>>> 
>>> 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f is the first bad commit
>>> commit 5a3ce8f85e7e7bdd339d259daa19f6bc5cb4735f
>>> Author: Jan Beulich 
>>> Date:   Wed Oct 21 10:56:31 2015 +0200
>>> 
>>>  x86/shadow: drop stray name tags from 
>>> sh_{guest_get,map}_eff_l1e()
>> 
>> Hmm, as Wei already indicated - that's rather odd. The commit isn't
>> really supposed to have any effect on functionality (and going
>> through it again I also can't spot any now). And are you indeed
>> using shadow mode, and if so does your problem not occur when
>> you use HAP instead?
>> 
>> In any event, if there was some hidden (and unintended) change
>> in functionality here, then the most likely result would seem to be
>> a crash, yet from the log fragment you posted it doesn't look like
>> there's _any_ relevant hypervisor output.
> 
> Hmm i was already afraid of that.
> Attached is the output of xl dmesg, HAP is supported and should be 
> enabled by default (and i didn't disable it explicitly in my guest.cfg).
> 
> I just tried the opposite and specified hap=0 in my guest.cfg and this 
> case leads to 2 lines of additional output:
> 
> XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): can't 
> find all mappings of mfn 471b69: c=8003 t=7401
> (XEN) [2016-09-05 09:58:22.201] sh error: sh_remove_all_mappings(): 
> can't find all mappings of mfn 471b68: c=8003 
> t=7401

And these two messages are relevant here? I.e. do they go away
when you use a commit ahead of the one your bisect spotted?

Anyway - with you quite clearly having used HAP before, I can't
see how this commit would matter for you at all. In case you want
to double check you could try with a hypervisor built without
shadow paging code (which we've been allowing for quite a
while).

Is it possible that the reproduction of the issue isn't 100% reliable?
I.e. did you verify with a couple of runs each that it really is this
commit, and not just some spurious effect? If it is, then from all I
know so far I'd suspect an effect from code / data arrangement
rather than the commit itself to be the actual culprit. Which reminds
me of another possible way of double checking: If said commit
reverts reasonably cleanly at the tip of staging or master, maybe
you could try with just this change reverted, instead of with
everything subsequent to it reverted too?

Jan


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

Re: [Xen-devel] [PATCH] libxl: update flex output files for DSA 3653-2

[Ian Jackson]

Wei Liu writes ("[PATCH] libxl: update flex output files for DSA 3653-2"):
> We updated flex output files in 4b314c89 ("libxl: update flex output
> files") for DSA 3653-1 / CVE-2016-6354. But Debian security team
> discovered the fix to flex was incomplete and issued DSA 3653-2. We need
> to update our flex output files accordingly.

*sigh*

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v3 10/38] arm/p2m: Move hostp2m init/teardown to individual functions

[Sergej Proskurin]

Hi Julien,


On 09/02/2016 12:51 PM, Julien Grall wrote:
>
>
> On 02/09/16 10:09, Sergej Proskurin wrote:
>> Hi Julien,
>>
>> On 09/01/2016 07:36 PM, Julien Grall wrote:
>>> Hello Sergej,
>>>
>>> On 16/08/16 23:16, Sergej Proskurin wrote:
 ---
  xen/arch/arm/p2m.c| 71
 +--
  xen/include/asm-arm/p2m.h | 11 
  2 files changed, 73 insertions(+), 9 deletions(-)

 diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
 index e859fca..9ef19d4 100644
 --- a/xen/arch/arm/p2m.c
 +++ b/xen/arch/arm/p2m.c
 @@ -1245,27 +1245,53 @@ static void p2m_free_vmid(struct domain *d)
  spin_unlock(&vmid_alloc_lock);
  }

 -void p2m_teardown(struct domain *d)
 +/* Reset this p2m table to be empty. */
 +void p2m_flush_table(struct p2m_domain *p2m)
  {
 -struct p2m_domain *p2m = p2m_get_hostp2m(d);
 -struct page_info *pg;
 +struct page_info *page, *pg;
 +unsigned int i;
 +
 +if ( p2m->root )
 +{
 +page = p2m->root;
 +
 +/* Clear all concatenated first level pages. */
>>>
>>> s/first/root/
>>>
>>
>> Ok.
>>
 +for ( i = 0; i < P2M_ROOT_PAGES; i++ )
 +clear_and_clean_page(page + i);
>>>
>>> Clearing live page table like that is not safe. Each entry (64-bit)
>>> should be written atomically to avoid breaking coherency (e.g if the
>>> MMU
>>> is walking the page table at the same time). However you don't know the
>>> implementation of clear_and_clean_page.
>>
>> The function p2m_flush_table gets called by the altp2m subsystem
>> indrectly through the function p2m_teardown_one when the associated view
>> gets destroyed. In this case we should not worry about crashing the
>> domain, as the altp2m views are not active anyway.
>>
>> The function altp2m_reset calls the function p2m_flush_table directly
>> (with active altp2m views), however, locks the p2m before flushing the
>> table. I did not find any locks on page-granularity, so please provide
>> me with further information about the solution you had in mind.
>
> I never mentioned any locking problem. As said in my previous mail,
> the altp2m may still be in use by another vCPU. So the MMU (i.e the
> hardware) may want do a table walk whilst you modify the entry.
>
> The MMU is reading the entry (64-bit) at once so it also expects the
> entry to be modified atomically. However, you don't know the
> implementation of clean_and_clean_page. The function might write
> 32-bit at the time, which means that the MMU will see bogus entry. At
> best it will lead to a crash, at worst open a security issue.
>

I see your point. Not sure how to fix this, though. I believe that the
described issue would remain if we would use free_domheap_pages.
Instead, maybe we should manually set the value in the translation tables?

Or, what if we flush the TLBs immediately before unmapping the root
pages? This would cause the system to load the mappings from memory and
delay a MMU table walk so that it would potentially resolve the
atomicity issue.

Do you have another suggestion?

>>>
>>> Also, this adds a small overhead when tearing down a p2m because the
>>> clear is not necessary.
>>>
>>
>> The p2m views are cleared very rarely so the overhead is really minimal
>> as it affects clearing the root tables.
>
> You seem to forget the p2m teardown is also called during domain
> destruction.
>
>> Besides the function
>> altp2m_reset calls the function p2m_flush_table and assumes that the
>> root tables are cleared as well. If the root tables would not be cleared
>> at this point, stalled entries in the altp2m views that got wiped out in
>> the hostp2m would make the system unstable.
>
> As I already mentioned in the previous version, this code was not
> present before and based of the description of this commit the patch
> is supposed to only move code around. This is not the case here.
>

I will move the part with the clear_and_clean_page invocation into a
separate patch.

>

  radix_tree_destroy(&p2m->mem_access_settings, NULL);
  }

 -int p2m_init(struct domain *d)
 +int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
  {
 -struct p2m_domain *p2m = p2m_get_hostp2m(d);
  int rc = 0;

  rwlock_init(&p2m->lock);
 @@ -1278,11 +1304,14 @@ int p2m_init(struct domain *d)
  return rc;

  p2m->max_mapped_gfn = _gfn(0);
 -p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 +p2m->lowest_mapped_gfn = INVALID_GFN;
>>>
>>> Why this change?
>>>
>>
>> Since we compare the gfn's with INVALID_GFN throughout the code it makes
>> sense to use the macro instead of a hardcoded value.
>
> Please don't do unnecessary change. This patch is complex enough to
> review.

Ok.

Cheers,
~Sergej


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

[Xen-devel] [distros-debian-sid test] 67637: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

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

baseline version:
 flight   67603

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub fail



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

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

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


Push not applicable.


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

[Xen-devel] [PATCH for-4.7, 4.6] libxl: do not assume Dom0 backend while getting nic info

[Marek Marczykowski-Górecki]

Fill backend_domid field based on backend path.

Cc: Ian Jackson 
Cc: Wei Liu 
Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index e1ab6ec..9a888a1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3601,6 +3601,18 @@ static int libxl__device_nic_from_xenstore(libxl__gc *gc,
 else
 nic->devid = 0;
 
+rc = libxl__xs_read_checked(gc, XBT_NULL,
+GCSPRINTF("%s/backend", libxl_path), &tmp);
+if (rc) goto out;
+
+if (!tmp) {
+LOG(ERROR, "nic %s does not exist (no backend path)", libxl_path);
+rc = ERROR_FAIL;
+goto out;
+}
+rc = libxl__backendpath_parse_domid(gc, tmp, &nic->backend_domid);
+if (rc) goto out;
+
 /* nic->mtu = */
 
 tmp = READ_LIBXLDEV(gc, "mac");
-- 
2.5.5


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

[Xen-devel] [PATCH RFC 6/6] xen/arm: platforms/tegra: ensure the hwdom can only affect its own interrupts

[Kyle Temkin]

From: "Kyle J. Temkin" 

Several Tegra hardware devices-- and the Tegra device tree--  expect
the presence of a Tegra Legacy Interrupt Controller (LIC) in the hardware
domain. Accordingly, we'll need to expose (most of) the LIC's registers
to the hardware domain.

As the Tegra LIC provides the ability to modify interrupt delivery (e.g.
by masking interrupts, forcing asserting/clearing them, or adjusting
their prority), it's important that the hardware domain's access be
mediated. This commit adds read/write handlers that prohibit
modification of register sections corresponding to interrupts not owned
by the hardware domain.

Note that this is written to be domain agnostic; this allows the
potential to e.g. map the ictlr into multiple domains if this is desired
for passthrough in the future.

Signed-off-by: Kyle Temkin 
---
 xen/arch/arm/platforms/tegra.c | 227 +++--
 1 file changed, 216 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/platforms/tegra.c b/xen/arch/arm/platforms/tegra.c
index e75242c..a119c01 100644
--- a/xen/arch/arm/platforms/tegra.c
+++ b/xen/arch/arm/platforms/tegra.c
@@ -21,11 +21,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 
 /* Permanent mapping to the Tegra legacy interrupt controller. */
@@ -258,6 +260,218 @@ static void tegra_route_irq_to_xen(struct irq_desc *desc, 
unsigned int priority)
 }
 
 /**
+ * Parses a LIC MMIO read or write, and extracts the information needed to
+ * complete the request.
+ *
+ * @param info Information describing the MMIO read/write being performed.
+ * @param register_number The register number in the ictlr; e.g.
+ *TEGRA_ICTLR_CPU_IER_SET.
+ * @param register_offset The offset into tegra_icltr_base at which the target
+ *register exists.
+ * @param The number of the first IRQ represented by the given ictlr register.
+ */
+static void tegra_ictlr_parse_mmio_request(mmio_info_t *info,
+int *register_number, int *register_offset, int *irq_base)
+{
+/* Determine the offset of the access into the ICTLR region. */
+uint32_t offset = info->gpa - TEGRA_ICTLR_BASE;
+
+if(register_number)
+*register_number = offset % TEGRA_ICTLR_SIZE;
+
+if(register_offset)
+*register_offset = offset;
+
+if(irq_base) {
+int ictlr_number = offset / TEGRA_ICTLR_SIZE;
+*irq_base = (ictlr_number * TEGRA_IRQS_PER_ICTLR) + NR_LOCAL_IRQS;
+}
+}
+
+/**
+ * Returns true iff the given IRQ is currently routed to the given domain.
+ *
+ * @param irq The IRQ number for the IRQ in question.
+ * @param d The domain in question.
+ * @return True iff the given domain is the current IRQ target.
+ */
+static bool irq_owned_by_domain(int irq, struct domain *d)
+{
+struct irq_desc *desc = irq_to_desc(irq);
+domid_t domid;
+unsigned long flags;
+
+BUG_ON(!desc);
+
+spin_lock_irqsave(&desc->lock, flags);
+domid = irq_get_domain_id(desc);
+spin_unlock_irqrestore(&desc->lock, flags);
+
+return (d->domain_id == domid);
+}
+
+
+/**
+ * Mediates an MMIO-read to the Tegra legacy interrupt controller.
+ * Ensures that each domain only is passed interrupt state for its
+ * own interupts.
+ */
+static int tegra_ictlr_domain_read(struct vcpu *v, mmio_info_t *info,
+register_t *target_register, void *priv)
+{
+register_t raw_value;
+
+int register_number;
+int register_offset;
+int irq_base;
+int i;
+
+tegra_ictlr_parse_mmio_request(info, ®ister_number, ®ister_offset,
+   &irq_base);
+
+/* Sanity check the read. */
+if ( register_offset & 0x3 ) {
+printk(XENLOG_G_ERR "d%u: Tegra LIC: Attempt to read unaligned ictlr 
addr"
+"(%" PRIpaddr ")!", current->domain->domain_id, 
info->gpa);
+domain_crash_synchronous();
+}
+if ( info->dabt.size != DABT_WORD ) {
+printk(XENLOG_G_ERR "d%u: Tegra LIC: Non-word read from ictlr addr"
+"%" PRIpaddr "!", current->domain->domain_id, 
info->gpa);
+domain_crash_synchronous();
+}
+
+/* Ensure that we've only been handed an offset within our region. */
+BUG_ON(register_offset > TEGRA_ICTLR_SIZE * TEGRA_ICTLR_COUNT);
+
+/* Perform the core ictlr read. */
+raw_value = readl(tegra_ictlr_base + register_offset);
+
+/*
+ * We don't want to leak information about interrupts not controlled
+ * by the active domain. Thus, we'll zero out any ictlr slots for
+ * IRQs not owned by the given domain.
+ */
+for (i = 0; i < TEGRA_IRQS_PER_ICTLR; ++i) {
+int irq = irq_base + i;
+int mask = BIT(irq % 32);
+
+if(!irq_owned_by_domain(irq, current->domain))
+raw_value &= ~mask;
+}
+
+/* Finally, set the target register to our read value */
+*target_register = raw_value;
+return 1;
+}
+
+
+/**
+ * Mediates an MMIO-read to the Tegra le