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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101050 pass in 101076
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 101050 pass 
in 101076
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 101050

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

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

version targeted for testing:
 xen  a7edbdcac31ad55e93e482f66050bc4ffd04d8a9
baseline version:
 xen  317eb71bc3b0830338601fb14d1f49546a1c1e35

Last test of basis   101022  2016-09-20 00:20:42 Z2 days
Testing same since   101050  2016-09-20 16:13:12 Z1 days2 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] [for-4.8][PATCH v2 17/23] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

[Stefano Stabellini]

On Thu, 15 Sep 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_set_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_set_entry, is provided to break down is region
> into mapping that is aligned to a block entry or 4KB when memaccess is
> enabled.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Changes in v2:
> - fix typoes in the commit message
> - don't use the default access when shattering the superpage
> - remove duplicated comment
> - export p2m_set_entry
> - s/todo/nr/
> - iommu flush
> - update the stats when removing/adding a mapping
> - update doc
> - fix p2m_split_superpage
> - don't try to allocate intermediate page table when removing an
> entry
> - the TLB flush is not necessary when only permission are
> changed (e.g memaccess).
> ---
>  xen/arch/arm/p2m.c | 374 
> +
>  xen/include/asm-arm/p2m.h  |  11 ++
>  xen/include/asm-arm/page.h |   4 +
>  3 files changed, 389 insertions(+)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 3ca2e90..5f7aef0 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -783,6 +783,380 @@ static void p2m_put_l3_page(const lpae_t pte)
>  }
>  }
>  
> +/* 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. */
> +if ( !p2m_valid(entry) )
> +return;
> +
> +/* Nothing to do but updating the states if the entry is a super-page. */
   ^ stats

Aside from this small typo, everything else is good:

Reviewed-by: Stefano Stabellini 


> +if ( p2m_is_superpage(entry, level) )
> +{
> +p2m->stats.mappings[level]--;
> +return;
> +}
> +
> +if ( level == 3 )
> +{
> +p2m->stats.mappings[level]--;
> +p2m_put_l3_page(entry);
> +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?
> + */
> +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 = 

[Xen-devel] [v2 3/3] tools & docs: add L2 CAT support in tools and docs.

[Yi Sun]

This patch is the xl/xc changes to support Intel L2 CAT
(Cache Allocation Technology).

The new level option is introduced to original CAT setting
command in order to set CBM for specified level CAT.
- 'xl psr-hwinfo' is updated to show both L3 CAT and L2 CAT
  info.
- 'xl psr-cat-cbm-set' is updated to set cache capacity
  bitmasks(CBM) for a domain according to input cache level.
- 'xl psr-cat-show' is updated to show CBM of a domain
  according to input cache level.

Examples:
root@:~$ xl psr-hwinfo --cat
Cache Allocation Technology (CAT): L2
Socket ID   : 0
Maximum COS : 3
CBM length  : 8
Default CBM : 0xff

root@:~$ xl psr-cat-cbm-set -l2 1 0x7f

root@:~$ xl psr-cat-show -l2 1
Socket ID   : 0
Default CBM : 0xff
   ID NAME CBM
1 ubuntu140x7f

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 

---
Changed since v1:
 * xl_cmdimpl.c
   - Add prompt message to input cache level.
 * xc_psr.c
   - Adjust codes to make it easier to read.
---
 docs/man/xl.pod.1.in  |  25 +-
 docs/misc/xl-psr.markdown |  10 ++-
 tools/libxc/include/xenctrl.h |   7 +-
 tools/libxc/xc_psr.c  |  47 +++---
 tools/libxl/libxl.h   |   2 +
 tools/libxl/libxl_psr.c   |  50 ++-
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/xl_cmdimpl.c  | 195 +++---
 tools/libxl/xl_cmdtable.c |   4 +-
 9 files changed, 287 insertions(+), 54 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index a2be541..f7887ac 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1696,6 +1696,9 @@ occupancy monitoring share the same set of underlying 
monitoring service. Once
 a domain is attached to the monitoring service, monitoring data can be shown
 for any of these monitoring types.
 
+There is no cache monitoring and memory bandwidth monitoring on L2 cache so
+far.
+
 =over 4
 
 =item B [I]
@@ -1720,7 +1723,7 @@ monitor types are:
 
 Intel Broadwell and later server platforms offer capabilities to configure and
 make use of the Cache Allocation Technology (CAT) mechanisms, which enable more
-cache resources (i.e. L3 cache) to be made available for high priority
+cache resources (i.e. L3/L2 cache) to be made available for high priority
 applications. In the Xen implementation, CAT is used to control cache 
allocation
 on VM basis. To enforce cache on a specific domain, just set capacity bitmasks
 (CBM) for the domain.
@@ -1730,7 +1733,7 @@ Intel Broadwell and later server platforms also offer 
Code/Data Prioritization
 applications. CDP is used on a per VM basis in the Xen implementation. To
 specify code or data CBM for the domain, CDP feature must be enabled and CBM
 type options need to be specified when setting CBM, and the type options (code
-and data) are mutually exclusive.
+and data) are mutually exclusive. There is no CDP support on L2 so far.
 
 =over 4
 
@@ -1747,6 +1750,11 @@ B
 
 Specify the socket to process, otherwise all sockets are processed.
 
+=item B<-l LEVEL>, B<--level=LEVEL>
+
+Specify the cache level to process, otherwise the last level cache is
+processed.
+
 =item B<-c>, B<--code>
 
 Set code CBM when CDP is enabled.
@@ -1757,10 +1765,21 @@ Set data CBM when CDP is enabled.
 
 =back
 
-=item B [I]
+=item B [I] [I]
 
 Show CAT settings for a certain domain or all domains.
 
+B
+
+=over 4
+
+=item B<-l LEVEL>, B<--level=LEVEL>
+
+Specify the cache level to process, otherwise the last level cache is
+processed.
+
+=back
+
 =back
 
 =head1 IGNORED FOR COMPATIBILITY WITH XM
diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index c3c1e8e..bd2b6bd 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -70,7 +70,7 @@ total-mem-bandwidth instead of cache-occupancy). E.g. after a 
`xl psr-cmt-attach
 
 Cache Allocation Technology (CAT) is a new feature available on Intel
 Broadwell and later server platforms that allows an OS or Hypervisor/VMM to
-partition cache allocation (i.e. L3 cache) based on application priority or
+partition cache allocation (i.e. L3/L2 cache) based on application priority or
 Class of Service (COS). Each COS is configured using capacity bitmasks (CBM)
 which represent cache capacity and indicate the degree of overlap and
 isolation between classes. System cache resource is divided into numbers of
@@ -119,13 +119,19 @@ A cbm is valid only when:
 In a multi-socket system, the same cbm will be set on each socket by default.
 Per socket cbm can be specified with the `--socket SOCKET` option.
 
+In different systems, the different cache level is supported, e.g. L3 cache or
+L2 cache. Per cache level cbm can be specified with the `--level LEVEL` option.
+
 Setting the CBM may not be successful if insufficient COS is available. In
 such case unused COS(es) may be freed by setting CBM of all related domains to
 its default 

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

[Yi Sun]

Current psr.c is designed for supporting L3 CAT/CDP. It has many
limitations to add new feature. Considering to support more PSR
features, we need refactor PSR implementation to make it more
flexible and fulfill the principle, open for extension but closed
for modification.

The core of the refactoring is to abstract the common actions and
encapsulate them into "struct feat_ops". The detailed steps to add
a new feature are described at the head of psr.c.

Signed-off-by: Yi Sun 

---
Changed since v1:
 * sysctl.c
- Interface change for abstraction requirement.
 * psr.c
- Function and variables names are changed to express accurately.
- Fix code style issues.
- Fix imprecise comments.
- Add one callback function, get_cos_num(), to fulfill the
  abstraction requirement.
- Divide get_old_set_new() callback functions into two functions:
  get_old_val() and set_new_val() make it more primitive.
- Change feat_info type from an array to union.
- Adjust some functions to replace if to switch to make them
  clearer.
- Replace custom list management to system.
- Use 'const' to make codes more safe.
 * psr.h
- Change 'enum mask_type' to 'enum psr_val_type' to express
  more accurate.
- Change parameters of psr_get_info() to fulfill abstraction
  requirement.
---
 xen/arch/x86/domctl.c |   36 +-
 xen/arch/x86/psr.c| 1105 +++--
 xen/arch/x86/sysctl.c |   14 +-
 xen/include/asm-x86/psr.h |   20 +-
 4 files changed, 903 insertions(+), 272 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2a2fe04..c53d819 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1386,41 +1386,41 @@ long arch_do_domctl(
 switch ( domctl->u.psr_cat_op.cmd )
 {
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CBM:
-ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
- domctl->u.psr_cat_op.data,
- PSR_CBM_TYPE_L3);
+ret = psr_set_val(d, domctl->u.psr_cat_op.target,
+  domctl->u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_CBM);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_CODE:
-ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
- domctl->u.psr_cat_op.data,
- PSR_CBM_TYPE_L3_CODE);
+ret = psr_set_val(d, domctl->u.psr_cat_op.target,
+  domctl->u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_CODE);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_SET_L3_DATA:
-ret = psr_set_l3_cbm(d, domctl->u.psr_cat_op.target,
- domctl->u.psr_cat_op.data,
- PSR_CBM_TYPE_L3_DATA);
+ret = psr_set_val(d, domctl->u.psr_cat_op.target,
+  domctl->u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_DATA);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
-ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- >u.psr_cat_op.data,
- PSR_CBM_TYPE_L3);
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  >u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_CBM);
 copyback = 1;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE:
-ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- >u.psr_cat_op.data,
- PSR_CBM_TYPE_L3_CODE);
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  >u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_CODE);
 copyback = 1;
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_DATA:
-ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- >u.psr_cat_op.data,
- PSR_CBM_TYPE_L3_DATA);
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  >u.psr_cat_op.data,
+  PSR_MASK_TYPE_L3_DATA);
 copyback = 1;
 break;
 
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 0b5073c..99e4c78 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -17,28 +17,159 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define PSR_CMT(1<<0)
 #define PSR_CAT(1<<1)
 #define PSR_CDP(1<<2)
 
-struct psr_cat_cbm {
+/*
+ * To add a new PSR feature, please follow below steps:
+ * 1. Implement feature specific callback functions listed in
+ *"struct feat_ops";
+ * 2. Implement a feature specific "struct 

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

[Yi Sun]

Add L2 CAT (Cache Allocation Technology) feature support in
hypervisor:
- Implement 'struct feat_ops' callback functions for L2 CAT
  and initialize L2 CAT feature and add it into feature list.
- Add new sysctl to get L2 CAT information.
- Add new domctl to set/get L2 CAT CBM.

Signed-off-by: He Chen 
Signed-off-by: Yi Sun 

---
Changed since v1:
 * psr.c
- Function and variables names are changed to express accurately.
- Fix code style issues.
- Fix imprecise comments.
- Add one callback function, get_cos_num(), to fulfill the
  abstraction requirement.
- Replace custom list management to system.
- Use 'const' to make codes more safe.
---
 xen/arch/x86/domctl.c   |  13 +++
 xen/arch/x86/psr.c  | 216 
 xen/arch/x86/sysctl.c   |  13 +++
 xen/include/asm-x86/msr-index.h |   1 +
 xen/include/asm-x86/psr.h   |   2 +
 xen/include/public/domctl.h |   2 +
 xen/include/public/sysctl.h |   6 ++
 7 files changed, 253 insertions(+)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index c53d819..24f85c7 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1424,6 +1424,19 @@ long arch_do_domctl(
 copyback = 1;
 break;
 
+case XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM:
+ret = psr_set_val(d, domctl->u.psr_cat_op.target,
+  domctl->u.psr_cat_op.data,
+  PSR_MASK_TYPE_L2_CBM);
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM:
+ret = psr_get_val(d, domctl->u.psr_cat_op.target,
+  >u.psr_cat_op.data,
+  PSR_MASK_TYPE_L2_CBM);
+copyback = 1;
+break;
+
 default:
 ret = -EOPNOTSUPP;
 break;
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 99e4c78..5000a3c 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -137,6 +137,7 @@ struct psr_cat_lvl_info {
 struct feat_info {
 union {
 struct psr_cat_lvl_info l3_info;
+struct psr_cat_lvl_info l2_info;
 };
 };
 
@@ -158,12 +159,15 @@ struct psr_ref {
 unsigned int ref;
 };
 
+
 #define PSR_SOCKET_L3_CAT 0
 #define PSR_SOCKET_L3_CDP 1
+#define PSR_SOCKET_L2_CAT 2
 
 struct psr_socket_info {
 /*
  * bit 1~0: [01]->L3 CAT-only, [10]->L3 CDP
+ * bit 2:   L2 CAT
  */
 unsigned int features;
 unsigned int nr_feat;
@@ -190,6 +194,7 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
 static struct psr_ref *temp_cos_ref;
 /* Every feature has its own object. */
 static struct feat_list *feat_l3;
+static struct feat_list *feat_l2;
 
 /* Common functions for supporting feature callback functions. */
 static void free_feature(struct psr_socket_info *info)
@@ -212,6 +217,12 @@ static void free_feature(struct psr_socket_info *info)
 xfree(feat_l3);
 feat_l3 = NULL;
 }
+
+if ( feat_l2 )
+{
+xfree(feat_l2);
+feat_l2 = NULL;
+}
 }
 
 static bool psr_check_cbm(unsigned int cbm_len, uint64_t cbm)
@@ -241,6 +252,195 @@ static bool psr_check_cbm(unsigned int cbm_len, uint64_t 
cbm)
  * Features specific implementations.
  */
 
+/* L2 CAT callback functions implementation. */
+static void l2_cat_init_feature(unsigned int eax, unsigned int ebx,
+unsigned int ecx, unsigned int edx,
+struct feat_list *feat,
+struct psr_socket_info *info)
+{
+struct psr_cat_lvl_info l2_cat;
+unsigned int socket;
+
+/* No valid value so do not enable feature. */
+if ( 0 == eax || 0 == edx )
+return;
+
+l2_cat.cbm_len = (eax & 0x1f) + 1;
+l2_cat.cos_max = min(opt_cos_max, edx & 0x);
+
+/* cos=0 is reserved as default cbm(all ones). */
+feat->cos_reg_val[0] = (1ull << l2_cat.cbm_len) - 1;
+
+feat->feature = PSR_SOCKET_L2_CAT;
+__set_bit(PSR_SOCKET_L2_CAT, >features);
+
+feat->info.l2_info = l2_cat;
+
+info->nr_feat++;
+
+/* Add this feature into list. */
+list_add_tail(>list, >feat_list);
+
+socket = cpu_to_socket(smp_processor_id());
+printk(XENLOG_INFO "L2 CAT: enabled on socket %u, cos_max:%u, 
cbm_len:%u.\n",
+   socket, feat->info.l2_info.cos_max, feat->info.l2_info.cbm_len);
+}
+
+static int l2_cat_compare_val(const uint64_t val[],
+  const struct feat_list *feat,
+  unsigned int cos, bool *found)
+{
+uint64_t l2_def_cbm;
+
+l2_def_cbm = (1ull << feat->info.l2_info.cbm_len) - 1;
+
+/* L2 CAT */
+if ( cos > feat->info.l2_info.cos_max )
+{
+if ( val[0] != l2_def_cbm )
+{
+*found = false;
+return -ENOENT;
+}
+*found = true;
+}
+else
+*found = (val[0] == 

[Xen-devel] [v2 0/3] Enable L2 Cache Allocation Technology

[Yi Sun]

Design document is below:
===
% Intel L2 Cache Allocation Technology (L2 CAT) Feature
% Revision 2.0

\clearpage

Hi all,

We plan to bring a new PSR (Platform Shared Resource) feature called
Intel L2 Cache Allocation Technology (L2 CAT) to Xen.

This is the design of L2 CAT. It might be a little long and detailed, hope
it doesn't matter.

Besides the L2 CAT implementaion, we refactor the psr.c to make it more
flexible to add new features and fulfill the principle, open for extension
but closed for modification. 

Comments and suggestions are welcome :-)

# Basics

 
 Status: **Tech Preview**

Architecture(s): Intel x86

   Component(s): Hypervisor, toolstack

   Hardware: Atom codename Goldmont and beyond
 

# Overview

L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
CPU's shared L2 cache based on application priority or Class of Service
(COS). Each CLOS is configured using capacity bitmasks (CBM) which
represent cache capacity and indicate the degree of overlap and
isolation between classes. Once L2 CAT is configured, the processor
allows access to portions of L2 cache according to the established
class of service (COS).

# Technical information

L2 CAT is a member of Intel PSR features and part of CAT, it shares
some base PSR infrastructure in Xen.

## Hardware perspective

L2 CAT defines a new range MSRs to assign different L2 cache access
patterns which are known as CBMs (Capacity BitMask), each CBM is
associated with a COS.

```

+++
   IA32_PQR_ASSOC   | MSR (per socket)   |Address |
 ++---+---+ +++
 ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
 ++---+---+ +++
└-> | ...|  ...   |
+++
| IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
+++
```

When context switch happens, the COS of VCPU is written to per-thread
MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
according to the corresponding CBM.

## The relationship between L2 CAT and L3 CAT/CDP

L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.

L2 CAT uses a new range CBMs from 0xD10 ~ 0xD10+n (n<64), following by
the L3 CAT/CDP CBMs, and supports setting different L2 cache accessing
patterns from L3 cache. Like L3 CAT/CDP requirement, the bits of CBM of
L2 CAT must be continuous too.

N.B. L2 CAT and L3 CAT/CDP share the same COS field in the same
associate register `IA32_PQR_ASSOC`, which means one COS associate to a
pair of L2 CBM and L3 CBM.
Besides, the max COS of L2 CAT may be different from L3 CAT/CDP (or
other PSR features in future). In some cases, a VM is permitted to have a
COS that is beyond one (or more) of PSR features but within the others. 
For instance, let's assume the max COS of L2 CAT is 8 but the max COS of
L3 CAT is 16, when a VM is assigned 9 as COS, the L3 CBM associated to
COS 9 would be enforced, but for L2 CAT, the behavior is fully open (no
limit) since COS 9 is beyond the max COS (8) of L2 CAT.

## Design Overview

* Core COS/CBM association

  When enforcing L2 CAT, all cores of domains have the same default
  COS (COS0) which associated to the fully open CBM (all ones bitmask)
  to access all L2 cache. The default COS is used only in hypervisor
  and is transparent to tool stack and user.

  System administrator can change PSR allocation policy at runtime by
  tool stack. Since L2 CAT share COS with L3 CAT/CDP, a COS corresponds
  to a 2-tuple, like [L2 CBM, L3 CBM] with only-CAT enabled, when CDP
  is enabled, one COS corresponds to a 3-tuple, like [L2 CBM,
  L3 Code_CBM, L3 Data_CBM]. If neither L3 CAT nor L3 CDP is enabled,
  things would be easier, one COS corresponds to one L2 CBM.

* VCPU schedule

  This part reuses L3 CAT COS infrastructure.

* Multi-sockets

  Different sockets may have different L2 CAT capability (e.g. max COS)
  although it is consistent on the same socket. So the capability of
  per-socket L2 CAT is specified.

## Implementation Description

* Hypervisor interfaces:

  1. Ext: Boot line parameter "psr=cat" now will enable L2 CAT and L3
  CAT if hardware supported.

  2. New: SYSCTL:
  - XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.

  3. New: DOMCTL:
  - XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a domain.
  - XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a domain.

* xl 

Re: [Xen-devel] [V4 PATCH 1/2] x86/panic: Replace smp_send_stop() with kdump friendly version in panic path

['Dave Young']

Hi, 河合英宏

Thanks for the patch log update, it looks good to me.

Acked-by: Dave Young 

On 09/20/16 at 11:22am, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Here is the revised commit description reflecting Dave's
> comment.  Cc list was copied from -mm version.
> 
> From: Hidehiro Kawai 
> Subject: x86/panic: replace smp_send_stop() with kdump friendly version in 
> panic path
> 
> This patch fixes a problem reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44).
> 
> When kernel panics with crash_kexec_post_notifiers kernel parameter
> enabled, other CPUs are stopped by smp_send_stop() instead of
> machine_crash_shutdown() in __crash_kexec() path.
> 
>   panic()
> if crash_kexec_post_notifiers == 1
>   smp_send_stop()
>   atomic_notifier_call_chain()
>   kmsg_dump()
> __crash_kexec()
>   machine_crash_shutdown()
> 
> Different from smp_send_stop(), machine_crash_shutdown() stops other
> CPUs with extra works for kdump.  So, if smp_send_stop() stops other
> CPUs in advance, these extra works won't be done.  For x86, kdump
> routines miss to save other CPUs' registers and disable virtualization
> extensions.
> 
> To fix this problem, call a new kdump friendly function,
> crash_smp_send_stop(), instead of the smp_send_stop() when
> crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
> weak function, and it just call smp_send_stop().  Architecture
> codes should override it so that kdump can work appropriately.
> This patch only provides x86-specific version.
> 
> For Xen's PV kernel, just keep the current behavior.
> As for Dom0, it doesn't use crash_kexec routines, and it relies on
> panic notifier chain.  At the end of the chain, a hypercall is
> issued which requests the hypervisor to execute kdump.  This means
> regardless of crash_kexec_post_notifiers setting, smp_send_stop().
> For PV HVM, it would work similarly to baremetal kernels with extra
> cleanups for hypervisor.  It doesn't need additional care.
> 
> Changes in V4:
> - Keep to use smp_send_stop if crash_kexec_post_notifiers is not set
> - Rename panic_smp_send_stop to crash_smp_send_stop
> - Don't change the behavior for Xen's PV kernel
> 
> Changes in V3:
> - Revise comments, description, and symbol names
> 
> Changes in V2:
> - Replace smp_send_stop() call with crash_kexec version which
>   saves cpu states and cleans up VMX/SVM
> - Drop a fix for Problem 1 at this moment
> 
> Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
> Link: 
> http://lkml.kernel.org/r/20160810080948.11028.15344.st...@sysi4-13.yrl.intra.hitachi.co.jp
> Signed-off-by: Hidehiro Kawai 
> Reported-by: Daniel Walker 
> Cc: Dave Young 
> Cc: Baoquan He 
> Cc: Vivek Goyal 
> Cc: Eric Biederman 
> Cc: Masami Hiramatsu 
> Cc: Daniel Walker 
> Cc: Xunlei Pang 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Borislav Petkov 
> Cc: David Vrabel 
> Cc: Toshi Kani 
> Cc: Ralf Baechle 
> Cc: David Daney 
> Cc: Aaro Koskinen 
> Cc: "Steven J. Hill" 
> Cc: Corey Minyard 
> Signed-off-by: Andrew Morton 
> 

[snip]

Thanks
Dave

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 11 guest-start/redhat.repeat fail in 101049 
pass in 101074
 test-amd64-i386-xl  19 guest-start/debian.repeat fail in 101049 pass in 101074
 test-amd64-i386-xl-raw   9 debian-di-install fail in 101049 pass in 101074
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 101049

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 101026
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101026
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101026
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101026
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101026

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

version targeted for testing:
 xen  245fa11021f8f123a82aa7e894d044d8f0ae6923
baseline version:
 xen  57dbc55cd3e239ab0ce5bdd62cf309e27fe52a1a

Last test of basis   101026  2016-09-20 02:02:05 Z1 days
Testing same since   101049  2016-09-20 16:13:11 Z1 days2 attempts


People who touched revisions under test:
  Ian Jackson 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7419aedd93132f2dfc91e7bf3634fba7e0842c7b
baseline version:
 ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4

Last test of basis67735  2016-09-20 22:21:05 Z1 days
Testing same since67741  2016-09-21 20:18:01 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

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



sg-report-flight on osstest.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 7419aedd93132f2dfc91e7bf3634fba7e0842c7b
Author: Liming Gao 
Date:   Mon Sep 12 15:28:47 2016 +0800

BaseTools: Update toolsetup.bat to set PYTHONPATH env to run python source

When python tool exe doesn't exist, toolsetup.bat will set up PYTHONPATH,
and set python tool dos script directory into system PATH.

Cc: Yonghong Zhu 
Cc: Michael Kinney 
Cc: Erik Bjorge 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 
Reviewed-by: Erik Bjorge 

commit efb1e40f91353d763b02a40c41ad7a38f3d8ff90
Author: Liming Gao 
Date:   Mon Sep 12 15:25:07 2016 +0800

BaseTools: Update Python Makefile not to depend on PYTHON_FREEZER_PATH

If PYTHON_FREEZER_PATH is not set, Python tools will not be freeze.

Cc: Yonghong Zhu 
Cc: Michael Kinney 
Cc: Erik Bjorge 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 
Reviewed-by: Erik Bjorge 

commit 71f5913eb9127305dc6ec63936c3c283975d86c0
Author: Liming Gao 
Date:   Mon Sep 12 15:22:49 2016 +0800

BaseTools: Update python tool to call external tools with shell true mode

Python tool may run from source as the dos batch files. So, update python
code to call external tools with shell true mode.

Cc: Yonghong Zhu 
Cc: Michael Kinney 
Cc: Erik Bjorge 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 
Reviewed-by: Erik Bjorge 

commit bf069759efc4d3b76c66bf992c49d673bb292410
Author: Liming Gao 
Date:   Mon Sep 12 15:19:37 2016 +0800

BaseTools: Add Windows batch files to run python tool from Source

Add 13 windows batch files for every python tool.

Cc: Yonghong Zhu 
Cc: Michael Kinney 
Cc: Erik Bjorge 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 
Reviewed-by: Erik Bjorge 

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Wed, 21 Sep 2016, Julien Grall wrote:
> > > > And in my suggestion, we allow a richer set of labels, so that the user
> > > > could also be more specific -- e.g., asking for "A15" specifically, for
> > > > example, and failing to build if there are no A15 cores present, while
> > > > allowing users to simply write "big" or "little" if they want simplicity
> > > > / things which work across different platforms.
> > > 
> > > Well, before trying to do something clever like that (i.e naming "big" and
> > > "little"), we need to have upstreamed bindings available to acknowledge
> > > the
> > > difference. AFAICT, it is not yet upstreamed for Device Tree (see [1]) and
> > > I
> > > don't know any static ACPI tables providing the similar information.
> > 
> > I like George's idea that "big" and "little" could be just convenience
> > aliases. Of course they are predicated on the necessary device tree
> > bindings being upstream. We don't need [1] to be upstream in Linux, just
> > the binding:
> > 
> > http://marc.info/?l=linux-arm-kernel=147308556729426=2
> > 
> > which has already been acked by the relevant maintainers.
> 
> This is device tree only. What about ACPI?

ACPI will come along with similar information at some point. When we'll
have it, we'll use it.


> > > I had few discussions and  more thought about big.LITTLE support in Xen.
> > > The
> > > main goal of big.LITTLE is power efficiency by moving task around and been
> > > able to idle one cluster. All the solutions suggested (including mine) so
> > > far,
> > > can be replicated by hand (except the VPIDR) so they are mostly an
> > > automatic
> > > way. This will also remove the real benefits of big.LITTLE because Xen
> > > will
> > > not be able to migrate vCPU across cluster for power efficiency.
> > 
> > The goal of the architects of big.LITTLE might have been power
> > efficiency, but of course we are free to use any features that the
> > hardware provides in the best way for Xen and the Xen community.
> 
> This is very dependent on how the big.LITTLE has been implemented by the
> hardware. Some platform can not run both big and LITTLE cores at the same
> time. You need a proper switch in the firmware/hypervisor.
 
Fair enough, that hardware wouldn't benefit from this work.


> > > If we care about power efficiency, we would have to handle seamlessly
> > > big.LITTLE in Xen (i.e a guess would only see a kind of CPU). This arise
> > > quite
> > > few problem, nothing insurmountable, similar to migration across two
> > > platforms
> > > with different micro-architecture (e.g processors): errata, features
> > > supported... The guest would have to know the union of all the errata
> > > (this is
> > > done so far via the MIDR, so we would a PV way to do it), and only the
> > > intersection of features would be exposed to the guest. This also means
> > > the
> > > scheduler would have to be modified to handle power efficiency (not
> > > strictly
> > > necessary at the beginning).
> > > 
> > > I agree that a such solution would require some work to implement,
> > > although
> > > Xen will have a better control of the energy consumption of the platform.
> > > 
> > > So the question here, is what do we want to achieve with big.LITTLE?
> > 
> > I don't think that handling seamlessly big.LITTLE in Xen is the best way
> > to do it in the scenarios where Xen on ARM is being used today. I
> > understand the principles behind it, but I don't think that it will lead
> > to good results in a virtualized environment, where there is more
> > activity and more vcpus than pcpus.
> 
> Can you detail why you don't think it will give good results?

I think big.LITTLE works well for cases where you have short clear burst
of activity while most of the time the system is quasi-idle (but not
completely idle). Basically like a smartphone. For other scenarios with
more uniform activity patterns, like a server or an infotainment system,
big.LITTLE is too big of an hammer to be used for dynamic power saving.
In those cases it is more flexible to expose all cores to VMs, so that
they can exploit all resources when necessary and idle them when they
can (with wfi or deeper sleep state if possible).


> > What we discussed in this thread so far is actionable, and gives us
> > big.LITTLE support in a short time frame. It is a good fit for Xen on
> > ARM use cases and still leads to lower power consumption with an wise
> > allocation of big and LITTLE vcpus and pcpus to guests.
> 
> How this would lead to lower power consumption?  If there is nothing
> running of the processor we would have a wfi loop which will never put
> the physical CPU in deep sleep.

I expect that by assigning appropriate tasks to big and LITTLE cores,
some big cores will be left to idle which will lead to some power
saving, especially if put idle cores in deep sleep (maybe using PSCI?).


> The main advantage of big.LITTLE is too be able to switch off a
> cluster/cpu when it is not used.

To me the main 

[Xen-devel] Fwd: Openindiana, using -machine pc,accel=xen in qemu

[jim burns]

Pls cc me with any replies. 

I didn't get any responses in xen-users, so I'm posting here. My use case is 
as below, but the jist of it is is the qemu option -machine pc,accel=xen meant 
to be usable in standalone qemu, or is it only available from a guest launched 
by xl, or libvirtd via libxl? If the latter, are there any plans to make it 
available as a standalone qemu option? 

Thank you.

--  Forwarded Message  --

Subject: Openindiana, using -machine pc,accel=xen in qemu
Date: Thursday, September 1, 2016
From: jim burns 
To: xen-us...@lists.xen.org

I have not been able to run OpenSolaris / openindiana (OI) in xen. OI is very 
sensitive to the -machine parm in qemu. You can get grub to come up with hvm, 
and add -v to the kernel line, and see that for -machine xenfv, the messages 
stop / hang right after the printing of the cpuid features, and just before 
pci bus enumeration. Qemu's -machine q35 is not much better. After the cpuid 
features, it complains that the usb controllers ohci / ehci are unusable (no 
SOF? Interrupts), enumerates the keyboard, then hangs. The next messages 
should be about the usb mouse, and pci devices.

Awhile back, Jun 2013, patches were discussed in xen-devel to add an accel= 
parm to the -machine type. I can use -machine pc,accel=kvm:tcg in stand alone 
qemu. Booting under xen, there is no kvm, so the slow tcg emulation is chosen, 
but it works. I can reboot bare-metal, and and kvm works marvelously, but I 
have other guests I want to run under xen.

If I use accel=xen:kvm:tcg, and start my stand alone qemu OI guest as an 
unpriviledged user, it complains about not having access to a priviledged 
interface (xenpriv?), but other wise goes on to reject kvm, and pick tcg - no 
surprise since you need root access to run xl, so why would stand alone qemu 
work? However, when I do run as root, I get the following error:

failed to get HVM_PARAM_IOREQ_PFN
qemu-system-x86_64: failed to get ioreq server info: error 22 
handle=0x562306ea5680
qemu-system-x86_64: xen hardware virtual machine initialisation failed

and then aborts, w/o going on to check kvm or tcg. Any ideas on where the 
error is, how to correct? Any other parms needed in qemu? I've checked the 
qemu-discuss and xen lists. There was one suggestion to use 
'xen_platform_pci=0' in your xen cfg, which changes the -machine from xenfv to 
pc,accel=xen, but the xen guest just aborts in the same place it was hanging 
before. Hence, I'm trying to just use stand alone qemu.

Thx. 
-


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

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

[osstest service owner]

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

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  b106f15efbfc99f52ccb94ab8ca7fdb21fcf
baseline version:
 xen  b67715f50ec6235903a6a030b530a0c65d80b351

Last test of basis   101082  2016-09-21 17:02:28 Z0 days
Testing same since   101083  2016-09-21 20:03:17 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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=b106f15efbfc99f52ccb94ab8ca7fdb21fcf
+ . ./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 
b106f15efbfc99f52ccb94ab8ca7fdb21fcf
+ branch=xen-unstable-smoke
+ revision=b106f15efbfc99f52ccb94ab8ca7fdb21fcf
+ . ./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
+ '[' xb106f15efbfc99f52ccb94ab8ca7fdb21fcf = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

On 09/21/2016 06:52 AM, Jan Beulich wrote:
 On 20.09.16 at 02:19,  wrote:
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -127,13 +127,13 @@ tools/firmware/*bios/*bios*.txt
>>  tools/firmware/etherboot/gpxe/*
>>  tools/firmware/extboot/extboot.img
>>  tools/firmware/extboot/signrom
>> -tools/firmware/hvmloader/acpi/mk_dsdt
>> -tools/firmware/hvmloader/acpi/dsdt*.c
>> -tools/firmware/hvmloader/acpi/dsdt_*cpu*.asl
>> -tools/firmware/hvmloader/acpi/ssdt_*.h
>> +tools/firmware/hvmloader/dsdt*.c
>> +tools/firmware/hvmloader/dsdt_*.asl
> Aren't you wrongly dropping the *cpu part here?

(Missed this)

No: *cpu* was added earlier to keep hvmloader/acpi/dsdt_acpi_info.asl
tracked by git but ignore generated files like
hvmloader/acpi/dsdt_anycpu.asl. With this patch, those generated files
will be created in hvmloader/ directory while dsdt_acpi_info.asl stays
in hvmloader/acpi/ (and will eventually be moved to tools/libacpi).

Come think of it, hvmloader/dsdt* and hvmloader/ssdt* should all be ignored.

-boris



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 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-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-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-i386-libvirt  12 migrate-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-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 libvirt  e5568193f4d663f6a9edebcf9044d527f90a031f
baseline version:
 libvirt  706b5b627719e95a33606c463bc83c841c7b5b0e

Last test of basis   100999  2016-09-18 04:20:39 Z3 days
Failing since101029  2016-09-20 04:23:33 Z1 days2 attempts
Testing same since   101072  2016-09-21 04:22:22 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Daniel P. Berrange 
  Eric Blake 
  Erik Skultety 
  Laine Stump 
  Martin Kletzander 
  Michal Privoznik 
  Pavel Hrdina 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=e5568193f4d663f6a9edebcf9044d527f90a031f
+ . ./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 ']'

[Xen-devel] [xen-4.5-testing test] 101070: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 101045
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
101045
 test-amd64-amd64-libvirt-vhd 13 guest-saverestorefail REGR. vs. 101045
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
101045

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 101045
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101045
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 101045
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101045
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101045

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

version targeted for testing:
 xen  84e4e56aa643444f13686362535d8ca8a06839c6
baseline version:
 xen  e4ae4b03d35babc9624b7286f1ea4c6749bad84b

Last test of basis   101045  2016-09-20 12:58:05 Z1 days
Testing same since   101070  2016-09-21 02:03:18 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  fail
 build-i386-rumprun   fail
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1
baseline version:
 xen  f1446de4ba5218a58fa2486ebe090495e0fb05c4

Last test of basis   101040  2016-09-20 11:08:59 Z1 days
Testing same since   101069  2016-09-21 01:49:11 Z0 days1 attempts


People who touched revisions under test:
  Dongli Zhang 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7419aedd93132f2dfc91e7bf3634fba7e0842c7b
baseline version:
 ovmf b6e89910dd31e38944900ddc5cb4b86cf25241b4

Last test of basis   101043  2016-09-20 11:51:49 Z1 days
Testing same since   101071  2016-09-21 03:48:57 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7419aedd93132f2dfc91e7bf3634fba7e0842c7b
+ . ./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 
7419aedd93132f2dfc91e7bf3634fba7e0842c7b
+ branch=ovmf
+ revision=7419aedd93132f2dfc91e7bf3634fba7e0842c7b
+ . ./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
+ '[' x7419aedd93132f2dfc91e7bf3634fba7e0842c7b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Julien Grall]

Hi Dario,

On 21/09/2016 16:45, Dario Faggioli wrote:

On Wed, 2016-09-21 at 14:06 +0100, Julien Grall wrote:

(CC a couple of ARM folks)


Yay, thanks for this! :-)


I had few discussions and  more thought about big.LITTLE support in
Xen.
The main goal of big.LITTLE is power efficiency by moving task
around
and been able to idle one cluster. All the solutions suggested
(including mine) so far, can be replicated by hand (except the VPIDR)
so
they are mostly an automatic way.


I'm sorry, how is this (going to be) handled in Linux? Is it that any
arbitrary task executing any arbitrary binary code can be run on both
big and LITTLE pcpus, depending on the scheduler's and energy
management's decisions?

This does not seem to match with what has been said at some point in
this thread... And if it's like that, how's that possible, if the
pcpus' ISAs are (even only slightly) different?


Right, at some point I mentioned that the set of errata and features 
will be different between processor.


However, it is possible to sanitize the feature registers to expose a 
common set to the guest. This is what is done in Linux at boot time, 
only the features common to all the CPUs will be enabled.


This allows a task to migrate between big and LITTLE CPUs seamlessly.




This will also remove the real
benefits of big.LITTLE because Xen will not be able to migrate vCPU
across cluster for power efficiency.

If we care about power efficiency, we would have to handle
seamlessly
big.LITTLE in Xen (i.e a guess would only see a kind of CPU).


Well, I'm a big fan of an approach that leaves the guests' scheduler
dumb about things like these (i.e., load balancing, energy efficiency,
etc), and hence puts Xen in charge. In fact, on a Xen system, it is
only Xen that has all the info necessary to make wise decisions (e.g.,
the load of the _whole_ host, the effect of any decisions on the
_whole_ host, etc).

But this case may be a LITTLE.bit ( :-PP ) different.

Anyway, I guess I'll way your reply to my question above before
commenting more.


This arise
quite few problem, nothing insurmountable, similar to migration
across
two platforms with different micro-architecture (e.g processors):
errata, features supported... The guest would have to know the union
of
all the errata (this is done so far via the MIDR, so we would a PV
way
to do it), and only the intersection of features would be exposed to
the
guest. This also means the scheduler would have to be modified to
handle
power efficiency (not strictly necessary at the beginning).

I agree that a such solution would require some work to implement,
although Xen will have a better control of the energy consumption of
the
platform.

So the question here, is what do we want to achieve with big.LITTLE?


Just thinking out loud here. So, instead of "just", as George
suggested:

 vcpuclass=["0-1:A35","2-5:A53", "6-7:A72"]

we can allow something like the following (note that I'm tossing out
random numbers next to the 'A's):

 vcpuclass = ["0-1:A35", "2-5:A53,A17", "6-7:A72,A24,A31", "12-13:A8"]

with the following meaning:
 - vcpus 0, 1 can only run on pcpus of class A35
 - vcpus 2,3,4,5 can run on pcpus of class A53 _and_ on pcpus of class
   A17
 - vcpus 6,7 can run on pcpus of class A72, A24, A31
 - vcpus 8,9,10,11 --since they're not mentioned, can run on pcpus of
   any class
 - vcpus 12,13 can only run on pcpus of class A8

This will set the "boundaries", for each vcpu. Then, within these
boundaries, once in the (Xen's) scheduler, we can implement whatever
complex/magic/silly logic we want, e.g.:
 - only use a pcpu of class A53 for vcpus that have an average load
   above 50%
 - only use a pcpu of class A31 if there are no idle pcpus of class A24
 - only use a pcpu of class A17 for a vcpu if the total system load
   divided by the vcpu ID give 42 as result
 - whatever

This allows us to achieve both the following goals:
 - allow Xen to take smart decisions, considering the load and the
   efficiency of the host as a whole
 - allow the guest to take smart decisions, like running lightweight
   tasks on low power vcpus (which then Xen will run on low
   power pcpus, at least on a properly configured system)

Of course this **requires** that, for instance, vcpu 6 must be able to
run on A72, A24 and A31 just fine, i.e., it must be possible for it to
block on I/O when executing on an A72 pcpu, and, later, after wakeup,
restart executing on an A24 pcpu.


With a bit of work in Xen, it would be possible to do move the vCPU 
between big and LITTLE cpus. As mentioned above, we could sanitize the 
features to only enable a common set. You can view the big.LITTLE 
problem as a local live migration between two kind of CPUs.


In your suggestion you don't mention what would happen if the guest 
configuration does not contain the affinity. Does it mean the vCPU will 
be scheduled anywhere? A pCPU/class will be chosen randomly?


To be honest, I quite like this idea. It could be used as soft/hard 

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

[osstest service owner]

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

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  b67715f50ec6235903a6a030b530a0c65d80b351
baseline version:
 xen  424fdc67e90baf543650be2f88e0894afb25494b

Last test of basis   101080  2016-09-21 14:07:51 Z0 days
Testing same since   101082  2016-09-21 17:02:28 Z0 days1 attempts


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

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=b67715f50ec6235903a6a030b530a0c65d80b351
+ . ./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 
b67715f50ec6235903a6a030b530a0c65d80b351
+ branch=xen-unstable-smoke
+ revision=b67715f50ec6235903a6a030b530a0c65d80b351
+ . ./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
+ '[' xb67715f50ec6235903a6a030b530a0c65d80b351 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Julien Grall]

On 21/09/2016 20:11, Julien Grall wrote:

Hi Stefano,

On 21/09/2016 19:13, Stefano Stabellini wrote:

On Wed, 21 Sep 2016, Julien Grall wrote:

(CC a couple of ARM folks)

On 21/09/16 11:22, George Dunlap wrote:

On 21/09/16 11:09, Julien Grall wrote:



On 20/09/16 21:17, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Julien Grall wrote:

Hi Stefano,

On 20/09/2016 20:09, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Julien Grall wrote:

Hi,

On 20/09/2016 12:27, George Dunlap wrote:

On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan

wrote:

On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli
wrote:

On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Dario Faggioli wrote:

I'd like to add a computing capability in xen/arm, like this:

struct compute_capatiliby
{
   char *core_name;
   uint32_t rank;
   uint32_t cpu_partnum;
};

struct compute_capatiliby cc=
{
  {"A72", 4, 0xd08},
  {"A57", 3, 0},
  {"A53", 2, 0xd03},
  {"A35", 1, ...},
}

Then when identify cpu, we decide which cpu is big and which
cpu is
little
according to the computing rank.

Any comments?


I think we definitely need to have Xen have some kind of idea
the
order between processors, so that the user doesn't need to
figure out
which class / pool is big and which pool is LITTLE.  Whether
this
sort
of enumeration is the best way to do that I'll let Julien and
Stefano
give their opinion.


I don't think an hardcoded list of processor in Xen is the right
solution.
There are many existing processors and combinations for big.LITTLE
so it
will
nearly be impossible to keep updated.

I would expect the firmware table (device tree, ACPI) to provide
relevant
data
for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is
looking
at
how Linux does.


That's right, see
Documentation/devicetree/bindings/arm/cpus.txt. It
is
trivial to identify the two different CPU classes and which cores
belong
to which class.t, as


The class of the CPU can be found from the MIDR, there is no need to
use the
device tree/acpi for that. Note that I don't think there is an easy
way in
ACPI (i.e not in AML) to find out the class.


It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot
cpu,
and utilize the second cluster only when the user demands it.


Why do you think the boot CPU will usually be a big one? In the case
of Juno
platform it is configurable, and the boot CPU is a little core on r2
by
default.

In any case, what we care about is differentiate between two set of
CPUs. I
don't think Xen should care about migrating a guest vCPU between big
and
LITTLE cpus. So I am not sure why we would want to know that.


No, it is not about migrating (at least yet). It is about giving
useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class
0x100", or
even "A7" or "A15".


I don't think it is wise to assume that we may have only 2 kind of
CPUs
on the platform. We may have more in the future, if so how would you
name them?


I would suggest that internally Xen recognize an arbitrary number of
processor "classes", and order them according to more powerful -> less
powerful.  Then if at some point someone makes a platform with three
processors, you can say "class 0", "class 1" or "class 2".  "big" would
be an alias for "class 0" and "little" would be an alias for "class 1".


As mentioned earlier, there is no upstreamed yet device tree bindings
to know
the "power" of a CPU (see [1]



And in my suggestion, we allow a richer set of labels, so that the user
could also be more specific -- e.g., asking for "A15" specifically, for
example, and failing to build if there are no A15 cores present, while
allowing users to simply write "big" or "little" if they want
simplicity
/ things which work across different platforms.


Well, before trying to do something clever like that (i.e naming
"big" and
"little"), we need to have upstreamed bindings available to
acknowledge the
difference. AFAICT, it is not yet upstreamed for Device Tree (see
[1]) and I
don't know any static ACPI tables providing the similar information.


I like George's idea that "big" and "little" could be just convenience
aliases. Of course they are predicated on the necessary device tree
bindings being upstream. We don't need [1] to be upstream in Linux, just
the binding:

http://marc.info/?l=linux-arm-kernel=147308556729426=2

which has already been acked by the relevant maintainers.


This is device tree only. What about ACPI?





I had few discussions and  more thought about big.LITTLE support in
Xen. The
main goal of big.LITTLE is power efficiency by moving task around and
been
able to idle one cluster. All the solutions suggested (including
mine) so far,
can be replicated 

[Xen-devel] [PATCH v1 3/3] xen-livepatch: If hypervisor is not compiled with Livepatching

[Konrad Rzeszutek Wilk]

. print a better error code.

Reported-by: Andrew Cooper 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/misc/xen-livepatch.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 2de04c0..f11e71f07f 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -100,8 +100,11 @@ static int list_func(int argc, char *argv[])
 rc = xc_livepatch_list(xch, MAX_LEN, idx, info, name, len, , 
);
 if ( rc )
 {
-fprintf(stderr, "Failed to list %d/%d: %d(%s)!\n",
-idx, left, errno, strerror(errno));
+if ( errno == ENOSYS )
+fprintf(stderr, "Hypervisor compiled without Xen 
Livepatching!\n");
+else
+fprintf(stderr, "Failed to list %d/%d: %d(%s)!\n",
+idx, left, errno, strerror(errno));
 break;
 }
 if ( !idx )
-- 
2.4.11


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

[Xen-devel] [PATCH v1 2/3] xen-livepatch: Print the header _after_ the first livepatch hypercall

[Konrad Rzeszutek Wilk]

That way we can print out the header if we are sure the
hypervisor has been compiled with Xen Livepatching.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/misc/xen-livepatch.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 7512a98..2de04c0 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -91,8 +91,6 @@ static int list_func(int argc, char *argv[])
 return rc;
 }
 
-fprintf(stdout," ID | status\n"
-   "+\n");
 do {
 done = 0;
 /* The memset is done to catch errors. */
@@ -106,6 +104,10 @@ static int list_func(int argc, char *argv[])
 idx, left, errno, strerror(errno));
 break;
 }
+if ( !idx )
+fprintf(stdout," ID | status\n"
+   
"+\n");
+
 for ( i = 0; i < done; i++ )
 {
 unsigned int j;
-- 
2.4.11


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

[Xen-devel] [PATCH v1 1/3] xen-livepatch: Remove the 'test' part

[Konrad Rzeszutek Wilk]

As it has evolved a bit and is more of a test tool.

Reported-by: Bhavesh Davda 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 tools/misc/xen-livepatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 62c072e..7512a98 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -20,7 +20,7 @@ static xc_interface *xch;
 void show_help(void)
 {
 fprintf(stderr,
-"xen-livepatch: live patching test tool\n"
+"xen-livepatch: live patching tool\n"
 "Usage: xen-livepatch  [args]\n"
 "  An unique name of payload. Up to %d characters.\n"
 "Commands:\n"
-- 
2.4.11


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

[Xen-devel] [PATCH v1] xen-livepatch fixes for Xen 4.8

[Konrad Rzeszutek Wilk]

Hey!

Three tiny fixes that came about from various reports from
folks.

 tools/misc/xen-livepatch.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

Konrad Rzeszutek Wilk (3):
  xen-livepatch: Remove the 'test' part
  xen-livepatch: Print the header _after_ the first livepatch hypercall
  xen-livepatch: If hypervisor is not compiled with Livepatching


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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Julien Grall]

Hi Stefano,

On 21/09/2016 19:13, Stefano Stabellini wrote:

On Wed, 21 Sep 2016, Julien Grall wrote:

(CC a couple of ARM folks)

On 21/09/16 11:22, George Dunlap wrote:

On 21/09/16 11:09, Julien Grall wrote:



On 20/09/16 21:17, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Julien Grall wrote:

Hi Stefano,

On 20/09/2016 20:09, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Julien Grall wrote:

Hi,

On 20/09/2016 12:27, George Dunlap wrote:

On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan

wrote:

On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli
wrote:

On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:

On Tue, 20 Sep 2016, Dario Faggioli wrote:

I'd like to add a computing capability in xen/arm, like this:

struct compute_capatiliby
{
   char *core_name;
   uint32_t rank;
   uint32_t cpu_partnum;
};

struct compute_capatiliby cc=
{
  {"A72", 4, 0xd08},
  {"A57", 3, 0},
  {"A53", 2, 0xd03},
  {"A35", 1, ...},
}

Then when identify cpu, we decide which cpu is big and which
cpu is
little
according to the computing rank.

Any comments?


I think we definitely need to have Xen have some kind of idea
the
order between processors, so that the user doesn't need to
figure out
which class / pool is big and which pool is LITTLE.  Whether
this
sort
of enumeration is the best way to do that I'll let Julien and
Stefano
give their opinion.


I don't think an hardcoded list of processor in Xen is the right
solution.
There are many existing processors and combinations for big.LITTLE
so it
will
nearly be impossible to keep updated.

I would expect the firmware table (device tree, ACPI) to provide
relevant
data
for each processor and differentiate big from LITTLE core.
Note that I haven't looked at it for now. A good place to start is
looking
at
how Linux does.


That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It
is
trivial to identify the two different CPU classes and which cores
belong
to which class.t, as


The class of the CPU can be found from the MIDR, there is no need to
use the
device tree/acpi for that. Note that I don't think there is an easy
way in
ACPI (i.e not in AML) to find out the class.


It is harder to figure out which one is supposed to be
big and which one LITTLE. Regardless, we could default to using the
first cluster (usually big), which is also the cluster of the boot
cpu,
and utilize the second cluster only when the user demands it.


Why do you think the boot CPU will usually be a big one? In the case
of Juno
platform it is configurable, and the boot CPU is a little core on r2
by
default.

In any case, what we care about is differentiate between two set of
CPUs. I
don't think Xen should care about migrating a guest vCPU between big
and
LITTLE cpus. So I am not sure why we would want to know that.


No, it is not about migrating (at least yet). It is about giving useful
information to the user. It would be nice if the user had to choose
between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
even "A7" or "A15".


I don't think it is wise to assume that we may have only 2 kind of CPUs
on the platform. We may have more in the future, if so how would you
name them?


I would suggest that internally Xen recognize an arbitrary number of
processor "classes", and order them according to more powerful -> less
powerful.  Then if at some point someone makes a platform with three
processors, you can say "class 0", "class 1" or "class 2".  "big" would
be an alias for "class 0" and "little" would be an alias for "class 1".


As mentioned earlier, there is no upstreamed yet device tree bindings to know
the "power" of a CPU (see [1]



And in my suggestion, we allow a richer set of labels, so that the user
could also be more specific -- e.g., asking for "A15" specifically, for
example, and failing to build if there are no A15 cores present, while
allowing users to simply write "big" or "little" if they want simplicity
/ things which work across different platforms.


Well, before trying to do something clever like that (i.e naming "big" and
"little"), we need to have upstreamed bindings available to acknowledge the
difference. AFAICT, it is not yet upstreamed for Device Tree (see [1]) and I
don't know any static ACPI tables providing the similar information.


I like George's idea that "big" and "little" could be just convenience
aliases. Of course they are predicated on the necessary device tree
bindings being upstream. We don't need [1] to be upstream in Linux, just
the binding:

http://marc.info/?l=linux-arm-kernel=147308556729426=2

which has already been acked by the relevant maintainers.


This is device tree only. What about ACPI?





I had few discussions and  more thought about big.LITTLE support in Xen. The
main goal of big.LITTLE is power efficiency by moving task around and been
able to idle one cluster. All the solutions suggested (including mine) so far,
can be replicated by hand (except the VPIDR) so they are 

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 9:30 AM, Tamas K Lengyel
 wrote:
> On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich  wrote:
> On 21.09.16 at 17:16,  wrote:
>>> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
>>>  wrote:
 On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich  wrote:
 On 21.09.16 at 16:18,  wrote:
>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
>> On 20.09.16 at 19:29,  wrote:
 I'm trying to figure out the design decision regarding the handling of
 guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
 VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
 (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
 hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
 TLB utilization point-of-view this seems to be rather wasteful.
 Furthermore, it even breaks the guests' ability to take advantage of
 PCID, as the TLB just guts flushed when a new process is scheduled.
 Does anyone have an insight into what was the rationale behind this?
>>>
>>> Since you don't quote the specific commit(s), I would guess that
>>> this was mainly an attempt by the author(s) to keep things simple
>>> for themselves, i.e. not having to properly think through under
>>> which conditions less than a full TLB flush would suffice.
>>
>> The commit that added VPID and the TLB flush is
>> e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
>> (Virtual Processor Identification). So this has been there as long as
>> Xen supported VPID. The only case where flushing the TLB on a guest
>> MOV-TO-CR3 that possibly would make sense to me is if we are running a
>> PV guest. But this is hvm/vmx, so why would we care about what the
>> guest does to its cr3 from a TLB standpoint?
>
> Are you forgetting that a move to CR3 needs to flush all non-global
> TLB entries? Or else, why do you think no flushing needs to happen
> at all?
>

 The guest can mark entries as global or non-global but it will have no
 affect on VPID, every translation is still going to be tagged by VPID
 when the translation was triggered in guest-context. So why does Xen
 need to jump in flush the TLB when the guest OS likely already done
 so?
>>
>> Likely? We can't base anything on likelihood (the more that no matter
>> what flushing may have been done before the CR3 write, further
>> flushing may be necessary and mustn't be skipped). We need to
>> provide architecturally correct behavior, and that includes the flushing
>> of non-global entries. This doesn't mean we need to flush anything
>> ourselves, but we have to make previously created non-global TLB
>> entries unavailable.
>
> What I'm saying is that the guest OS should be in charge of managing
> its own TLB when VPID is in use. Whether it does flush the TLB or not
> is not of our concern. If it's a sane OS it will likely flush when it
> needs to, but we should not be jumping in and doing it as we do right
> now. We are actually breaking the architectural behavior by forcing a
> flush, MOV-TO-CR3 doesn't by itself flush the TLB on real hardware.
> Also, there are no non-global TLB entries we need to flush as long as
> we are using VPID. Any translation used by Xen or by any other domain
> will have a different VPID, so there is no chance of stale TLB entries
> being an issue.
>

So reading through the Intel SDM the following bits are relevant here:

28.3.3.1
Operations that Invalidate Cached Mappings
The following operations invalidate cached mappings as indicated:
• Operations that architecturally invalidate entries in the TLBs or
paging-structure caches independent of VMX
operation (e.g., the INVLPG and INVPCID instructions) invalidate
linear mappings and combined mappings. 1
They are required to do so only for the current VPID (but, for
combined mappings, all EP4TAs). Linear
mappings for the current VPID are invalidated even if EPT is in use. 2
Combined mappings for the current
VPID are invalidated even if EPT is not in use.

To me this reads that the CPU will automatically handle the TLB
flushing for all operations that would normally do so when running
without a hypervisor, but only within the context of the VPID. While
it doesn't list MOV-TO-CR3 specifically, I'm sure it falls into this
same category regarding non-global TLB entries that would be flushed
by it. Thus, there is no need for the VMM to step in do anything in
this regard if my interpretation is correct.

Tamas

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

Re: [Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

[Stefano Stabellini]

On Wed, 21 Sep 2016, Konrad Rzeszutek Wilk wrote:
> On Wed, Sep 21, 2016 at 03:52:12PM +0100, Julien Grall wrote:
> > The invalidation of the instructions cache requires barriers to ensure
> > the completion of the invalidation before continuing (see B2.3.4 in ARM
> > DDI 0487A.j).
> > 
> > This was overlooked in commit fb9d877 "xen/arm64: Add an helper to
> > invalidate all instruction caches".
> > 
> > Signed-off-by: Julien Grall 
> 
> Reviewed-by: Konrad Rzeszutek Wilk 

Reviewed-by: Stefano Stabellini 

and committed

> 
> > ---
> >  xen/include/asm-arm/arm64/page.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/xen/include/asm-arm/arm64/page.h 
> > b/xen/include/asm-arm/arm64/page.h
> > index 79ef7bd..23d7781 100644
> > --- a/xen/include/asm-arm/arm64/page.h
> > +++ b/xen/include/asm-arm/arm64/page.h
> > @@ -33,6 +33,8 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
> >  static inline void invalidate_icache(void)
> >  {
> >  asm volatile ("ic ialluis");
> > +dsb(ish);   /* Ensure completion of the flush I-cache */
> > +isb();
> >  }
> >  
> >  /*
> > -- 
> > 1.9.1
> > 
> 

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

Re: [Xen-devel] [PATCH] misc/arm: Correctly name bit in the booting document

[Stefano Stabellini]

On Wed, 21 Sep 2016, Julien Grall wrote:
> SCTLR_EL3.HCR does not exists in the documentation (see D7.2.80 in ARM
> DDI 0487A.j). It was meant to be SCTRL_EL3.HCE.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


>  docs/misc/arm/booting.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/misc/arm/booting.txt b/docs/misc/arm/booting.txt
> index c7c1d7e..d3f6ce4 100644
> --- a/docs/misc/arm/booting.txt
> +++ b/docs/misc/arm/booting.txt
> @@ -31,7 +31,7 @@ Xen relies on some settings the firmware has to configure 
> in EL3 before starting
>  
>  * Xen must be entered in NS EL2 mode
>  
> -* The bit SCR_EL3.HCR (resp. SCR.HCE for 32-bit ARM) must be set to 1.
> +* The bit SCR_EL3.HCE (resp. SCR.HCE for 32-bit ARM) must be set to 1.
>  
>  
>  [1] linux/Documentation/arm/Booting
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Andrew Cooper]

On 21/09/16 19:06, Wei Liu wrote:

On Wed, Sep 21, 2016 at 02:00:50PM -0400, Boris Ostrovsky wrote:

On 09/21/2016 01:36 PM, Wei Liu wrote:

On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote:

On 09/21/2016 12:13 PM, Ian Jackson wrote:

Platform Team regression test user writes ("[xen-4.5-testing baseline-only test] 
67737: regressions - FAIL"):

test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706

Several of these, 32bit and 64bit HVM.  This is in the Citrix
Cambridge osstest instance.  The Xen Project colo instance is
unaffected (flight 101045 there passed with the same revisions of
everything)

This is with:

   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860

I can't get these commits neither for Xen nor for Linux. Are these from
Citrix trees?

No. They are all upstream commits.

Apparently xen commit *just* made it to the tree, after I checked it.

Yes, it passed in Mass COLO. We suspected it can be related to
generations of AMD cpus (hence the "old" in email title).


It will be because of Gen1 SVM which doesn't have NRIP support. This 
case requires emulation of the invlpg instruction, rather than just 
using the information provided by the intercept.


~Andrew

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Stefano Stabellini]

On Wed, 21 Sep 2016, Julien Grall wrote:
> (CC a couple of ARM folks)
> 
> On 21/09/16 11:22, George Dunlap wrote:
> > On 21/09/16 11:09, Julien Grall wrote:
> > > 
> > > 
> > > On 20/09/16 21:17, Stefano Stabellini wrote:
> > > > On Tue, 20 Sep 2016, Julien Grall wrote:
> > > > > Hi Stefano,
> > > > > 
> > > > > On 20/09/2016 20:09, Stefano Stabellini wrote:
> > > > > > On Tue, 20 Sep 2016, Julien Grall wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 20/09/2016 12:27, George Dunlap wrote:
> > > > > > > > On Tue, Sep 20, 2016 at 11:03 AM, Peng Fan
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > On Tue, Sep 20, 2016 at 02:54:06AM +0200, Dario Faggioli
> > > > > > > > > wrote:
> > > > > > > > > > On Mon, 2016-09-19 at 17:01 -0700, Stefano Stabellini wrote:
> > > > > > > > > > > On Tue, 20 Sep 2016, Dario Faggioli wrote:
> > > > > > > > > I'd like to add a computing capability in xen/arm, like this:
> > > > > > > > > 
> > > > > > > > > struct compute_capatiliby
> > > > > > > > > {
> > > > > > > > >char *core_name;
> > > > > > > > >uint32_t rank;
> > > > > > > > >uint32_t cpu_partnum;
> > > > > > > > > };
> > > > > > > > > 
> > > > > > > > > struct compute_capatiliby cc=
> > > > > > > > > {
> > > > > > > > >   {"A72", 4, 0xd08},
> > > > > > > > >   {"A57", 3, 0},
> > > > > > > > >   {"A53", 2, 0xd03},
> > > > > > > > >   {"A35", 1, ...},
> > > > > > > > > }
> > > > > > > > > 
> > > > > > > > > Then when identify cpu, we decide which cpu is big and which
> > > > > > > > > cpu is
> > > > > > > > > little
> > > > > > > > > according to the computing rank.
> > > > > > > > > 
> > > > > > > > > Any comments?
> > > > > > > > 
> > > > > > > > I think we definitely need to have Xen have some kind of idea
> > > > > > > > the
> > > > > > > > order between processors, so that the user doesn't need to
> > > > > > > > figure out
> > > > > > > > which class / pool is big and which pool is LITTLE.  Whether
> > > > > > > > this
> > > > > > > > sort
> > > > > > > > of enumeration is the best way to do that I'll let Julien and
> > > > > > > > Stefano
> > > > > > > > give their opinion.
> > > > > > > 
> > > > > > > I don't think an hardcoded list of processor in Xen is the right
> > > > > > > solution.
> > > > > > > There are many existing processors and combinations for big.LITTLE
> > > > > > > so it
> > > > > > > will
> > > > > > > nearly be impossible to keep updated.
> > > > > > > 
> > > > > > > I would expect the firmware table (device tree, ACPI) to provide
> > > > > > > relevant
> > > > > > > data
> > > > > > > for each processor and differentiate big from LITTLE core.
> > > > > > > Note that I haven't looked at it for now. A good place to start is
> > > > > > > looking
> > > > > > > at
> > > > > > > how Linux does.
> > > > > > 
> > > > > > That's right, see Documentation/devicetree/bindings/arm/cpus.txt. It
> > > > > > is
> > > > > > trivial to identify the two different CPU classes and which cores
> > > > > > belong
> > > > > > to which class.t, as
> > > > > 
> > > > > The class of the CPU can be found from the MIDR, there is no need to
> > > > > use the
> > > > > device tree/acpi for that. Note that I don't think there is an easy
> > > > > way in
> > > > > ACPI (i.e not in AML) to find out the class.
> > > > > 
> > > > > > It is harder to figure out which one is supposed to be
> > > > > > big and which one LITTLE. Regardless, we could default to using the
> > > > > > first cluster (usually big), which is also the cluster of the boot
> > > > > > cpu,
> > > > > > and utilize the second cluster only when the user demands it.
> > > > > 
> > > > > Why do you think the boot CPU will usually be a big one? In the case
> > > > > of Juno
> > > > > platform it is configurable, and the boot CPU is a little core on r2
> > > > > by
> > > > > default.
> > > > > 
> > > > > In any case, what we care about is differentiate between two set of
> > > > > CPUs. I
> > > > > don't think Xen should care about migrating a guest vCPU between big
> > > > > and
> > > > > LITTLE cpus. So I am not sure why we would want to know that.
> > > > 
> > > > No, it is not about migrating (at least yet). It is about giving useful
> > > > information to the user. It would be nice if the user had to choose
> > > > between "big" and "LITTLE" rather than "class 0x1" and "class 0x100", or
> > > > even "A7" or "A15".
> > > 
> > > I don't think it is wise to assume that we may have only 2 kind of CPUs
> > > on the platform. We may have more in the future, if so how would you
> > > name them?
> > 
> > I would suggest that internally Xen recognize an arbitrary number of
> > processor "classes", and order them according to more powerful -> less
> > powerful.  Then if at some point someone makes a platform with three
> > processors, you can say "class 0", "class 1" or "class 2".  "big" would
> > be an alias for "class 0" and "little" would be an alias for "class 1".
> 
> As mentioned earlier, there is no 

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Wei Liu]

On Wed, Sep 21, 2016 at 02:00:50PM -0400, Boris Ostrovsky wrote:
> On 09/21/2016 01:36 PM, Wei Liu wrote:
> > On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote:
> >> On 09/21/2016 12:13 PM, Ian Jackson wrote:
> >>> Platform Team regression test user writes ("[xen-4.5-testing 
> >>> baseline-only test] 67737: regressions - FAIL"):
>  test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 
>  67706
>  test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
>  67706
> >>> Several of these, 32bit and 64bit HVM.  This is in the Citrix
> >>> Cambridge osstest instance.  The Xen Project colo instance is
> >>> unaffected (flight 101045 there passed with the same revisions of
> >>> everything)
> >>>
> >>> This is with:
> >>>
> >>>   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
> >>>   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
> >>>   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
> >>>   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860
> >> I can't get these commits neither for Xen nor for Linux. Are these from
> >> Citrix trees?
> > No. They are all upstream commits.
> 
> Apparently xen commit *just* made it to the tree, after I checked it.

Yes, it passed in Mass COLO. We suspected it can be related to
generations of AMD cpus (hence the "old" in email title).

> And I still don't see Linux one.
> 

It should be upstream commit, too. But I don't think it matters that
much anyway.

> I ran a quick test (not xtf, our internal one) with 32-bit shadow guest
> and didn't see anything. But then Andrew seems to have pointed out what

That's probably because your guest is a well-behaved guest.

> the problem is.
> 
> -boris
> 

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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Boris Ostrovsky]

On 09/21/2016 01:36 PM, Wei Liu wrote:
> On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote:
>> On 09/21/2016 12:13 PM, Ian Jackson wrote:
>>> Platform Team regression test user writes ("[xen-4.5-testing baseline-only 
>>> test] 67737: regressions - FAIL"):
 test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
 67706
>>> Several of these, 32bit and 64bit HVM.  This is in the Citrix
>>> Cambridge osstest instance.  The Xen Project colo instance is
>>> unaffected (flight 101045 there passed with the same revisions of
>>> everything)
>>>
>>> This is with:
>>>
>>>   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
>>>   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
>>>   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
>>>   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860
>> I can't get these commits neither for Xen nor for Linux. Are these from
>> Citrix trees?
> No. They are all upstream commits.

Apparently xen commit *just* made it to the tree, after I checked it.
And I still don't see Linux one.

I ran a quick test (not xtf, our internal one) with 32-bit shadow guest
and didn't see anything. But then Andrew seems to have pointed out what
the problem is.

-boris


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

Re: [Xen-devel] [PATCH] xen: switch to threaded irq in netback

[Wei Liu]

I think you'd better resubmit this patch to netdev@ because
netfront/back patches will go via David Miller's tree.

And perhaps uses the subject line:

xen-netback: switch to threaded irq for control ring

On Tue, Sep 20, 2016 at 04:21:37PM +0200, Juergen Gross wrote:
> Instead of open coding it use the threaded irq mechanism in
> xen-netback.
> 
> Signed-off-by: Juergen Gross 

The code looks OK:

Acked-by: Wei Liu 

Wei.

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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Wei Liu]

On Wed, Sep 21, 2016 at 12:42:51PM -0400, Boris Ostrovsky wrote:
> On 09/21/2016 12:13 PM, Ian Jackson wrote:
> > Platform Team regression test user writes ("[xen-4.5-testing baseline-only 
> > test] 67737: regressions - FAIL"):
> >> test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
> >> test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
> >> 67706
> > Several of these, 32bit and 64bit HVM.  This is in the Citrix
> > Cambridge osstest instance.  The Xen Project colo instance is
> > unaffected (flight 101045 there passed with the same revisions of
> > everything)
> >
> > This is with:
> >
> >   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
> >   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
> >   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
> >   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860
> 
> I can't get these commits neither for Xen nor for Linux. Are these from
> Citrix trees?

No. They are all upstream commits.

> 
> >
> > The log says this:
> >
> >   2016-09-21 06:07:36 Z -- substep 19 xtf/test-hvm32-invlpg~shadow 
> > running -- 
> >   2016-09-21 06:07:36 Z executing ssh ... root@10.80.228.78 
> > /home/xtf/xtf-runner -m logfile test-hvm32-invlpg~shadow 1>&2; echo $?
> >
> >   Using logfile '/var/log/xen/console/guest-test-hvm32-invlpg~shadow.log'
> >   Executing 'xl create -F tests/invlpg/test-hvm32-invlpg~shadow.cfg'
> >   --- Xen Test Framework ---
> >   Environment: HVM 32bit (No paging)
> >   Testing 'invlpg' in normally-faulting conditions
> > Test: Mapped address
> > Test: Unmapped address
> > Test: NULL segment override
> > Test: Past segment limit
> >   Fail: Unexpected #GP[]
> > Test: Before expand-down segment limit
> >   Fail: Unexpected #GP[]
> >   Test result: FAILURE
> >
> >   Combined test results:
> >   test-hvm32-invlpg~shadow FAILURE
> >
> > Sadly we haven't yet managed to make the logs from this instance
> > public.
> 
> I looked at the logs you posted but I can't find guest config file. Are
> they part of the logs?

The guest config file is not stored because it is part of xtf. So ...

> 
> >
> > Do you have any idea what might be causing this ?  Is there a real
> > problem with the Xen 4.5 branch ?  The Citrix Cambridge instance has
> > old hardware.
> 
> We run 4.5 every week or so here but we don't run without HAP (which,
> based on the name, I assume is what this guest is).
> 
> I'll give it a try.
> 

... the best way to try is to build and run xtf.

After building:

./xtf-runner --host --functional

> -boris

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

[Xen-devel] [PATCH v5 10/16] livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH

[Konrad Rzeszutek Wilk]

To use as a common way of testing alternative patching for
livepatches. Both architectures have this FEATURE and the
test-cases can piggyback on that.

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

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

v3: New submission
v4: Move the LIVEPATCH_FEATURE to asm-x86/livepatch.h
v5: Reorder the patch to be before " livepatch: tests: Make them
compile under ARM64"
Always expose FEATURE_LIVEPATCH on ARM.
---
 xen/arch/arm/livepatch.c  | 3 +++
 xen/include/asm-arm/cpufeature.h  | 3 ++-
 xen/include/asm-x86/livepatch.h   | 1 +
 xen/test/livepatch/xen_hello_world_func.c | 3 ++-
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 5a99ab5..7855bc5 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -177,6 +178,8 @@ void __init arch_livepatch_init(void)
 end = (void *)LIVEPATCH_VMAP_END;
 
 vm_init_type(VMAP_XEN, start, end);
+
+cpus_set_cap(LIVEPATCH_FEATURE);
 }
 
 /*
diff --git a/xen/include/asm-arm/cpufeature.h b/xen/include/asm-arm/cpufeature.h
index 66e930f..af60fe3 100644
--- a/xen/include/asm-arm/cpufeature.h
+++ b/xen/include/asm-arm/cpufeature.h
@@ -39,8 +39,9 @@
 #define ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE1
 #define ARM32_WORKAROUND_766422 2
 #define ARM64_WORKAROUND_834220 3
+#define LIVEPATCH_FEATURE   4
 
-#define ARM_NCAPS   4
+#define ARM_NCAPS   5
 
 #ifndef __ASSEMBLY__
 
diff --git a/xen/include/asm-x86/livepatch.h b/xen/include/asm-x86/livepatch.h
index 7dfc2e7..00aefd2 100644
--- a/xen/include/asm-x86/livepatch.h
+++ b/xen/include/asm-x86/livepatch.h
@@ -10,6 +10,7 @@
 
 #define ARCH_PATCH_INSN_SIZE 5
 #define ARCH_LIVEPATCH_RANGE SZ_2G
+#define LIVEPATCH_FEATUREX86_FEATURE_ALWAYS
 
 #endif /* __XEN_X86_LIVEPATCH_H__ */
 
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 03d6b84..0321f3e 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -6,6 +6,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -17,7 +18,7 @@ const char *xen_hello_world(void)
 unsigned long tmp;
 int rc;
 
-alternative(ASM_NOP8, ASM_NOP1, X86_FEATURE_LM);
+alternative(ASM_NOP8, ASM_NOP1, LIVEPATCH_FEATURE);
 /*
  * Any BUG, or WARN_ON will contain symbol and payload name. Furthermore
  * exceptions will be caught and processed properly.
-- 
2.4.11


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

[Xen-devel] [PATCH v5 05/16] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

As compared to x86 the va of the hypervisor .text
is locked down - we cannot modify the running pagetables
to have the .ro flag unset. We borrow the same idea that
alternative patching has - which is to vmap the entire
.text region and use the alternative virtual address
for patching.

Since we are doing vmap we may fail, hence the
arch_livepatch_quiesce was changed (see "x86,arm:
Change arch_livepatch_quiesce() declaration") to return
an error value which will be bubbled in payload->rc and
provided to the user (along with messages in the ring buffer).

The livepatch virtual address space (where the new functions
are) needs to be close to the hypervisor virtual address
so that the trampoline can reach it. As such we re-use
the BOOT_RELOC_VIRT_START which is not used after bootup
(alternatively we can also use the space after the _end to
FIXMAP_ADDR(0), but that may be too small).

The ELF relocation engine at the start was coded from
the "ELF for the ARM 64-bit Architecture (AArch64)"
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf)
but after a while of trying to write the correct bit shifting
and masking from scratch I ended up borrowing from Linux, the
'reloc_insn_imm' (Linux v4.7 arch/arm64/kernel/module.c function.
See 257cb251925f854da435cbf79b140984413871ac "arm64: Loadable modules")

And while at it - we also utilize code from Linux to construct
the right branch instruction (see "arm64/insn: introduce
aarch64_insn_gen_{nop|branch_imm}() helper functions").

In the livepatch payload loading code we tweak the #ifdef to
only exclude ARM_32. The exceptions are not part of ARM 32/64 hence
they are still behind the #ifdef.

We also expand the MAINTAINERS file to include the arm64 and arm32
platform specific livepatch file.

Acked-by: Jan Beulich  [non-arm parts]
Signed-off-by: Konrad Rzeszutek Wilk 

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

RFC: Wholy cow! It works!
v1: Finished the various TODOs and reviews outlined by Julien in RFC.
v2: Call check_for_livepatch_work in leave_hypervisor_tail not in
reset_stack_and_jump
   - Move ARM 32 components in other patch
   - Blacklist platform options in Kconfig
   - Added R_AARCH64_LDST128_ABS_LO12_NC, R_AARCH64_TSTBR14, and
 R_AARCH64_ADR_PREL_PG_HI21_NC
   - Added do_reloc and reloc_data along with overflow checks from Linux.
   - Use apply_alternatives without any #ifdef
   - Use leave_hypervisor_tail to call check_for_livepatch_work
   - Add ASSERT that isns is not AARCH64_BREAK_FAULT
   - Spun out arch_livepatch_quiesce changes in seperate patch.
   - Spun out changes to config.h (document ones) to seperate patch.
   - Move the livepatch.h to include/xen/asm-arm.
   - Add LIVEPATCH_VMAP_END and LIVEPATCH_VMAP_START in config.h
   - In arch_livepatch_secure use switch for va_type.
   - Drop the #ifndef CONFIG_ARM for .ex_table (see
 "arm/x86: Add HAS_ALTERNATIVE and HAS_EX_TABLE")
   - Piggyback on "x86: change modify_xen_mappings to return error"
  so that arch_livepatch_secure can return errors.
   - Moves comment about branch predictor out of this patch.
v3: Fix StyleGuide violations (switch statements)
   - Fix incorrect cast of addr when reverting.
   - Drop old_ptr variable.
   - Use bool_t values instead of numbers.
   - Sprinkle \n as requested by Julien.
   - In arch_livepatch_quiesce use 1U instead of 1.
   - Use C99 #defines for [U,]INT[16,32]_[MIN,MAX] instead of Linux
 kernel ones ([S,U][16,32]_[MIN,MAX]).
   - Include the ELF relocations for R_AARCH64_[ABS,PRE]16, and
 all the various groupings for R_AARCH64_MOVW_[UABS,SABS,PREL]_*
 family.
   - Redo the NOP patching to use more of the opaque size (so up to 7
 instructions in one go).
   - Drop the cpu_to_le32 macros as they are not needed (and can allow
 use to share more code with ARM32).
   - Flush out func->old_addr instead of vmap pointer when reverting.
v4: Added Jan's Ack
   s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
   s/arch_livepatch_insn_len/livepatch_insn_len/
v5: Added 'fallthrough' comments on the switch statements.
   - Added more invalidate of dcache on the old_addr and the vmap area.
   - Rebased on "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
   - Move most of  docs part from "livepatch: ARM/x86: Check displacement of
 old_addr and new_addr" in this patch.
   - Added syncing of data cache along with explanation for its usage.
---
 MAINTAINERS |   1 +
 docs/misc/livepatch.markdown|  14 +-
 xen/arch/arm/Makefile   |  13 +-
 xen/arch/arm/arm32/Makefile |   1 +
 xen/arch/arm/arm32/livepatch.c  |  38 
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/livepatch.c  | 488 
 

[Xen-devel] [PATCH v5 13/16] bug/x86/arm: Align bug_frames sections.

[Konrad Rzeszutek Wilk]

Most of the WARN_ON or BUG_ON sections are properly aligned on
x86. However on ARM and on x86 assembler the macros don't include
any alignment information - hence they end up being the default
byte granularity.

On ARM32 it is paramount that the alignment is word-size (4)
otherwise if one tries to use (uint32_t*) access (such
as livepatch ELF relocations) we get a Data Abort.

Enforcing bug_frames to have the proper alignment across all
architectures and in both C and x86 makes them all the same.

Furthermore on x86 the bloat-o-meter detects that with this
change:

add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
function old new   delta

On ARM32:
add/remove: 1/0 grow/shrink: 0/1 up/down: 384/-288 (96)
function old new   delta
gnttab_unpopulate_status_frames- 384+384
do_grant_table_op  10808   10520-288

And ARM64:
add/remove: 1/2 grow/shrink: 0/1 up/down: 4164/-4236 (-72)
function old new   delta
gnttab_map_grant_ref   -4164   +4164
do_grant_table_op   98929836 -56
grant_map_exists 300   --300
__gnttab_map_grant_ref  3880   -   -3880

Reviewed-by: Julien Grall 
Acked-by: Jan Beulich  [x86 parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First submission. Replaces the "livepatch/elf: Adjust section aligment to 
word"
patch.
v4: Remove the .ALIGN(4) in xen.lds.S for x86 (the only place needing
that change).
Update the commit description with correct x86 results
Remove the . = ALIGN(4); in linker filer on x86 [the only file needing the 
change]
v5: Add Jan's Ack on x86 parts.
v6: Added Julien's Reviewed-by
s/aligment/alignment/
s/align 4/p2align 2/ as the align semnatics varies by platforms, while
p2align is the same across all of them.
---
 xen/arch/x86/xen.lds.S| 1 -
 xen/include/asm-arm/bug.h | 1 +
 xen/include/asm-x86/bug.h | 1 +
 3 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index d903c31..7676de9 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -79,7 +79,6 @@ SECTIONS
   .rodata : {
_srodata = .;
/* Bug frames table */
-   . = ALIGN(4);
__start_bug_frames = .;
*(.bug_frames.0)
__stop_bug_frames_0 = .;
diff --git a/xen/include/asm-arm/bug.h b/xen/include/asm-arm/bug.h
index 68353e1..4704e2d 100644
--- a/xen/include/asm-arm/bug.h
+++ b/xen/include/asm-arm/bug.h
@@ -52,6 +52,7 @@ struct bug_frame {
  ".popsection\n"\
  ".pushsection .bug_frames." __stringify(type) ", \"a\", %progbits\n"\
  "4:\n" \
+ ".p2align 2\n" \
  ".long (1b - 4b)\n"\
  ".long (2b - 4b)\n"\
  ".long (3b - 4b)\n"\
diff --git a/xen/include/asm-x86/bug.h b/xen/include/asm-x86/bug.h
index c5d2d4c..9bb4a19 100644
--- a/xen/include/asm-x86/bug.h
+++ b/xen/include/asm-x86/bug.h
@@ -98,6 +98,7 @@ extern const struct bug_frame __start_bug_frames[],
 .popsection
 
 .pushsection .bug_frames.\type, "a", @progbits
+.p2align 2
 .L\@bf:
 .long (.L\@ud - .L\@bf) + \
((\line >> BUG_LINE_LO_WIDTH) << BUG_DISP_WIDTH)
-- 
2.4.11


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

[Xen-devel] [PATCH v5 03/16] livepatch: Reject payloads with .alternative or .ex_table if support is not built-in.

[Konrad Rzeszutek Wilk]

If the payload had the sections mentioned but the hypervisor
did not support some of them (say on ARM the .ex_table) - instead
of ignoring them - it should forbid loading of such payload.

Reviewed-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission.
v4: Added Julien's Reviewed-by tag.
---
 xen/common/livepatch.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 292dd2e..66f23e0 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -643,10 +643,10 @@ static int prepare_payload(struct payload *payload,
   sizeof(*region->frame[i].bugs);
 }
 
-#ifdef CONFIG_HAS_ALTERNATIVE
 sec = livepatch_elf_sec_by_name(elf, ".altinstructions");
 if ( sec )
 {
+#ifdef CONFIG_HAS_ALTERNATIVE
 struct alt_instr *a, *start, *end;
 
 if ( sec->sec->sh_size % sizeof(*a) )
@@ -673,13 +673,17 @@ static int prepare_payload(struct payload *payload,
 }
 }
 apply_alternatives(start, end);
-}
+#else
+dprintk(XENLOG_ERR, LIVEPATCH "%s: We don't support alternative 
patching!\n",
+elf->name);
+return -EOPNOTSUPP;
 #endif
+}
 
-#ifdef CONFIG_HAS_EX_TABLE
 sec = livepatch_elf_sec_by_name(elf, ".ex_table");
 if ( sec )
 {
+#ifdef CONFIG_HAS_EX_TABLE
 struct exception_table_entry *s, *e;
 
 if ( !sec->sec->sh_size ||
@@ -698,8 +702,12 @@ static int prepare_payload(struct payload *payload,
 
 region->ex = s;
 region->ex_end = e;
-}
+#else
+dprintk(XENLOG_ERR, LIVEPATCH "%s: We don't support .ex_table!\n",
+elf->name);
+return -EOPNOTSUPP;
 #endif
+}
 
 return 0;
 }
-- 
2.4.11


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

[Xen-devel] [PATCH v5 04/16] arm: poison initmem when it is freed.

[Konrad Rzeszutek Wilk]

The current byte sequence is '0xcc' which makes sense on x86,
but on ARM it is:

stclgt  12, cr12, [ip], {204}   ; 0xcc

Picking something more ARM applicable such as:

efefefefsvc 0x00efefef

Creates a nice crash if one executes that code:
(XEN) CPU1: Unexpected Trap: Supervisor Call

But unfortunately that may not be a good choice either as in the future
we may want to implement support for it.

Julien suggested that we use a 4-byte insn instruction instead
of trying to work with one byte. To make sure nothing goes bad
we also require that the __init_[begin|end] be aligned properly.

As such on ARM 32 we use the udf instruction (see A8.8.247
in ARM DDI 0406C.c) and on ARM 64 use the AARCH64_BREAK_FAULT
instruction (aka brk instruction).

We don't have to worry about Thumb code so this instruction
is a safe to execute.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission
v4: Instead of using 0xef, use specific insn for architectures.
v5: Add BUILD_BUG_ON
Fix the loop to cover the full 'len' instead of 1/4 of it
(used __init_begin which is a char instead of uint32_t).
---
 xen/arch/arm/mm.c  | 15 ++-
 xen/arch/arm/xen.lds.S |  6 ++
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 07e2037..99588a3 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -994,8 +994,21 @@ void free_init_memory(void)
 {
 paddr_t pa = virt_to_maddr(__init_begin);
 unsigned long len = __init_end - __init_begin;
+uint32_t insn;
+unsigned int i, nr = len / sizeof(insn);
+uint32_t *p;
+
 set_pte_flags_on_range(__init_begin, len, mg_rw);
-memset(__init_begin, 0xcc, len);
+#ifdef CONFIG_ARM_32
+/* udf instruction i.e (see A8.8.247 in ARM DDI 0406C.c) */
+insn = 0xe7f000f0;
+#else
+insn = AARCH64_BREAK_FAULT;
+#endif
+p = (uint32_t *)__init_begin;
+for ( i = 0; i < nr; i++ )
+*(p + i) = insn;
+
 set_pte_flags_on_range(__init_begin, len, mg_clear);
 init_domheap_pages(pa, pa + len);
 printk("Freed %ldkB init memory.\n", (long)(__init_end-__init_begin)>>10);
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 47b910d..ddef595 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -221,3 +221,9 @@ SECTIONS
  * code running on the boot time identity map cannot cross a section boundary.
  */
 ASSERT( _end_boot - start <= PAGE_SIZE, "Boot code is larger than 4K")
+/*
+ * __init_[begin|end] MUST be at word size boundary otherwise we cannot
+ * write fault instructions in the space properly.
+ */
+ASSERT(IS_ALIGNED(__init_begin, 4), "__init_begin is misaligned")
+ASSERT(IS_ALIGNED(__init_end,   4), "__init_end is misaligned")
-- 
2.4.11


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

[Xen-devel] [PATCH v5 06/16] livepatch: ARM/x86: Check displacement of old_addr and new_addr

[Konrad Rzeszutek Wilk]

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

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

Note: On x86 we could use the 64-bit jmpq instruction which
would provide much bigger displacement to do a jump, but we would
still have issues with the new function not being able to reach
any of the old functions (as all the relocations would assume 32-bit
displacement). And "furthermore would require an register or
memory location to load/store the address to." (From Jan).

On ARM the conditional branch supports even a smaller displacement
but fortunately we are not using that.

Signed-off-by: Konrad Rzeszutek Wilk 

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

v3: New submission.
v4: s/arch_livepatch_verify_distance/livepatch_verify_distance/
s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
v5: Updated commit description with Jan's comment
Ditch the casting of long on calculating offset.
Move most of the docs in "livepatch: Initial ARM64 support."
Drop the cast on assigning ARCH_LIVEPATCH_RANGE to an variable.
---
 docs/misc/livepatch.markdown|  3 +++
 xen/arch/arm/arm64/livepatch.c  |  1 +
 xen/common/livepatch.c  |  4 
 xen/include/asm-arm/livepatch.h | 11 +++
 xen/include/asm-x86/livepatch.h |  3 +++
 xen/include/xen/livepatch.h | 17 -
 6 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index ff2cfb8..16f45f3 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -1151,6 +1151,9 @@ with proper offset is used for an unconditional branch to 
the new code.
 This means that that `old_size` **MUST** be at least four bytes if patching
 in trampoline.
 
+The instruction offset is limited on ARM32 to +/- 32MB to displacement
+and on ARM64 to +/- 128MB displacement.
+
 The new code is placed in the 8M - 10M virtual address space while the
 Xen code is in 2M - 4M. That gives us enough space.
 
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index 7cb1812..d3fc9ac 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -40,6 +40,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 else
 insn = aarch64_insn_gen_nop();
 
+/* Verified in livepatch_verify_distance. */
 ASSERT(insn != AARCH64_BREAK_FAULT);
 
 new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 66f23e0..f2f866c 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -545,6 +545,10 @@ static int prepare_payload(struct payload *payload,
 rc = resolve_old_address(f, elf);
 if ( rc )
 return rc;
+
+rc = livepatch_verify_distance(f);
+if ( rc )
+return rc;
 }
 
 sec = livepatch_elf_sec_by_name(elf, ".livepatch.hooks.load");
diff --git a/xen/include/asm-arm/livepatch.h b/xen/include/asm-arm/livepatch.h
index 929c7d9..482d74f 100644
--- a/xen/include/asm-arm/livepatch.h
+++ b/xen/include/asm-arm/livepatch.h
@@ -6,6 +6,8 @@
 #ifndef __XEN_ARM_LIVEPATCH_H__
 #define __XEN_ARM_LIVEPATCH_H__
 
+#include  /* For SZ_* macros. */
+
 /* On ARM32,64 instructions are always 4 bytes long. */
 #define ARCH_PATCH_INSN_SIZE 4
 
@@ -15,6 +17,15 @@
  */
 extern void *vmap_of_xen_text;
 
+/* These ranges are only for unconditional branches. */
+#ifdef CONFIG_ARM_32
+/* ARM32: A4.3 IN ARM DDI 0406C.j -  we are using only ARM instructions in 
Xen.*/
+#define ARCH_LIVEPATCH_RANGE SZ_32M
+#else
+/* ARM64: C1.3.2 in ARM DDI 0487A.j */
+#define ARCH_LIVEPATCH_RANGE SZ_128M
+#endif
+
 #endif /* __XEN_ARM_LIVEPATCH_H__ */
 
 /*
diff --git a/xen/include/asm-x86/livepatch.h b/xen/include/asm-x86/livepatch.h
index 5e04aa1..7dfc2e7 100644
--- a/xen/include/asm-x86/livepatch.h
+++ b/xen/include/asm-x86/livepatch.h
@@ -6,7 +6,10 @@
 #ifndef __XEN_X86_LIVEPATCH_H__
 #define __XEN_X86_LIVEPATCH_H__
 
+#include  /* For SZ_* macros. */
+
 #define ARCH_PATCH_INSN_SIZE 5
+#define ARCH_LIVEPATCH_RANGE SZ_2G
 
 #endif /* __XEN_X86_LIVEPATCH_H__ */
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index b7f66d4..b7b84e7 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -12,6 +12,7 @@ struct livepatch_elf_sym;
 struct xen_sysctl_livepatch_op;
 
 #include 
+#include  /* For -ENOSYS or -EOVERFLOW */
 #ifdef CONFIG_LIVEPATCH
 
 /*
@@ -79,6 +80,21 @@ unsigned int livepatch_insn_len(const struct livepatch_func 
*func)
 
 return ARCH_PATCH_INSN_SIZE;
 }
+
+static inline int 

[Xen-devel] [PATCH v5 16/16] livepatch: arm[32, 64], x86: NOP test-case

[Konrad Rzeszutek Wilk]

The test-case is quite simple - we NOP the 'xen_minor_version'.
The amount of NOPs depends on the architecture.

On x86 the function is 11 bytes long:

   55  push   %rbp  <- NOP
   48 89 e5mov%rsp,%rbp <- NOP
   b8 04 00 00 00  mov$0x4,%eax <- NOP
   5d  pop%rbp  <- NOP
   c3  retq

We can NOP everything but the last instruction (so 10 bytes).

On ARM64 its 8 bytes:

  52800100mov w0, #0x8 <- NOP
  d65f03c0ret

We can NOP the first instruction.

While on ARM32 there are 24 bytes:

  e52db004push{fp}
  e28db000add fp, sp, #0 <- NOP
  e3a8mov r0, #8 <- NOP
  e24bd000sub sp, fp, #0 <- NOP
  e49db004pop {fp}
  e12fff1ebx  lr

And we can NOP instruction 2,3, and 4.

Granted this code may be different per compiler!

Hence if anybody does run this test-case - they should
verify that the assumptions made here are correct.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: New submission.
---
 xen/test/livepatch/Makefile  | 15 +-
 xen/test/livepatch/xen_nop.c | 49 
 2 files changed, 63 insertions(+), 1 deletion(-)
 create mode 100644 xen/test/livepatch/xen_nop.c

diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 4d66a40..d7a4735 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -18,6 +18,7 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ 
print "0x"$$2}')
 LIVEPATCH := xen_hello_world.livepatch
 LIVEPATCH_BYE := xen_bye_world.livepatch
 LIVEPATCH_REPLACE := xen_replace_world.livepatch
+LIVEPATCH_NOP := xen_nop.livepatch
 
 default: livepatch
 
@@ -25,10 +26,12 @@ install: livepatch
$(INSTALL_DATA) $(LIVEPATCH) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
$(INSTALL_DATA) $(LIVEPATCH_BYE) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
$(INSTALL_DATA) $(LIVEPATCH_REPLACE) 
$(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   $(INSTALL_DATA) $(LIVEPATCH_NOP) $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_BYE)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_REPLACE)
+   rm -f $(DESTDIR)$(DEBUG_DIR)/$(LIVEPATCH_NOP)
 
 .PHONY: clean
 clean::
@@ -41,9 +44,13 @@ clean::
 .PHONY: config.h
 config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
 config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
+config.h: MINOR_VERSION_SZ=$(call 
CODE_SZ,$(BASEDIR)/xen-syms,xen_minor_version)
+config.h: MINOR_VERSION_ADDR=$(call 
CODE_ADDR,$(BASEDIR)/xen-syms,xen_minor_version)
 config.h: xen_hello_world_func.o
(set -e; \
 echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
+echo "#define MINOR_VERSION_SZ $(MINOR_VERSION_SZ)"; \
+echo "#define MINOR_VERSION_ADDR $(MINOR_VERSION_ADDR)"; \
 echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
 
 xen_hello_world.o: config.h
@@ -92,5 +99,11 @@ xen_replace_world.o: config.h
 $(LIVEPATCH_REPLACE): xen_replace_world_func.o xen_replace_world.o note.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_REPLACE) $^
 
+xen_nop.o: config.h
+
+.PHONY: $(LIVEPATCH_NOP)
+$(LIVEPATCH_NOP): xen_nop.o note.o
+   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH_NOP) $^
+
 .PHONY: livepatch
-livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE)
+livepatch: $(LIVEPATCH) $(LIVEPATCH_BYE) $(LIVEPATCH_REPLACE) $(LIVEPATCH_NOP)
diff --git a/xen/test/livepatch/xen_nop.c b/xen/test/livepatch/xen_nop.c
new file mode 100644
index 000..3827979
--- /dev/null
+++ b/xen/test/livepatch/xen_nop.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include "config.h"
+#include 
+
+#include 
+
+/*
+ * All of the .new_size and .old_addr are based on assumptions that the
+ * code for 'xen_minor_version' is compiled in specific way. Before
+ * running this test-case you MUST verify that the assumptions are
+ * correct (Hint: make debug and look in xen.s).
+ */
+struct livepatch_func __section(".livepatch.funcs") livepatch_nop = {
+.version = LIVEPATCH_PAYLOAD_VERSION,
+.old_size = MINOR_VERSION_SZ,
+
+#ifdef CONFIG_X86
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Everything but the last instruction: "req". */
+.new_size = MINOR_VERSION_SZ-1,
+#endif
+
+#ifdef CONFIG_ARM_64
+.old_addr = (void *)MINOR_VERSION_ADDR,
+/* Replace the first one: "mov w0, #0x8".  */
+.new_size = 4,
+#endif
+
+#ifdef CONFIG_ARM_32
+/* Skip the first instruction: "push {fp}". */
+.old_addr = (void *)(MINOR_VERSION_ADDR + 4),
+/* And replace the next 

[Xen-devel] [PATCH v5 02/16] arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]

[Konrad Rzeszutek Wilk]

x86 implements all of them by default - and we just
add two extra HAS_ variables to be declared in autoconf.h.

ARM 64 only has alternative while ARM 32 has none of them.

And while at it change the livepatch common code that
would benefit from this.

Acked-by: Jan Beulich  [relevant parts]
Suggested-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 

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

v2: First submission
v3: Move the config options to common code
Don't include  in the file.
Don't even include  in the file as xen/Rules.mk automatically
includes the config.h for every GCC invocation.
v4: Depend on "arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/"
Remove the extra newline in arch/x86/Kconfig
v5: Add Jan's Ack.
---
 xen/arch/arm/Kconfig   | 3 ---
 xen/arch/x86/Kconfig   | 2 ++
 xen/common/Kconfig | 6 ++
 xen/common/livepatch.c | 4 +++-
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 558d013..2e023d1 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -45,9 +45,6 @@ config ACPI
 config HAS_GICV3
bool
 
-config HAS_ALTERNATIVE
-   bool
-
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 265fd79..96ca2bf 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -7,8 +7,10 @@ config X86
select ACPI_LEGACY_TABLES_LOOKUP
select COMPAT
select CORE_PARKING
+   select HAS_ALTERNATIVE
select HAS_CPUFREQ
select HAS_EHCI
+   select HAS_EX_TABLE
select HAS_GDBSX
select HAS_IOPORTS
select HAS_KEXEC
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 4331874..81e0017 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -11,9 +11,15 @@ config COMPAT
 config CORE_PARKING
bool
 
+config HAS_ALTERNATIVE
+   bool
+
 config HAS_DEVICE_TREE
bool
 
+config HAS_EX_TABLE
+   bool
+
 config HAS_MEM_ACCESS
bool
 
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 5f9986d..292dd2e 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -643,7 +643,7 @@ static int prepare_payload(struct payload *payload,
   sizeof(*region->frame[i].bugs);
 }
 
-#ifndef CONFIG_ARM
+#ifdef CONFIG_HAS_ALTERNATIVE
 sec = livepatch_elf_sec_by_name(elf, ".altinstructions");
 if ( sec )
 {
@@ -674,7 +674,9 @@ static int prepare_payload(struct payload *payload,
 }
 apply_alternatives(start, end);
 }
+#endif
 
+#ifdef CONFIG_HAS_EX_TABLE
 sec = livepatch_elf_sec_by_name(elf, ".ex_table");
 if ( sec )
 {
-- 
2.4.11


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

[Xen-devel] [PATCH v5 15/16] livepatch, arm[32|64]: Share arch_livepatch_revert

[Konrad Rzeszutek Wilk]

It is exactly the same in both platforms.

No functional change.

Acked-by: Julien Grall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v3: New submission.
v4: s/arch_livepatch_insn_len/livepatch_insn_len/
s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
v5: Added Julien's Acked-by.
Fixed comments.
  - Rebase on top "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
  - s/_jmp//
---
 xen/arch/arm/arm32/livepatch.c | 17 +
 xen/arch/arm/arm64/livepatch.c | 17 +
 xen/arch/arm/livepatch.c   | 17 +
 3 files changed, 19 insertions(+), 32 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 3f47326..7e600f2 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -74,22 +74,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(func->new_addr, func->new_size);
 }
 
-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
index ea8044d..a7a292f 100644
--- a/xen/arch/arm/arm64/livepatch.c
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -61,22 +61,7 @@ void arch_livepatch_apply(struct livepatch_func *func)
 clean_and_invalidate_dcache_va_range(func->new_addr, func->new_size);
 }
 
-void arch_livepatch_revert(const struct livepatch_func *func)
-{
-uint32_t *new_ptr;
-unsigned int i, len;
-
-new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
-len = livepatch_insn_len(func) / sizeof(uint32_t);
-for ( i = 0; i < len; i++ )
-{
-uint32_t insn;
-
-memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
-/* PATCH! */
-*(new_ptr + i) = insn;
-}
-}
+/* arch_livepatch_revert shared with ARM 32/ARM 64. */
 
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
 {
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 6ee7081..2d62a24 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -69,6 +69,23 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
+void arch_livepatch_revert(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+unsigned int i, len;
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = livepatch_insn_len(func) / sizeof(uint32_t);
+for ( i = 0; i < len; i++ )
+{
+uint32_t insn;
+
+memcpy(, func->opaque + (i * sizeof(uint32_t)), 
ARCH_PATCH_INSN_SIZE);
+/* PATCH! */
+*(new_ptr + i) = insn;
+}
+}
+
 void arch_livepatch_post_action(void)
 {
 /* arch_livepatch_revive has nuked the instruction cache. */
-- 
2.4.11


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

[Xen-devel] [PATCH v5 08/16] livepatch/arm/x86: Check payload for for unwelcomed symbols.

[Konrad Rzeszutek Wilk]

Certain platforms, such as ARM [32|64] add extra mapping symbols
such as $x (for ARM64 instructions), or more interesting to
this patch: $t (for Thumb instructions). These symbols are suppose
to help the final linker to make any adjustments (such as
add an veneer). But more importantly - we do not compile Xen
with any Thumb instructions (which are variable length) - and
if we find these mapping symbols we should disallow such payload.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v3: New submission.
Use [i] instead of sym (as that will always be NULL).
v4: Use bool instead of int for return
Update comment in common code about ARM odd symbols.
s/_check/_deny/ to make it more clear.
v5: Also check for $t.* wildcard.
Use Julien's variant where we roll the [2] check in the return.
---
 xen/arch/arm/livepatch.c| 16 
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch_elf.c  |  7 +++
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 32 insertions(+)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9959315..5a99ab5 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -117,6 +117,22 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+#ifdef CONFIG_ARM_32
+/*
+ * Xen does not use Thumb instructions - and we should not see any of
+ * them. If we do, abort.
+ */
+if ( sym->name && sym->name[0] == '$' && sym->name[1] == 't' )
+{
+return ( !sym->name[2] || sym->name[2] == '.' );
+}
+#endif
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 7a369a0..9663ef6 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -131,6 +131,13 @@ bool arch_livepatch_symbol_ok(const struct livepatch_elf 
*elf,
 return true;
 }
 
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return false;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index f46990e..ec74beb 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -251,6 +251,13 @@ static int elf_get_sym(struct livepatch_elf *elf, const 
void *data)
 
 sym[i].sym = s;
 sym[i].name = strtab_sec->data + delta;
+/* e.g. On ARM we should NEVER see $t* symbols. */
+if ( arch_livepatch_symbol_deny(elf, [i]) )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Symbol '%s' should not be in 
payload!\n",
+elf->name, sym[i].name);
+return -EINVAL;
+}
 }
 elf->nsym = nsym;
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index e8c67d6..98ec012 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -50,6 +50,8 @@ bool_t is_patch(const void *addr);
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf);
 bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
   const struct livepatch_elf_sym *sym);
+bool arch_livepatch_symbol_deny(const struct livepatch_elf *elf,
+const struct livepatch_elf_sym *sym);
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela);
-- 
2.4.11


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

[Xen-devel] [PATCH v5 09/16] livepatch: Move test-cases to their own sub-directory in test.

[Konrad Rzeszutek Wilk]

So they can be shared with ARM64 (but not yet, so they
are only built on x86).

No functional change.

We also need to tweak the MAINTAINERS and .gitignore file.

Also we need to update SUBDIRS to include the new 'test'
directory so 'cscope' can show the example livepatches.

Acked-by: Jan Beulich  [for directory]
Signed-off-by: Konrad Rzeszutek Wilk 

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

v1: First submission
v2: Move to test/livepatch per Jan's recommendation
v3: Sort MAINTAINERS for livepatch.
Add Jan's Acked-by.
Added on the SUBDIRS the 'test' directory
Change title of patch (common-> own sub-directory)
---
 .gitignore | 8 
 MAINTAINERS| 1 +
 xen/Makefile   | 5 +++--
 xen/arch/arm/Makefile  | 3 ---
 xen/arch/x86/Makefile  | 5 -
 xen/test/Makefile  | 9 +
 xen/{arch/x86/test => test/livepatch}/Makefile | 0
 xen/{arch/x86/test => test/livepatch}/xen_bye_world.c  | 0
 xen/{arch/x86/test => test/livepatch}/xen_bye_world_func.c | 0
 xen/{arch/x86/test => test/livepatch}/xen_hello_world.c| 0
 xen/{arch/x86/test => test/livepatch}/xen_hello_world_func.c   | 0
 xen/{arch/x86/test => test/livepatch}/xen_replace_world.c  | 0
 xen/{arch/x86/test => test/livepatch}/xen_replace_world_func.c | 0
 13 files changed, 17 insertions(+), 14 deletions(-)
 create mode 100644 xen/test/Makefile
 rename xen/{arch/x86/test => test/livepatch}/Makefile (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_bye_world.c (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_bye_world_func.c (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_hello_world.c (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_hello_world_func.c (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_replace_world.c (100%)
 rename xen/{arch/x86/test => test/livepatch}/xen_replace_world_func.c (100%)

diff --git a/.gitignore b/.gitignore
index cc64fc9..eeabe0b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -254,10 +254,6 @@ xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
 xen/arch/x86/efi/mkreloc
-xen/arch/x86/test/config.h
-xen/arch/x86/test/xen_hello_world.livepatch
-xen/arch/x86/test/xen_bye_world.livepatch
-xen/arch/x86/test/xen_replace_world.livepatch
 xen/arch/*/efi/boot.c
 xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
@@ -274,6 +270,10 @@ xen/include/public/public
 xen/include/xen/*.new
 xen/include/xen/acm_policy.h
 xen/include/xen/compile.h
+xen/test/livepatch/config.h
+xen/test/livepatch/xen_bye_world.livepatch
+xen/test/livepatch/xen_hello_world.livepatch
+xen/test/livepatch/xen_replace_world.livepatch
 xen/tools/kconfig/.tmp_gtkcheck
 xen/tools/kconfig/.tmp_qtcheck
 xen/tools/symbols
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c39146..8c5b756 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -273,6 +273,7 @@ F:  xen/arch/*/*/livepatch*
 F:  xen/common/livepatch*
 F:  xen/include/asm-*/livepatch.h
 F:  xen/include/xen/livepatch*
+F:  xen/test/livepatch/*
 
 MACHINE CHECK (MCA) & RAS
 M: Christoph Egger 
diff --git a/xen/Makefile b/xen/Makefile
index 012509b..e989a20 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -80,7 +80,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
 
 .PHONY: _tests
 _tests:
-   $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) tests
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C test tests
 
 .PHONY: _uninstall
 _uninstall: D=$(DESTDIR)
@@ -114,6 +114,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean
$(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean
+   $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
@@ -189,7 +190,7 @@ include/asm-$(TARGET_ARCH)/asm-offsets.h: 
arch/$(TARGET_ARCH)/asm-offsets.s
  echo ""; \
  echo "#endif") <$< >$@
 
-SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers
+SUBDIRS = xsm arch/$(TARGET_ARCH) common drivers test
 define all_sources
 ( find include/asm-$(TARGET_ARCH) -name '*.h' -print; \
   find include -name 'asm-*' -prune -o -name '*.h' -print; \
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 5cee84d..1d9051c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile

[Xen-devel] [PATCH v5 01/16] arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/

[Konrad Rzeszutek Wilk]

No functional change. We resist the temptation to move
the entries in the Kconfig file to be more in alphabetical
order as the "arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]"
will move one of the entries to common file.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Doug Goldstein 

v4: New submission.
[Forgot to post as part of the patch series, included as
inline reply to one of the patches].
v5: Don't sort the HAS_ALTERNATIVE and HAS_GICV3 in alphabetical
order.
---
 xen/arch/arm/Kconfig  | 6 +++---
 xen/arch/arm/Makefile | 2 +-
 xen/arch/arm/xen.lds.S| 2 +-
 xen/include/asm-arm/alternative.h | 4 ++--
 xen/include/asm-arm/cpuerrata.h   | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 797c91f..558d013 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -12,8 +12,8 @@ config ARM_32
 config ARM_64
def_bool y
depends on 64BIT
+   select HAS_ALTERNATIVE
select HAS_GICV3
-   select ALTERNATIVE
 
 config ARM
def_bool y
@@ -45,13 +45,13 @@ config ACPI
 config HAS_GICV3
bool
 
-config ALTERNATIVE
+config HAS_ALTERNATIVE
bool
 
 endmenu
 
 menu "ARM errata workaround via the alternative framework"
-   depends on ALTERNATIVE
+   depends on HAS_ALTERNATIVE
 
 config ARM64_ERRATUM_827319
bool "Cortex-A53: 827319: Data cache clean instructions might cause 
overlapping transactions to the interconnect"
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 64fdf41..61e655b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -4,7 +4,7 @@ subdir-y += platforms
 subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi
 
-obj-$(CONFIG_ALTERNATIVE) += alternative.o
+obj-$(CONFIG_HAS_ALTERNATIVE) += alternative.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpuerrata.o
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 3c5e7ba..47b910d 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -151,7 +151,7 @@ SECTIONS
*(.initcall1.init)
__initcall_end = .;
 
-#ifdef CONFIG_ALTERNATIVE
+#ifdef CONFIG_HAS_ALTERNATIVE
. = ALIGN(4);
__alt_instructions = .;
*(.altinstructions)
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 9f88fd9..6851217 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -5,7 +5,7 @@
 #include 
 #include 
 
-#ifdef CONFIG_ALTERNATIVE
+#ifdef CONFIG_HAS_ALTERNATIVE
 
 #ifndef __ASSEMBLY__
 
@@ -154,7 +154,7 @@ int apply_alternatives(const struct alt_instr *start, const 
struct alt_instr *en
 #define ALTERNATIVE(oldinstr, newinstr, ...)   \
_ALTERNATIVE_CFG(oldinstr, newinstr, __VA_ARGS__, 1)
 
-#else /* !CONFIG_ALTERNATIVE */
+#else /* !CONFIG_HAS_ALTERNATIVE */
 
 static inline void apply_alternatives_all(void)
 {
diff --git a/xen/include/asm-arm/cpuerrata.h b/xen/include/asm-arm/cpuerrata.h
index 5e35b4f..8c57c6a 100644
--- a/xen/include/asm-arm/cpuerrata.h
+++ b/xen/include/asm-arm/cpuerrata.h
@@ -7,7 +7,7 @@
 
 void check_local_cpu_errata(void);
 
-#ifdef CONFIG_ALTERNATIVE
+#ifdef CONFIG_HAS_ALTERNATIVE
 
 #define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
 static inline bool_t check_workaround_##erratum(void)   \
@@ -27,7 +27,7 @@ static inline bool_t check_workaround_##erratum(void) 
  \
 }   \
 }
 
-#else /* CONFIG_ALTERNATIVE */
+#else /* CONFIG_HAS_ALTERNATIVE */
 
 #define CHECK_WORKAROUND_HELPER(erratum, feature, arch) \
 static inline bool_t check_workaround_##erratum(void)   \
-- 
2.4.11


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

[Xen-devel] [PATCH v5] Livepatch for ARM 64 and 32.

[Konrad Rzeszutek Wilk]

Hey!
Since v4:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01734.html]
 - Added Acks/Reviewed-by
 - Reworked "arm: poison initmem when it is freed." and
   "xen/arm32: Add an helper to invalidate all instruction caches"
 - Moved "livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH" to
   be in front of "livepatch: tests: Make them compile under ARM64"
 - Fixed up code as suggested by reviewers.

v3: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01127.html]
 - Addressed Jan's comment (most are renaming)
 - Addressed Julien's and Jan's idea of HAS_ALTERNATIVE
 - Addressed Julien's review comments of "arm: poison initmem when it is freed."

v2: [http://www.gossamer-threads.com/lists/xen/devel/61?page=last]
 - Addressed the two outstanding concerns: CPU bit feature to test alternative
   test-case, and errata #843419 on some Cortex-A53 
 - Dealt with comments from Jan, Julien and Andrew.
 - Fixed (offlist) with Julien ARM32 not branching properly.
 - Committed some of the patches that had been reviewed/Acked.

v1 (and RFC): 
[https://lists.xen.org/archives/html/xen-devel/2016-08/msg01835.html]
 - Acted on most all comments.
 - Added ARM 32 support.

The patches are based on: [PATCH v7] Livepatch fixes and features for v4.8.
https://lists.xen.org/archives/html/xen-devel/2016-09/msg02305.html

And the git tree is:
 git://xenbits.xen.org/people/konradwilk/xen.git livepatch.v4.8.v7

These patches enable livepatching to work on ARM64 and ARM32. They have
been tested on multi-CPU environments (Foundation Model, 4CPU for ARM64;
and ARM CubieTruck for ARM32).

The state of the patches is as follow:

Legend:
 r - Reviewed
 a - Acked


arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/
a   arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]
 r  livepatch: Reject payloads with .alternative or .ex_table if support is not 
built-in.
arm: poison initmem when it is freed.
a   livepatch: Initial ARM64 support.
livepatch: ARM/x86: Check displacement of old_addr and new_addr
 r  livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]
livepatch/arm/x86: Check payload for for unwelcomed symbols.
a   livepatch: Move test-cases to their own sub-directory in test.
livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH
livepatch: tests: Make them compile under ARM64
xen/arm32: Add an helper to invalidate all instruction caches
ar  bug/x86/arm: Align bug_frames sections.
a   livepatch: Initial ARM32 support.
a   livepatch, arm[32|64]: Share arch_livepatch_revert
livepatch: arm[32,64],x86: NOP test-case

Please review!

Konrad Rzeszutek Wilk (16):
  arm64: s/ALTERNATIVE/HAS_ALTERNATIVE/
  arm/x86/common: Add HAS_[ALTERNATIVE|EX_TABLE]
  livepatch: Reject payloads with .alternative or .ex_table if support is 
not built-in.
  arm: poison initmem when it is freed.
  livepatch: Initial ARM64 support.
  livepatch: ARM/x86: Check displacement of old_addr and new_addr
  livepatch: ARM 32|64: Ignore mapping symbols: $[d,a,x]
  livepatch/arm/x86: Check payload for for unwelcomed symbols.
  livepatch: Move test-cases to their own sub-directory in test.
  livepatch: x86, ARM, alternative: Expose FEATURE_LIVEPATCH
  livepatch: tests: Make them compile under ARM64
  xen/arm32: Add an helper to invalidate all instruction caches
  bug/x86/arm: Align bug_frames sections.
  livepatch: Initial ARM32 support.
  livepatch, arm[32|64]: Share arch_livepatch_revert
  livepatch: arm[32,64],x86: NOP test-case

 .gitignore  |   8 +-
 MAINTAINERS |   2 +
 docs/misc/livepatch.markdown|  17 +-
 xen/Makefile|   5 +-
 xen/arch/arm/Kconfig|   7 +-
 xen/arch/arm/Makefile   |  18 +-
 xen/arch/arm/arm32/Makefile |   1 +
 xen/arch/arm/arm32/livepatch.c  | 298 +
 xen/arch/arm/arm64/Makefile |   1 +
 xen/arch/arm/arm64/livepatch.c  | 481 
 xen/arch/arm/domain.c   |   6 +
 xen/arch/arm/livepatch.c| 159 +++--
 xen/arch/arm/mm.c   |  15 +-
 xen/arch/arm/traps.c|   6 +
 xen/arch/arm/xen.lds.S  |   8 +-
 xen/arch/x86/Kconfig|   2 +
 xen/arch/x86/Makefile   |   5 -
 xen/arch/x86/livepatch.c|  14 +
 xen/arch/x86/test/Makefile  |  85 -
 xen/arch/x86/test/xen_bye_world.c   |  34 --
 xen/arch/x86/test/xen_bye_world_func.c  |  22 --
 xen/arch/x86/test/xen_hello_world.c |  67 
 xen/arch/x86/test/xen_hello_world_func.c|  39 ---
 xen/arch/x86/test/xen_replace_world.c   |  33 --
 xen/arch/x86/test/xen_replace_world_func.c  |  22 --
 xen/arch/x86/xen.lds.S  |   1 -
 

[Xen-devel] [PATCH v5 07/16] livepatch: ARM 32|64: Ignore mapping symbols: $[d, a, x]

[Konrad Rzeszutek Wilk]

Those symbols are used to help final linkers to replace insn.
The ARM ELF specification mandates that they are present
to denote the start of certain CPU features. There are two
variants of it - short and long format.

Either way - we can ignore these symbols.

Reviewed-by: Andrew Cooper  [x86 bits]
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 

v1: First submission
v2: Update the order of symbols, fix title
Add {} in after the first if - per Jan's recommendation.
v3: Add Andrew's Review tag
Make the function return an bool_t.
Skip check for '$t'
Fix spelling of comments.
s/arch_is_payload_symbol/arch_livepatch_symbol_ok/
v4: s/bool_t/bool/
v5: Removed an extra space in the conditional.
---
 xen/arch/arm/livepatch.c| 33 +
 xen/arch/x86/livepatch.c|  7 +++
 xen/common/livepatch.c  |  2 +-
 xen/include/xen/livepatch.h |  2 ++
 4 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 9284766..9959315 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -84,6 +84,39 @@ void arch_livepatch_unmask(void)
 local_abort_enable();
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/*
+ * - Mapping symbols - denote the "start of a sequence of bytes of the
+ *   appropriate type" to mark certain features - such as start of region
+ *   containing data ($d); ARM ($a), or A64 ($x) instructions.
+ *   We ignore Thumb instructions ($t) as we shouldn't have them.
+ *
+ * The format is either short: '$x' or long: '$x.'. We do not
+ * need this and more importantly - each payload will contain this
+ * resulting in symbol collisions.
+ */
+if ( *sym->name == '$' && sym->name[1] != '\0' )
+{
+char p = sym->name[1];
+size_t len = strlen(sym->name);
+
+if ( (len >= 3 && (sym->name[2] == '.' )) || (len == 2) )
+{
+if ( p == 'd' ||
+#ifdef CONFIG_ARM_32
+ p == 'a'
+#else
+ p == 'x'
+#endif
+   )
+return false;
+}
+}
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index b0d81d7..7a369a0 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -124,6 +124,13 @@ int arch_livepatch_verify_elf(const struct livepatch_elf 
*elf)
 return 0;
 }
 
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym)
+{
+/* No special checks on x86. */
+return true;
+}
+
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela)
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index f2f866c..082f553 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -749,7 +749,7 @@ static bool_t is_payload_symbol(const struct livepatch_elf 
*elf,
  !strncmp(sym->name, ".L", 2) )
 return 0;
 
-return 1;
+return arch_livepatch_symbol_ok(elf, sym);
 }
 
 static int build_symbol_table(struct payload *payload,
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index b7b84e7..e8c67d6 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -48,6 +48,8 @@ bool_t is_patch(const void *addr);
 
 /* Arch hooks. */
 int arch_livepatch_verify_elf(const struct livepatch_elf *elf);
+bool arch_livepatch_symbol_ok(const struct livepatch_elf *elf,
+  const struct livepatch_elf_sym *sym);
 int arch_livepatch_perform_rel(struct livepatch_elf *elf,
const struct livepatch_elf_sec *base,
const struct livepatch_elf_sec *rela);
-- 
2.4.11


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

[Xen-devel] [PATCH v5 14/16] livepatch: Initial ARM32 support.

[Konrad Rzeszutek Wilk]

The patch piggybacks on: livepatch: Initial ARM64 support, which
brings up all of the necessary livepatch infrastructure pieces in.

This patch adds three major pieces:

 1) ELF relocations. ARM32 uses SHT_REL instead of SHT_RELA which
means the adddendum had to be extracted from within the
instruction. Which required parsing BL/BLX, B/BL,
MOVT, and MOVW instructions.

The code was written from scratch using the ARM ELF manual
(and the ARM Architecture Reference Manual)

 2) Inserting an trampoline. We use the B (branch to address)
which uses an offset that is based on the PC value: PC + imm32.
Because we insert the branch at the start of the old function
we have to account for the instruction already being fetched
and subtract -8 from the delta (new_addr - old_addr). See
ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)

 3) Allows the test-cases to be built under ARM 32.
The "livepatch: tests: Make them compile under ARM64"
put in the right infrastructure for it and we piggyback on it.

Acked-by: Julien Grall 
Acked-by: Jan Beulich  [for non-ARM parts]
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 

v2: First submission.
v3: Use LIVEPATCH_ARCH_RANGE instead of NEGATIVE_32MB macro
   -Use PATCH_INSN_SIZE instead of the value 4.
   -Ditch the old_ptr local variable.
   -Use 8 for evaluating the branch instead of 4. Based on ARM docs.
   -NOP patch up to sizeof(opaque) % PATCH_INSN_SIZE (so 7 instructions).
   -Don't mask 0x00F_E_ after shifting, instead mask by 0x00F_F_.
The reason is that offset is constructed by shifting by two the insn
(except the first two bytes) by left which meant we would have cleared
offset[2]! - and jumped to a location that was -4 bytes off.
   -Update commit description to have -8 instead of -4 delta and also
include reference to spec.
v4: Added Jan's Ack.
   s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
   s/arch_livepatch_insn_len/livepatch_insn_len/
   s/LIVEPATCH_ARCH_RANGE/ARCH_LIVEPATCH_RANGE/
v5: Added Julien's Ack.
   - Rebased on "livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp"
   - Added explanation for the usage of data cache and why we need to sync it.
---
 xen/arch/arm/arm32/livepatch.c | 279 -
 xen/arch/arm/arm64/livepatch.c |   7 ++
 xen/arch/arm/livepatch.c   |   7 --
 xen/common/Kconfig |   2 +-
 xen/include/xen/elfstructs.h   |  24 +++-
 xen/test/Makefile  |   2 -
 xen/test/livepatch/Makefile|   3 +
 7 files changed, 311 insertions(+), 13 deletions(-)

diff --git a/xen/arch/arm/arm32/livepatch.c b/xen/arch/arm/arm32/livepatch.c
index 80f9646..3f47326 100644
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -3,28 +3,303 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 void arch_livepatch_apply(struct livepatch_func *func)
 {
+uint32_t insn;
+uint32_t *new_ptr;
+unsigned int i, len;
+
+BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+len = livepatch_insn_len(func);
+if ( !len )
+return;
+
+/* Save old ones. */
+memcpy(func->opaque, func->old_addr, len);
+
+if ( func->new_addr )
+{
+s32 delta;
+
+/*
+ * PC is current address (old_addr) + 8 bytes. The semantics for a
+ * unconditional branch is to jump to PC + imm32 (offset).
+ *
+ * ARM DDI 0406C.c, see A2.3 (pg 45) and A8.8.18 pg (pg 334,335)
+ *
+ */
+delta = (s32)func->new_addr - (s32)(func->old_addr + 8);
+
+/* The arch_livepatch_symbol_ok should have caught it. */
+ASSERT(delta >= -(s32)ARCH_LIVEPATCH_RANGE ||
+   delta < (s32)ARCH_LIVEPATCH_RANGE);
+
+/* CPU shifts by two (left) when decoding, so we shift right by two. */
+delta = delta >> 2;
+/* Lets not modify the cond. */
+delta &= 0x00FF;
+
+insn = 0xea00 | delta;
+}
+else
+insn = 0xe1a0; /* mov r0, r0 */
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+len = len / sizeof(uint32_t);
+
+/* PATCH! */
+for ( i = 0; i < len; i++ )
+*(new_ptr + i) = insn;
+
+/*
+* When we upload the payload, it will go through the data cache
+* (the region is cacheable). Until the data cache is cleaned, the data
+* may not reach the memory. And in the case the data and instruction cache
+* are separated, we may read invalid instruction from the memory because
+* the data cache have not yet synced with the memory. Hence sync it.
+*/
+if ( func->new_addr )
+clean_and_invalidate_dcache_va_range(func->new_addr, 

[Xen-devel] [PATCH v5 11/16] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

We need to two things:
1) Wrap the platform-specific objcopy parameters in defines
   The input and output parameters for $(OBJCOPY) are different
   based on the platforms. As such provide them in the
   OBJCOPY_MAGIC define and use that.

2) The alternative is a bit different (exists only under ARM64
   and x86), while and there are no exceptions under ARM at all.
   We use the LIVEPATCH_FEATURE CPU id feature for ARM similar to
   how it is done on x86.

We are not yet attempting to build them under ARM32 so
that is still ifdefed out.

Signed-off-by: Konrad Rzeszutek Wilk 

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

v1: First submission
v2: Corrected description by Julien
Add #ifeq instead of #else for ARM case.
v3: Moved 'asm(alter..)' by one space to the left.
v4: Rebase on top of "livepatch/tests: Make .livepatch.depends be read-only"
Rewrote the commit description 2) a bit.
---
 xen/test/Makefile |  2 +-
 xen/test/livepatch/Makefile   | 12 ++--
 xen/test/livepatch/xen_hello_world_func.c |  7 +++
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/xen/test/Makefile b/xen/test/Makefile
index 8c53040..95c1755 100644
--- a/xen/test/Makefile
+++ b/xen/test/Makefile
@@ -1,6 +1,6 @@
 .PHONY: tests
 tests:
-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq $(XEN_TARGET_ARCH),arm32)
$(MAKE) -f $(BASEDIR)/Rules.mk -C livepatch livepatch
 endif
 
diff --git a/xen/test/livepatch/Makefile b/xen/test/livepatch/Makefile
index 48ff843..5db4d9c 100644
--- a/xen/test/livepatch/Makefile
+++ b/xen/test/livepatch/Makefile
@@ -1,5 +1,12 @@
 include $(XEN_ROOT)/Config.mk
 
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+endif
+ifeq ($(XEN_TARGET_ARCH),arm64)
+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
+endif
+
 CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
 CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
 
@@ -54,8 +61,9 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 .PHONY: note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
-   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
+  --rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin
 
 #
@@ -65,7 +73,7 @@ note.o:
 .PHONY: hello_world_note.o
 hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
$@.bin
-   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   
--rename-section=.data=.livepatch.depends,alloc,load,readonly,data,contents -S 
$@.bin $@
rm -f $@.bin
 
diff --git a/xen/test/livepatch/xen_hello_world_func.c 
b/xen/test/livepatch/xen_hello_world_func.c
index 0321f3e..c5c0da1 100644
--- a/xen/test/livepatch/xen_hello_world_func.c
+++ b/xen/test/livepatch/xen_hello_world_func.c
@@ -7,14 +7,17 @@
 
 #include 
 #include 
+#ifdef CONFIG_X86
 #include 
 #include 
 
 static unsigned long *non_canonical_addr = (unsigned long 
*)0xdeadULL;
+#endif
 
 /* Our replacement function for xen_extra_version. */
 const char *xen_hello_world(void)
 {
+#ifdef CONFIG_X86
 unsigned long tmp;
 int rc;
 
@@ -25,6 +28,10 @@ const char *xen_hello_world(void)
  */
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
+#endif
+#ifdef CONFIG_ARM_64
+asm(ALTERNATIVE("nop", "nop", LIVEPATCH_FEATURE));
+#endif
 
 return "Hello World";
 }
-- 
2.4.11


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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Andrew Cooper]

On 21/09/16 17:13, Ian Jackson wrote:

Platform Team regression test user writes ("[xen-4.5-testing baseline-only test] 
67737: regressions - FAIL"):

test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706

Several of these, 32bit and 64bit HVM.  This is in the Citrix
Cambridge osstest instance.  The Xen Project colo instance is
unaffected (flight 101045 there passed with the same revisions of
everything)

This is with:

   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860

The log says this:

   2016-09-21 06:07:36 Z -- substep 19 xtf/test-hvm32-invlpg~shadow 
running --
   2016-09-21 06:07:36 Z executing ssh ... root@10.80.228.78 
/home/xtf/xtf-runner -m logfile test-hvm32-invlpg~shadow 1>&2; echo $?

   Using logfile '/var/log/xen/console/guest-test-hvm32-invlpg~shadow.log'
   Executing 'xl create -F tests/invlpg/test-hvm32-invlpg~shadow.cfg'
   --- Xen Test Framework ---
   Environment: HVM 32bit (No paging)
   Testing 'invlpg' in normally-faulting conditions
 Test: Mapped address
 Test: Unmapped address
 Test: NULL segment override
 Test: Past segment limit
   Fail: Unexpected #GP[]
 Test: Before expand-down segment limit
   Fail: Unexpected #GP[]
   Test result: FAILURE

   Combined test results:
   test-hvm32-invlpg~shadow FAILURE

Sadly we haven't yet managed to make the logs from this instance
public.

Do you have any idea what might be causing this ?  Is there a real
problem with the Xen 4.5 branch ?  The Citrix Cambridge instance has
old hardware.


This is the 4.5 tree missing some fixes:

* 31d961f - x86/hvm: Fix invalidation for emulated invlpg instructions 
(4 months ago) 
* eee511d - x86/svm: Don't unconditionally use a new ASID in 
svm_invlpg_intercept() (4 months ago) 
* a373db2 - x86/hvm: Correct the emulated interaction of invlpg with 
segments (4 months ago) 
* a94b35d - x86/hvm: Raise #SS faults for %ss-based segmentation 
violations (4 months ago) 
* 6093515 - x86/hvm: Always return the linear address from 
hvm_virtual_to_linear_addr() (4 months ago) 


In this case, XTF is complaining that `invlpg`, as used in a shadow 
guest, is not behaving in the architecturally specified way.


~Andrew

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

Re: [Xen-devel] [Patch] x86emul: simplify prefix handling for VMFUNC

[Lai, Paul]

On Wed, Sep 21, 2016 at 02:39:58AM -0600, Jan Beulich wrote:
> >>> On 21.09.16 at 00:35,  wrote:
> > On Tue, Sep 20, 2016 at 09:50:15AM -0600, Jan Beulich wrote:
> >> 
> >> Paul, there's been no reply to
> >> https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg00380.html 
> > 
> > The refered to patch, commit a1b1572833, adds a check for vmfunc.
> > I look a little time to look at the SDM and finally found the reference.
> > The vmfunc can be found in Table A-6 "Opcode Extensions for One- and Two-
> > byte Opcodes by Group Number" on page A-18 Vol. 2D of the
> >  e64-ia-32-architectures-software-developer-manual-325462.pdf.
> > The values for vmfunc match the values in the code.
> > I also took the liberty of looking at the other existing cases in the
> > switch statement, and can find RDTSCP and INVLPG. The CLZERO extension
> > value is a mystery to me.
> 
> Well - the question raised was whether the documentation is
> perhaps wrong.

VMFUNC allowing 66, F2, and F3 prefixes when
> other opcodes in its neighborhood (e.g. xsetbv, xtest, xend)
> don't seems at least suspicious. 

Thanks for the clearer problem statement. 

> Extensions originating from AMD
> (rdtscp, clzero) can't be reasonably taken for reference.
> 
> Jan
> 

I'll check


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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

[George Dunlap]

On Wed, Sep 21, 2016 at 2:56 PM, Jan Beulich  wrote:
> Again this looks like much clutter with little benefit to me, i.e. I'd
> then rather go with the unmodified original proposal. That's largely
> because nothing really enforces anyone to use the (disconnected)
> xen_dmop_foo_entry type. I.e. it continues to be a matter of the
> programmer's and the reviewers' attention/discipline.

But is "Must use hypercall dmop, subop foo with struct dmop_foo" any
different than "Must use hypercall bar with struct bar"?

In theory there could be a mismatch between the struct libxc expected
to use for a whole hypercall with the struct Xen expected to find for
an entire hypercall. But in practice that never happens because we set
up the call with the appropriate struct once and then never change it.
(That is, we may change the struct elements, but not the name.)  This
seems to me like a fairly similar case.

Note that I'm not arguing for the extra "clutter" per se, I just think
that it will be pretty effective in mitigating the type safety issue.

 -George

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

[Xen-devel] [PATCH v7 3/5] livepatch: NOP if func->new_addr is zero.

[Konrad Rzeszutek Wilk]

The NOP functionality will NOP any of the code at
the 'old_addr' or at 'name' if the 'new_addr' is zero.
The purpose of this is to NOP out calls, such as:

 e8 <4-bytes-offset>

(5 byte insn), or on ARM a 4 byte insn for branching.

We need the EIP of where we need to the NOP, and that can
be provided via the `old_addr` or `name`.

If the `old_addr` is provided we will NOP 'new_size'
amount of bytes at that location.

The amount is up to 31 instructions if desired (which is
the size of the opaque member). If there is a need to NOP
more then: a) more 'struct livepatch_func' structures need
to be present, b) we have to implement a variable size
buffer (in the future), or c) first byte an unconditional
branch skipping the to be disabled code (of course provided
there are no branch targets in the middle).

While at it, also unify the code on x86 patching so
it is a bit simpler (instead of two seperate writes
just make it one memcpy).

And introduce a general livepatch_insn_len inline function
that would depend on platform specific instruction size
(for a unconditional branch). As such we also rename the
PATCH_INSN_SIZE to ARCH_PATCH_INSN_SIZE.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Konrad Rzeszutek Wilk 
Cc: Ross Lagerwall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3: First submission
v4: Fix description - e9 -> e8
Remove the restriction of only doing 5 or 4 bytes.
Redo the patching code to deal with variable size of new_size.
Expand the amount of bytes we can NOP.
Move the PATCH_INSN_SIZE definition in platform specific headers
Move the get_len to livepatch_get_insn_len inline function.
v5: s/PATCH_INSN_SIZE/ARCH_PATCH_INSN_SIZE/
s/arch_livepatch_insn_len/livepatch_insn_len/
s/size_t len/unsigned int len/
Add in commit description the c) mechanism (insert an unconditional
branch).
v6: Expand in the documentation about the old_addr being at least 5.
v7: Added the extra entry in the MAINTAINERS file.
  - Expanded on the livepatch.markdown the description.
  - Used add_nops(insn, .. instead of add_nops(, ..)
---
 MAINTAINERS   |  1 +
 docs/misc/livepatch.markdown  | 22 ++
 xen/arch/x86/alternative.c|  2 +-
 xen/arch/x86/livepatch.c  | 48 +++
 xen/common/livepatch.c|  3 ++-
 xen/include/asm-x86/alternative.h |  1 +
 xen/include/asm-x86/livepatch.h   | 21 +
 xen/include/xen/livepatch.h   | 10 
 8 files changed, 86 insertions(+), 22 deletions(-)
 create mode 100644 xen/include/asm-x86/livepatch.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 97720a8..9b30600 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -270,6 +270,7 @@ F:  docs/misc/livepatch.markdown
 F:  tools/misc/xen-livepatch.c
 F:  xen/arch/*/livepatch*
 F:  xen/common/livepatch*
+F:  xen/include/asm-*/livepatch.h
 F:  xen/include/xen/livepatch*
 
 MACHINE CHECK (MCA) & RAS
diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 81f4fc9..37a0860 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -318,13 +318,24 @@ The size of the structure is 64 bytes on 64-bit 
hypervisors. It will be
   payload generation time if hypervisor function address is known. If unknown,
   the value *MUST* be zero and the hypervisor will attempt to resolve the 
address.
 
-* `new_addr` is the address of the function that is replacing the old
-  function. The address is filled in during relocation. The value **MUST** be
-  the address of the new function in the file.
+* `new_addr` can either have a non-zero value or be zero.
+  * If there is a non-zero value, then it is the address of the function that 
is
+replacing the old function and the address is recomputed during relocation.
+The value **MUST** be the address of the new function in the payload file.
 
-* `old_size` and `new_size` contain the sizes of the respective functions in 
bytes.
+  * If the value is zero, then we NOPing out at the `old_addr` location
+`new_size` bytes.
+
+* `old_size` contains the sizes of the respective `old_addr` function in bytes.
The value of `old_size` **MUST** not be zero.
 
+* `new_size` depends on what `new_addr` contains:
+  * If `new_addr` contains an non-zero value, then `new_size` has the size of
+the new function (which will replace the one at `old_addr`)  in bytes.
+  * If the value of `new_addr` is zero then `new_size` determines how many
+instruction bytes to NOP (up to opaque size modulo smallest platform
+instruction - 1 byte x86 and 4 bytes on ARM).
+
 * `version` is to be one.
 
 * `opaque` **MUST** be zero.
@@ -1087,7 +1098,8 @@ limit that calls the next trampoline.
 Please note there is a small limitation for trampolines in
 function entries: The target function (+ trailing padding) must be able
 to accomodate 

[Xen-devel] [PATCH v7 5/5] livepach: Add .livepatch.hooks functions and test-case

[Konrad Rzeszutek Wilk]

From: Ross Lagerwall 

Add hook functions which run during patch apply and patch revert.
Hook functions are used by livepatch payloads to manipulate data
structures during patching, etc.

One use case is the XSA91. As Martin mentions it:
"If we have shadow variables, we also need an unload hook to garbage
collect all the variables introduced by a hotpatch to prevent memory
leaks.  Potentially, we also want to pre-reserve memory for static or
existing dynamic objects in the load-hook instead of on the fly.

For testing and debugging, various applications are possible.

In general, the hooks provide flexibility when having to deal with
unforeseen cases, but their application should be rarely required (<
10%)."

Furthermore include a test-case for it.

Reviewed-by: Andrew Cooper 
Signed-off-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

v0.4..v0.11: Defered for v4.8
v0.12: s/xsplice/livepatch/

v3: Clarify the comments about spin_debug_enable
Rename one of the hooks to lower-case (Z->z) to guarantee it being
called last.
Learned a lot of about 'const'
v4: Do the actual const of the hooks.
Remove the requirement for the tests-case hooks to be sorted
(they never were to start with).
Fix up the comment about spin_debug_enable so more.
v5: Added Reviewed-by from Andrew.
Dropped the check_fnc hook
Added the check_fnc hook back again as "livepatch: Disallow applying
after an revert" guarantees we won't hit the BUG_ON check.
---
 docs/misc/livepatch.markdown| 23 +
 xen/arch/x86/test/xen_hello_world.c | 34 +
 xen/common/livepatch.c  | 50 -
 xen/include/xen/livepatch_payload.h | 49 
 4 files changed, 155 insertions(+), 1 deletion(-)
 create mode 100644 xen/include/xen/livepatch_payload.h

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 37a0860..f2ae52a 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -351,6 +351,13 @@ When reverting a patch, the hypervisor iterates over each 
`livepatch_func`
 and the core code copies the data from the undo buffer (private internal copy)
 to `old_addr`.
 
+It optionally may contain the address of functions to be called right before
+being applied and after being reverted:
+
+ * `.livepatch.hooks.load` - an array of function pointers.
+ * `.livepatch.hooks.unload` - an array of function pointers.
+
+
 ### Example of .livepatch.funcs
 
 A simple example of what a payload file can be:
@@ -388,6 +395,22 @@ struct livepatch_func livepatch_hello_world = {
 
 Code must be compiled with -fPIC.
 
+### .livepatch.hooks.load and .livepatch.hooks.unload
+
+This section contains an array of function pointers to be executed
+before payload is being applied (.livepatch.funcs) or after reverting
+the payload. This is useful to prepare data structures that need to
+be modified patching.
+
+Each entry in this array is eight bytes.
+
+The type definition of the function are as follow:
+
+
+typedef void (*livepatch_loadcall_t)(void);  
+typedef void (*livepatch_unloadcall_t)(void);   
+
+
 ### .livepatch.depends and .note.gnu.build-id
 
 To support dependencies checking and safe loading (to load the
diff --git a/xen/arch/x86/test/xen_hello_world.c 
b/xen/arch/x86/test/xen_hello_world.c
index d80963e..02f3f85 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -4,14 +4,48 @@
  */
 
 #include "config.h"
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 static const char hello_world_patch_this_fnc[] = "xen_extra_version";
 extern const char *xen_hello_world(void);
+static unsigned int cnt;
+
+static void apply_hook(void)
+{
+printk(KERN_DEBUG "Hook executing.\n");
+}
+
+static void revert_hook(void)
+{
+printk(KERN_DEBUG "Hook unloaded.\n");
+}
+
+static void  hi_func(void)
+{
+printk(KERN_DEBUG "%s: Hi! (called %u times)\n", __func__, ++cnt);
+};
+
+static void check_fnc(void)
+{
+printk(KERN_DEBUG "%s: Hi func called %u times\n", __func__, cnt);
+BUG_ON(cnt == 0 || cnt > 2);
+}
+
+LIVEPATCH_LOAD_HOOK(apply_hook);
+LIVEPATCH_UNLOAD_HOOK(revert_hook);
+
+/* Imbalance here. Two load and three unload. */
+
+LIVEPATCH_LOAD_HOOK(hi_func);
+LIVEPATCH_UNLOAD_HOOK(hi_func);
+
+LIVEPATCH_UNLOAD_HOOK(check_fnc);
 
 struct livepatch_func __section(".livepatch.funcs") livepatch_xen_hello_world 
= {
 .version = LIVEPATCH_PAYLOAD_VERSION,
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 

[Xen-devel] [PATCH v7 1/5] livepatch: Disallow applying after an revert

[Konrad Rzeszutek Wilk]

On general this is unhealthy - as the payload's .bss (definitly)
or .data (maybe) will be modified once the payload is running.

Doing an revert and then re-applying the payload with a non-pristine
.bss or .data can lead to unforseen consequences (.bss are assumed
to always contain zero value but now they may have a different value).

There is one exception - if the payload contains only one .data section
- the .livepatch.funcs, then it is OK to re-apply an revert.
We detect this rather simply (if there is one RW section and its name
is .livepatch.funcs) - but the payload may have many other RW sections
that are not used at all (such as .bss or .data sections with zero
length). To not account those we also ignore sections with sh_size
being zero.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Andrew Cooper 
Cc: Jan Beulich 

v6: New submission.
v7: Use 'bool' instead of 'bool_t'
  - Ignore sh_size==0 sections as a way to make the exception check work.
  - Also add the sh_size==0 check in livepatch_elf_resolve_symbols.
  - Update comment in load move_payload to mention
"livepatch_elf_resolve_symbols"
---
 docs/misc/livepatch.markdown |  7 +++
 xen/common/livepatch.c   | 36 +---
 xen/common/livepatch_elf.c   |  3 ++-
 3 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 89c1050..81f4fc9 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -1061,6 +1061,13 @@ depending on the current state of data. As such it 
should not be attempted.
 That said we should provide hook functions so that the existing data
 can be changed during payload application.
 
+To guarantee safety we disallow re-applying an payload after it has been
+reverted. This is because we cannot guarantee that the state of .bss
+and .data to be exactly as it was during loading. Hence the administrator
+MUST unload the payload and upload it again to apply it.
+
+There is an exception to this: if the payload only has .livepatch.funcs;
+and no .data or .bss sections.
 
 ### Inline patching
 
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 23e4d51..1f527a3 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -52,6 +52,8 @@ struct livepatch_build_id {
 struct payload {
 uint32_t state;  /* One of the LIVEPATCH_STATE_*. */
 int32_t rc;  /* 0 or -XEN_EXX. */
+bool reverted;   /* Whether it was reverted. */
+bool safe_to_reapply;/* Can apply safely after revert. */
 struct list_head list;   /* Linked to 'payload_list'. */
 const void *text_addr;   /* Virtual address of .text. */
 size_t text_size;/* .. and its size. */
@@ -308,7 +310,7 @@ static void calc_section(const struct livepatch_elf_sec 
*sec, size_t *size,
 static int move_payload(struct payload *payload, struct livepatch_elf *elf)
 {
 void *text_buf, *ro_buf, *rw_buf;
-unsigned int i;
+unsigned int i, rw_buf_sec, rw_buf_cnt = 0;
 size_t size = 0;
 unsigned int *offset;
 int rc = 0;
@@ -325,8 +327,13 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
  * and .shstrtab. For the non-relocate we allocate and copy these
  * via other means - and the .rel we can ignore as we only use it
  * once during loading.
+ *
+ * Also ignore sections with zero size. Those can be .data, or .bss.
+ *
+ * This logic must MATCH what is done in livepatch_elf_resolve_symbols.
  */
-if ( !(elf->sec[i].sec->sh_flags & SHF_ALLOC) )
+if ( !(elf->sec[i].sec->sh_flags & SHF_ALLOC) ||
+ elf->sec[i].sec->sh_size == 0 )
 offset[i] = UINT_MAX;
 else if ( (elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
!(elf->sec[i].sec->sh_flags & SHF_WRITE) )
@@ -374,14 +381,18 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 
 for ( i = 1; i < elf->hdr->e_shnum; i++ )
 {
-if ( elf->sec[i].sec->sh_flags & SHF_ALLOC )
+if ( elf->sec[i].sec->sh_flags & SHF_ALLOC && elf->sec[i].sec->sh_size 
)
 {
 void *buf;
 
 if ( elf->sec[i].sec->sh_flags & SHF_EXECINSTR )
 buf = text_buf;
 else if ( elf->sec[i].sec->sh_flags & SHF_WRITE )
+{
 buf = rw_buf;
+rw_buf_sec = i;
+rw_buf_cnt++;
+}
 else
 buf = ro_buf;
 
@@ -402,6 +413,10 @@ static int move_payload(struct payload *payload, struct 
livepatch_elf *elf)
 }
 }
 
+/* Only one RW section with non-zero size: .livepatch.funcs */
+if ( rw_buf_cnt == 1 &&

[Xen-devel] [PATCH v7 4/5] livepatch: Drop _jmp from arch_livepatch_[apply, revert]_jmp

[Konrad Rzeszutek Wilk]

With "livepatch: NOP if func->new_addr is zero." that name
makes no more sense as we also NOP now.

Suggested-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
v7: New submission.
---
 xen/arch/arm/livepatch.c| 4 ++--
 xen/arch/x86/livepatch.c| 4 ++--
 xen/common/livepatch.c  | 4 ++--
 xen/include/xen/livepatch.h | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 755f596..7f067a0 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -21,11 +21,11 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return -ENOSYS;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 }
 
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index d5e7174..b0d81d7 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -46,7 +46,7 @@ int arch_livepatch_verify_func(const struct livepatch_func 
*func)
 return 0;
 }
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
 {
 uint8_t *old_ptr;
 uint8_t insn[sizeof(func->opaque)];
@@ -75,7 +75,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
 memcpy(old_ptr, insn, len);
 }
 
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
 {
 memcpy(func->old_addr, func->opaque, livepatch_insn_len(func));
 }
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index ed41f39..9d2e86d 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1033,7 +1033,7 @@ static int apply_payload(struct payload *data)
 }
 
 for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_apply_jmp(>funcs[i]);
+arch_livepatch_apply(>funcs[i]);
 
 arch_livepatch_revive();
 
@@ -1062,7 +1062,7 @@ static int revert_payload(struct payload *data)
 }
 
 for ( i = 0; i < data->nfuncs; i++ )
-arch_livepatch_revert_jmp(>funcs[i]);
+arch_livepatch_revert(>funcs[i]);
 
 arch_livepatch_revive();
 
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 174af06..b7f66d4 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -86,8 +86,8 @@ unsigned int livepatch_insn_len(const struct livepatch_func 
*func)
 int arch_livepatch_quiesce(void);
 void arch_livepatch_revive(void);
 
-void arch_livepatch_apply_jmp(struct livepatch_func *func);
-void arch_livepatch_revert_jmp(const struct livepatch_func *func);
+void arch_livepatch_apply(struct livepatch_func *func);
+void arch_livepatch_revert(const struct livepatch_func *func);
 void arch_livepatch_post_action(void);
 
 void arch_livepatch_mask(void);
-- 
2.4.11


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

[Xen-devel] [PATCH v7] Livepatch fixes and general features for Xen 4.8.

[Konrad Rzeszutek Wilk]

Hey!

Since v6: [https://lists.xen.org/archives/html/xen-devel/2016-09/msg01719.html]
 - Remade "livepatch: Disallow applying after an revert" to look at sh_size.
 - Added some Reviewed-by/Acks.
 - Added changes as requested.
 - Included a new patch: "livepatch: Drop _jmp from 
arch_livepatch_[apply,revert]_jmp"
 - Commited two patches which were Acked/Reviewed-by.
Since v5:[https://lists.xen.org/archives/html/xen-devel/2016-09/msg01114.html]
 - Acted on the review comments.
 - Replaced "livepatch/docs: Document .bss not being cleared, and .data 
potentially 
   having changed values" with "livepatch: Disallow applying after an revert"
 - Added two minor fixes to the test-cases (one of them was part of the ARM32/64
   livepatch support).
Since v4: 
[https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg02705.html]
 - Committed Acked/Reviewed patches.
 - Discarded couple of patches to address later.

Since v3: [https://lists.xen.org/archives/html/xen-devel/2016-08/msg01825.html]
 - Acked on reviews
v2, v1:
 - Left over fixes and features that didn't get quite done in 4.7

Included are:
 - Bug-fixes
 - NOP patching
 - Hooks

The legend is:

 r - Reviewed-by
 a - Acked-by

   livepatch: Disallow applying after an revert
r  livepatch: Add limit of 2MB to payload .bss sections.
   livepatch: NOP if func->new_addr is zero.
   livepatch: Drop _jmp from
r  livepach: Add .livepatch.hooks functions and test-case


Thanks!

The git tree is

 git://xenbits.xen.org/people/konradwilk/xen.git livepatch.v4.8.v7

contains all the following patches (and more):

 MAINTAINERS |  1 +
 docs/misc/livepatch.markdown| 52 ++--
 xen/arch/arm/livepatch.c|  4 +-
 xen/arch/x86/alternative.c  |  2 +-
 xen/arch/x86/livepatch.c| 52 +---
 xen/arch/x86/test/xen_hello_world.c | 34 +
 xen/common/livepatch.c  | 95 +
 xen/common/livepatch_elf.c  |  7 ++-
 xen/include/asm-x86/alternative.h   |  1 +
 xen/include/asm-x86/livepatch.h | 21 
 xen/include/xen/livepatch.h | 16 ++-
 xen/include/xen/livepatch_payload.h | 49 +++
 12 files changed, 298 insertions(+), 36 deletions(-)

Konrad Rzeszutek Wilk (4):
  livepatch: Disallow applying after an revert
  livepatch: Add limit of 2MB to payload .bss sections.
  livepatch: NOP if func->new_addr is zero.
  livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp

Ross Lagerwall (1):
  livepach: Add .livepatch.hooks functions and test-case


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

[Xen-devel] [PATCH v7 2/5] livepatch: Add limit of 2MB to payload .bss sections.

[Konrad Rzeszutek Wilk]

The initial patch: 11ff40fa7bb5fdcc69a58d0fec49c904ffca4793
"xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op" caps the
size of the binary at 2MB. We follow that in capping the size
of the .BSSes to be at maximum 2MB.

We also bubble up the payload limit and this one in one #define
called LIVEPATCH_MAX_SIZE to make it easier to find these
arbitrary limits.

Reviewed-by: Ross Lagerwall 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ross Lagerwall 
Cc: Jan Beulich 

v5: Initial submission. Came about from conversation about
"livepatch: Clear .bss when payload is reverted"
   - Use only one sh_flags comparison instead of two.
   - And check for the _right_ combination (WA).
v6: Remove the logging
   - Move the MB(2) to a #define in the header file.
   - Add the newline after the addition in livepatch_elf.c.
   - Added Reviewed-by from Ross.
v7:- s/MAX_BSS_SIZE/LIVEPATCH_MAX_SIZE/
   - Also use this LIVEPATHCH_MAX_SIZE in verify_payload
---
 xen/common/livepatch.c  | 2 +-
 xen/common/livepatch_elf.c  | 4 
 xen/include/xen/livepatch.h | 2 ++
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 1f527a3..c9e5318 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -123,7 +123,7 @@ static int verify_payload(const 
xen_sysctl_livepatch_upload_t *upload, char *n)
 if ( !upload->size )
 return -EINVAL;
 
-if ( upload->size > MB(2) )
+if ( upload->size > LIVEPATCH_MAX_SIZE )
 return -EINVAL;
 
 if ( !guest_handle_okay(upload->payload, upload->size) )
diff --git a/xen/common/livepatch_elf.c b/xen/common/livepatch_elf.c
index 303115f..f46990e 100644
--- a/xen/common/livepatch_elf.c
+++ b/xen/common/livepatch_elf.c
@@ -86,6 +86,10 @@ static int elf_resolve_sections(struct livepatch_elf *elf, 
const void *data)
 delta < sizeof(Elf_Ehdr) ? "at ELF header" : "is past 
end");
 return -EINVAL;
 }
+else if ( (sec[i].sec->sh_flags & (SHF_WRITE | SHF_ALLOC)) &&
+  sec[i].sec->sh_type == SHT_NOBITS &&
+  sec[i].sec->sh_size > LIVEPATCH_MAX_SIZE )
+return -EINVAL;
 
 sec[i].data = data + delta;
 /* Name is populated in elf_resolve_section_names. */
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 243e240..29c9b31 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -30,6 +30,8 @@ struct xen_sysctl_livepatch_op;
 #define ELF_LIVEPATCH_FUNC".livepatch.funcs"
 #define ELF_LIVEPATCH_DEPENDS ".livepatch.depends"
 #define ELF_BUILD_ID_NOTE  ".note.gnu.build-id"
+/* Arbitrary limit for payload size and .bss section size. */
+#define LIVEPATCH_MAX_SIZE MB(2)
 
 struct livepatch_symbol {
 const char *name;
-- 
2.4.11


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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Boris Ostrovsky]

On 09/21/2016 12:13 PM, Ian Jackson wrote:
> Platform Team regression test user writes ("[xen-4.5-testing baseline-only 
> test] 67737: regressions - FAIL"):
>> test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
>> test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 
>> 67706
> Several of these, 32bit and 64bit HVM.  This is in the Citrix
> Cambridge osstest instance.  The Xen Project colo instance is
> unaffected (flight 101045 there passed with the same revisions of
> everything)
>
> This is with:
>
>   xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
>   xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
>   linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
>   linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860

I can't get these commits neither for Xen nor for Linux. Are these from
Citrix trees?

>
> The log says this:
>
>   2016-09-21 06:07:36 Z -- substep 19 xtf/test-hvm32-invlpg~shadow 
> running -- 
>   2016-09-21 06:07:36 Z executing ssh ... root@10.80.228.78 
> /home/xtf/xtf-runner -m logfile test-hvm32-invlpg~shadow 1>&2; echo $?
>
>   Using logfile '/var/log/xen/console/guest-test-hvm32-invlpg~shadow.log'
>   Executing 'xl create -F tests/invlpg/test-hvm32-invlpg~shadow.cfg'
>   --- Xen Test Framework ---
>   Environment: HVM 32bit (No paging)
>   Testing 'invlpg' in normally-faulting conditions
> Test: Mapped address
> Test: Unmapped address
> Test: NULL segment override
> Test: Past segment limit
>   Fail: Unexpected #GP[]
> Test: Before expand-down segment limit
>   Fail: Unexpected #GP[]
>   Test result: FAILURE
>
>   Combined test results:
>   test-hvm32-invlpg~shadow FAILURE
>
> Sadly we haven't yet managed to make the logs from this instance
> public.

I looked at the logs you posted but I can't find guest config file. Are
they part of the logs?

>
> Do you have any idea what might be causing this ?  Is there a real
> problem with the Xen 4.5 branch ?  The Citrix Cambridge instance has
> old hardware.

We run 4.5 every week or so here but we don't run without HAP (which,
based on the name, I assume is what this guest is).

I'll give it a try.

-boris

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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/21/2016 12:02 PM, Jan Beulich wrote:
 On 21.09.16 at 17:34,  wrote:
>> On 09/21/2016 11:16 AM, Jan Beulich wrote:
>> On 21.09.16 at 17:09,  wrote:
 On 09/21/2016 07:33 AM, Jan Beulich wrote:
 On 20.09.16 at 02:19,  wrote:
>> --- a/tools/libacpi/build.c
>> +++ b/tools/libacpi/build.c
>> @@ -20,6 +20,7 @@
>>  #include "ssdt_s4.h"
>>  #include "ssdt_tpm.h"
>>  #include "ssdt_pm.h"
>> +#include 
> ... I don't really see why this becomes necessary here. Please
> clarify.
 xen/hvm/hvm_info_table.h in included by hvmloader/util.h so we haven't
 needed this include until now.
>>> But you're not removing any inclusion here. Does that addition
>>> perhaps belong elsewhere?
>> I suppose I can add it to libxl_x86_acpi.h (and remove from
>> libxl_x86_acpi.c) to be consistent with how it is included by util.h
> That doesn't answer my question (by "elsewhere" I meant
> another, earlier patch). By the time stuff got moved to tools/
> you can't possibly rely on util.h inclusion here anymore.

Patch 11 ("acpi/hvmloader: Include file/paths adjustments") may be a
better place to make this change.

I don't understand though why we can't rely on util.h after the move.
hvmloader will continue including it via
-DLIBACPI_STDUTILS=\"$(CURDIR)/util.h. At that point (and until this
patch) hvmloader is the only user of libacpi and including
hvm_info_table.h via util.h works fine (but, as I said in the previous
message, is not logical).

-boris



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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Konrad Rzeszutek Wilk]

On Wed, Sep 21, 2016 at 10:04:21AM -0600, Jan Beulich wrote:
> >>> On 21.09.16 at 17:59,  wrote:
> > The fix can be done two ways:
> >  a) See if xen.efi.map exists and then copy it
> >  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
> > against xen).
> > 
> > The patch chooses the latter.
> 
> Well, if the ARM maintainers like that ... I don't really see a point in
> installing the same file twice without its second incarnation having a
> specific purpose.

I also have the a) part ready, which is simple:


diff --git a/xen/Makefile b/xen/Makefile
index e989a20..678f188 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -67,7 +67,9 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
$(INSTALL_DATA) $(TARGET).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
-   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
+if [ -e $(TARGET).efi.map ]; then \
+   $(INSTALL_DATA) $(TARGET).efi.map 
$(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
+fi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).$(XEN_SUBVERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi 
$(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi; \
ln -sf $(T)-$(XEN_FULLVERSION).efi $(D)$(EFI_DIR)/$(T).efi; \

Either fix works.

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

Re: [Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Ian Jackson]

Ian Jackson writes ("Problem with Xen 4.5 failing XTF tests on old AMD cpus ?"):
> Sadly we haven't yet managed to make the logs from this instance
> public.

I have copied the logs from this one test job to here:

  http://xenbits.xen.org/people/iwj/2016/67737/test-xtf-amd64-amd64-1/info.html

Ian.

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

[Xen-devel] Problem with Xen 4.5 failing XTF tests on old AMD cpus ?

[Ian Jackson]

Platform Team regression test user writes ("[xen-4.5-testing baseline-only 
test] 67737: regressions - FAIL"):
> test-xtf-amd64-amd64-1 19 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
> test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706

Several of these, 32bit and 64bit HVM.  This is in the Citrix
Cambridge osstest instance.  The Xen Project colo instance is
unaffected (flight 101045 there passed with the same revisions of
everything)

This is with:

  xen e4ae4b03d35babc9624b7286f1ea4c6749bad84b
  xtf b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
  linux b65f2f457c49b2cfd7967c34b7a0b04c25587f13
  linux-firmware c530a75c1e6a472b0eb9558310b518f0dfcd8860

The log says this:

  2016-09-21 06:07:36 Z -- substep 19 xtf/test-hvm32-invlpg~shadow 
running -- 
  2016-09-21 06:07:36 Z executing ssh ... root@10.80.228.78 
/home/xtf/xtf-runner -m logfile test-hvm32-invlpg~shadow 1>&2; echo $?

  Using logfile '/var/log/xen/console/guest-test-hvm32-invlpg~shadow.log'
  Executing 'xl create -F tests/invlpg/test-hvm32-invlpg~shadow.cfg'
  --- Xen Test Framework ---
  Environment: HVM 32bit (No paging)
  Testing 'invlpg' in normally-faulting conditions
Test: Mapped address
Test: Unmapped address
Test: NULL segment override
Test: Past segment limit
  Fail: Unexpected #GP[]
Test: Before expand-down segment limit
  Fail: Unexpected #GP[]
  Test result: FAILURE

  Combined test results:
  test-hvm32-invlpg~shadow FAILURE

Sadly we haven't yet managed to make the logs from this instance
public.

Do you have any idea what might be causing this ?  Is there a real
problem with the Xen 4.5 branch ?  The Citrix Cambridge instance has
old hardware.

Ian.

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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Jan Beulich]

>>> On 21.09.16 at 17:59,  wrote:
> The fix can be done two ways:
>  a) See if xen.efi.map exists and then copy it
>  b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
> against xen).
> 
> The patch chooses the latter.

Well, if the ARM maintainers like that ... I don't really see a point in
installing the same file twice without its second incarnation having a
specific purpose.

Jan


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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Jan Beulich]

>>> On 21.09.16 at 17:34,  wrote:
> On 09/21/2016 11:16 AM, Jan Beulich wrote:
> On 21.09.16 at 17:09,  wrote:
>>> On 09/21/2016 07:33 AM, Jan Beulich wrote:
>>> On 20.09.16 at 02:19,  wrote:
> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -20,6 +20,7 @@
>  #include "ssdt_s4.h"
>  #include "ssdt_tpm.h"
>  #include "ssdt_pm.h"
> +#include 
 ... I don't really see why this becomes necessary here. Please
 clarify.
>>> xen/hvm/hvm_info_table.h in included by hvmloader/util.h so we haven't
>>> needed this include until now.
>> But you're not removing any inclusion here. Does that addition
>> perhaps belong elsewhere?
> 
> I suppose I can add it to libxl_x86_acpi.h (and remove from
> libxl_x86_acpi.c) to be consistent with how it is included by util.h

That doesn't answer my question (by "elsewhere" I meant
another, earlier patch). By the time stuff got moved to tools/
you can't possibly rely on util.h inclusion here anymore.

Jan


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

Re: [Xen-devel] [PATCH] fix EFI part of "symbols: Generate an xen-sym.map"

[Konrad Rzeszutek Wilk]

On Tue, Sep 20, 2016 at 08:22:01AM -0600, Jan Beulich wrote:
> >>> On 08.09.16 at 18:21,  wrote:
> > On Thu, Sep 08, 2016 at 06:45:36AM -0600, Jan Beulich wrote:
> >> Commit 6ea24e53f1 introduced two problems: It left out a semicolon and
> >> typo-ed the source file name of the EFI map file install command.
> > 
> >  I really need Fedora to start building ld with PE support.
> >> 
> >> Signed-off-by: Jan Beulich 
> > 
> > Reviewed-by: Konrad Rzeszutek Wilk 
> >> 
> >> --- a/xen/Makefile
> >> +++ b/xen/Makefile
> >> @@ -67,7 +67,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_
> >>if [ -r $(TARGET).efi -a -n '$(EFI_DIR)' ]; then \
> >>[ -d $(D)$(EFI_DIR) ] || $(INSTALL_DIR) $(D)$(EFI_DIR); \
> >>$(INSTALL_DATA) $(TARGET).efi 
> >> $(D)$(EFI_DIR)/$(T)-$(XEN_FULLVERSION).efi; \
> >> -  $(INSTALL_DATA) $(TARGET)-efi.map 
> >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map \
> >> +  $(INSTALL_DATA) $(TARGET).efi.map 
> >> $(D)$(DEBUG_DIR)/$(T)-$(XEN_FULLVERSION).efi.map; \
> 
> Sadly this has further fallout: The file being installed here does not
> exist in an ARM64 build. Can you please invent a fix for that?


From 24f37051126f04de42dee5cff24b8c05541db2d8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 21 Sep 2016 11:39:44 -0400
Subject: [PATCH] Makefile: fix (again) EFI part of "symbols: Generate an
 xen-sym.map

This is a follow-up to commit d14fffcc6a7c054db9e337026a3c850152244ac4
"fix EFI part of "symbols: Generate an xen-sym.map" which fixed most of
the issues.

However we still have an issue - The file being installed (xen.efi.map)
does not exist in an ARM64 build (the xen.efi is linked againts xen).

The fix can be done two ways:
 a) See if xen.efi.map exists and then copy it
 b) Or link xen.efi.map to xen-syms.map (similar to how xen.efi is linked
against xen).

The patch chooses the latter.

Reported-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Julien Grall 
Cc: Stefano Stabellini 
---
 xen/arch/arm/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 1d9051c..09a3518 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -72,6 +72,7 @@ $(TARGET): $(TARGET)-syms $(TARGET).axf
$(OBJCOPY) -O binary -S $< $@
 ifeq ($(CONFIG_ARM_64),y)
ln -sf $(notdir $@)  ../../$(notdir $@).efi
+   ln -sf $(notdir $@)-syms.map  ../../$(notdir $@).efi.map
 endif
 
 $(TARGET).axf: $(TARGET)-syms
-- 
2.4.11

> 
> Thanks, Jan
> 

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

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

[osstest service owner]

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

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  424fdc67e90baf543650be2f88e0894afb25494b
baseline version:
 xen  a9c9600bb5b2f79058ce24f0ef51f22c78e89ba1

Last test of basis   101056  2016-09-20 18:03:25 Z0 days
Testing same since   101080  2016-09-21 14:07:51 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Razvan Cojocaru 

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=424fdc67e90baf543650be2f88e0894afb25494b
+ . ./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 
424fdc67e90baf543650be2f88e0894afb25494b
+ branch=xen-unstable-smoke
+ revision=424fdc67e90baf543650be2f88e0894afb25494b
+ . ./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
+ '[' x424fdc67e90baf543650be2f88e0894afb25494b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Wed, 2016-09-21 at 14:06 +0100, Julien Grall wrote:
> (CC a couple of ARM folks)
> 
Yay, thanks for this! :-)

> I had few discussions and  more thought about big.LITTLE support in
> Xen. 
> The main goal of big.LITTLE is power efficiency by moving task
> around 
> and been able to idle one cluster. All the solutions suggested 
> (including mine) so far, can be replicated by hand (except the VPIDR)
> so 
> they are mostly an automatic way. 
>
I'm sorry, how is this (going to be) handled in Linux? Is it that any
arbitrary task executing any arbitrary binary code can be run on both
big and LITTLE pcpus, depending on the scheduler's and energy
management's decisions?

This does not seem to match with what has been said at some point in
this thread... And if it's like that, how's that possible, if the
pcpus' ISAs are (even only slightly) different?

> This will also remove the real 
> benefits of big.LITTLE because Xen will not be able to migrate vCPU 
> across cluster for power efficiency.
> 
> If we care about power efficiency, we would have to handle
> seamlessly 
> big.LITTLE in Xen (i.e a guess would only see a kind of CPU). 
>
Well, I'm a big fan of an approach that leaves the guests' scheduler
dumb about things like these (i.e., load balancing, energy efficiency,
etc), and hence puts Xen in charge. In fact, on a Xen system, it is
only Xen that has all the info necessary to make wise decisions (e.g.,
the load of the _whole_ host, the effect of any decisions on the
_whole_ host, etc).

But this case may be a LITTLE.bit ( :-PP ) different.

Anyway, I guess I'll way your reply to my question above before
commenting more.

> This arise 
> quite few problem, nothing insurmountable, similar to migration
> across 
> two platforms with different micro-architecture (e.g processors): 
> errata, features supported... The guest would have to know the union
> of 
> all the errata (this is done so far via the MIDR, so we would a PV
> way 
> to do it), and only the intersection of features would be exposed to
> the 
> guest. This also means the scheduler would have to be modified to
> handle 
> power efficiency (not strictly necessary at the beginning).
> 
> I agree that a such solution would require some work to implement, 
> although Xen will have a better control of the energy consumption of
> the 
> platform.
> 
> So the question here, is what do we want to achieve with big.LITTLE?
> 
Just thinking out loud here. So, instead of "just", as George
suggested:

 vcpuclass=["0-1:A35","2-5:A53", "6-7:A72"]

we can allow something like the following (note that I'm tossing out
random numbers next to the 'A's):

 vcpuclass = ["0-1:A35", "2-5:A53,A17", "6-7:A72,A24,A31", "12-13:A8"]

with the following meaning:
 - vcpus 0, 1 can only run on pcpus of class A35
 - vcpus 2,3,4,5 can run on pcpus of class A53 _and_ on pcpus of class 
   A17
 - vcpus 6,7 can run on pcpus of class A72, A24, A31
 - vcpus 8,9,10,11 --since they're not mentioned, can run on pcpus of 
   any class
 - vcpus 12,13 can only run on pcpus of class A8

This will set the "boundaries", for each vcpu. Then, within these
boundaries, once in the (Xen's) scheduler, we can implement whatever
complex/magic/silly logic we want, e.g.:
 - only use a pcpu of class A53 for vcpus that have an average load 
   above 50%
 - only use a pcpu of class A31 if there are no idle pcpus of class A24
 - only use a pcpu of class A17 for a vcpu if the total system load 
   divided by the vcpu ID give 42 as result
 - whatever

This allows us to achieve both the following goals:
 - allow Xen to take smart decisions, considering the load and the 
   efficiency of the host as a whole
 - allow the guest to take smart decisions, like running lightweight 
   tasks on low power vcpus (which then Xen will run on low 
   power pcpus, at least on a properly configured system)

Of course this **requires** that, for instance, vcpu 6 must be able to
run on A72, A24 and A31 just fine, i.e., it must be possible for it to
block on I/O when executing on an A72 pcpu, and, later, after wakeup,
restart executing on an A24 pcpu.

If that is not possible, and doing such vcpu movement, instead than
just calling schedule.c:vcpu_migrate() (or equivalent), requires some
more complex fiddling, involving local migration --or alike--
techniques, then I honestly don't think this is something that can be
solved at the scheduler level anyway... :-O

> [1] https://lwn.net/Articles/699569/
> 
I tried to have a quick look, but I don't have the time right now, and
firthermore, it's all about ARM, and I still speak too few ARM for
properly understanding what's going on... :-(

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

signature.asc
Description: This is a digitally signed message part
___

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/21/2016 11:16 AM, Jan Beulich wrote:
 On 21.09.16 at 17:09,  wrote:
>> On 09/21/2016 07:33 AM, Jan Beulich wrote:
>> On 20.09.16 at 02:19,  wrote:
 --- a/tools/libacpi/build.c
 +++ b/tools/libacpi/build.c
 @@ -20,6 +20,7 @@
  #include "ssdt_s4.h"
  #include "ssdt_tpm.h"
  #include "ssdt_pm.h"
 +#include 
>>> ... I don't really see why this becomes necessary here. Please
>>> clarify.
>> xen/hvm/hvm_info_table.h in included by hvmloader/util.h so we haven't
>> needed this include until now.
> But you're not removing any inclusion here. Does that addition
> perhaps belong elsewhere?

I suppose I can add it to libxl_x86_acpi.h (and remove from
libxl_x86_acpi.c) to be consistent with how it is included by util.h

OTOH, include files that we pass as
-DLIBACPI_STDUTILS=\"$(CURDIR)/ are intended to provide
declarations for things that are specific to the caller, not to Xen in
general.

-boris


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

Re: [Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

[Konrad Rzeszutek Wilk]

On Wed, Sep 21, 2016 at 03:52:12PM +0100, Julien Grall wrote:
> The invalidation of the instructions cache requires barriers to ensure
> the completion of the invalidation before continuing (see B2.3.4 in ARM
> DDI 0487A.j).
> 
> This was overlooked in commit fb9d877 "xen/arm64: Add an helper to
> invalidate all instruction caches".
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Konrad Rzeszutek Wilk 

[by reading the docs]

> ---
>  xen/include/asm-arm/arm64/page.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/include/asm-arm/arm64/page.h 
> b/xen/include/asm-arm/arm64/page.h
> index 79ef7bd..23d7781 100644
> --- a/xen/include/asm-arm/arm64/page.h
> +++ b/xen/include/asm-arm/arm64/page.h
> @@ -33,6 +33,8 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
>  static inline void invalidate_icache(void)
>  {
>  asm volatile ("ic ialluis");
> +dsb(ish);   /* Ensure completion of the flush I-cache */
> +isb();
>  }
>  
>  /*
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 9:23 AM, Jan Beulich  wrote:
 On 21.09.16 at 17:16,  wrote:
>> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
>>  wrote:
>>> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich  wrote:
>>> On 21.09.16 at 16:18,  wrote:
> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
> On 20.09.16 at 19:29,  wrote:
>>> I'm trying to figure out the design decision regarding the handling of
>>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
>>> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
>>> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
>>> TLB utilization point-of-view this seems to be rather wasteful.
>>> Furthermore, it even breaks the guests' ability to take advantage of
>>> PCID, as the TLB just guts flushed when a new process is scheduled.
>>> Does anyone have an insight into what was the rationale behind this?
>>
>> Since you don't quote the specific commit(s), I would guess that
>> this was mainly an attempt by the author(s) to keep things simple
>> for themselves, i.e. not having to properly think through under
>> which conditions less than a full TLB flush would suffice.
>
> The commit that added VPID and the TLB flush is
> e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
> (Virtual Processor Identification). So this has been there as long as
> Xen supported VPID. The only case where flushing the TLB on a guest
> MOV-TO-CR3 that possibly would make sense to me is if we are running a
> PV guest. But this is hvm/vmx, so why would we care about what the
> guest does to its cr3 from a TLB standpoint?

 Are you forgetting that a move to CR3 needs to flush all non-global
 TLB entries? Or else, why do you think no flushing needs to happen
 at all?

>>>
>>> The guest can mark entries as global or non-global but it will have no
>>> affect on VPID, every translation is still going to be tagged by VPID
>>> when the translation was triggered in guest-context. So why does Xen
>>> need to jump in flush the TLB when the guest OS likely already done
>>> so?
>
> Likely? We can't base anything on likelihood (the more that no matter
> what flushing may have been done before the CR3 write, further
> flushing may be necessary and mustn't be skipped). We need to
> provide architecturally correct behavior, and that includes the flushing
> of non-global entries. This doesn't mean we need to flush anything
> ourselves, but we have to make previously created non-global TLB
> entries unavailable.

What I'm saying is that the guest OS should be in charge of managing
its own TLB when VPID is in use. Whether it does flush the TLB or not
is not of our concern. If it's a sane OS it will likely flush when it
needs to, but we should not be jumping in and doing it as we do right
now. We are actually breaking the architectural behavior by forcing a
flush, MOV-TO-CR3 doesn't by itself flush the TLB on real hardware.
Also, there are no non-global TLB entries we need to flush as long as
we are using VPID. Any translation used by Xen or by any other domain
will have a different VPID, so there is no chance of stale TLB entries
being an issue.

Tamas

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

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object 
files directly"):
> On 09/21/2016 11:05 AM, Ian Jackson wrote:
> > Wait, the libxl makefiles are going to end up running iasl ?
> 
> Not directly. There is a new target in libxl's Makefile:
> 
> acpi:
> $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)
> 
> (ACPI_PATH is tools/libacpi)

Right.

> > If you end up making these files appear elsewhere then I think ".tmp"
> > is fine if the first part of the filename is unique enough.
> 
> They are built in libxl directory, this is by design. If we were to
> build them in tools/libacpi then we may collide with other components
> (such as hvmloader) doing the build at the same time.

I see.  Yes, this is a good approach.

> Keeping them in /tmp/`mktemp -d`, for example, does not quite work since
> we can't easily clean this up in case of an interrupt. (I tried this in
> an earlier version and it doesn't look good).

What you have now is better.

> But the names are pretty unique (dsdt_ or ).

That's good.

Thanks,
Ian.

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Jan Beulich]

>>> On 21.09.16 at 17:16,  wrote:
> On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
>  wrote:
>> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich  wrote:
>> On 21.09.16 at 16:18,  wrote:
 On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
 On 20.09.16 at 19:29,  wrote:
>> I'm trying to figure out the design decision regarding the handling of
>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
>> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
>> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
>> TLB utilization point-of-view this seems to be rather wasteful.
>> Furthermore, it even breaks the guests' ability to take advantage of
>> PCID, as the TLB just guts flushed when a new process is scheduled.
>> Does anyone have an insight into what was the rationale behind this?
>
> Since you don't quote the specific commit(s), I would guess that
> this was mainly an attempt by the author(s) to keep things simple
> for themselves, i.e. not having to properly think through under
> which conditions less than a full TLB flush would suffice.

 The commit that added VPID and the TLB flush is
 e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
 (Virtual Processor Identification). So this has been there as long as
 Xen supported VPID. The only case where flushing the TLB on a guest
 MOV-TO-CR3 that possibly would make sense to me is if we are running a
 PV guest. But this is hvm/vmx, so why would we care about what the
 guest does to its cr3 from a TLB standpoint?
>>>
>>> Are you forgetting that a move to CR3 needs to flush all non-global
>>> TLB entries? Or else, why do you think no flushing needs to happen
>>> at all?
>>>
>>
>> The guest can mark entries as global or non-global but it will have no
>> affect on VPID, every translation is still going to be tagged by VPID
>> when the translation was triggered in guest-context. So why does Xen
>> need to jump in flush the TLB when the guest OS likely already done
>> so?

Likely? We can't base anything on likelihood (the more that no matter
what flushing may have been done before the CR3 write, further
flushing may be necessary and mustn't be skipped). We need to
provide architecturally correct behavior, and that includes the flushing
of non-global entries. This doesn't mean we need to flush anything
ourselves, but we have to make previously created non-global TLB
entries unavailable.

>> It will render the guest OS's use of PCID optimization useless.
>> But even if the guest OS didn't flush - for whatever strange reason -
>> it would have no effect on anything else outside the guest context, so
>> Xen jumping in and doing this flush is unwarranted AFAICT.
> 
> Also, Xen flushing on every MOV-TO-CR3 effectively disables the use of
> global TLB entries in the guest as well. So both global TLB entries
> and TLB entries tagged with PCID are disabled with this flush in
> place. That seems to be a bad idea from a performance perspective..

I didn't say what gets done right now looks to be optimal.

Jan


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

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

On 09/21/2016 11:05 AM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI 
> object files directly"):
>> 2. ".tmp__" vs ".tmp": Because the temporary files are generated not in
>> tools/libacpi but in the directory of the libacpi user (such as libxl)
>> it is possible that a Makefile there might use ".tmp' for its own
>> purposes so I am trying here to minimize chances of a conflict. Maybe
>> even ".tmp_acpi"?
> Wait, the libxl makefiles are going to end up running iasl ?

Not directly. There is a new target in libxl's Makefile:

acpi:
$(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(CURDIR)

(ACPI_PATH is tools/libacpi)

>
> If you end up making these files appear elsewhere then I think ".tmp"
> is fine if the first part of the filename is unique enough.

They are built in libxl directory, this is by design. If we were to
build them in tools/libacpi then we may collide with other components
(such as hvmloader) doing the build at the same time.

Keeping them in /tmp/`mktemp -d`, for example, does not quite work since
we can't easily clean this up in case of an interrupt. (I tried this in
an earlier version and it doesn't look good).

But the names are pretty unique (dsdt_ or ).

-boris


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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Jan Beulich]

>>> On 21.09.16 at 17:09,  wrote:
> On 09/21/2016 07:33 AM, Jan Beulich wrote:
> On 20.09.16 at 02:19,  wrote:
>>> --- a/tools/libacpi/build.c
>>> +++ b/tools/libacpi/build.c
>>> @@ -20,6 +20,7 @@
>>>  #include "ssdt_s4.h"
>>>  #include "ssdt_tpm.h"
>>>  #include "ssdt_pm.h"
>>> +#include 
>> ... I don't really see why this becomes necessary here. Please
>> clarify.
> 
> xen/hvm/hvm_info_table.h in included by hvmloader/util.h so we haven't
> needed this include until now.

But you're not removing any inclusion here. Does that addition
perhaps belong elsewhere?

Jan


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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 9:09 AM, Tamas K Lengyel
 wrote:
> On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich  wrote:
> On 21.09.16 at 16:18,  wrote:
>>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
>>> On 20.09.16 at 19:29,  wrote:
> I'm trying to figure out the design decision regarding the handling of
> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
> TLB utilization point-of-view this seems to be rather wasteful.
> Furthermore, it even breaks the guests' ability to take advantage of
> PCID, as the TLB just guts flushed when a new process is scheduled.
> Does anyone have an insight into what was the rationale behind this?

 Since you don't quote the specific commit(s), I would guess that
 this was mainly an attempt by the author(s) to keep things simple
 for themselves, i.e. not having to properly think through under
 which conditions less than a full TLB flush would suffice.
>>>
>>> The commit that added VPID and the TLB flush is
>>> e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
>>> (Virtual Processor Identification). So this has been there as long as
>>> Xen supported VPID. The only case where flushing the TLB on a guest
>>> MOV-TO-CR3 that possibly would make sense to me is if we are running a
>>> PV guest. But this is hvm/vmx, so why would we care about what the
>>> guest does to its cr3 from a TLB standpoint?
>>
>> Are you forgetting that a move to CR3 needs to flush all non-global
>> TLB entries? Or else, why do you think no flushing needs to happen
>> at all?
>>
>
> The guest can mark entries as global or non-global but it will have no
> affect on VPID, every translation is still going to be tagged by VPID
> when the translation was triggered in guest-context. So why does Xen
> need to jump in flush the TLB when the guest OS likely already done
> so? It will render the guest OS's use of PCID optimization useless.
> But even if the guest OS didn't flush - for whatever strange reason -
> it would have no effect on anything else outside the guest context, so
> Xen jumping in and doing this flush is unwarranted AFAICT.
>

Also, Xen flushing on every MOV-TO-CR3 effectively disables the use of
global TLB entries in the guest as well. So both global TLB entries
and TLB entries tagged with PCID are disabled with this flush in
place. That seems to be a bad idea from a performance perspective..

Tamas

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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 8:44 AM, Jan Beulich  wrote:
 On 21.09.16 at 16:18,  wrote:
>> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
>> On 20.09.16 at 19:29,  wrote:
 I'm trying to figure out the design decision regarding the handling of
 guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
 VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
 (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
 hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
 TLB utilization point-of-view this seems to be rather wasteful.
 Furthermore, it even breaks the guests' ability to take advantage of
 PCID, as the TLB just guts flushed when a new process is scheduled.
 Does anyone have an insight into what was the rationale behind this?
>>>
>>> Since you don't quote the specific commit(s), I would guess that
>>> this was mainly an attempt by the author(s) to keep things simple
>>> for themselves, i.e. not having to properly think through under
>>> which conditions less than a full TLB flush would suffice.
>>
>> The commit that added VPID and the TLB flush is
>> e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
>> (Virtual Processor Identification). So this has been there as long as
>> Xen supported VPID. The only case where flushing the TLB on a guest
>> MOV-TO-CR3 that possibly would make sense to me is if we are running a
>> PV guest. But this is hvm/vmx, so why would we care about what the
>> guest does to its cr3 from a TLB standpoint?
>
> Are you forgetting that a move to CR3 needs to flush all non-global
> TLB entries? Or else, why do you think no flushing needs to happen
> at all?
>

The guest can mark entries as global or non-global but it will have no
affect on VPID, every translation is still going to be tagged by VPID
when the translation was triggered in guest-context. So why does Xen
need to jump in flush the TLB when the guest OS likely already done
so? It will render the guest OS's use of PCID optimization useless.
But even if the guest OS didn't flush - for whatever strange reason -
it would have no effect on anything else outside the guest context, so
Xen jumping in and doing this flush is unwarranted AFAICT.

Tamas

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

Re: [Xen-devel] [PATCH v4 20/21] libxl/acpi: Build ACPI tables for HVMlite guests

[Boris Ostrovsky]

On 09/21/2016 07:33 AM, Jan Beulich wrote:
 On 20.09.16 at 02:19,  wrote:
>> Signed-off-by: Boris Ostrovsky 
> libacpi parts
> Acked-by: Jan Beulich 
> albeit ...
>
>
>> --- a/tools/libacpi/build.c
>> +++ b/tools/libacpi/build.c
>> @@ -20,6 +20,7 @@
>>  #include "ssdt_s4.h"
>>  #include "ssdt_tpm.h"
>>  #include "ssdt_pm.h"
>> +#include 
> ... I don't really see why this becomes necessary here. Please
> clarify.

xen/hvm/hvm_info_table.h in included by hvmloader/util.h so we haven't
needed this include until now.


-boris

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Wed, 2016-09-21 at 20:28 +0800, Peng Fan wrote:
> Use this in xl cfg file?
> vcpuclass=["0-1:A35","2-5:A53", "6-7:A72"] ?
> 
> I am not sure. If there are more kinds of CPUs, how to handle guest
> vcpus,
> as we discussed in this thread, we tend to support different classes
> of vcpu
> for guest. But if there are many kinds of physical CPUs, we also need
> to let
> guest have so many kinds of virtual cpus?
> 
We don't _need_ to necessarily do that, or not right now.

**However**, this is the main point of spending time designing things
and/or having the kind of conversation we're having here: i.e., if the
design, and the resulting implementation, is generic enough, we may get
that for free, which would be great.

This seems to me to be the case, if we go for George's "vcpuclass=[]"
suggesion, and, even better, it doesn't look like it would make the
code much more difficult to write or complex (wrt to just allowing
"vcpus_big" and "vcpus_little").

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

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

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Ian Jackson]

Boris Ostrovsky writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object 
files directly"):
> 2. ".tmp__" vs ".tmp": Because the temporary files are generated not in
> tools/libacpi but in the directory of the libacpi user (such as libxl)
> it is possible that a Makefile there might use ".tmp' for its own
> purposes so I am trying here to minimize chances of a conflict. Maybe
> even ".tmp_acpi"?

Wait, the libxl makefiles are going to end up running iasl ?

If you end up making these files appear elsewhere then I think ".tmp"
is fine if the first part of the filename is unique enough.

Ian.

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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

[Ian Jackson]

Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, re 
qemu depriv) [and 1 more messages]"):
> On 21.09.16 at 15:24,  wrote:
> > Would this be enough of an improvement, for you, to be worth the
> > additional type name clutter etc. ?
> 
> Again this looks like much clutter with little benefit to me, i.e. I'd
> then rather go with the unmodified original proposal. That's largely
> because nothing really enforces anyone to use the (disconnected)
> xen_dmop_foo_entry type. I.e. it continues to be a matter of the
> programmer's and the reviewers' attention/discipline.

Fair enough.

Thanks for your opinions.

Regards,
Ian.

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

Re: [Xen-devel] [RFC 0/5] xen/arm: support big.little SoC

[Dario Faggioli]

On Wed, 2016-09-21 at 10:22 +0100, George Dunlap wrote:
> On 21/09/16 09:38, Peng Fan wrote:
> > User may change the hard affinity of a vcpu, so we also need to
> > block a little
> > vcpu be scheduled to a big physical cpu. Add some checking code in
> > xen,
> > when chaning the hard affnity, check whether the cap of a vcpu is
> > compatible
> > with the cap of the physical cpus.
> 
Yes, restricting affinity changes would indeed will be necessary. Note
that this is not a limit of the 'pinning based' implementation. Even
if/when we'll have in-scheduler support, trying to pin a LITTLE vcpu to
a big pcpu should, AFAIUI, will have to fail.

I was thinking to some parameter, that we can set from xl (applicable also on 
non-big.LITTLE or non-heterogeneous configurations), for askting Xen to make 
the hard-affinity 'immutable'. That would be rather simple to do.

But I like Peng's idea of validating hard-affinity against the class even 
better! :-)

> Dario, what do we do with vNUMA / soft affinity?
> 
We do nothing actually. I mean, for now, we just accept whatever the
user asks, which might well be setting soft, or even hard, affinity of
all the domain to a set of nodes when the domain itself does not have
any memory.

This is actually another case where either immutability or restriction
of the changes that we allow to the (soft, in this case) affinity would
be useful. I'd always liked to introduce the logic that at least would
print a warning is something that looks really bad is being done, but
never got down to actually do that.

Maybe this will be the chance to improve wrt to this too! :-)

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

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 67724
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 67724

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

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

version targeted for testing:
 xen  f1446de4ba5218a58fa2486ebe090495e0fb05c4
baseline version:
 xen  6559a686ae77bca2539d826120c9f3bd0d75cdf8

Last test of basis67724  2016-09-17 01:14:01 Z4 days
Testing same since67736  2016-09-21 01:17:27 Z0 days1 attempts


People who touched revisions under test:
  

[Xen-devel] [for-4.8][PATCH] xen/arm64: Add missing synchronization barrier in invalidate_cache

[Julien Grall]

The invalidation of the instructions cache requires barriers to ensure
the completion of the invalidation before continuing (see B2.3.4 in ARM
DDI 0487A.j).

This was overlooked in commit fb9d877 "xen/arm64: Add an helper to
invalidate all instruction caches".

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

diff --git a/xen/include/asm-arm/arm64/page.h b/xen/include/asm-arm/arm64/page.h
index 79ef7bd..23d7781 100644
--- a/xen/include/asm-arm/arm64/page.h
+++ b/xen/include/asm-arm/arm64/page.h
@@ -33,6 +33,8 @@ static inline void write_pte(lpae_t *p, lpae_t pte)
 static inline void invalidate_icache(void)
 {
 asm volatile ("ic ialluis");
+dsb(ish);   /* Ensure completion of the flush I-cache */
+isb();
 }
 
 /*
-- 
1.9.1


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

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Jan Beulich]

>>> On 21.09.16 at 16:18,  wrote:
> On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
> On 20.09.16 at 19:29,  wrote:
>>> I'm trying to figure out the design decision regarding the handling of
>>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
>>> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
>>> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
>>> TLB utilization point-of-view this seems to be rather wasteful.
>>> Furthermore, it even breaks the guests' ability to take advantage of
>>> PCID, as the TLB just guts flushed when a new process is scheduled.
>>> Does anyone have an insight into what was the rationale behind this?
>>
>> Since you don't quote the specific commit(s), I would guess that
>> this was mainly an attempt by the author(s) to keep things simple
>> for themselves, i.e. not having to properly think through under
>> which conditions less than a full TLB flush would suffice.
> 
> The commit that added VPID and the TLB flush is
> e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
> (Virtual Processor Identification). So this has been there as long as
> Xen supported VPID. The only case where flushing the TLB on a guest
> MOV-TO-CR3 that possibly would make sense to me is if we are running a
> PV guest. But this is hvm/vmx, so why would we care about what the
> guest does to its cr3 from a TLB standpoint?

Are you forgetting that a move to CR3 needs to flush all non-global
TLB entries? Or else, why do you think no flushing needs to happen
at all?

Jan

> Wouldn't the guest OS
> need be in charge of that? With the TLBs being tagged there is no
> side-effect the guest can induce on any other domain whether it
> flushes its TLB or not.
> 
> Tamas




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

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Konrad Rzeszutek Wilk]

On Wed, Sep 21, 2016 at 10:23:09AM -0400, Chris Patterson wrote:
> On Wed, Sep 21, 2016 at 10:07 AM, Konrad Rzeszutek Wilk
>  wrote:
> > On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote:
> >> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu  wrote:
> >> > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
> >> >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
> >> >> > From: Chris Patterson 
> >> >> >
> >> >> > xs_watch() creates a thread to listen to xenstore events.  Currently, 
> >> >> > the
> >> >> > thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
> >> >> >
> >> >> > There have been several bug reports and workarounds related to the 
> >> >> > issue
> >> >> > where xs_watch() fails because its attempt to create the reader 
> >> >> > thread with
> >> >> > pthread_create() fails. This is due to insufficient stack space size
> >> >> > given the requirements for thread-local storage usage in the 
> >> >> > applications
> >> >> > and libraries that are linked against libxenstore.  [1,2,3,4].
> >> >> >
> >> >> > Specifying the stack size appears to have been added to reduce memory
> >> >> > footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
> >> >>
> >> >> Ugh. 8MB.
> >> >
> >> > OOI isn't that 8MB virtual memory, which means it shouldn't have real
> >> > impact unless it is used?
> >
> > /me nods. That is my recollection too. But it does mean that 'top'
> > shows the application as bigger (by 8MB).
> >
> >> >
> >>
> >> >From what I understand, that is correct.  At least in the Linux/glibc
> >> case, I believe the stack is allocated using anonymous mmap() and that
> >> resident memory usage shouldn't be greater than what you actually end
> >> up writing.  However, I do not know if this holds true universally...
> >
> > That should be faily easy to find out. One just needs to check
> > the RSS size. Not sure how to do that on FreeBSD thought..
> 
> I did validate that yesterday (using pmap -x ) and it appeared to
> hold true (for that case anyways).

Thank you for checking that.
> 
> If using the default stack size (as this patch reverts to), the stack
> size can be controlled with ulimit -s 

That should be part of the patch description and perhaps even in libxs.h
header.

Lets wait for Simon to chime in. It may be that he had some other reasons
to limit the stack size that weren't mentioned in the commit.


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

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Chris Patterson]

On Wed, Sep 21, 2016 at 10:07 AM, Konrad Rzeszutek Wilk
 wrote:
> On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote:
>> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu  wrote:
>> > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
>> >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
>> >> > From: Chris Patterson 
>> >> >
>> >> > xs_watch() creates a thread to listen to xenstore events.  Currently, 
>> >> > the
>> >> > thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
>> >> >
>> >> > There have been several bug reports and workarounds related to the issue
>> >> > where xs_watch() fails because its attempt to create the reader thread 
>> >> > with
>> >> > pthread_create() fails. This is due to insufficient stack space size
>> >> > given the requirements for thread-local storage usage in the 
>> >> > applications
>> >> > and libraries that are linked against libxenstore.  [1,2,3,4].
>> >> >
>> >> > Specifying the stack size appears to have been added to reduce memory
>> >> > footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
>> >>
>> >> Ugh. 8MB.
>> >
>> > OOI isn't that 8MB virtual memory, which means it shouldn't have real
>> > impact unless it is used?
>
> /me nods. That is my recollection too. But it does mean that 'top'
> shows the application as bigger (by 8MB).
>
>> >
>>
>> >From what I understand, that is correct.  At least in the Linux/glibc
>> case, I believe the stack is allocated using anonymous mmap() and that
>> resident memory usage shouldn't be greater than what you actually end
>> up writing.  However, I do not know if this holds true universally...
>
> That should be faily easy to find out. One just needs to check
> the RSS size. Not sure how to do that on FreeBSD thought..

I did validate that yesterday (using pmap -x ) and it appeared to
hold true (for that case anyways).

If using the default stack size (as this patch reverts to), the stack
size can be controlled with ulimit -s 

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

Re: [Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 3:03 AM, Jan Beulich  wrote:
 On 20.09.16 at 17:54,  wrote:
>> On Tue, Sep 20, 2016 at 9:39 AM, Jan Beulich  wrote:
>> On 20.09.16 at 17:14,  wrote:
 On Tue, Sep 20, 2016 at 9:12 AM, Jan Beulich  wrote:
 On 20.09.16 at 16:56,  wrote:
>> On Tue, Sep 20, 2016 at 1:26 AM, Jan Beulich  wrote:
>> On 19.09.16 at 20:27,  wrote:
 On Mon, Sep 19, 2016 at 2:19 AM, Jan Beulich  wrote:
 On 15.09.16 at 18:51,  wrote:
>> @@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct 
>> hvm_emulate_ctxt
 *hvmemul_ctxt,
>>  pfec |= PFEC_user_mode;
>>
>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && 
>> curr->arch.vm_event )
>> +{
>> +BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
>> + sizeof(curr->arch.vm_event->emul.insn));
>
> This should quite clearly be !=, and I think it builds only because 
> you
> use the wrong operand in the first sizeof().
>
>> +hvmemul_ctxt->insn_buf_bytes = 
>> sizeof(curr->arch.vm_event->emul.insn);
>> +memcpy(hvmemul_ctxt->insn_buf, 
>> >arch.vm_event->emul.insn,
>> +   hvmemul_ctxt->insn_buf_bytes);
>
> This memcpy()s between dissimilar types. Please omit the & and
> properly add .data on the second argument (and this .data
> addition should then also be mirrored in the BUILD_BUG_ON()).
>
>> +}
>> +else if ( !vio->mmio_insn_bytes )
>
> And then - I'm sorry for not having thought of this before - I think
> this would better not live here, or have an effect more explicitly
> only when coming here through hvm_emulate_one_vm_event().
> Since the former seems impractical, I think giving _hvm_emulate_one()
> one or two extra parameters would be the most straightforward
> approach.

 So this is the spot where the mmio insn buffer is getting copied as
 well instead of fetching the instructions from the guest memory. So
 having the vm_event buffer getting copied here too makes the most
 sense. Having the vm_event insn buffer getting copied in somewhere
 else, while the mmio insn buffer getting copied here, IMHO just
 fragments the flow even more making it harder to see what is actually
 happening.
>>>
>>> And I didn't unconditionally ask to move the copying elsewhere.
>>> The alternative - passing the override in as function argument(s),
>>> which would then be NULL/zero for all cases except the VM event
>>> one, would be as suitable. It is in particular ...
>>>
 How about adjusting the if-else here to be:

 if ( !vio->mmio_insn_bytes && !hvmemul_ctxt->set_context_insn  )
 ...
 else if ( vio->mmio_insn_bytes )
 ...
 else if ( unlikely(hvmemul_ctxt->set_context_insn) && 
 curr->arch.vm_event )
>>>
>>> ... this curr->arch.vm_event reference which I'd like to see gone
>>> from this specific code path. The ordering in your original patch,
>>> otoh, would then be fine (check for the override first with unlikely(),
>>> else do what is being done today). Such a code structure would
>>> then also ease a possible second way of overriding the insn by
>>> some other party, without having to touch the code here again.
>>
>> So that check is one that Razvan asked to be added. I think it is
>> necessary too as there seems to be a race-condition if vm_event gets
>> shutdown after the response flag is set but before this emulation path
>> takes place. Effectively set_context_insn may be set but the
>> arch.vm_event already gotten freed. Razvan, is that correct?
>
> Well, in case you misunderstood: I didn't ask for the check to be
> _removed_, but for it to be _moved elsewhere_.
>

 So as Razvan pointed out, there is a check already in hvm_do_resume
 for exactly the same effect, so then what you are asking for is
 already done.
>>>
>>> Partly - I really meant all curr->arch.vm_event uses to go away from
>>> that path. The other part (passing in the override buffer instead of
>>> special casing vm-event handling here) still would need to be done.
>>>
>>
>> I don't really follow what exactly you are looking for. You want the
>> buffer to be sent in as an input? We can do that but I mean the mmio
>> case doesn't do that 

Re: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault

[Kevin.Mayer]

Hi guys

I have found the problem (after hours and hours of gruesome
debugging with the almighty print) and it seems that this could potentially
have quite a bit of impact if altp2m is enabled for a guest domain (even if
the
functionality is never actively used), since destroying any vcpu of this
guest could lead to a hypervisor panic.
So a malicious user could simply destroy and restart his VM(s) in order to
DOS the VMs of other users by killing the hypervisor.
Granted, this is not very effective, but, depending on the environment, it
is extremely easy to implement.
The bug persists in Xen 4.7 and I do not that it was fixed in the current
master branch.

The following happens.
The call
void hvm_vcpu_destroy(struct vcpu *v)
{
hvm_all_ioreq_servers_remove_vcpu(v->domain, v);
if ( hvm_altp2m_supported() )
altp2m_vcpu_destroy(v);

at some time reaches vmx_vcpu_update_eptp which ends with a
vmx_vmcs_exit(v);.
There vmx_clear_vmcs(v); -> __vmx_clear_vmcs  is called where the
current_vmcs is invalidated if the current vmcs in the CPU is the same as
virt_to_maddr (v->arch.hvm_vmx->vmcs):

__vmpclear(virt_to_maddr(arch_vmx->vmcs)); (
http://www.tptp.cc/mirrors/siyobik.info/instruction/VMCLEAR.html )

To check this assumption I implemented a basic __vmptrst (
http://www.tptp.cc/mirrors/siyobik.info/instruction/VMPTRST.html ) and added
the result to the debug output.
(XEN) vmcs.c:519:IDLEv4 __vmx_clear_vmcs: realVMCS BEFORE __vmpclear
82415a000 
(XEN) vmcs.c:522:IDLEv4 __vmx_clear_vmcs: realVMCS AFTER __vmpclear


After that no vmcs_load / enter is executed so the vmcs in the CPU remains
invalidated.

For the next function in hvm_vcpu_destroy, the nestedhvm_vcpu_destroy(v) the
missing vmcs is no problem (at least in our use case), but the
free_compat_arg_xlat crashes.
The callstack is as follows:
hvm_vcpu_destroy
free_compat_arg_xlat
destroy_perdomain_mapping
map_domain_page
(probably inlined) mapcache_current_vcpu
sync_local_execstate
__sync_local_execstate
__context_switch
(with function pointer v->arch.ctxt_switch_from = vmx_ctxt_switch_from)
vmx_ctxt_switch_from 
(probably inlined) vmx_fpu_leave

There a vmwrite is tried if either ( !(v->arch.hvm_vmx.host_cr0 &
X86_CR0_TS) ) or ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) ) is true.
The executed vmwrite then crashes.
As my knowledge of Xen is not that comprehensive, could you tell me when the
TS-bits are set / cleared and what they are used for?

static void vmx_fpu_leave(struct vcpu *v)
{
ASSERT(!v->fpu_dirtied);
ASSERT(read_cr0() & X86_CR0_TS);

if ( !(v->arch.hvm_vmx.host_cr0 & X86_CR0_TS) )
{
v->arch.hvm_vmx.host_cr0 |= X86_CR0_TS;
__vmwrite(HOST_CR0, v->arch.hvm_vmx.host_cr0);
}

if ( !(v->arch.hvm_vcpu.guest_cr[0] & X86_CR0_TS) )
{
v->arch.hvm_vcpu.hw_cr[0] |= X86_CR0_TS;
__vmwrite(GUEST_CR0, v->arch.hvm_vcpu.hw_cr[0]);
v->arch.hvm_vmx.exception_bitmap |= (1u << TRAP_no_device);
vmx_update_exception_bitmap(v);
}
}

In the crash dump the additional debug output shows that at least one
__vmwrite will be tried and that the VMCS in the CPU is invalidated:
(XEN) vmx.c:698:IDLEv4 vmx_fpu_leave: vcpu 8300defae000 vmcs
8301586c9000 host_cr0-case FALSE guest_cr[0]-case TRUE curr
8300df2fb000 curr->arch.hvm_vmx.vmcs  realVMCS


As a quick fix I patched the fpu_leave to only allow the __vmwrite when the
realVMCS is valid.
This seems to work fine, but requires a call to __vmptrst every time
vmx_fpu_leave is called. Also I do not know if an ignored TS has any
negative consequences when destroying a vcpu. I assume that this is not
case. In our tests nothing pointed to any problems.

I added the patch to enable altp2m unconditionally and a patch which evades
the panic in vmx_fpu_leave.
They are not pretty or anywhere near production ready, but I think you will
get the idea.
I tried to implement the __vmptrst with the #ifdef HAVE_GAS_VM parts (
analogue to the other functions in vmx.h ) but failed miserably since I lack
the required knowledge about the OPCODE definitions. :-D

Cheers

Kevin

> -Ursprüngliche Nachricht-
> Von: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Gesendet: Montag, 22. August 2016 13:58
> An: Mayer, Kevin ; jbeul...@suse.com
> Cc: xen-devel@lists.xen.org
> Betreff: Re: AW: [Xen-devel] Xen 4.6.1 crash with altp2m enabledbydefault
> 
> On 19/08/16 11:01, kevin.ma...@gdata.de wrote:
> > Hi
> >
> > I took another look at Xen and a new crashdump.
> > The last successful __vmwrite should be in static void
> > vmx_vcpu_update_vmfunc_ve(struct vcpu *v) [...]
> > __vmwrite(SECONDARY_VM_EXEC_CONTROL,
> >   v->arch.hvm_vmx.secondary_exec_control);
> > [...]
> > After this the altp2m_vcpu_destroy wakes up the vcpu and is then
> finished.
> >
> > In nestedhvm_vcpu_destroy (nvmx_vcpu_destroy) the vmcs can
> overwritten (but is not reached in our case as 

Re: [Xen-devel] Question about VPID during MOV-TO-CR3

[Tamas K Lengyel]

On Wed, Sep 21, 2016 at 4:23 AM, Jan Beulich  wrote:
 On 20.09.16 at 19:29,  wrote:
>> I'm trying to figure out the design decision regarding the handling of
>> guest MOV-TO-CR3 operations and TLB flushes. AFAICT since support for
>> VPID has been added to Xen, every guest MOV-TO-CR3 flushes the TLB
>> (vmx_cr_access -> hvm_mov_to_cr -> hvm_set_cr3 -> paging_update_cr3 ->
>> hap_update_cr3 -> vmx_update_guest_cr -> hvm_asid_flush_vcpu). From a
>> TLB utilization point-of-view this seems to be rather wasteful.
>> Furthermore, it even breaks the guests' ability to take advantage of
>> PCID, as the TLB just guts flushed when a new process is scheduled.
>> Does anyone have an insight into what was the rationale behind this?
>
> Since you don't quote the specific commit(s), I would guess that
> this was mainly an attempt by the author(s) to keep things simple
> for themselves, i.e. not having to properly think through under
> which conditions less than a full TLB flush would suffice.

The commit that added VPID and the TLB flush is
e2cf9bd6e055ea678da129b776f4521f6a0b50fe x86, vmx: Enable VPID
(Virtual Processor Identification). So this has been there as long as
Xen supported VPID. The only case where flushing the TLB on a guest
MOV-TO-CR3 that possibly would make sense to me is if we are running a
PV guest. But this is hvm/vmx, so why would we care about what the
guest does to its cr3 from a TLB standpoint? Wouldn't the guest OS
need be in charge of that? With the TLBs being tagged there is no
side-effect the guest can induce on any other domain whether it
flushes its TLB or not.

Tamas

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

[Xen-devel] [xen-4.5-testing baseline-only test] 67737: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-119 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-1 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-134 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-519 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-5 26 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 67706
 test-xtf-amd64-amd64-534 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 67706
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 67706

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 67706
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 67706
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67706
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 67706
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 67706
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67706

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

version targeted for testing:
 xen  e4ae4b03d35babc9624b7286f1ea4c6749bad84b
baseline version:
 xen  c18dfbb88670e9f2cabd93bbb32f661b71ffb73a

Last test of basis67706  2016-09-13 20:15:55 Z7 days
Testing same since67737  2016-09-21 02:18:55 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Konrad Rzeszutek Wilk]

On Wed, Sep 21, 2016 at 09:50:30AM -0400, Chris Patterson wrote:
> On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu  wrote:
> > On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
> >> > From: Chris Patterson 
> >> >
> >> > xs_watch() creates a thread to listen to xenstore events.  Currently, the
> >> > thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
> >> >
> >> > There have been several bug reports and workarounds related to the issue
> >> > where xs_watch() fails because its attempt to create the reader thread 
> >> > with
> >> > pthread_create() fails. This is due to insufficient stack space size
> >> > given the requirements for thread-local storage usage in the applications
> >> > and libraries that are linked against libxenstore.  [1,2,3,4].
> >> >
> >> > Specifying the stack size appears to have been added to reduce memory
> >> > footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
> >>
> >> Ugh. 8MB.
> >
> > OOI isn't that 8MB virtual memory, which means it shouldn't have real
> > impact unless it is used?

/me nods. That is my recollection too. But it does mean that 'top'
shows the application as bigger (by 8MB).

> >
> 
> >From what I understand, that is correct.  At least in the Linux/glibc
> case, I believe the stack is allocated using anonymous mmap() and that
> resident memory usage shouldn't be greater than what you actually end
> up writing.  However, I do not know if this holds true universally...

That should be faily easy to find out. One just needs to check
the RSS size. Not sure how to do that on FreeBSD thought..

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install  fail REGR. vs. 101017

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

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

version targeted for testing:
 qemuua008535b9fa396226ff9cf78b8ac5f3584bda58e
baseline version:
 qemuu3d47a1390bd80b7b974185827a340012d21ad1e3

Last test of basis   101017  2016-09-19 17:22:00 Z1 days
Failing since101032  2016-09-20 05:57:15 Z1 days2 attempts
Testing same since   101062  2016-09-20 19:50:57 Z0 days1 attempts


People who touched revisions under test:
  Eduardo Habkost 
  Marc-André Lureau 
  Markus Armbruster 
  Michael S. Tsirkin 
  Peter Maydell 
  Richard Henderson 
  Riku Voipio 

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 

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv) [and 1 more messages]

[Jan Beulich]

>>> On 21.09.16 at 15:24,  wrote:
> Jan Beulich writes ("Re: [Xen-devel] Device model operation hypercall (DMOP, 
> re qemu depriv) [and 1 more messages]"):
>> On 21.09.16 at 14:23,  wrote:
>> > But changes in the contents of the specific struct /will/ be spotted.
>> 
>> As long as it is a structure, yes. What about someone changing
>> uint64_t to xen_pfn_t?
> 
> You mean if someone changes one of the buffers from "array of
> uint64_t" to "array of xen_pfn_t", so that the ABI changes on some but
> not all architectures ?
> 
> We could declare a rule that a dmop buffer may contain only a struct
> or type name specific to that dmop (or an array of such), and must
> always be accessed through a copy to or from such a type.
> 
> The rule would mean that if we had a dmop which wanted to call, using
> one of the buffers, a function like this:
> 
>  int some_function(uint64_t *pfns, size_t n_pfns);
> 
> You'd have to write the dmop definition like this:
> 
>  typedef uint64_t xen_dmop_foo_entry;
> 
>  xen_dmop_foo_entry *pfns;
>  size_t n_pfns;
> 
>  ...allocate table somehow...
>  ret = copy_dm_buffer_from_guest(pfns,
>  sizeof(pfns[0])*n_pfns,
>  buffers, nr_buffers, 1);
>  ...
>  ret = some_function(pfns, n_pfns);
> 
> And similar code, again using xen_dmop_foo_entry. on the calling side.
> Then if the buffer entry type is changed to xen_pfn_t you change it
> to:
> 
>  typedef xen_pfn_t xen_dmop_foo_entry;
> 
> Now, unless the rest of the code is changed too, the compiler will
> warn that a xen_pfn_t* cannot be converted to a uint64_t* in the call
> to some_function.  (And likewise at the hypercall site in libxc.)
> 
> Would this be enough of an improvement, for you, to be worth the
> additional type name clutter etc. ?

Again this looks like much clutter with little benefit to me, i.e. I'd
then rather go with the unmodified original proposal. That's largely
because nothing really enforces anyone to use the (disconnected)
xen_dmop_foo_entry type. I.e. it continues to be a matter of the
programmer's and the reviewers' attention/discipline.

Jan


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

Re: [Xen-devel] [RFC PATCH] xs: use system's default stack size for xs_watch's reader thread

[Chris Patterson]

On Wed, Sep 21, 2016 at 9:00 AM, Wei Liu  wrote:
> On Wed, Sep 21, 2016 at 08:51:07AM -0400, Konrad Rzeszutek Wilk wrote:
>> On Tue, Sep 20, 2016 at 05:29:39PM -0400, Chris Patterson wrote:
>> > From: Chris Patterson 
>> >
>> > xs_watch() creates a thread to listen to xenstore events.  Currently, the
>> > thread is created with the greater of 16K or PTHREAD_MIN_SIZE.
>> >
>> > There have been several bug reports and workarounds related to the issue
>> > where xs_watch() fails because its attempt to create the reader thread with
>> > pthread_create() fails. This is due to insufficient stack space size
>> > given the requirements for thread-local storage usage in the applications
>> > and libraries that are linked against libxenstore.  [1,2,3,4].
>> >
>> > Specifying the stack size appears to have been added to reduce memory
>> > footprint (1d00c73b983b09fbee4d9dc0f58f6663c361c345).
>>
>> Ugh. 8MB.
>
> OOI isn't that 8MB virtual memory, which means it shouldn't have real
> impact unless it is used?
>

From what I understand, that is correct.  At least in the Linux/glibc
case, I believe the stack is allocated using anonymous mmap() and that
resident memory usage shouldn't be greater than what you actually end
up writing.  However, I do not know if this holds true universally...

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

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Jan Beulich]

>>> On 21.09.16 at 15:34,  wrote:
> On 09/21/2016 06:39 AM, Jan Beulich wrote:
> On 20.09.16 at 02:19,  wrote:
>>> --- a/tools/firmware/hvmloader/acpi/dsdt.asl
>>> +++ /dev/null
>> Please try to represent this as a move, not as a delete+create.
> 
> This was done by 'git mv' and patches were generated with 'git
> format-patch -M5 ...' so I am not sure how I can convince git to show it
> as a rename. Maybe increase the argument to -M to something higher?

Or perhaps with the other adjustment carried out, the delta will
become small enough.

>>> +Scope ( \_SB.PCI0 )
>>> +{
>>> +Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, Shared) { 
>>> 5, 10, 11 } } )
>>> +Name ( BUFB, Buffer() { 0x23, 0x00, 0x00, 0x18, 0x79, 0 } )
>>> +CreateWordField ( BUFB, 0x01, IRQV )
>>> +Device ( LNKA ) {
>>> +Name ( _HID,  EISAID("PNP0C0F") )
>>> +Name ( _UID, 1 )
>>> +Method ( _STA, 0 ) {
>>> +If ( And(PIRA, 0x80) ) {
>>> +Return ( 0x09 )
>>> +}
>>> +Else {
>>> +Return ( 0x0B )
>>> +}
>>> +}
>>> +Method ( _PRS ) {
>>> +Return ( BUFA )
>>> +}
>>> +Method ( _DIS ) {
>>> +Or ( PIRA, 0x80, PIRA )
>>> +}
>>> +Method ( _CRS ) {
>>> +And ( PIRA, 0x0f, Local0 )
>>> +ShiftLeft ( 0x1, Local0, IRQV )
>>> +Return ( BUFB )
>>> +}
>>> +Method ( _SRS, 1 ) {
>>> +CreateWordField ( ARG0, 0x01, IRQ1 )
>>> +FindSetRightBit ( IRQ1, Local0 )
>>> +Decrement ( Local0 )
>>> +Store ( Local0, PIRA )
>>> +}
>>> +}
>>> +Device ( LNKB ) {
>>> [...]
>>> +Name(PRTP, Package()
>>> +{
>>> +Package(){0x0001, 0, \_SB.PCI0.LNKB, 0},
>>> +Package(){0x0001, 1, \_SB.PCI0.LNKC, 0},
>>> +Package(){0x0001, 2, \_SB.PCI0.LNKD, 0},
>>> +Package(){0x0001, 3, \_SB.PCI0.LNKA, 0},
>>> +Package(){0x0002, 0, \_SB.PCI0.LNKC, 0},
>>> [...]
>>> +Package(){0x001f, 3, \_SB.PCI0.LNKC, 0},
>>> +})
>>> +
>>> +Name(PRTA, Package()
>>> +{
>>> +Package(){0x0001, 0, 0, 20},
>>> +Package(){0x0001, 1, 0, 21},
>>> +Package(){0x0001, 2, 0, 22},
>>> +Package(){0x0001, 3, 0, 23},
>>> +Package(){0x0002, 0, 0, 24},
>>> [...]
>>> +Package(){0x001f, 3, 0, 18},
>>> +})
>>> +}
>>> +}
>> I realize this is the easiest route, but how the various hard coded
>> numbers got generated would be completely lost, making it
>> extremely hard to make any changes here down the road. I
>> wonder whether the Makefile / output redirection approach couldn't
>> be easily extended to create all that data via a shell script fragment,
>> if retaining the C source (moved to a separate file) is indeed not an
>> option.
>>
>> Nor would I think that would qualify here as someone having
>> produced the replacement code without having looked at the
>> original, as was suggested as a criteria before.
> 
> I can do that (but then I think it would also make sense to have it
> generate _S5 and _PIC methods as well, even though they are "static").

Sounds reasonable.

Jan


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

Re: [Xen-devel] [PATCH V2] x86/mm: Fix Coverity issues 1373105 and 1373106

[Jan Beulich]

>>> On 21.09.16 at 14:55,  wrote:
> On 21/09/16 13:52, Jan Beulich wrote:
> On 21.09.16 at 14:41,  wrote:
>>> Added missing error checks in p2m_set_mem_access_multi().
>> 
>> I think the patch subject should say what is being changed/fixed,
>> and the two Coverity IDs should be listed here instead. Otherwise
>> someone looking over just the patch titles will have no idea what
>> this is actually about. If I end up committing this, I'll take the liberty
>> to do adjustments.
> 
> I said I'd commit it, so how about:
> 
> x86/mm: Add missing copy_from_user error checks in p2m_set_access_multi

Sound good.

Jan


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

Re: [Xen-devel] [PATCH v4 10/21] acpi/hvmloader: Link ACPI object files directly

[Boris Ostrovsky]

On 09/21/2016 07:40 AM, Jan Beulich wrote:
 On 21.09.16 at 13:38,  wrote:
>> Jan Beulich writes ("Re: [PATCH v4 10/21] acpi/hvmloader: Link ACPI object 
>> files directly"):
>>> On 21.09.16 at 13:29,  wrote:
 I think `.dummy' would be a better string, if indeed it's a string
 which we expect always to be stripped, and not to appear in any
 filenames.
>>> Another (currently later, but I'd prefer it to be moved ahead)
>>> patch uses this for actual temporary files.
>> OK, then I don't understand what's wrong with ".tmp" ...
> So did I think when looking at the patch, but then I also thought
> (at least until I saw that actual files get created with that suffix)
> that it doesn't really matter. Boris?

I think there are two questions about using TMP_SUFFIX=tmp__

1. It is indeed used for two purposes --- one is to work around the bug
and the other is to append to intermediate build files (that are later
removed). There are two instances where I need to handle the bug and
thus I use a variable and not a literal ".dummy". And since I already
have (or, in this iteration of the series, will have in the later patch)
TMP_SUFFIX I figured I'd use it here as well.

2. ".tmp__" vs ".tmp": Because the temporary files are generated not in
tools/libacpi but in the directory of the libacpi user (such as libxl)
it is possible that a Makefile there might use ".tmp' for its own
purposes so I am trying here to minimize chances of a conflict. Maybe
even ".tmp_acpi"?

-boris


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

Re: [Xen-devel] [PATCH v4 02/21] acpi: Prevent GPL-only code from seeping into non-GPL binaries

[Boris Ostrovsky]

On 09/21/2016 06:39 AM, Jan Beulich wrote:
 On 20.09.16 at 02:19,  wrote:
>> --- a/tools/firmware/hvmloader/acpi/dsdt.asl
>> +++ /dev/null
> Please try to represent this as a move, not as a delete+create.

This was done by 'git mv' and patches were generated with 'git
format-patch -M5 ...' so I am not sure how I can convince git to show it
as a rename. Maybe increase the argument to -M to something higher?


>
>> +Scope ( \_SB.PCI0 )
>> +{
>> +Name ( BUFA, ResourceTemplate() { IRQ(Level, ActiveLow, Shared) { 
>> 5, 10, 11 } } )
>> +Name ( BUFB, Buffer() { 0x23, 0x00, 0x00, 0x18, 0x79, 0 } )
>> +CreateWordField ( BUFB, 0x01, IRQV )
>> +Device ( LNKA ) {
>> +Name ( _HID,  EISAID("PNP0C0F") )
>> +Name ( _UID, 1 )
>> +Method ( _STA, 0 ) {
>> +If ( And(PIRA, 0x80) ) {
>> +Return ( 0x09 )
>> +}
>> +Else {
>> +Return ( 0x0B )
>> +}
>> +}
>> +Method ( _PRS ) {
>> +Return ( BUFA )
>> +}
>> +Method ( _DIS ) {
>> +Or ( PIRA, 0x80, PIRA )
>> +}
>> +Method ( _CRS ) {
>> +And ( PIRA, 0x0f, Local0 )
>> +ShiftLeft ( 0x1, Local0, IRQV )
>> +Return ( BUFB )
>> +}
>> +Method ( _SRS, 1 ) {
>> +CreateWordField ( ARG0, 0x01, IRQ1 )
>> +FindSetRightBit ( IRQ1, Local0 )
>> +Decrement ( Local0 )
>> +Store ( Local0, PIRA )
>> +}
>> +}
>> +Device ( LNKB ) {
>> [...]
>> +Name(PRTP, Package()
>> +{
>> +Package(){0x0001, 0, \_SB.PCI0.LNKB, 0},
>> +Package(){0x0001, 1, \_SB.PCI0.LNKC, 0},
>> +Package(){0x0001, 2, \_SB.PCI0.LNKD, 0},
>> +Package(){0x0001, 3, \_SB.PCI0.LNKA, 0},
>> +Package(){0x0002, 0, \_SB.PCI0.LNKC, 0},
>> [...]
>> +Package(){0x001f, 3, \_SB.PCI0.LNKC, 0},
>> +})
>> +
>> +Name(PRTA, Package()
>> +{
>> +Package(){0x0001, 0, 0, 20},
>> +Package(){0x0001, 1, 0, 21},
>> +Package(){0x0001, 2, 0, 22},
>> +Package(){0x0001, 3, 0, 23},
>> +Package(){0x0002, 0, 0, 24},
>> [...]
>> +Package(){0x001f, 3, 0, 18},
>> +})
>> +}
>> +}
> I realize this is the easiest route, but how the various hard coded
> numbers got generated would be completely lost, making it
> extremely hard to make any changes here down the road. I
> wonder whether the Makefile / output redirection approach couldn't
> be easily extended to create all that data via a shell script fragment,
> if retaining the C source (moved to a separate file) is indeed not an
> option.
>
> Nor would I think that would qualify here as someone having
> produced the replacement code without having looked at the
> original, as was suggested as a criteria before.

I can do that (but then I think it would also make sense to have it
generate _S5 and _PIC methods as well, even though they are "static").

I think bash script would be better than C since we mostly care about
loops that generate values and not language constructs such as stmt()
and push_blk().

-boris



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