[Xen-devel] [qemu-mainline baseline-only test] 67590: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 67583
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 67583
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 20 leak-check/check fail REGR. 
vs. 67583

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

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

version targeted for testing:
 qemuu8c1c230a6e941a2b2c014fed0dc5db08694480d8
baseline version:
 qemuud75aa4372f0414c9960534026a562b0302fcff29

Last test of basis67583  2016-08-23 11:45:48 Z1 days
Testing same since67590  2016-08-24 23:44:41 Z0 days1 attempts


People who touched revisions under test:
  Ed Maste 
  Peter Maydell 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
baseline version:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da

Last test of basis   100602  2016-08-24 01:58:47 Z1 days
Testing same since   100607  2016-08-24 14:12:47 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Lars Kurth 
  Wei Liu 

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

Re: [Xen-devel] [PATCHv2 0/2] xen/privcmd: prevent page migration for hypercall buffers

[Juergen Gross]

On 22/08/16 19:25, David Vrabel wrote:
> On 04/08/16 16:16, David Vrabel wrote:
>> Currently libxencall using mlocked buffers for hypercall buffers.
>> This pages are subject to compaction and page migration. A userspace
>> process may see a hypercall fail with -EFAULT if a page backing a
>> hypercall buffer is in the process of being migrated.
>>
>> Page migration can be prevented by taking an additional reference to
>> the page.
>>
>> There are three possible ways to do this:
>>
>> 1. Add a new device which when mmap()'d populated the VMA with
>>suitable memory that has an additional reference.  This would give
>>VMAs that have appropriate properties set (e.g., VM_DONTCOPY)
>>without having to do additional madvise() calls.
>>
>> 2. Add a new ioctl to privcmd to populate a VMA with suitably
>>ref-counted pages.  However, mmap() on privcmd is already used for
>>foreign mappings and the VMA properties for hypercall buffers and
>>foreign mappings might need to be different and the handling of
>>unmap will need to be different.  This might be tricky.
>>
>> 3. Add a pair of ioctls to privcmd to lock/unlock a buffer by
>>getting/putting an additional reference to the page.  This is
>>what's implemented in this series.
>>
>> Any thoughts on which is the best approach?
> 
> Did no one have an opinions on these three options?

I think 3 is the best solution.

So for this series:

Acked-by: Juergen Gross 


Juergen


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

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

[Yi Sun]

Design document is below:
===
% Intel L2 Cache Allocation Technology (L2 CAT) Feature
% Revision 1.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 initial 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.

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 interfaces:

  1. Ext: psr-cat-show -l2 domain-id
  Show L2 

[Xen-devel] [PATCH 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 
---
 xen/arch/x86/domctl.c |   36 +-
 xen/arch/x86/psr.c| 1121 +++--
 xen/arch/x86/sysctl.c |9 +-
 xen/include/asm-x86/psr.h |   21 +-
 4 files changed, 912 insertions(+), 275 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index bed70aa..a51ed2c 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1358,41 +1358,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..a77b55a 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -23,22 +23,116 @@
 #define PSR_CAT(1<<1)
 #define PSR_CDP(1<<2)
 
-struct psr_cat_cbm {
-union {
-uint64_t cbm;
-struct {
-uint64_t code;
-uint64_t data;
-};
-};
+/*
+ * 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 feat_ops" object and register
+ *feature specific callback functions into it;
+ * 3. Delcare feat_list object for the feature and malloc memory for it
+ *in internal_cpu_prepare(). Correspondingly, free them in
+ *free_feature();
+ * 4. Add feature initialization codes in internal_cpu_init().
+ */
+
+struct feat_list;
+struct psr_socket_alloc_info;
+
+/* Every feature enabled should implement such ops and callback functions. */
+struct feat_ops {
+/*
+ * init_feature is used in cpu initialization process to do feature
+ * specific initialization works.
+ */
+void (*init_feature)(unsigned int eax, unsigned int ebx,
+ unsigned int ecx, unsigned int edx,
+ struct feat_list *pFeat,
+ struct 

[Xen-devel] [PATCH 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 
---
 xen/arch/x86/domctl.c   |  13 +++
 xen/arch/x86/psr.c  | 226 +++-
 xen/arch/x86/sysctl.c   |  16 ++-
 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 |   3 +-
 7 files changed, 258 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index a51ed2c..604d202 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1396,6 +1396,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 a77b55a..a23d3c9 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -123,6 +123,7 @@ struct psr_ref {
 
 #define PSR_SOCKET_L3_CAT 0
 #define PSR_SOCKET_L3_CDP 1
+#define PSR_SOCKET_L2_CAT 2
 
 struct psr_socket_alloc_info {
 /*
@@ -153,6 +154,7 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc);
 static struct psr_ref *temp_cos_ref;
 /* Every feature has its own object. */
 struct feat_list *pL3CAT;
+struct feat_list *pL2CAT;
 
 /* Common functions for supporting feature callback functions. */
 static void add_feature(struct feat_list *pHead, struct feat_list *pTmp)
@@ -215,12 +217,215 @@ static bool_t psr_check_cbm(unsigned int cbm_len, 
uint64_t cbm)
  * Features specific implementations.
  */
 
-/* CAT/CDP data structure and callback functions implementation. */
+/* CAT/CDP data structure definition. */
 struct psr_cat_lvl_info {
 unsigned int cbm_len;
 unsigned int cos_max;
 };
 
+/* 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 *pFeat,
+struct psr_socket_alloc_info *info)
+{
+struct psr_cat_lvl_info l2_cat;
+unsigned int socket;
+
+if ( MAX_FEAT_INFO_SIZE < sizeof(struct psr_cat_lvl_info) )
+return;
+
+/* 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). */
+pFeat->cos_reg_val[0] = (1ull << l2_cat.cbm_len) - 1;
+
+pFeat->feature = PSR_SOCKET_L2_CAT;
+set_bit(PSR_SOCKET_L2_CAT, &(info->features));
+
+memcpy(pFeat->feat_info, _cat, sizeof(struct psr_cat_lvl_info));
+
+info->nr_feat++;
+
+/* Add this feature into list. */
+add_feature(info->pFeat, pFeat);
+
+socket = cpu_to_socket(smp_processor_id());
+printk(XENLOG_INFO "L2 CAT: enabled on socket %u, cos_max:%u, 
cbm_len:%u.\n",
+   socket, pFeat->feat_info[1], pFeat->feat_info[0]);
+}
+
+static int l2_cat_compare_mask(uint64_t *mask, struct feat_list *pFeat,
+   unsigned int cos, bool_t *found)
+{
+struct psr_cat_lvl_info cat_info;
+uint64_t l2_def_cbm;
+
+memcpy(_info, pFeat->feat_info, sizeof(struct psr_cat_lvl_info));
+l2_def_cbm = (1ull << cat_info.cbm_len) - 1;
+
+/* L2 CAT */
+if ( cos > cat_info.cos_max )
+{
+if ( mask[0] != l2_def_cbm )
+{
+printk(XENLOG_ERR "L2 CAT exceed cos max.\n");
+*found = 0;
+return -ENOENT;
+}
+*found = 1;
+return 1;
+}
+
+if ( mask[0] == pFeat->cos_reg_val[cos] )
+*found = 1;
+else
+*found = 0;
+
+return 1;
+}
+
+static unsigned int l2_cat_get_cos_max_as_type(struct feat_list *pFeat,
+   enum mask_type type)
+{
+struct psr_cat_lvl_info cat_info;
+
+if ( type != PSR_MASK_TYPE_L2_CBM )
+return 0;
+
+memcpy(_info, pFeat->feat_info, sizeof(struct psr_cat_lvl_info));
+return cat_info.cos_max;
+}
+
+static unsigned int l2_cat_exceed_range(uint64_t *mask, struct feat_list 
*pFeat,
+ 

[Xen-devel] [PATCH 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 
---
 docs/man/xl.pod.1.in  |  25 +-
 docs/misc/xl-psr.markdown |  10 ++-
 tools/libxc/include/xenctrl.h |   7 +-
 tools/libxc/xc_psr.c  |  28 +--
 tools/libxl/libxl.h   |   2 +
 tools/libxl/libxl_psr.c   |  50 ++-
 tools/libxl/libxl_types.idl   |   1 +
 tools/libxl/xl_cmdimpl.c  | 191 +++---
 tools/libxl/xl_cmdtable.c |   4 +-
 9 files changed, 268 insertions(+), 50 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 1adf322..47bdfc6 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1660,6 +1660,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]
@@ -1684,7 +1687,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.
@@ -1694,7 +1697,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
 
@@ -1711,6 +1714,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.
@@ -1721,10 +1729,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 value(all-ones).
 
 Per domain CBM settings can be shown by:
 
-`xl psr-cat-show`
+`xl psr-cat-show [OPTIONS] `
+
+In different systems, the different 

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[Nicholas Piggin]

On Wed, 24 Aug 2016 22:12:53 +0200
"Luis R. Rodriguez"  wrote:

> On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote:
> > On Tue, 23 Aug 2016 19:33:06 +0200
> > "Luis R. Rodriguez"  wrote:
> >   
> > > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:  
> > > > On Fri, 19 Aug 2016 14:34:02 -0700
> > > > mcg...@kernel.org wrote:
> > > > > +/**
> > > > > + * DOC: Standard ELF section use in Linux
> > > > > + *
> > > > > + * Linux makes use of the standard ELF sections, this sections 
> > > > > documents
> > > > > + * these.
> > > > > + */
> > > > > +
> > > > > +/**
> > > > > + * DOC: SECTION_RODATA
> > > > > + *
> > > > > + * Macro name for code which must be protected from write access, 
> > > > > read only
> > > > > + * data.
> > > > > + */
> > > > > +#define SECTION_RODATA   .rodata
> > > > 
> > > > These, for example. The exact name of the section is important in linker
> > > > scripts and asm, so I can't see the benefit of hiding it. I could be
> > > > missing the bigger picture.
> > > 
> > > There's two goals by using a macro for these core names. One is to allow 
> > > us
> > > to easily aggregate documentation in central place for each, the second is
> > > to then provide more easily grep'able helpers so we can use them when 
> > > devising
> > > extensions or using them in extensions which further customize the 
> > > sections
> > > in the kernel.  
> 
> Just thought of more more justification I had forgotten. I cover it below.
> 
> > Documentation is good, but not necessary to have the extra name 
> > indirection.  
> 
> Fair point.
> 
> > Sections tend (not always, but it would be nice if they did) to follow the
> > .name convention, which makes them reasonably easy to grep for.  
> 
> git grep .text  doesn't work but that is typically expected...
> git grep \.text doesn't work as expected
> 
> Ah finally:
> 
> git grep "\.text" seems to work. But WTF.

This is simply how grep works though.


> But:
> 
> git grep SECTION_TEXT works as expected immediately.
> 
> I guess its a matter of perspective.
> 
> > They are also
> > the names you'll be grepping for when you look at disassembly.  
> 
> Sure but if you're grepping asm, you very likely know what to look for.

After you have gone through the extra layer of naming indirection
to work out what it is. I'm still not sold on the name indirection
and hiding wildcards. Not just for asm grepping, but I don't think
it's a negative thing for devs working on the linker to know what
actual section names and commands are being used, as much as possible.


> > > > > +/**
> > > > > + * DOC: SECTION_TEXT
> > > > > + *
> > > > > + * Macro name used to annotate code (functions) used during regular
> > > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > > > > + * section also allows for execution.
> > > > > + *
> > > > > + */
> > > > > +#define SECTION_TEXT .text
> > > > 
> > > > I can't see how these comments are right. .rodata doesn't seem like it
> > > > should be combined with .text, and is not currently on powerpc. I think
> > > > it's for data, not code.
> > > 
> > > On x86 and powerpc .rodata follows .text.  
> > 
> > But follows is not the same as combined.  
> 
> True and as I confirmed below, on PowerPC this is certainly not true.

OK.


> > And together with the comment that RODATA is for code (which is wrong, it's 
> > data),  
> 
> Where did I have that? If you refer to the above SECTION_TEXT documentation, 
> it
> refers to SECTION_TEXT being for code, but the goal was to highlight that
> SECTION_TEXT is for execution, while SECTION_RODATA was for data. This
> certainly can use some love though, thanks, will just drop the SECTION_RODATA
> reference *or* properly explain the whole thing below.

+/**
+ * DOC: SECTION_RODATA
+ *
+ * Macro name for code which must be protected from write access, read only
+ * data.
+ */
+#define SECTION_RODATA .rodata

This together with the "combined with .text" part confused me.


> > it make it seem like it is actually combined.  
> 
> Will fix to ensure this is understood in proper context.

Thanks.



> > > Its not intended to grab .text but rather its for helpers that provide 
> > > customizations
> > > based on a core section as base, in this case given your example it would 
> > > be used by
> > > section ranges and linker tables for .text. Both section ranges and 
> > > linker tables
> > > use postfix .something for their customizations. The SECTION_ALL() macro 
> > > then is
> > > a helper for customizations on a core section.  
> > 
> > Right, it's just that .text.* is *immediately* obvious. SECTION_ALL() is 
> > not.  
> 
> Which is why I was suggesting perhaps an alternative name.
> 
> > > If the name is misleading would SECTION_CORE_ALL() be better with some 
> > > documentation
> > > explaining this and the above goal ?  
> > 
> > I don't 

Re: [Xen-devel] [PATCH] VT-d: drop pointless uses of __func__

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 24, 2016 3:54 PM
> To: xen-devel 
> Cc: Wu, Feng ; Tian, Kevin 
> Subject: [PATCH] VT-d: drop pointless uses of __func__
> 
> Debugging message text already includes file name and line number, so
> also logging function names is redundant.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -242,8 +242,8 @@ static int remap_entry_to_ioapic_rte(
>  if ( index < 0 || index > IREMAP_ENTRY_NR - 1 )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: index (%d) for remap table is invalid !\n",
> -__func__, index);
> +"IO-APIC index (%d) for remap table is invalid\n",
> +index);
>  return -EFAULT;
>  }
> 
> @@ -255,8 +255,8 @@ static int remap_entry_to_ioapic_rte(
>  if ( iremap_entry->val == 0 )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: index (%d) get an empty entry!\n",
> -__func__, index);
> +"IO-APIC index (%d) has an empty entry\n",
> +index);
>  unmap_vtd_domain_page(iremap_entries);
>  spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
>  return -EFAULT;
> @@ -301,9 +301,8 @@ static int ioapic_rte_to_remap_entry(str
>  if ( index > IREMAP_ENTRY_NR - 1 )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: intremap index (%d) is larger than"
> -" the maximum index (%d)!\n",
> -__func__, index, IREMAP_ENTRY_NR - 1);
> +"IO-APIC intremap index (%d) larger than maximum index 
> (%d)\n",
> +index, IREMAP_ENTRY_NR - 1);
>  spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
>  return -EFAULT;
>  }
> @@ -500,8 +499,8 @@ static int remap_entry_to_msi_msg(
>  if ( index >= IREMAP_ENTRY_NR )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: index (%d) for remap table is invalid !\n",
> -__func__, index);
> +"MSI index (%d) for remap table is invalid\n",
> +index);
>  return -EFAULT;
>  }
> 
> @@ -513,8 +512,8 @@ static int remap_entry_to_msi_msg(
>  if ( iremap_entry->val == 0 )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: index (%d) get an empty entry!\n",
> -__func__, index);
> +"MSI index (%d) has an empty entry\n",
> +index);
>  unmap_vtd_domain_page(iremap_entries);
>  spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
>  return -EFAULT;
> @@ -585,9 +584,8 @@ static int msi_msg_to_remap_entry(
>  if ( index > IREMAP_ENTRY_NR - 1 )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: intremap index (%d) is larger than"
> -" the maximum index (%d)!\n",
> -__func__, index, IREMAP_ENTRY_NR - 1);
> +"MSI intremap index (%d) larger than maximum index (%d)!\n",
> +index, IREMAP_ENTRY_NR - 1);
>  for ( i = 0; i < nr; ++i )
>  msi_desc[i].remap_index = -1;
>  spin_unlock_irqrestore(_ctrl->iremap_lock, flags);
> @@ -689,9 +687,8 @@ int __init intel_setup_hpet_msi(struct m
>  if ( msi_desc->remap_index >= IREMAP_ENTRY_NR )
>  {
>  dprintk(XENLOG_ERR VTDPREFIX,
> -"%s: intremap index (%d) is larger than"
> -" the maximum index (%d)!\n",
> -__func__, msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
> +"HPET intremap index (%d) larger than maximum index (%d)!\n",
> +msi_desc->remap_index, IREMAP_ENTRY_NR - 1);
>  msi_desc->remap_index = -1;
>  rc = -ENXIO;
>  }
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -129,11 +129,11 @@ static int context_get_domain_id(struct
> 
>  dom_index = context_domain_id(*context);
> 
> -if ( dom_index < nr_dom && iommu->domid_map)
> +if ( dom_index < nr_dom && iommu->domid_map )
>  domid = iommu->domid_map[dom_index];
>  else
> -dprintk(XENLOG_DEBUG VTDPREFIX, "%s: dom_index %lu exceeds
> nr_dom %lu or iommu has no domid_map\n",
> -__func__, dom_index, nr_dom);
> +dprintk(XENLOG_DEBUG VTDPREFIX, "dom_index %lu exceeds
> nr_dom %lu or iommu has no domid_map\n",

This line exceeds the 80 characters limitation, do we have better way to handle 
this?

Thanks,
Feng

> +dom_index, nr_dom);
>  }
>  return domid;
>  }
> 


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

Re: [Xen-devel] [PATCH] VT-d: drop pointless uses of __func__

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, August 24, 2016 3:54 PM
> 
> Debugging message text already includes file name and line number, so
> also logging function names is redundant.
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Kevin Tian 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu8c1c230a6e941a2b2c014fed0dc5db08694480d8
baseline version:
 qemuud75aa4372f0414c9960534026a562b0302fcff29

Last test of basis   100589  2016-08-22 21:47:46 Z2 days
Testing same since   100608  2016-08-24 16:42:42 Z0 days1 attempts


People who touched revisions under test:
  Ed Maste 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v4 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Boris Ostrovsky]

On 08/16/2016 06:25 AM, Shannon Zhao wrote:
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index f7338a3..8a0327d 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -30,6 +30,7 @@
>   */
>  
>  #define HVM_PARAM_CALLBACK_IRQ 0
> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56

May be worth updating hvm_set_callback_via() with this parameter.

-boris


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-native   fail REGR. vs. 100602
 test-armhf-armhf-xl-credit2  16 guest-start.2fail REGR. vs. 100602
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail REGR. vs. 100602

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

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

version targeted for testing:
 xen  fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
baseline version:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da

Last test of basis   100602  2016-08-24 01:58:47 Z0 days
Testing same since   100607  2016-08-24 14:12:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Lars Kurth 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v4 03/16] libxl/arm: Generate static ACPI DSDT table

[Boris Ostrovsky]

On 08/16/2016 06:25 AM, Shannon Zhao wrote:
> diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
> index d741ac5..7f50a33 100644
> --- a/tools/libacpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -19,6 +19,7 @@ MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt
>  
>  # Sources to be generated
>  C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c  
> dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
> +C_SRC += $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c
>  H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h 
> ssdt_tpm.h)
>  
>  vpath iasl $(PATH)
> @@ -32,7 +33,7 @@ $(H_SRC): $(ACPI_BUILD_DIR)/%.h: %.asl iasl
>   cd $(CURDIR)
>  
>  $(MK_DSDT): mk_dsdt.c
> - $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -o $@ mk_dsdt.c
> + $(HOSTCC) $(HOSTCFLAGS) $(CFLAGS_xeninclude) -D__XEN_TOOLS__ -o $@ 
> mk_dsdt.c
>  
>  $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl 
> $(MK_DSDT)
>   awk 'NR > 1 {print s} {s=$$0}' $< > $@
> @@ -62,6 +63,18 @@ $(ACPI_BUILD_DIR)/dsdt_pvh.c: iasl 
> $(ACPI_BUILD_DIR)/dsdt_pvh.asl
>   echo "int dsdt_pvh_len=sizeof(dsdt_pvh);" >>$@
>   rm -f $(ACPI_BUILD_DIR)/$*.aml $(ACPI_BUILD_DIR)/$*.hex
>  
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl: $(MK_DSDT)
> + printf "DefinitionBlock (\"DSDT.aml\", \"DSDT\", 3, \"XenARM\", \"Xen 
> DSDT\", 1)\n{" > $@
> + $(MK_DSDT) --debug=$(debug) --arch arm >> $@
> +
> +$(ACPI_BUILD_DIR)/dsdt_anycpu_arm.c: iasl 
> $(ACPI_BUILD_DIR)/dsdt_anycpu_arm.asl
> + cd $(ACPI_BUILD_DIR)
> + iasl -vs -p $* -tc $(ACPI_BUILD_DIR)/$*.asl
> + sed -e 's/AmlCode/$*/g' $*.hex >$@
> + echo "int $*_len=sizeof($*);" >>$@
> + rm -f $*.aml $*.hex
> + cd $(CURDIR)
> +

Note that x86 targets have been updated not to use 'cd'.


> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
> index 6139bed..ce356d0 100644
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -90,7 +90,10 @@ acpi:
>  
>  LIBXL_OBJS-$(CONFIG_X86) += libxl_cpuid.o libxl_x86.o libxl_psr.o 
> libxl_x86_acpi.o
>  LIBXL_OBJS-$(CONFIG_ARM) += libxl_nocpuid.o libxl_arm.o libxl_libfdt_compat.o
> -LIBXL_OBJS-$(CONFIG_ARM_64) += libxl_arm_acpi.o
> +LIBXL_OBJS-$(CONFIG_ARM_64) += libxl_arm_acpi.o dsdt_anycpu_arm.o
> +
> +dsdt_anycpu_arm.c:
> + $(MAKE) -C $(ACPI_PATH) ACPI_BUILD_DIR=$(shell pwd)

$(CURDIR) ?

(Both of these were requested by Jan when reviewing my x86 series so I
figured I'd mention them here as well)

-boris


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

Re: [Xen-devel] [PATCH] x86: correct PT_NOTE file position

[Konrad Rzeszutek Wilk]

On Wed, Aug 24, 2016 at 09:24:38AM -0600, Jan Beulich wrote:
> Program and section headers disagreed about the file offset at which
> the build ID note lives.

Gosh. That was an oversight.
> 
> Reported-by: Sylvain Munaut 

'whatever-company'? Really?

Huh. Imagine that.

> Signed-off-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 
> 
> --- a/xen/arch/x86/boot/mkelf32.c
> +++ b/xen/arch/x86/boot/mkelf32.c
> @@ -394,7 +394,7 @@ int main(int argc, char **argv)
>  note_phdr.p_paddr   = note_base;
>  note_phdr.p_filesz  = note_sz;
>  note_phdr.p_memsz   = note_sz;
> -note_phdr.p_offset  = offset;
> +note_phdr.p_offset  = RAW_OFFSET + offset;
>  
>  /* Tack on the .note\0 */
>  out_shdr[2].sh_size += sizeof(out_shstrtab_extra);
> 
> 
> 

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

Re: [Xen-devel] [PATCH] x86/mm: drop pointless use of __FUNCTION__

[Konrad Rzeszutek Wilk]

On Wed, Aug 24, 2016 at 02:01:09AM -0600, Jan Beulich wrote:
> Non-debugging message text should be (and is here) distinguishable
> without also logging function names.

Reviewed-by: Konrad Rzeszutek Wilk 

> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/mm/paging.c
> +++ b/xen/arch/x86/mm/paging.c
> @@ -469,8 +469,9 @@ static int paging_log_dirty_op(struct do
>  peek = 0;
>  
>  if ( unlikely(d->arch.paging.log_dirty.failed_allocs) ) {
> -printk("%s: %d failed page allocs while logging dirty pages\n",
> -   __FUNCTION__, d->arch.paging.log_dirty.failed_allocs);
> +printk(XENLOG_WARNING
> +   "%u failed page allocs while logging dirty pages of Dom%d\n",
> +   d->arch.paging.log_dirty.failed_allocs, d->domain_id);
>  rv = -ENOMEM;
>  goto out;
>  }

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

Re: [Xen-devel] [PATCH] x86: drop pointless uses of __func__ / __FUNCTION__

[Konrad Rzeszutek Wilk]

On Wed, Aug 24, 2016 at 02:02:51AM -0600, Jan Beulich wrote:
> Non-debugging message text should be (and is in the cases here)
> distinguishable without also logging function names. Debugging message
> text, otoh, already includes file name and line number, so also
> logging function names is redundant. One relatively pointless debugging
> message gets removed altogether. In another case a mising log level

s/mising/missing/
> specifier gets added at once.

Which one? I was thinking it would be either one of these:

> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1467,8 +1467,7 @@ static int __init verify_tsc_reliability
>  tsc_check_reliability();
>  if ( tsc_max_warp )
>  {
> -printk("%s: TSC warp detected, disabling TSC_RELIABLE\n",
> -   __func__);
> +printk("TSC warp detected, disabling TSC_RELIABLE\n");
>  setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
>  }
>  }
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -574,8 +574,8 @@ void xstate_init(struct cpuinfo_x86 *c)
>   * We know FP/SSE and YMM about eax, and nothing about edx at 
> present.
>   */
>  xsave_cntxt_size = _xstate_ctxt_size(feature_mask);
> -printk("%s: using cntxt_size: %#x and states: %#"PRIx64"\n",
> -__func__, xsave_cntxt_size, xfeature_mask);
> +printk("xstate: size: %#x and states: %#"PRIx64"\n",
> +   xsave_cntxt_size, xfeature_mask);
>  
>  asm ( "fxsave %0" : "=m" (ctxt) );
>  if ( ctxt.mxcsr_mask )
> 
>

but both just remove the __func__ usage? 

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

Re: [Xen-devel] [PATCH] VT-d: drop pointless uses of __func__

[Konrad Rzeszutek Wilk]

On Wed, Aug 24, 2016 at 01:54:08AM -0600, Jan Beulich wrote:
> Debugging message text already includes file name and line number, so
> also logging function names is redundant.

And you also fixed one style guide violation :-)
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [PATCH] pass-through: drop pointless uses of __func__

[Konrad Rzeszutek Wilk]

On Wed, Aug 24, 2016 at 01:51:13AM -0600, Jan Beulich wrote:
> Non-debugging message text should be (and is in the cases here)
> distinguishable without also logging function names. Additionally log
> the PCI device coordinates for alloc_pdev() failure.
> 

Reviewed-by: Konrad Rzeszutek Wilk 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -379,8 +379,8 @@ static struct pci_dev *alloc_pdev(struct
>  break;
>  
>  default:
> -printk(XENLOG_WARNING "%s: unknown type: %04x:%02x:%02x.%u\n",
> -   __func__, pseg->nr, bus, PCI_SLOT(devfn), 
> PCI_FUNC(devfn));
> +printk(XENLOG_WARNING "%04x:%02x:%02x.%u: unknown type %d\n",
> +   pseg->nr, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 
> pdev->type);
>  break;
>  }
>  
> @@ -991,7 +991,8 @@ static int __init _scan_pci_devices(stru
>  pdev = alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
>  if ( !pdev )
>  {
> -printk("%s: alloc_pdev failed.\n", __func__);
> +printk(XENLOG_WARNING "%04x:%02x:%02x.%u: alloc_pdev 
> failed\n",
> +   pseg->nr, bus, dev, func);
>  return -ENOMEM;
>  }
>  
> 
> 
> 

> pass-through: drop pointless uses of __func__
> 
> Non-debugging message text should be (and is in the cases here)
> distinguishable without also logging function names. Additionally log
> the PCI device coordinates for alloc_pdev() failure.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -379,8 +379,8 @@ static struct pci_dev *alloc_pdev(struct
>  break;
>  
>  default:
> -printk(XENLOG_WARNING "%s: unknown type: %04x:%02x:%02x.%u\n",
> -   __func__, pseg->nr, bus, PCI_SLOT(devfn), 
> PCI_FUNC(devfn));
> +printk(XENLOG_WARNING "%04x:%02x:%02x.%u: unknown type %d\n",
> +   pseg->nr, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), 
> pdev->type);
>  break;
>  }
>  
> @@ -991,7 +991,8 @@ static int __init _scan_pci_devices(stru
>  pdev = alloc_pdev(pseg, bus, PCI_DEVFN(dev, func));
>  if ( !pdev )
>  {
> -printk("%s: alloc_pdev failed.\n", __func__);
> +printk(XENLOG_WARNING "%04x:%02x:%02x.%u: alloc_pdev 
> failed\n",
> +   pseg->nr, bus, dev, func);
>  return -ENOMEM;
>  }
>  

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


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

Re: [Xen-devel] [PATCH v4 04/16] generic-sections: add section core helpers

[Luis R. Rodriguez]

On Wed, Aug 24, 2016 at 01:51:41PM +1000, Nicholas Piggin wrote:
> On Tue, 23 Aug 2016 19:33:06 +0200
> "Luis R. Rodriguez"  wrote:
> 
> > On Tue, Aug 23, 2016 at 11:26:33AM +1000, Nicholas Piggin wrote:
> > > On Fri, 19 Aug 2016 14:34:02 -0700
> > > mcg...@kernel.org wrote:  
> > > > +/**
> > > > + * DOC: Standard ELF section use in Linux
> > > > + *
> > > > + * Linux makes use of the standard ELF sections, this sections 
> > > > documents
> > > > + * these.
> > > > + */
> > > > +
> > > > +/**
> > > > + * DOC: SECTION_RODATA
> > > > + *
> > > > + * Macro name for code which must be protected from write access, read 
> > > > only
> > > > + * data.
> > > > + */
> > > > +#define SECTION_RODATA .rodata  
> > > 
> > > These, for example. The exact name of the section is important in linker
> > > scripts and asm, so I can't see the benefit of hiding it. I could be
> > > missing the bigger picture.  
> > 
> > There's two goals by using a macro for these core names. One is to allow us
> > to easily aggregate documentation in central place for each, the second is
> > to then provide more easily grep'able helpers so we can use them when 
> > devising
> > extensions or using them in extensions which further customize the sections
> > in the kernel.

Just thought of more more justification I had forgotten. I cover it below.

> Documentation is good, but not necessary to have the extra name indirection.

Fair point.

> Sections tend (not always, but it would be nice if they did) to follow the
> .name convention, which makes them reasonably easy to grep for.

git grep .text  doesn't work but that is typically expected...
git grep \.text doesn't work as expected

Ah finally:

git grep "\.text" seems to work. But WTF.

But:

git grep SECTION_TEXT works as expected immediately.

I guess its a matter of perspective.

> They are also
> the names you'll be grepping for when you look at disassembly.

Sure but if you're grepping asm, you very likely know what to look for.

> > > > +/**
> > > > + * DOC: SECTION_TEXT
> > > > + *
> > > > + * Macro name used to annotate code (functions) used during regular
> > > > + * kernel run time. This is combined with `SECTION_RODATA`, only this
> > > > + * section also allows for execution.
> > > > + *
> > > > + */
> > > > +#define SECTION_TEXT   .text  
> > > 
> > > I can't see how these comments are right. .rodata doesn't seem like it
> > > should be combined with .text, and is not currently on powerpc. I think
> > > it's for data, not code.  
> > 
> > On x86 and powerpc .rodata follows .text.
> 
> But follows is not the same as combined.

True and as I confirmed below, on PowerPC this is certainly not true.

> And together with the comment that RODATA is for code (which is wrong, it's 
> data),

Where did I have that? If you refer to the above SECTION_TEXT documentation, it
refers to SECTION_TEXT being for code, but the goal was to highlight that
SECTION_TEXT is for execution, while SECTION_RODATA was for data. This
certainly can use some love though, thanks, will just drop the SECTION_RODATA
reference *or* properly explain the whole thing below.

> it make it seem like it is actually combined.

Will fix to ensure this is understood in proper context.

> > On power currently the comment
> > above in .rodata is:
> > 
> > /* Text, read only data and other permanent read-only sections */
> > 
> > When this was introduced however read commit 14cf11af6cf60 ("powerpc: Merge
> > enough to start building in arch/powerpc.")
> > 
> > /* Read-only sections, merged into text segment: */
> > 
> > The format and style of putting rodata after text is kept from the older
> > commits.
> > 
> > This begs the question. What the hell is this thing talking about?
> > 
> > On Linux this is done via mark_rodata_ro() on init/main.c when 
> > CONFIG_DEBUG_RODATA
> > on architectures that support it. Architectures that implement this 
> > typically use
> > issues set_memory_ro() -- on x86 a start address used is PFN_ALIGN(_text) 
> > with
> > an end address of &__end_rodata_hpage_align.
> > 
> > When architectures do not have CONFIG_DEBUG_RODATA() you end up with:
> > 
> > static inline void mark_readonly(void)  
> > 
> > {   
> > 
> > pr_warn("This architecture does not have kernel memory 
> > protection.\n"); 
> > }
> > 
> > So -- I should I clarify then in Linux we strive to have helpers adjust 
> > text and
> > rodata set to ro with memory protection implemented via mark_readonly(). 
> > Architectures
> > that do not support memory protection will lack a mark_readonly() 
> > implementation.
> 
> Right, I wasn't talking about arch implementation of how the ro
> protection is done, so much as just the comments being a bit misleading.

Sure, got it, thanks, will fix.

> > For now I figured a less controversial introduction to the 

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

[Daniel De Graaf]

On 08/24/2016 04:06 AM, Jan Beulich wrote:

Non-debugging message text should be (and is in the cases here)
distinguishable without also logging function names.

Signed-off-by: Jan Beulich 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH v3] xen: Make VPMU init message look less scary

[David Vrabel]

On 02/08/16 08:22, Juergen Gross wrote:
> The default for the Xen hypervisor is to not enable VPMU in order to
> avoid security issues. In this case the Linux kernel will issue the
> message "Could not initialize VPMU for cpu 0, error -95" which looks
> more like an error than a normal state.
> 
> Change the message to something less scary in case the hypervisor
> returns EOPNOTSUPP or ENOSYS when trying to activate VPMU.

Applied to for-linus-4.9, thanks.

David

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

Re: [Xen-devel] [PATCH v2] xen: rename xen_pmu_init() in sys-hypervisor.c

[David Vrabel]

On 02/08/16 07:53, Juergen Gross wrote:
> There are two functions with name xen_pmu_init() in the kernel. Rename
> the one in drivers/xen/sys-hypervisor.c to avoid shadowing the one in
> arch/x86/xen/pmu.c
> 
> To avoid the same problem in future rename some more functions.

Applied to for-linus-4.9, thanks.

David

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

Re: [Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

[David Vrabel]

On 03/08/16 18:22, Boris Ostrovsky wrote:
> Original version of that patch (commit a89941816726) had to be reverted
> due to Xen allocating irqs in its cpu_up ops.
> 
> The first patch moves allocations into hotplug notifiers and the second
> one restores the original patch (with minor adjustments to new hotplug
> framework)
> 
> This originally went through tip tree but after a couple of failures
> reportedby kbuild robot (due to various combinations of CONFIG_SMP and
> CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems
> hopefully finally fixed).

Applied to for-linus-4.9, thanks.

David

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

Re: [Xen-devel] [PATCH linux v2] xen: change the type of xen_vcpu_id to uint32_t

[David Vrabel]

On 29/07/16 10:06, Vitaly Kuznetsov wrote:
> We pass xen_vcpu_id mapping information to hypercalls which require
> uint32_t type so it would be cleaner to have it as uint32_t. The
> initializer to -1 can be dropped as we always do the mapping before using
> it and we never check the 'not set' value anyway.

Applied to for-linus-4.8b, thanks.

David

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

Re: [Xen-devel] [PATCH] xenbus: don't look up transaction IDs for ordinary writes

[David Vrabel]

On 15/08/16 16:02, Jan Beulich wrote:
> This should really only be done for XS_TRANSACTION_END messages, or
> else at least some of the xenstore-* tools don't work anymore.

Applied to for-linus-4.8b, thanks.

David

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

[Xen-devel] [GIT PULL] xen: regression fix for 4.8-rc3

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.8b-rc3-tag

xen: regression fix for 4.8-rc3

- - Fix a regression in the xenbus device preventing userspace tools
  from working.

Thanks.

David

 arch/arm/xen/enlighten.c | 2 +-
 arch/x86/xen/enlighten.c | 2 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c | 2 +-
 include/xen/xen-ops.h| 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

Jan Beulich (1):
  xenbus: don't look up transaction IDs for ordinary writes

Vitaly Kuznetsov (1):
  xen: change the type of xen_vcpu_id to uint32_t
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXvdwIAAoJEFxbo/MsZsTR9mAH/1E/8K10KzhYXWy1hS9/Vsfz
Kn2l3ymT8RAANRHq3fL/wFMF+6KPKxbJ7A3CSkismPLZTnPA4WuKp/CiLEVBS3vm
GONWXLBlcWVttAxfsMd9tFAz9VHP2MsYy2iRzaTeBmmouBrjKb/FygUctHgPhGjI
9793Pw10TfVEc2efmSM06c6Jfy26mcclQ8gisOlT6TyjJbBMiRXhc2LjHDpD9jYy
wIKirBwSaL7oN+CM1ua/apu+n7h/bXg+bSsDWqdu7e+vETgVxwrk5kflgcENf+pO
bBn5LR8fMeFd6WrQfWkVpSX7gRFBBAH+XkMdYo7C/s5MYuL143dVdq9ZbAlfVr8=
=L0YJ
-END PGP SIGNATURE-

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

Re: [Xen-devel] [PATCH] Xen: remove -fshort-wchar gcc flag

[David Vrabel]

On 11/08/16 13:39, Arnd Bergmann wrote:
> A previous patch added the --no-wchar-size-warning to the Makefile to
> avoid this harmless warning:
> 
> arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the 
> output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
> 
> Changing kbuild to use thin archives instead of recursive linking
> unfortunately brings the same warning back during the final link.
> 
> This time, we remove the -fshort-wchar flag that originally caused
> the warning, hopefully fixing the problem for good. I don't see
> any reason for having the flag in the first place, as the Xen code
> does not use wchar_t at all.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 971a69db7dc0 ("Xen: don't warn about 2-byte wchar_t in efi")

Acked-by: David Vrabel 

David

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

[Xen-devel] [RFC] Classify and remove (some) abort()s in libxl

[Wei Liu]

Hi all

There has been some interest in removing abort() in libxl in another
thread. I think this topic deserves a dedicated thread.

I've checked most instances of abort() and exit() in code and classify
them as several classes.

* System has entered an impossible to recover state

Can't be removed, there is no meaningful return code to return.

E.g. libxl_utils.c, libxl_event.c, libxl_exec.c and libxl_fork.c

* Used by some stub functions

Can be classified as "impossible to recover state" because caller
shouldn't have use them in the first place. But can be relaxed to
return error code.

* Configuration error

Some internal functions expect sanitised input. Up until now the
expectation (at least AIUI) is that libxl should have sanitised those
values before calling internal functions. I'm not sure if this rule is
strictly followed though.

The abort() in this class can be and turn into error return path.

E.g. various devices and domain configuration options

* Memory allocation failure

Actually exit() is called, but process will exit anyway.  Can't be
easily changed without rewriting error handle logic across libxl.


The "configuration error" class is the easiest one to trip over for
library user. I think we can change that class to return error code
provided there is enough interest.

The "stub functions" class can also be dealt with, but I'm not too keen
on changing that.


Wei.

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

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

[Jan Beulich]

Another place where we should try to behave like real hardware; see
the code comments.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
 if ( !edx )
 edx = 
 
+if ( input & 0x )
+{
+/*
+ * Requests beyond the highest supported leaf within a group return
+ * zero on AMD and the highest basic leaf output on others.
+ */
+unsigned int lvl;
+
+hvm_cpuid(input & 0x, , NULL, NULL, NULL);
+if ( ((lvl ^ input) >> 16) || input > lvl )
+{
+if ( d->arch.x86_vendor == X86_VENDOR_AMD )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+if ( input >> 16 )
+hvm_cpuid(0, , NULL, NULL, NULL);
+input = lvl;
+}
+}
+
 if ( cpuid_viridian_leaves(input, eax, ebx, ecx, edx) )
 return;
 
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -944,7 +944,40 @@ void pv_cpuid(struct cpu_user_regs *regs
 struct vcpu *curr = current;
 struct domain *currd = curr->domain;
 
-leaf = a = regs->eax;
+leaf = regs->eax;
+
+if ( leaf & 0x )
+{
+/*
+ * Requests beyond the highest supported leaf within a group return
+ * zero on AMD and the highest basic leaf output on others.
+ */
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, leaf & 0x, 0, , , , );
+else
+a = cpuid_eax(leaf & 0x);
+if ( ((a ^ leaf) >> 16) || leaf > a )
+{
+if ( currd->arch.x86_vendor == X86_VENDOR_AMD )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+if ( leaf >> 16 )
+{
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 0, 0, , , , );
+else
+a = cpuid_eax(0);
+}
+leaf = a;
+}
+}
+
+a = regs->eax;
 b = regs->ebx;
 subleaf = c = regs->ecx;
 d = regs->edx;



x86: correct CPUID output for out of bounds input

Another place where we should try to behave like real hardware; see
the code comments.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3358,6 +3358,31 @@ void hvm_cpuid(unsigned int input, unsig
 if ( !edx )
 edx = 
 
+if ( input & 0x )
+{
+/*
+ * Requests beyond the highest supported leaf within a group return
+ * zero on AMD and the highest basic leaf output on others.
+ */
+unsigned int lvl;
+
+hvm_cpuid(input & 0x, , NULL, NULL, NULL);
+if ( ((lvl ^ input) >> 16) || input > lvl )
+{
+if ( d->arch.x86_vendor == X86_VENDOR_AMD )
+{
+*eax = 0;
+*ebx = 0;
+*ecx = 0;
+*edx = 0;
+return;
+}
+if ( input >> 16 )
+hvm_cpuid(0, , NULL, NULL, NULL);
+input = lvl;
+}
+}
+
 if ( cpuid_viridian_leaves(input, eax, ebx, ecx, edx) )
 return;
 
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -944,7 +944,40 @@ void pv_cpuid(struct cpu_user_regs *regs
 struct vcpu *curr = current;
 struct domain *currd = curr->domain;
 
-leaf = a = regs->eax;
+leaf = regs->eax;
+
+if ( leaf & 0x )
+{
+/*
+ * Requests beyond the highest supported leaf within a group return
+ * zero on AMD and the highest basic leaf output on others.
+ */
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, leaf & 0x, 0, , , , );
+else
+a = cpuid_eax(leaf & 0x);
+if ( ((a ^ leaf) >> 16) || leaf > a )
+{
+if ( currd->arch.x86_vendor == X86_VENDOR_AMD )
+{
+regs->eax = 0;
+regs->ebx = 0;
+regs->ecx = 0;
+regs->edx = 0;
+return;
+}
+if ( leaf >> 16 )
+{
+if ( !is_control_domain(currd) && !is_hardware_domain(currd) )
+domain_cpuid(currd, 0, 0, , , , );
+else
+a = cpuid_eax(0);
+}
+leaf = a;
+}
+}
+
+a = regs->eax;
 b = regs->ebx;
 subleaf = c = regs->ecx;
 d = regs->edx;
___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH] x86: correct PT_NOTE file position

[Jan Beulich]

Program and section headers disagreed about the file offset at which
the build ID note lives.

Reported-by: Sylvain Munaut 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -394,7 +394,7 @@ int main(int argc, char **argv)
 note_phdr.p_paddr   = note_base;
 note_phdr.p_filesz  = note_sz;
 note_phdr.p_memsz   = note_sz;
-note_phdr.p_offset  = offset;
+note_phdr.p_offset  = RAW_OFFSET + offset;
 
 /* Tack on the .note\0 */
 out_shdr[2].sh_size += sizeof(out_shstrtab_extra);



x86: correct PT_NOTE file position

Program and section headers disagreed about the file offset at which
the build ID note lives.

Reported-by: Sylvain Munaut 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -394,7 +394,7 @@ int main(int argc, char **argv)
 note_phdr.p_paddr   = note_base;
 note_phdr.p_filesz  = note_sz;
 note_phdr.p_memsz   = note_sz;
-note_phdr.p_offset  = offset;
+note_phdr.p_offset  = RAW_OFFSET + offset;
 
 /* Tack on the .note\0 */
 out_shdr[2].sh_size += sizeof(out_shstrtab_extra);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 07/16] libxl/arm: Construct ACPI GTDT table

[Roger Pau Monné]

On Wed, Aug 24, 2016 at 01:56:04PM +0100, Wei Liu wrote:
> On Tue, Aug 16, 2016 at 06:25:04PM +0800, Shannon Zhao wrote:
> > From: Shannon Zhao 
> > 
> > Construct GTDT table with the interrupt information of timers.
> > 
> > Signed-off-by: Shannon Zhao 
> > ---
> >  tools/libxl/libxl_arm_acpi.c | 29 +
> >  1 file changed, 29 insertions(+)
> > 
> > diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> > index 8cd1d9b..28fb6fe 100644
> > --- a/tools/libxl/libxl_arm_acpi.c
> > +++ b/tools/libxl/libxl_arm_acpi.c
> > @@ -24,10 +24,18 @@ typedef uint8_t u8;
> >  typedef uint16_t u16;
> >  typedef uint32_t u32;
> >  typedef uint64_t u64;
> > +typedef int64_t s64;
> >  
> >  #include 
> >  #include 
> >  
> > +#include 
> 
> Hmm... This is likely to be Linux-centric. But I'm not sure if FreeBSD
> or other BSDes have plan for Xen on ARM support.

I would certainly love to see that happen, but I don't see myself working on 
that in the near future. In any case, this is a Linux-specific header, and 
should be included in libxl_osdeps.h. I would recommend that you use 
something like:

#ifndef BITS_PER_LONG
#ifdef _LP64
#define BITS_PER_LONG 64
#else
#define BITS_PER_LONG 32
#endif
#endif

So that it works on other systems also (or maybe you don't even need to 
include bitsperlong.h at all).

Roger.

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

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

[osstest service owner]

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

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  fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
baseline version:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da

Last test of basis   100583  2016-08-22 14:01:54 Z1 days
Testing same since   100606  2016-08-24 12:01:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Lars Kurth 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
+ . ./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 
fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
+ branch=xen-unstable-smoke
+ revision=fb3cc1796201b249f5bee2b8b3583d279fb4d7cf
+ . ./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
+ '[' xfb3cc1796201b249f5bee2b8b3583d279fb4d7cf = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print 

Re: [Xen-devel] Memory sizes obtained from the hypervisor

[Jan Beulich]

>>> On 24.08.16 at 13:38,  wrote:
> During test of HVMlite Mini-OS I found that the memory size obtained
> via HYPERVISOR_memory_op(XENMEM_current_reservation) was higher than
> expected: for a 16MB domain the number of pages was 8 pages larger than
> I thought it should be. This seems to include the p2m map allocated by
> the toolstack.

I don't think that should be counted separately.

> The size returned by HYPERVISOR_memory_op(XENMEM_maximum_reservation)
> was 1MB larger than expected (additional space for first MB?).

Isn't that the result of XSA-153?

Overall the question here really is whether the values read match
the values previously set (by the tool stack).

Jan


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

Re: [Xen-devel] [PATCH v4 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Jan Beulich]

>>> On 24.08.16 at 15:06,  wrote:
> CC Jan and Andrew to review change in hvm/params.h

Well, it looks reasonable, but this really needs to first be approved by
the ARM maintainers.

Jan

> On Tue, Aug 16, 2016 at 06:25:11PM +0800, Shannon Zhao wrote:
>> From: Shannon Zhao 
>> 
>> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
>> them in evtchn_fixup().
>> 
>> Signed-off-by: Shannon Zhao 
>> ---
>>  xen/arch/arm/domain_build.c | 8 +---
>>  xen/include/public/hvm/params.h | 4 
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>> 
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index 60db9e4..94cd3ce 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -2019,9 +2019,11 @@ static void evtchn_fixup(struct domain *d, struct 
> kernel_info *kinfo)
>> d->arch.evtchn_irq);
>>  
>>  /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
>> -val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
>> -val |= (2 << 8); /* Active-low level-sensitive  */
>> -val |= d->arch.evtchn_irq & 0xff;
>> +val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 
> HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
>> +/* Active-low level-sensitive  */
>> +val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
>> +HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
>> +val |= d->arch.evtchn_irq & HVM_PARAM_CALLBACK_TYPE_PPI_MASK;
>>  d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
>>  
>>  /*
>> diff --git a/xen/include/public/hvm/params.h 
>> b/xen/include/public/hvm/params.h
>> index f7338a3..8a0327d 100644
>> --- a/xen/include/public/hvm/params.h
>> +++ b/xen/include/public/hvm/params.h
>> @@ -30,6 +30,7 @@
>>   */
>>  
>>  #define HVM_PARAM_CALLBACK_IRQ 0
>> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
>>  /*
>>   * How should CPU0 event-channel notifications be delivered?
>>   *
>> @@ -66,6 +67,9 @@
>>   * This is only used by ARM/ARM64 and masking/eoi the interrupt associated 
> to
>>   * the notification is handled by the interrupt controller.
>>   */
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_MASK   0xff
>>  #endif
>>  
>>  /*
>> -- 
>> 2.0.4
>> 
>> 




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

Re: [Xen-devel] [PATCH v4 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Wei Liu]

CC Jan and Andrew to review change in hvm/params.h

On Tue, Aug 16, 2016 at 06:25:11PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Add macros for HVM_PARAM_CALLBACK_TYPE_PPI operation values and update
> them in evtchn_fixup().
> 
> Signed-off-by: Shannon Zhao 
> ---
>  xen/arch/arm/domain_build.c | 8 +---
>  xen/include/public/hvm/params.h | 4 
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 60db9e4..94cd3ce 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -2019,9 +2019,11 @@ static void evtchn_fixup(struct domain *d, struct 
> kernel_info *kinfo)
> d->arch.evtchn_irq);
>  
>  /* Set the value of domain param HVM_PARAM_CALLBACK_IRQ */
> -val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 56;
> -val |= (2 << 8); /* Active-low level-sensitive  */
> -val |= d->arch.evtchn_irq & 0xff;
> +val = (u64)HVM_PARAM_CALLBACK_TYPE_PPI << 
> HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT;
> +/* Active-low level-sensitive  */
> +val |= (HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL <<
> +HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT);
> +val |= d->arch.evtchn_irq & HVM_PARAM_CALLBACK_TYPE_PPI_MASK;
>  d->arch.hvm_domain.params[HVM_PARAM_CALLBACK_IRQ] = val;
>  
>  /*
> diff --git a/xen/include/public/hvm/params.h b/xen/include/public/hvm/params.h
> index f7338a3..8a0327d 100644
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -30,6 +30,7 @@
>   */
>  
>  #define HVM_PARAM_CALLBACK_IRQ 0
> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
>  /*
>   * How should CPU0 event-channel notifications be delivered?
>   *
> @@ -66,6 +67,9 @@
>   * This is only used by ARM/ARM64 and masking/eoi the interrupt associated to
>   * the notification is handled by the interrupt controller.
>   */
> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
> +#define HVM_PARAM_CALLBACK_TYPE_PPI_MASK   0xff
>  #endif
>  
>  /*
> -- 
> 2.0.4
> 
> 

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

Re: [Xen-devel] Do people want a Developer Meeting on Aug 24th (before Dev Summit)

[Neil Sikka]

Hey guys, is anything happening today regarding a meeting or going out for
lunch if people arrive a day early?

On Thu, Jun 23, 2016 at 8:43 AM, Lars Kurth 
wrote:

>
> > On 23 Jun 2016, at 12:39, George Dunlap 
> wrote:
> >
> > On 23/06/16 12:33, Lars Kurth wrote:
> >> Folks,
> >>
> >> do you guys want to hold a Developer Meeting on Aug 24th (before Dev
> Summit). I do have space to do this, but last year's was very poorly
> attended. If you could get back to me with an opinion, that would help
> hugely. Alternatively it would also be possible to use the space for more
> focused meetings with fewer people. In that case, I would need a number of
> suggestions for meetings including meeting leaders.
> >>
> >> Please have a look at the schedule http://events.linuxfoundation.
> org/events/xen-project-developer-summit/program/schedule ... note that on
> the 26th, I kept the 2nd room free and was planning to use the Hackathon
> format in parallel to the talks in the main program. rather than having
> BoFs interspersed with talks. Some of the slots could be used to host the
> developer meeting, of desired.
> >
> > So to a large degree, the actual nuts-and-bolts planning which that
> > meeting was meant to cover happens now at the "hackathons" instead.
> > It's important I think, however, for the XenSummit to have a venue for
> > people in the industry who may not know about the Hackathons (or for
> > whatever reason can't come to them) to raise issues with the core
> > developers and have them discussed.
> >
> > If the parallel track could actually fulfill that role, then I think it
> > would be enough; the key would be making sure that the appropriate
> > attention could be attracted.
>
> That's why I asked. Maybe we can come up with a short list of topics that
> need to be discussed and are worthwhile for the developer meetings.
>
> The idea behind using the Hackathon scheduling methodology for the
> parallel track is an experiment to make assigning of topics to space mor
> effective than in the past.
>
> I don't have an opinion one way or another. We can have a developer
> meeting as well. Just shout and I will set it up.
>
> Lars
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>



-- 
My Blog: http://www.neilscomputerblog.blogspot.com/
Twitter: @neilsikka
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 00/16] Xen ARM DomU ACPI support

[Wei Liu]

On Tue, Aug 16, 2016 at 06:24:57PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> The design of this feature is described as below.
> Firstly, the toolstack (libxl) generates the ACPI tables according the
> number of vcpus and gic controller.
> 
> Then, it copies these ACPI tables to DomU non-RAM memory map space and
> passes them to UEFI firmware through the "ARM multiboot" protocol.
> 
> At last, UEFI gets the ACPI tables through the "ARM multiboot" protocol
> and installs these tables like the usual way and passes both ACPI and DT
> information to the Xen DomU.
> 
> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT, DSDT tables
> since it's enough now.
> 
> This has been tested using guest kernel with the Dom0 ACPI support
> patches which could be fetched from linux master or:
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> The UEFI binary could be fetched from or built from edk2 master branch:
> http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
> 
> This series can be fetched from:
> https://git.linaro.org/people/shannon.zhao/xen.git  domu_acpi_v4
> 

Thanks for posting this version and sorry for the late review.

I've skimmed the whole series and pointed out things I think should be
improved. I will leave reviewing all the table building code to ARM
maintainers.

Wei.

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

Re: [Xen-devel] [PATCH v4 07/16] libxl/arm: Construct ACPI GTDT table

[Wei Liu]

On Tue, Aug 16, 2016 at 06:25:04PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Construct GTDT table with the interrupt information of timers.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arm_acpi.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 8cd1d9b..28fb6fe 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -24,10 +24,18 @@ typedef uint8_t u8;
>  typedef uint16_t u16;
>  typedef uint32_t u32;
>  typedef uint64_t u64;
> +typedef int64_t s64;
>  
>  #include 
>  #include 
>  
> +#include 

Hmm... This is likely to be Linux-centric. But I'm not sure if FreeBSD
or other BSDes have plan for Xen on ARM support.

CC Roger here.

> +#define ACPI_MACHINE_WIDTH __BITS_PER_LONG
> +#define COMPILER_DEPENDENT_INT64 int64_t
> +#define COMPILER_DEPENDENT_UINT64 uint64_t
> +
> +#include 
> +
>  _hidden
>  extern const unsigned char dsdt_anycpu_arm[];
>  _hidden
> @@ -175,6 +183,26 @@ static void make_acpi_xsdt(libxl__gc *gc, struct 
> xc_dom_image *dom,
> acpitables[XSDT].size);
>  }
>  
> +static void make_acpi_gtdt(libxl__gc *gc, struct xc_dom_image *dom,
> +   struct acpitable acpitables[])
> +{
> +uint64_t offset = acpitables[GTDT].addr - GUEST_ACPI_BASE;
> +struct acpi_table_gtdt *gtdt = (void *)dom->acpi_modules[0].data + 
> offset;
> +
> +gtdt->non_secure_el1_interrupt = GUEST_TIMER_PHYS_NS_PPI;
> +gtdt->non_secure_el1_flags =
> + (ACPI_LEVEL_SENSITIVE << 
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW << 
> ACPI_GTDT_INTERRUPT_POLARITY);
> +gtdt->virtual_timer_interrupt = GUEST_TIMER_VIRT_PPI;
> +gtdt->virtual_timer_flags =
> + (ACPI_LEVEL_SENSITIVE << 
> ACPI_GTDT_INTERRUPT_MODE)
> + |(ACPI_ACTIVE_LOW << 
> ACPI_GTDT_INTERRUPT_POLARITY);
> +
> +make_acpi_header(>header, "GTDT", acpitables[GTDT].size, 2);
> +calculate_checksum(gtdt, offsetof(struct acpi_table_header, checksum),
> +   acpitables[GTDT].size);
> +}
> +
>  int libxl__prepare_acpi(libxl__gc *gc, libxl_domain_build_info *info,
>  libxl__domain_build_state *state,
>  struct xc_dom_image *dom)
> @@ -205,6 +233,7 @@ int libxl__prepare_acpi(libxl__gc *gc, 
> libxl_domain_build_info *info,
>  
>  make_acpi_rsdp(gc, dom, acpitables);
>  make_acpi_xsdt(gc, dom, acpitables);
> +make_acpi_gtdt(gc, dom, acpitables);
>  
>  out:
>  return rc;
> -- 
> 2.0.4
> 
> 

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

Re: [Xen-devel] [PATCH v4 05/16] libxl/arm: Construct ACPI RSDP table

[Wei Liu]

On Tue, Aug 16, 2016 at 06:25:02PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Construct ACPI RSDP table and add a helper to calculate the ACPI table
> checksum.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_arm_acpi.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/tools/libxl/libxl_arm_acpi.c b/tools/libxl/libxl_arm_acpi.c
> index 6be9eb0..9432e44 100644
> --- a/tools/libxl/libxl_arm_acpi.c
> +++ b/tools/libxl/libxl_arm_acpi.c
> @@ -33,6 +33,9 @@ extern const unsigned char dsdt_anycpu_arm[];
>  _hidden
>  extern const int dsdt_anycpu_arm_len;
>  
> +#define ACPI_BUILD_APPNAME6 "XenARM"
> +#define ACPI_BUILD_APPNAME4 "Xen "
> +

Where do these come from? If they are from a spec, could you please add
a comment here?

>  enum {
>  RSDP,
>  XSDT,
> @@ -112,6 +115,37 @@ out:
>  return rc;
>  }
>  
> +static void calculate_checksum(void *table, uint32_t checksum_offset,
> +   uint32_t length)
> +{
> +uint8_t *p, sum = 0;
> +
> +p = table;
> +p[checksum_offset] = 0;
> +
> +while ( length-- )

Coding style.

Wei.

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

Re: [Xen-devel] [PATCH v4 01/16] tools/libxl: Add an unified configuration option for ACPI

[Wei Liu]

On Tue, Aug 16, 2016 at 06:24:58PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Since the existing configuration option "u.hvm.acpi" is x86 specific and
> we want to reuse it on ARM as well, add a unified option "acpi" for
> x86 and ARM, and for ARM it's disabled by default.
> 
> Signed-off-by: Shannon Zhao 
> ---
>  tools/libxl/libxl_create.c  | 9 -
>  tools/libxl/libxl_dm.c  | 6 --
>  tools/libxl/libxl_types.idl | 4 
>  tools/libxl/xl_cmdimpl.c| 2 +-
>  4 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index 08822e3..3043b1f 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -215,6 +215,12 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
>  if (!b_info->event_channels)
>  b_info->event_channels = 1023;
>  
> +#if defined(__arm__) || defined(__aarch64__)
> +libxl_defbool_setdefault(_info->acpi, false);
> +#else
> +libxl_defbool_setdefault(_info->acpi, true);
> +#endif
> +

I recently thought about how to handle the divergence between ARM and
x86. It would make sense to have an
libxl__arch_domain_build_info_acpi_setdefault here.

>  switch (b_info->type) {
>  case LIBXL_DOMAIN_TYPE_HVM:
>  if (b_info->shadow_memkb == LIBXL_MEMKB_DEFAULT)
> @@ -454,7 +460,8 @@ int libxl__domain_build(libxl__gc *gc,
>  localents = libxl__calloc(gc, 9, sizeof(char *));
>  i = 0;
>  localents[i++] = "platform/acpi";
> -localents[i++] = libxl_defbool_val(info->u.hvm.acpi) ? "1" : "0";
> +localents[i++] = (libxl_defbool_val(info->acpi) &&
> + libxl_defbool_val(info->u.hvm.acpi)) ? "1" : "0";

Please provide a function for this.

And the logic doesn't seem right. If the user sets u.hvm.acpi only,
(s)he should still have ACPI enabled.

Wei.

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

Re: [Xen-devel] [PATCH v3 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support

[Joao Martins]

[Missed CC-ing the maintainers in the cover letter, my apologies]

On 08/24/2016 01:43 PM, Joao Martins wrote:
> Hey!
> 
> This is v3 on the pvclock TSC stable bit series.
> 
> Complete changelog on individual patches but overall is addressing
> Jan's comments, plus some other changes regarding the recent monotonicity
> improvements on x86/time.
> 
> Series is divided as follows:
> 
>  R  * Patch 1: Small refactor around init_platform_time to reuse
>initialization code when switching to TSC.
>  U  * Patch 2: Adds a new clocksource based on TSC
>  U,U* Patch 3, 4: Adjustments for patch 5
>  U  * Patch 5: Implements the PVCLOCK_TSC_STABLE_BIT
>  N  * Patch 6: Document new clocksource
> 
> [ R := Reviewed-by ;; U := Updated ;; N := New ]
> 
> I kept the series the same but a fundamental difference from previous
> versions is that I stop clocksource=tsc from being used at all if hotplug is
> possible. To facilitate the review I kept it on Patch 5 as originally posted,
> whereas clocksource is added in Patch 2. But if preferred I can merge these 
> two.
> 
> The main benefit of this series is two-fold:
>  
>  1. Provide the guarantee of monotonic results on xen own system time as seen
>  by any cpu when using TSC as clocksource.
> 
>  2. Provide this same guarantee to guests and thus set the
>  TSC_STABLE_BIT (both FreeBSD and Linux support it) which then allows guests 
> to
>  skip expensive monotonicity check between PV CPU time infos. Plus, on Linux
>  specifically this also means that it could support vDSO which greatly 
> increases
>  performance (x10) for gettimeofday and clock_gettime since it would no
>  longer need to do the system call to get a reliable snapshot of system time.
>  For a reference on my laptop the speed of gettimeofday under xen pvclock is 
>  ~2 Mops/sec (Million ops per sec) whereas with vDSO it's on the range
>  of ~22 Mops/sec on <= 4.4 kernels and ~37 Mops on >= 4.5.
>  
>  Doing a long running time warp test for the past days on a dual-socket 
> Haswell
>  machine and I haven't yet seen time going backwards.
> 
> Thanks!
> Joao
> 
> Joao Martins (6):
>   x86/time: refactor init_platform_time()
>   x86/time: implement tsc as clocksource
>   x86/time: streamline platform time init on plt_update()
>   x86/time: refactor read_platform_stime()
>   x86/time: implement PVCLOCK_TSC_STABLE_BIT
>   docs: update clocksource option
> 
>  docs/misc/xen-command-line.markdown |   6 +-
>  xen/arch/x86/platform_hypercall.c   |   3 +-
>  xen/arch/x86/time.c | 226 
> +++-
>  xen/include/asm-x86/time.h  |   1 +
>  4 files changed, 205 insertions(+), 31 deletions(-)
> 

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

Re: [Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files

[Lars Kurth]

On 24/08/2016 06:10, "Wei Liu"  wrote:

>
>> diff --git a/stubdom/vtpmmgr/README.source
>>b/stubdom/vtpmmgr/README.source
>> new file mode 100644
>> index 000..1b45997
>> --- /dev/null
>> +++ b/stubdom/vtpmmgr/README.source
>> @@ -0,0 +1,23 @@
>> +About
>> +=
>> +This documents the upstream sources for files in this directory.
>> +
>> +The following files are based off of the original
>> +tools/vtpm_manager code base in xen.git, which has since been
>> +deleted: 
>> +
>
>It doesn't seem obvious to me during my archeology.
>
>tools/vtpm_manager was deleted in
>b918dce5bb2a665a34ff893a9df5392fb8ea429d, but it is not clear whether
>your claim (the new code based off the deleted files) is true.
>
>For one, there is no uuid.h in the deleted code -- apparently vtpm
>wouldn't have to ship its own uuid library because OS has one. But then,
>there is such claim in the new uuid.h, so I'm rather confused. I'm
>inclined to believe that this uuid.h is either written afresh or
>imported from somewhere else.
>
>It would also be helpful if you can post your methodology for getting
>the list of file so that I can check if there is something either you or
>I miss.

I merely copied the claims from the existing (c) header files in the
files below, which all say

  5 * based off of the original tools/vtpm_manager code base which is:
  6 * Copyright (c) 2005, Intel Corp.
  7 * All rights reserved.


So I was merely restating the information, which was already present,
assuming that it is in fact correct. Uuid.h seems to have been introduced
in the same commit as all the files below.

>
>New line please.

Will fix the newline and other issues.

Lars

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

Re: [Xen-devel] mkelf32 incorrectly filling out the program headers for NOTE

[Sylvain Munaut]

Hi Jan,


> Indeed, patch in the works. But why did you not provide a patch
> yourself, considering that you've done all the diagnosis?

I read the code of that tool this morning and couldn't really
understand how "offset" was computed.

I was seeing :

offset = in64_phdr.p_offset;

then a bit later

offset = in64_phdr.p_offset - offset;

which made no sense to me and so decided I'd better not meddle with
things I didn't understand.


Re-reading it now a bit more awake, I see I completely overlooked that
in64_phdr is changed in the mean time (duh ! not sure how I missed it)
...
I could also have looked at how out_shdr_note.sh_offset is assigned
since that one seems correct and notice the missing RAW_OFFSET.


Next time, I'll give it a fresh second look a day later before
posting, sorry about that.


Cheers,

Sylvain

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

[Xen-devel] [PATCH v3 6/6] docs: update clocksource option

[Joao Martins]

Add TSC as another clocksource that can be used, plus
a mention to the maxcpus parameter and that it requires
being explicitly set.

Signed-off-by: Joao Martins 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 

New in v3.
---
 docs/misc/xen-command-line.markdown | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 3a250cb..210927f 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -264,9 +264,13 @@ minimum of 32M, subject to a suitably aligned and sized 
contiguous
 region of memory being available.
 
 ### clocksource
-> `= pit | hpet | acpi`
+> `= pit | hpet | acpi | tsc`
 
 If set, override Xen's default choice for the platform timer.
+Having TSC as platform timer requires being explicitly set.
+This is because TSC can only be safely used if CPU hotplug isn't performed on
+the system. In some platforms, "maxcpus" parameter may require further
+adjustment to the number of online cpus.
 
 ### cmci-threshold
 > `= `
-- 
2.1.4


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

[Xen-devel] [PATCH v3 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support

[Joao Martins]

Hey!

This is v3 on the pvclock TSC stable bit series.

Complete changelog on individual patches but overall is addressing
Jan's comments, plus some other changes regarding the recent monotonicity
improvements on x86/time.

Series is divided as follows:

 R  * Patch 1: Small refactor around init_platform_time to reuse
   initialization code when switching to TSC.
 U  * Patch 2: Adds a new clocksource based on TSC
 U,U* Patch 3, 4: Adjustments for patch 5
 U  * Patch 5: Implements the PVCLOCK_TSC_STABLE_BIT
 N  * Patch 6: Document new clocksource

[ R := Reviewed-by ;; U := Updated ;; N := New ]

I kept the series the same but a fundamental difference from previous
versions is that I stop clocksource=tsc from being used at all if hotplug is
possible. To facilitate the review I kept it on Patch 5 as originally posted,
whereas clocksource is added in Patch 2. But if preferred I can merge these two.

The main benefit of this series is two-fold:
 
 1. Provide the guarantee of monotonic results on xen own system time as seen
 by any cpu when using TSC as clocksource.

 2. Provide this same guarantee to guests and thus set the
 TSC_STABLE_BIT (both FreeBSD and Linux support it) which then allows guests to
 skip expensive monotonicity check between PV CPU time infos. Plus, on Linux
 specifically this also means that it could support vDSO which greatly increases
 performance (x10) for gettimeofday and clock_gettime since it would no
 longer need to do the system call to get a reliable snapshot of system time.
 For a reference on my laptop the speed of gettimeofday under xen pvclock is 
 ~2 Mops/sec (Million ops per sec) whereas with vDSO it's on the range
 of ~22 Mops/sec on <= 4.4 kernels and ~37 Mops on >= 4.5.
 
 Doing a long running time warp test for the past days on a dual-socket Haswell
 machine and I haven't yet seen time going backwards.

Thanks!
Joao

Joao Martins (6):
  x86/time: refactor init_platform_time()
  x86/time: implement tsc as clocksource
  x86/time: streamline platform time init on plt_update()
  x86/time: refactor read_platform_stime()
  x86/time: implement PVCLOCK_TSC_STABLE_BIT
  docs: update clocksource option

 docs/misc/xen-command-line.markdown |   6 +-
 xen/arch/x86/platform_hypercall.c   |   3 +-
 xen/arch/x86/time.c | 226 +++-
 xen/include/asm-x86/time.h  |   1 +
 4 files changed, 205 insertions(+), 31 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v3 1/6] x86/time: refactor init_platform_time()

[Joao Martins]

And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).

Signed-off-by: Joao Martins 
Reviewed-by: Konrad Rzeszutek Wilk 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v2:
 - Remove pointless intializer and replace it with the
 platform_time init return.
---
 xen/arch/x86/time.c | 30 --
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b316f23..6750e46 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -576,6 +576,24 @@ static void resume_platform_timer(void)
 plt_stamp = plt_src.read_counter();
 }
 
+static s64 __init try_platform_timer(struct platform_timesource *pts)
+{
+s64 rc = pts->init(pts);
+
+if ( rc <= 0 )
+return rc;
+
+plt_mask = (u64)~0ull >> (64 - pts->counter_bits);
+
+set_time_scale(_scale, pts->frequency);
+
+plt_overflow_period = scale_delta(
+1ull << (pts->counter_bits - 1), _scale);
+plt_src = *pts;
+
+return rc;
+}
+
 static u64 __init init_platform_timer(void)
 {
 static struct platform_timesource * __initdata plt_timers[] = {
@@ -593,7 +611,7 @@ static u64 __init init_platform_timer(void)
 pts = plt_timers[i];
 if ( !strcmp(opt_clocksource, pts->id) )
 {
-rc = pts->init(pts);
+rc = try_platform_timer(pts);
 break;
 }
 }
@@ -609,21 +627,13 @@ static u64 __init init_platform_timer(void)
 for ( i = 0; i < ARRAY_SIZE(plt_timers); i++ )
 {
 pts = plt_timers[i];
-if ( (rc = pts->init(pts)) > 0 )
+if ( (rc = try_platform_timer(pts)) > 0 )
 break;
 }
 }
 
 BUG_ON(rc <= 0);
 
-plt_mask = (u64)~0ull >> (64 - pts->counter_bits);
-
-set_time_scale(_scale, pts->frequency);
-
-plt_overflow_period = scale_delta(
-1ull << (pts->counter_bits-1), _scale);
-plt_src = *pts;
-
 printk("Platform timer is %s %s\n",
freq_string(pts->frequency), pts->name);
 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 2/6] x86/time: implement tsc as clocksource

[Joao Martins]

Recent x86/time changes improved a lot of the monotonicity in xen timekeeping,
making it much harder to observe time going backwards.  Although platform timer
can't be expected to be perfectly in sync with TSC and so get_s_time won't be
guaranteed to always return monotonically increasing values across cpus. This
is the case in some of the boxes I am testing with, observing sometimes ~100
warps (of very few nanoseconds each) after a few hours.

This patch introduces support for using TSC as platform time source
which is the highest resolution time and most performant to get (~20
nsecs). Though there are also several problems associated with its
usage, and there isn't a complete (and architecturally defined)
guarantee that all machines will provide reliable and monotonic TSC in
all cases (I believe Intel to be the only that can guarantee that?) For
this reason it's set with less priority when compared to HPET unless
adminstrator changes "clocksource" boot option to "tsc". Initializing
TSC clocksource requires all CPUs up to have the tsc reliability checks
performed. init_xen_time is called before all CPUs are up, and so we
would start with HPET at boot time, and switch later to TSC. The switch
then happens on verify_tsc_reliability initcall that is invoked when all
CPUs are up. When attempting to initialize TSC we also check for time
warps and if it has invariant TSC. And in case none of these conditions
are met, we keep the clocksource that was previously initialized on
init_xen_time. Note that while we deem reliable a CONSTANT_TSC with no
deep C-states, it might not always be the case, so we're conservative
and allow TSC to be used as platform timer only with invariant TSC.

Since b64438c7c ("x86/time: use correct (local) time stamp in
constant-TSC calibration fast path") updates to cpu time use local
stamps, which means platform timer is only used to seed the initial cpu
time. With clocksource=tsc there is no need to be in sync with another
clocksource, so we reseed the local/master stamps to be values of TSC
and update the platform time stamps accordingly. Time calibration is set
to 1sec after we switch to TSC, thus these stamps are reseeded to also
ensure monotonic returning values right after the point we switch to
TSC. This is also to avoid the possibility of having inconsistent
readings in this short period (i.e. until calibration fires).

Signed-off-by: Joao Martins 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v2:
 - Suggest "HPET switching to TSC" only as an example as otherwise it
 would be misleading on platforms not having one.
 - Change init_tsctimer to skip all the tests and assume it's called
 only on reliable TSC conditions and no warps observed. Tidy
 initialization on verify_tsc_reliability as suggested by Konrad.
 - CONSTANT_TSC and max_cstate <= 2 case removed and only allow tsc
   clocksource in invariant TSC boxes.
 - Prefer omit !=0 on init_platform_timer for tsc case.
 - Change comment on init_platform_timer.
 - Add comment on plt_tsc declaration.
 - Reinit CPU time for all online cpus instead of just CPU 0.
 - Use rdtsc_ordered() as opposed to rdtsc()
 - Remove tsc_freq variable and set plt_tsc clocksource frequency
 with the refined tsc calibration.
 - Rework a bit the commit message.

Changes since v1:
 - s/printk/printk(XENLOG_INFO
 - Remove extra space on inner brackets
 - Add missing space around brackets
 - Defer TSC initialization when all CPUs are up.

Changes since RFC:
 - Spelling fixes in the commit message.
 - Remove unused clocksource_is_tsc variable and introduce it instead
 on the patch that uses it.
 - Move plt_tsc from second to last in the available clocksources.
---
 xen/arch/x86/time.c | 82 -
 1 file changed, 81 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 6750e46..b2a11a8 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -475,6 +475,30 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
 }
 
 /
+ * PLATFORM TIMER 4: TSC
+ */
+
+static s64 __init init_tsctimer(struct platform_timesource *pts)
+{
+return pts->frequency;
+}
+
+static u64 read_tsc(void)
+{
+return rdtsc_ordered();
+}
+
+static struct platform_timesource __initdata plt_tsc =
+{
+.id = "tsc",
+.name = "TSC",
+.read_counter = read_tsc,
+.counter_bits = 64,
+/* Not called by init_platform_timer as it is not on the plt_timers array 
*/
+.init = init_tsctimer,
+};
+
+/
  * GENERIC PLATFORM TIMER INFRASTRUCTURE
  */
 
@@ -576,6 +600,21 @@ static void resume_platform_timer(void)
 plt_stamp = plt_src.read_counter();
 }
 
+static void __init reset_platform_timer(void)
+{
+/* Deactivate any timers running */
+kill_timer(_overflow_timer);
+kill_timer(_timer);
+

[Xen-devel] [PATCH v3 4/6] x86/time: refactor read_platform_stime()

[Joao Martins]

To fetch the last read from the clocksource which was used to
calculate system_time. In the case of clocksource=tsc we will
use it to set tsc_timestamp.

Signed-off-by: Joao Martins 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v2:
 - s/plt_stamp_counter/plt_counter/g
 - Move conditional write of stamp out of the locked region.

Changes since v1:
 - Add missing spaces between brackets
 - Move plt_stamp_counter to read_platform_stime()
 - Add signature change in time_calibration_std_rendezvous()
---
 xen/arch/x86/time.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index a03127e..57c1b47 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -575,18 +575,22 @@ static void plt_overflow(void *unused)
 set_timer(_overflow_timer, NOW() + plt_overflow_period);
 }
 
-static s_time_t read_platform_stime(void)
+static s_time_t read_platform_stime(u64 *stamp)
 {
-u64 count;
+u64 plt_counter, count;
 s_time_t stime;
 
 ASSERT(!local_irq_is_enabled());
 
 spin_lock(_timer_lock);
-count = plt_stamp64 + ((plt_src.read_counter() - plt_stamp) & plt_mask);
+plt_counter = plt_src.read_counter();
+count = plt_stamp64 + ((plt_counter - plt_stamp) & plt_mask);
 stime = __read_platform_stime(count);
 spin_unlock(_timer_lock);
 
+if ( stamp )
+*stamp = plt_counter;
+
 return stime;
 }
 
@@ -731,7 +735,7 @@ void cstate_restore_tsc(void)
 if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
 return;
 
-write_tsc(stime2tsc(read_platform_stime()));
+write_tsc(stime2tsc(read_platform_stime(NULL)));
 }
 
 /***
@@ -1050,7 +1054,7 @@ int cpu_frequency_change(u64 freq)
 
 local_irq_disable();
 /* Platform time /first/, as we may be delayed by platform_timer_lock. */
-t->stamp.master_stime = read_platform_stime();
+t->stamp.master_stime = read_platform_stime(NULL);
 curr_tsc = rdtsc_ordered();
 /* TSC-extrapolated time may be bogus after frequency change. */
 /*t->stamp.local_stime = get_s_time_fixed(curr_tsc);*/
@@ -1355,7 +1359,7 @@ static void time_calibration_tsc_rendezvous(void *_r)
 
 if ( r->master_stime == 0 )
 {
-r->master_stime = read_platform_stime();
+r->master_stime = read_platform_stime(NULL);
 r->master_tsc_stamp = rdtsc_ordered();
 }
 atomic_inc(>semaphore);
@@ -1395,7 +1399,7 @@ static void time_calibration_std_rendezvous(void *_r)
 {
 while ( atomic_read(>semaphore) != (total_cpus - 1) )
 cpu_relax();
-r->master_stime = read_platform_stime();
+r->master_stime = read_platform_stime(NULL);
 smp_wmb(); /* write r->master_stime /then/ signal */
 atomic_inc(>semaphore);
 }
@@ -1434,7 +1438,7 @@ void time_latch_stamps(void)
 unsigned long flags;
 
 local_irq_save(flags);
-ap_bringup_ref.master_stime = read_platform_stime();
+ap_bringup_ref.master_stime = read_platform_stime(NULL);
 ap_bringup_ref.local_tsc = rdtsc_ordered();
 local_irq_restore(flags);
 
@@ -1452,7 +1456,7 @@ void init_percpu_time(void)
 t->tsc_scale = per_cpu(cpu_time, 0).tsc_scale;
 
 local_irq_save(flags);
-now = read_platform_stime();
+now = read_platform_stime(NULL);
 tsc = rdtsc_ordered();
 local_irq_restore(flags);
 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 3/6] x86/time: streamline platform time init on plt_update()

[Joao Martins]

And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
only fire in ~180 years (on 2.2 Ghz Broadwell processor).

Signed-off-by: Joao Martins 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v2:
 - Remove pointless intializer and replace it with the
 platform_time init return.
 - s/plt_init/plt_update/g
---
 xen/arch/x86/time.c | 37 +++--
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index b2a11a8..a03127e 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -526,17 +526,31 @@ static s_time_t __read_platform_stime(u64 platform_time)
 return (stime_platform_stamp + scale_delta(diff, _scale));
 }
 
+static void __plt_update(void)
+{
+u64 count;
+
+ASSERT(spin_is_locked(_timer_lock));
+count = plt_src.read_counter();
+plt_stamp64 += (count - plt_stamp) & plt_mask;
+plt_stamp = count;
+}
+
+static void plt_update(void)
+{
+spin_lock_irq(_timer_lock);
+__plt_update();
+spin_unlock_irq(_timer_lock);
+}
+
 static void plt_overflow(void *unused)
 {
 int i;
-u64 count;
 s_time_t now, plt_now, plt_wrap;
 
 spin_lock_irq(_timer_lock);
 
-count = plt_src.read_counter();
-plt_stamp64 += (count - plt_stamp) & plt_mask;
-plt_stamp = count;
+__plt_update();
 
 now = NOW();
 plt_wrap = __read_platform_stime(plt_stamp64);
@@ -630,10 +644,21 @@ static s64 __init try_platform_timer(struct 
platform_timesource *pts)
 
 set_time_scale(_scale, pts->frequency);
 
-plt_overflow_period = scale_delta(
-1ull << (pts->counter_bits - 1), _scale);
 plt_src = *pts;
 
+if ( pts == _tsc )
+{
+plt_update();
+}
+else
+{
+plt_overflow_period = scale_delta(
+1ull << (pts->counter_bits - 1), _scale);
+
+printk(XENLOG_INFO "Platform timer overflow period is %lu msecs\n",
+   plt_overflow_period / MILLISECS(1));
+}
+
 return rc;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH v3 5/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT

[Joao Martins]

This patch proposes relying on host TSC synchronization and
passthrough to the guest, when running on a TSC-safe platform. On
time_calibration we retrieve the platform time in ns and the counter
read by the clocksource that was used to compute system time. We
introduce a new rendezous function which doesn't require
synchronization between master and slave CPUS and just reads
calibration_rendezvous struct and writes it down the stime and stamp
to the cpu_calibration struct to be used later on. We can guarantee that
on a platform with a constant and reliable TSC, that the time read on
vcpu B right after A is bigger independently of the VCPU calibration
error. Since pvclock time infos are monotonic as seen by any vCPU set
PVCLOCK_TSC_STABLE_BIT, which then enables usage of VDSO on Linux.
IIUC, this is similar to how it's implemented on KVM.

This also changes clocksource=tsc initialization to be used only when CPU
hotplug isn't meant to be performed on the host, which will either be when max
vcpus and num_present_cpu are the same.  This is because a newly hotplugged CPU
may not satisfy the condition of having all TSCs synchronized - so when having
tsc clocksource being used we allow offlining CPUs but not onlining any ones
back. Should note that I've yet to see time going backwards in a long running
test in the past few days (in a dual socket machine), plus few other tests I
did on older platforms.

Signed-off-by: Joao Martins 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v2:
 - Add XEN_ prefix to pvclock flags.
 - Adapter time_calibration_rendezvous_tail to have the case of setting master
 tsc/stime and use it for the nop_rendezvous.
 - Removed hotplug CPU option that was added in v1
 - Prevent online of CPUs when clocksource is tsc.
 - Remove use_tsc_stable_bit, since clocksource is only used to seed
 values. So instead we test if hotplug is possible, and prevent clocksource=tsc
 to be used.
 - Remove 1st paragrah of commit message since the behaviour described
   no longer applies since b64438c.

Changes since v1:
 - Change approach to skip std_rendezvous by introducing a
   nop_rendezvous
 - Change commit message reflecting the change above.
 - Use TSC_STABLE_BIT only if cpu hotplug isn't possible.
 - Add command line option to override it if no cpu hotplug is
 intended.
---
 xen/arch/x86/platform_hypercall.c |  3 +-
 xen/arch/x86/time.c   | 59 +++
 xen/include/asm-x86/time.h|  1 +
 3 files changed, 57 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/platform_hypercall.c 
b/xen/arch/x86/platform_hypercall.c
index 780f22d..edef334 100644
--- a/xen/arch/x86/platform_hypercall.c
+++ b/xen/arch/x86/platform_hypercall.c
@@ -631,7 +631,8 @@ ret_t 
do_platform_op(XEN_GUEST_HANDLE_PARAM(xen_platform_op_t) u_xenpf_op)
 if ( ret )
 break;
 
-if ( cpu >= nr_cpu_ids || !cpu_present(cpu) )
+if ( cpu >= nr_cpu_ids || !cpu_present(cpu) ||
+ host_tsc_is_clocksource() )
 {
 ret = -EINVAL;
 break;
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 57c1b47..81db255 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -480,6 +480,13 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
 
 static s64 __init init_tsctimer(struct platform_timesource *pts)
 {
+if ( nr_cpu_ids != num_present_cpus() )
+{
+printk(XENLOG_INFO "TSC: CPU Hotplug intended,"
+   "not using TSC as clocksource\n");
+return 0;
+}
+
 return pts->frequency;
 }
 
@@ -955,6 +962,8 @@ static void __update_vcpu_system_time(struct vcpu *v, int 
force)
 
 _u.tsc_timestamp = tsc_stamp;
 _u.system_time   = t->stamp.local_stime;
+if ( host_tsc_is_clocksource() )
+_u.flags|= XEN_PVCLOCK_TSC_STABLE_BIT;
 
 if ( is_hvm_domain(d) )
 _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
@@ -1328,12 +1337,22 @@ struct calibration_rendezvous {
 };
 
 static void
-time_calibration_rendezvous_tail(const struct calibration_rendezvous *r)
+time_calibration_rendezvous_tail(const struct calibration_rendezvous *r,
+ bool_t master_tsc)
 {
 struct cpu_time_stamp *c = _cpu(cpu_calibration);
 
-c->local_tsc= rdtsc_ordered();
-c->local_stime  = get_s_time_fixed(c->local_tsc);
+if ( master_tsc )
+{
+c->local_tsc= r->master_tsc_stamp;
+c->local_stime  = r->master_stime;
+}
+else
+{
+c->local_tsc= rdtsc_ordered();
+c->local_stime  = get_s_time_fixed(c->local_tsc);
+}
+
 c->master_stime = r->master_stime;
 
 raise_softirq(TIME_CALIBRATE_SOFTIRQ);
@@ -1386,7 +1405,7 @@ static void time_calibration_tsc_rendezvous(void *_r)
 }
 }
 
-time_calibration_rendezvous_tail(r);
+time_calibration_rendezvous_tail(r, false);
 }
 
 /* Ordinary 

Re: [Xen-devel] [PATCH v3 38/38] arm/p2m: Add test of xc_altp2m_change_gfn

[Wei Liu]

On Wed, Aug 17, 2016 at 12:17:14AM +0200, Sergej Proskurin wrote:
> This commit extends xen-access by a simple test of the functionality
> provided by "xc_altp2m_change_gfn". The idea is to dynamically remap a
> trapping gfn to another mfn, which holds the same content as the
> original mfn. On success, the guest will continue to run. Subsequent
> altp2m access violations will trap into Xen and be forced by xen-access
> to switch to the default view (altp2m[0]) as before. The introduced test
> can be invoked by providing the argument "altp2m_remap".
> 
> Signed-off-by: Sergej Proskurin 
> ---
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
> v3: Cosmetic fixes in "xenaccess_copy_gfn" and "xenaccess_change_gfn".
> 
> Added munmap in "copy_gfn" in the second error case.
> 
> Added option "altp2m_remap" selecting the altp2m-remap test.
> ---
>  tools/tests/xen-access/xen-access.c | 162 
> +++-
>  1 file changed, 158 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/tests/xen-access/xen-access.c 
> b/tools/tests/xen-access/xen-access.c
> index eafd7d6..5909a8a 100644
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -38,6 +38,7 @@
>  #include 
>  #include 
>  
> +#define XC_WANT_COMPAT_MAP_FOREIGN_API

I know Razvan already acked this, but general you shouldn't use the
COMPAT APIs. You should use libs/foreignmemory library, which is a
stable library.

>  #include 
>  #include 
>  #include 
> @@ -49,6 +50,8 @@
>  #define START_PFN 0ULL
>  #endif
>  
> +#define INVALID_GFN ~(0UL)
> +
>  #define DPRINTF(a, b...) fprintf(stderr, a, ## b)
>  #define ERROR(a, b...) fprintf(stderr, a "\n", ## b)
>  #define PERROR(a, b...) fprintf(stderr, a ": %s\n", ## b, strerror(errno))
> @@ -72,9 +75,14 @@ typedef struct xenaccess {
>  xen_pfn_t max_gpfn;
>  
>  vm_event_t vm_event;
> +
> +unsigned int ap2m_idx;
> +xen_pfn_t gfn_old;
> +xen_pfn_t gfn_new;
>  } xenaccess_t;
>  
>  static int interrupted;
> +static int gfn_changed = 0;
>  bool evtchn_bind = 0, evtchn_open = 0, mem_access_enable = 0;
>  
>  static void close_handler(int sig)
> @@ -82,6 +90,100 @@ static void close_handler(int sig)
>  interrupted = sig;
>  }
>  
> +static int xenaccess_copy_gfn(xc_interface *xch,
> +  domid_t domain_id,
> +  xen_pfn_t dst_gfn,
> +  xen_pfn_t src_gfn)
> +{
> +void *src_vaddr = NULL;
> +void *dst_vaddr = NULL;
> +
> +src_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
> + PROT_READ, src_gfn);
> +if ( src_vaddr == MAP_FAILED || src_vaddr == NULL)
> +return -1;
> +
> +dst_vaddr = xc_map_foreign_range(xch, domain_id, XC_PAGE_SIZE,
> + PROT_WRITE, dst_gfn);

You can have a look at libxc/xc_foreign_memory.c for how to replace this
legacy call with the new function.

Wei.

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

Re: [Xen-devel] [PATCH v3 36/38] altp2m: Allow specifying external-only use-case

[Wei Liu]

On Wed, Aug 17, 2016 at 12:17:12AM +0200, Sergej Proskurin wrote:
> From: Tamas K Lengyel 
> 
> Currently setting altp2mhvm=1 in the domain configuration allows access to the
> altp2m interface for both in-guest and external privileged tools. This poses
> a problem for use-cases where only external access should be allowed, 
> requiring
> the user to compile Xen with XSM enabled to be able to appropriately restrict
> access.
> 
> In this patch we deprecate the altp2mhvm domain configuration option and
> introduce the altp2m option, which allows specifying if by default the altp2m
> interface should be external-only. The information is stored in
> HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
> If external_only mode is selected, the XSM check is shifted to use XSM_DM_PRIV
> type check, thus restricting access to the interface by the guest itself. Note
> that we keep the default XSM policy untouched. Users of XSM who wish to 
> enforce
> external_only mode for altp2m can do so by adjusting their XSM policy 
> directly,
> as this domain config option does not override an active XSM policy.
> 
> Also, as part of this patch we adjust the hvmop handler to require
> HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has 
> been
> previously only required for get/set altp2m domain state, all other options
> were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
> altp2m domain state, this change introduces no new requirements to the other
> ops but makes it more clear that it is required for all ops.
> 
> Signed-off-by: Tamas K Lengyel 
> Signed-off-by: Sergej Proskurin 


During my review of Tamas's original patch, I figured that it would
be quite ugly to handle the old type vs new type of altp2m in order to
not break compilation for older application.

But it seems that we shall just keep altp2mhvm libxl_def_bool and use
the new type for altp2m.  I think by taking this patch in the series, we
manage to reduce the compatibility cruft needed, which is good.

> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Daniel De Graaf 
> 
> v2: Rename HVMALTP2M_* to XEN_ALTP2M_*
> Relax xsm check to XSM_DM_PRIV for external-only mode
> 
> v3: Introduce macro LIBXL_HAVE_ARM_ALTP2M in parallel to the former
> LIBXL_HAVE_ALTP2M to differentiate between altp2m for x86 and and
> altp2m for ARM architectures.
> 
> Document the option "altp2m" in ./docs/man/xl.cfg.pod.5.in.
> 
> Maintain the legacy info->u.hvm.altp2m field for x86 HVM domains in
> parallel to the introduced info->altp2m field for x86 HVM and ARM
> domains.
> ---
>  docs/man/xl.cfg.pod.5.in| 37 -
>  tools/libxl/libxl.h | 10 +-
>  tools/libxl/libxl_create.c  |  7 +--
>  tools/libxl/libxl_dom.c | 30 --
>  tools/libxl/libxl_types.idl | 13 +
>  tools/libxl/xl_cmdimpl.c| 25 -
>  xen/arch/arm/hvm.c  | 14 +-
>  xen/arch/x86/hvm/hvm.c  | 20 ++--
>  xen/include/public/hvm/params.h | 10 +-
>  xen/include/xsm/dummy.h | 14 +++---
>  xen/include/xsm/xsm.h   |  6 +++---
>  xen/xsm/flask/hooks.c   |  2 +-
>  12 files changed, 162 insertions(+), 26 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
> index 48c9c0d..bf9a48a 100644
> --- a/docs/man/xl.cfg.pod.5.in
> +++ b/docs/man/xl.cfg.pod.5.in
> @@ -1268,6 +1268,37 @@ enabled by default and you should usually omit it. It 
> may be necessary
>  to disable the HPET in order to improve compatibility with guest
>  Operating Systems (X86 only)
>  
> +=item 

[Xen-devel] Memory sizes obtained from the hypervisor

[Juergen Gross]

During test of HVMlite Mini-OS I found that the memory size obtained
via HYPERVISOR_memory_op(XENMEM_current_reservation) was higher than
expected: for a 16MB domain the number of pages was 8 pages larger than
I thought it should be. This seems to include the p2m map allocated by
the toolstack.

The size returned by HYPERVISOR_memory_op(XENMEM_maximum_reservation)
was 1MB larger than expected (additional space for first MB?).

I don't see a problem in this behavior, I just wanted to report it in
case this is regarded to be wrong.


Juergen

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d82d59edb0ec23e6ef708e04a5553ac32f1eb12e
baseline version:
 ovmf 4962fcfa7d265824f01f74d782d5ed841ec8a72f

Last test of basis67587  2016-08-24 01:20:54 Z0 days
Testing same since67589  2016-08-24 08:48:36 Z0 days1 attempts


People who touched revisions under test:
  Zhang Lubo 

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 d82d59edb0ec23e6ef708e04a5553ac32f1eb12e
Author: Zhang Lubo 
Date:   Fri Aug 19 15:38:20 2016 +0800

MdeModulePkg:Fix bug in function AsciiStrToIp4.

If a FQDN contains 3 dots '.' like "a.b.c.com", the AsciiStrToIp4
will return success as the HostName has a valid IP address. So we
need to check if it is a decimal character before using 
AsciiStrDecimalToUintn.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Reviewed-by: Sriram Subramanian 

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

Re: [Xen-devel] [PATCH 0/3] tools: support autoballooning of xenstore domain

[Wei Liu]

On Mon, Aug 08, 2016 at 07:31:28PM +0200, Juergen Gross wrote:
> On 08/08/16 16:45, Ian Jackson wrote:
> > Juergen Gross writes ("[PATCH 0/3] tools: support autoballooning of 
> > xenstore domain"):
> >> Support xenstore domain autoballooning by:
> >> - adding --maxmem parameter to init-xenstore-domain
> >> - build xenstore stubdom with Mini-OS CONFIG_BALLOON set
> >> - add XENSTORE_MAX_DOMAIN_SIZE parameter to sysconfig.xencommons
> >>
> >> This series requires Mini-OS ballooning support, of course. I'm posting
> >> it now because this will make it easier to test my Mini-OS series.
> > 
> > The basic idea seems sound enough, and I didn't spot much wrong with
> > the implementation, although I have some questions/observations:
> > 
> >  * AFAICT this is going to take effect for C xenstored.  But ISTM that
> >we probably want to be moving away from C xenstored; its code is
> >difficult, it has a history of hard to fathom bugs, and I'm
> >concerned about its security properties.
> 
> This should work for ocaml based xenstore domain, too. I've been told
> that is based on Mini-OS, so there is no reason it shouldn't work.
> 
> >  * I find that the pointer-arithmetic-based parsing style (as seen in
> >patch 1) very hard to read.  I haven't reviewed it.  But I think it
> >is not exposed to untrusted input so I don't think I care.
> 
> I wouldn't mind another way to do it. This variant seemed to be most
> compact and passed all verification testing I did (and I tried a lot
> of nonsense).
> 
> >  * If we are going in this direction, this feature probably wants to
> >be enabled by default.  Do you have a good idea of default
> >parameters ?
> 
> Hmm, that's not too easy. For a "normal" guest about a quarter MB of
> memory for Xenstore seems to be a lot. I guess these days most guests
> have at least 256 MB, so 1/1000 of host memory seems to be appropriate.
> We don't risk anything going a little bit higher, as Mini-OS doesn't
> have anything like page structures consuming memory for the not yet
> taken domain memory. Of course we need some MB (e.g. 4) as a starting
> point as the kernel needs some memory even if the host is very small.
> So what about 4:1/512 ? This would give us 4 MB at minimum and on a
> 16 TB machine we could go up to 32 GB which still wouldn't blow up the
> theoretical boundaries of Mini-OS.
> 
> 

Ian, are all your concerns addressed?

Wei.

> Juergen

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

Re: [Xen-devel] Save/Restore is not working properly

[Roger Pau Monné]

On Fri, Aug 19, 2016 at 08:45:49PM +0430, Cendrin Sa wrote:
> Hi again,
> So save/restore has a bug or not? I still have problem with it when i use
> LVM.

Which kernel version are you using on the Dom0?

Roger.

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

[Xen-devel] [xen-unstable test] 100602: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-boot fail in 100592 pass in 100602
 test-armhf-armhf-xl  15 guest-start/debian.repeat  fail pass in 100592

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

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

version targeted for testing:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da
baseline version:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da

Last test of basis   100602  2016-08-24 01:58:47 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17037 days0 attempts

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

Re: [Xen-devel] Save/Restore is not working properly

[Wei Liu]

On Fri, Aug 19, 2016 at 08:45:49PM +0430, Cendrin Sa wrote:
> Hi again,
> So save/restore has a bug or not? I still have problem with it when i use
> LVM.
> 

I think we need more logs.

Which task hung? Can you provide kernel backtrace?

Wei.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  94d3b9990bf73459919fb5b234d088d1ac41c9da
baseline version:
 xen  2a99aa99fc84a45f505f84802af56b006d14c52e

Last test of basis   100576  2016-08-21 09:19:09 Z3 days
Testing same since   100605  2016-08-24 09:19:07 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=94d3b9990bf73459919fb5b234d088d1ac41c9da
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
xen-unstable-coverity 94d3b9990bf73459919fb5b234d088d1ac41c9da
+ branch=xen-unstable-coverity
+ revision=94d3b9990bf73459919fb5b234d088d1ac41c9da
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.7-testing
+ '[' x94d3b9990bf73459919fb5b234d088d1ac41c9da = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 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 v2 00/22] mini-os: support HVMlite mode

[Wei Liu]

On Wed, Aug 24, 2016 at 12:11:22PM +0200, Juergen Gross wrote:
> This patch series adds HVMlite support for Mini-OS. Setting
> CONFIG_PARAVIRT to "n" (default is "y") will build mini-os as a
> HVMlite domain on x86. Both 32- and 64-bit builds are supported.
> 
> Tested with plain Mini-OS configuration to work in 32- and 64-bit
> mode either paravirtualized or as HVM domain (device-model none).
> 
> Ballooning should basically work, too, but there is some support for
> a sparse memory map missing in HVMlite mode.
> 
> Changes in V2:
> - some minor changes requested by Samuel Thibault (added comments,
>   moved sone code to another position in file, add one print)
> 
> Juergen Gross (22):
>   mini-os: resync xen headers
>   mini-os: make dump_regs() work in early boot
>   mini-os: add CONFIG_PARAVIRT
>   mini-os: make some memory management related macros usable from
> assembler
>   mini-os: add boot code for HVMlite support
>   mini-os: setup hypercall page for HVMlite
>   mini-os: support hvm_op hypercall
>   mini-os: initialize trap handling for HVMlite
>   mini-os: support HVMlite traps
>   mini-os: make p2m related code depend on CONFIG_PARAVIRT
>   mini-os: add static page tables for virtual kernel area for HVMlite
>   mini-os: add x86 native page table handling
>   mini-os: correct wrong calculation of alloc bitmap size
>   mini-os: add map_frame_virt() function
>   mini-os: setup console interface parameters
>   mini-os: setup xenbus interface parameters
>   mini-os: add get_cmdline() function
>   mini-os: map shared info page for HVMlite
>   mini-os: remove using start_info in architecture independent code
>   mini-os: print start of day messages depending on domain type
>   mini-os: get physical memory map
>   mini-os: support idle for HVMlite

Folded in Samuel's RoB in patch 5 and pushed.

Wei.

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

Re: [Xen-devel] mkelf32 incorrectly filling out the program headers for NOTE

[Jan Beulich]

>>> On 24.08.16 at 12:07,  wrote:
> Hi,
> 
> Here's the readelf output (snipped) on a xen-4.7 build :
> 
> Section Headers:
>   [Nr] Name  TypeAddr OffSize   ES Flg Lk 
> Inf Al
>   [ 0]   NULL 00 00 00  0   
> 0  0
>   [ 1] .text PROGBITS0010 80 1d0220 00 WAX  0   
> 0 64
>   [ 2] .shstrtab STRTAB   1d0340 18 00  0   
> 0  1
>   [ 3] .note NOTE00168e58 168ed8 24 00  0   
> 0  4
> 
> Program Headers:
>   Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
>   LOAD   0x80 0x0010 0x0010 0x1d0220 0x216000 RWE 0x40
>   NOTE   0x168e58 0x00168e58 0x00168e58 0x00024 0x00024 R   0x4
> 
> If you look at the "offset" value for the .note section and the NOTE
> program headers, they don't match ... but both should represent an
> offset inside the file image and to the same thing, so they should
> match.
> 
> The correct one is the one of the .note and the incorrect value of the
> program header one causes kexec to parse the header wrongly and just
> plain crash. (granted it should be more robust and not segfault, but
> still)

Indeed, patch in the works. But why did you not provide a patch
yourself, considering that you've done all the diagnosis?

Jan


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

Re: [Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files

[Wei Liu]

On Wed, Aug 24, 2016 at 11:10:02AM +0100, Wei Liu wrote:
> On Fri, Aug 12, 2016 at 06:32:35PM +0100, Lars Kurth wrote:
> > Added a COPYING file as a boilerplate to explain license oddities in
> > this directory
> > 
> > Added a vtpm/COPYING file which contains MIT licensed files only
> > 
> > Added a vtpmmgr/README.source file which contains many BSD-3-Clause
> > files that originally came from tools/vtpm_manager
> > 
> > Signed-off-by: Lars Kurth 
> > ---
> >  stubdom/COPYING   | 31 +++
> >  stubdom/vtpm/COPYING  | 26 ++
> >  stubdom/vtpmmgr/README.source | 23 +++
> >  3 files changed, 80 insertions(+)
> >  create mode 100644 stubdom/COPYING
> >  create mode 100644 stubdom/vtpm/COPYING
> >  create mode 100644 stubdom/vtpmmgr/README.source
> > 
> > diff --git a/stubdom/COPYING b/stubdom/COPYING
> > new file mode 100644
> > index 000..a5071b3
> > --- /dev/null
> > +++ b/stubdom/COPYING
> > @@ -0,0 +1,31 @@
> > +Most files in this directory are covered by version 2 of the 
> > +GNU General Public License except where explicitly stated.
> > +See the main COPYING file in xen.git for more information.
> > +
> > +Notable exceptions are in the following directories
> > +
> > +vtpm
> > + 
> > +Exclusively contains code licensed under a MIT license
> > +Also see vtpm/COPYING
> > +
> > +vtpmmgr
> > +===
> > +Contains a significant portion of files which are licensed
> > +under a BSD-3-Clause license. These files were imported from
> > +elsewhere and are copyrighted as follows:
> > +
> > +Copyright (c) 2005, Intel Corp.
> > +All rights reserved.
> > +
> > +See README.source for a complete list of files
> > +
> > +Otherwise, this directory contains several files licensed under
> > +GPLv2+, or without copyright headers. 
> > +
> > +*.patch and *.diff files
> > +
> > +This directory contains a number of *.patch and *.diff files. 
> > +These files describe changes to source files and are thus 
> > +licensed under the license from which the *.patch and *.diff
> > +were generated.
> > diff --git a/stubdom/vtpm/COPYING b/stubdom/vtpm/COPYING
> > new file mode 100644
> > index 000..80780b8
> > --- /dev/null
> > +++ b/stubdom/vtpm/COPYING
> > @@ -0,0 +1,26 @@
> > +This copyright applies to all files within this subdirectory and its
> > +subdirectories, unless explicitly stated otherwise within individual 
> > +source files.
> > +
> > +All other files in the Xen source distribution are covered by version
> > +2 of the GNU General Public License except where explicitly stated.
> > +See the main COPYING file in xen.git for more information.
> > +
> > +=
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a 
> > copy
> > +of this software and associated documentation files (the "Software"), to
> > +deal in the Software without restriction, including without limitation the
> > +rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> > +sell copies of the Software, and to permit persons to whom the Software is
> > +furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice shall be included in
> > +all copies or substantial portions of the Software.
> > +
> > +THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
> > +ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
> > +INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
> > +FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
> > +DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
> > +SOFTWARE.
> > \ No newline at end of file
> 
> Here, please add a new line.
> 
> > diff --git a/stubdom/vtpmmgr/README.source b/stubdom/vtpmmgr/README.source
> > new file mode 100644
> > index 000..1b45997
> > --- /dev/null
> > +++ b/stubdom/vtpmmgr/README.source
> > @@ -0,0 +1,23 @@
> > +About
> > +=
> > +This documents the upstream sources for files in this directory.
> > +
> > +The following files are based off of the original 
> > +tools/vtpm_manager code base in xen.git, which has since been 
> > +deleted: 
> > +
> 
> It doesn't seem obvious to me during my archeology.
> 
> tools/vtpm_manager was deleted in
> b918dce5bb2a665a34ff893a9df5392fb8ea429d, but it is not clear whether
> your claim (the new code based off the deleted files) is true.
> 
> For one, there is no uuid.h in the deleted code -- apparently vtpm
> wouldn't have to ship its own uuid library because OS has one. But then,
> there is such claim in the new uuid.h, so I'm rather confused. I'm
> inclined to believe that this uuid.h is either written afresh or
> imported from somewhere else.
> 

For uuid.h, the code resembles neither Linux's nor FreeBSD's.  The
closest thing I can find is libxl_uuid.h. If that's the case, my

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

[Jan Beulich]

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

Reviewed-by: Jan Beulich 

But I'd specifically like to have at least an ack from Andrew too
before putting this in.

Jan


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

[Xen-devel] [PATCH v2 12/22] mini-os: add x86 native page table handling

[Juergen Gross]

For support of HVMlite don't use mmu_update hypercalls, but write the
page table entries directly.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/mm.c | 147 +-
 arch/x86/traps.c  |  10 
 include/x86/arch_mm.h |   4 ++
 include/x86/os.h  |   9 
 4 files changed, 132 insertions(+), 38 deletions(-)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index cbb5617..f5248a4 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -123,16 +123,25 @@ void arch_mm_preinit(void *p)
  * table at offset in previous level MFN (pref_l_mfn). pt_pfn is a guest
  * PFN.
  */
+static pgentry_t pt_prot[PAGETABLE_LEVELS] = {
+L1_PROT,
+L2_PROT,
+L3_PROT,
+#if defined(__x86_64__)
+L4_PROT,
+#endif
+};
+
 static void new_pt_frame(unsigned long *pt_pfn, unsigned long prev_l_mfn, 
  unsigned long offset, unsigned long level)
 {   
-pgentry_t *tab = pt_base;
+pgentry_t *tab;
 unsigned long pt_page = (unsigned long)pfn_to_virt(*pt_pfn); 
-pgentry_t prot_e, prot_t;
+#ifdef CONFIG_PARAVIRT
 mmu_update_t mmu_updates[1];
 int rc;
+#endif
 
-prot_e = prot_t = 0;
 DEBUG("Allocating new L%d pt frame for pfn=%lx, "
   "prev_l_mfn=%lx, offset=%lx", 
   level, *pt_pfn, prev_l_mfn, offset);
@@ -140,30 +149,12 @@ static void new_pt_frame(unsigned long *pt_pfn, unsigned 
long prev_l_mfn,
 /* We need to clear the page, otherwise we might fail to map it
as a page table page */
 memset((void*) pt_page, 0, PAGE_SIZE);  
- 
-switch ( level )
-{
-case L1_FRAME:
-prot_e = L1_PROT;
-prot_t = L2_PROT;
-break;
-case L2_FRAME:
-prot_e = L2_PROT;
-prot_t = L3_PROT;
-break;
-#if defined(__x86_64__)
-case L3_FRAME:
-prot_e = L3_PROT;
-prot_t = L4_PROT;
-break;
-#endif
-default:
-printk("new_pt_frame() called with invalid level number %lu\n", level);
-do_exit();
-break;
-}
 
+ASSERT(level >= 1 && level <= PAGETABLE_LEVELS);
+
+#ifdef CONFIG_PARAVIRT
 /* Make PFN a page table page */
+tab = pt_base;
 #if defined(__x86_64__)
 tab = pte_to_virt(tab[l4_table_offset(pt_page)]);
 #endif
@@ -172,7 +163,7 @@ static void new_pt_frame(unsigned long *pt_pfn, unsigned 
long prev_l_mfn,
 mmu_updates[0].ptr = (tab[l2_table_offset(pt_page)] & PAGE_MASK) + 
 sizeof(pgentry_t) * l1_table_offset(pt_page);
 mmu_updates[0].val = (pgentry_t)pfn_to_mfn(*pt_pfn) << PAGE_SHIFT | 
-(prot_e & ~_PAGE_RW);
+(pt_prot[level - 1] & ~_PAGE_RW);
 
 if ( (rc = HYPERVISOR_mmu_update(mmu_updates, 1, NULL, DOMID_SELF)) < 0 )
 {
@@ -184,13 +175,18 @@ static void new_pt_frame(unsigned long *pt_pfn, unsigned 
long prev_l_mfn,
 /* Hook the new page table page into the hierarchy */
 mmu_updates[0].ptr =
 ((pgentry_t)prev_l_mfn << PAGE_SHIFT) + sizeof(pgentry_t) * offset;
-mmu_updates[0].val = (pgentry_t)pfn_to_mfn(*pt_pfn) << PAGE_SHIFT | prot_t;
+mmu_updates[0].val = (pgentry_t)pfn_to_mfn(*pt_pfn) << PAGE_SHIFT |
+pt_prot[level];
 
 if ( (rc = HYPERVISOR_mmu_update(mmu_updates, 1, NULL, DOMID_SELF)) < 0 ) 
 {
 printk("ERROR: mmu_update failed with rc=%d\n", rc);
 do_exit();
 }
+#else
+tab = mfn_to_virt(prev_l_mfn);
+tab[offset] = (*pt_pfn << PAGE_SHIFT) | pt_prot[level];
+#endif
 
 *pt_pfn += 1;
 }
@@ -202,12 +198,14 @@ static void build_pagetable(unsigned long *start_pfn, 
unsigned long *max_pfn)
 {
 unsigned long start_address, end_address;
 unsigned long pfn_to_map, pt_pfn = *start_pfn;
-static mmu_update_t mmu_updates[L1_PAGETABLE_ENTRIES + 1];
 pgentry_t *tab = pt_base, page;
 unsigned long pt_mfn = pfn_to_mfn(virt_to_pfn(pt_base));
 unsigned long offset;
+#ifdef CONFIG_PARAVIRT
+static mmu_update_t mmu_updates[L1_PAGETABLE_ENTRIES + 1];
 int count = 0;
 int rc;
+#endif
 
 /* Be conservative: even if we know there will be more pages already
mapped, start the loop at the very beginning. */
@@ -225,6 +223,10 @@ static void build_pagetable(unsigned long *start_pfn, 
unsigned long *max_pfn)
((unsigned long)pfn_to_virt(*max_pfn) - 
 (unsigned long)&_text)>>20);
 }
+#else
+/* Round up to next 2MB boundary as we are using 2MB pages on HVMlite. */
+pfn_to_map = (pfn_to_map + L1_PAGETABLE_ENTRIES - 1) &
+ ~(L1_PAGETABLE_ENTRIES - 1);
 #endif
 
 start_address = (unsigned long)pfn_to_virt(pfn_to_map);
@@ -257,6 +259,7 @@ static void build_pagetable(unsigned long *start_pfn, 
unsigned long *max_pfn)
 pt_mfn = pte_to_mfn(page);
 tab = to_virt(mfn_to_pfn(pt_mfn) << PAGE_SHIFT);
 offset = l2_table_offset(start_address);
+#ifdef CONFIG_PARAVIRT
 /* Need new L1 pt frame */
 

[Xen-devel] [PATCH v2 22/22] mini-os: support idle for HVMlite

[Juergen Gross]

Instead of calling HYPERVISOR_sched_op(SCHEDOP_block, 0) we need to use
the "hlt" instruction with interrupts enabled to switch to idle when
running as HVMlite domain.

This requires to setup a new timer in the timer handler as there is no
guarantee the original timer event we are waiting for won't fire
between enabling interrupts and calling "hlt".

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/time.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/x86/time.c b/arch/x86/time.c
index af45e56..3658142 100644
--- a/arch/x86/time.c
+++ b/arch/x86/time.c
@@ -212,17 +212,20 @@ void block_domain(s_time_t until)
 if(monotonic_clock() < until)
 {
 HYPERVISOR_set_timer_op(until);
+#ifdef CONFIG_PARAVIRT
 HYPERVISOR_sched_op(SCHEDOP_block, 0);
+#else
+local_irq_enable();
+asm volatile ( "hlt" : : : "memory" );
+#endif
 local_irq_disable();
+HYPERVISOR_set_timer_op(0);
 }
 }
 
-
-/*
- * Just a dummy
- */
 static void timer_handler(evtchn_port_t ev, struct pt_regs *regs, void *ign)
 {
+HYPERVISOR_set_timer_op(monotonic_clock() + MILLISECS(1));
 }
 
 
-- 
2.6.6


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

[Xen-devel] [PATCH v2 18/22] mini-os: map shared info page for HVMlite

[Juergen Gross]

Add a service function to map the shared info page on a
non-paravirtualized system. The code is already existing on ARM side,
just move it to hypervisor.c.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/arm32.S |  4 ++--
 arch/arm/setup.c | 11 +--
 arch/x86/setup.c | 38 --
 hypervisor.c | 17 +
 include/hypervisor.h |  1 +
 5 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/arch/arm/arm32.S b/arch/arm/arm32.S
index a08a170..bcaca17 100644
--- a/arch/arm/arm32.S
+++ b/arch/arm/arm32.S
@@ -151,8 +151,8 @@ stage2:
 .pushsection .bss
 @ Note: calling arch_init zeroes out this region.
 .align 12
-.globl shared_info_page
-shared_info_page:
+.globl shared_info
+shared_info:
.fill (1024), 4, 0x0
 
 .align 3
diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 72e025a..05b405b 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -21,8 +21,6 @@ union start_info_union start_info_union;
  */
 shared_info_t *HYPERVISOR_shared_info;
 
-extern char shared_info_page[PAGE_SIZE];
-
 void *device_tree;
 
 /*
@@ -30,7 +28,6 @@ void *device_tree;
  */
 void arch_init(void *dtb_pointer, uint32_t physical_offset)
 {
-struct xen_add_to_physmap xatp;
 int r;
 
 memset(&__bss_start, 0, &_end - &__bss_start);
@@ -48,13 +45,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
 device_tree = dtb_pointer;
 
 /* Map shared_info page */
-xatp.domid = DOMID_SELF;
-xatp.idx = 0;
-xatp.space = XENMAPSPACE_shared_info;
-xatp.gpfn = virt_to_pfn(shared_info_page);
-if (HYPERVISOR_memory_op(XENMEM_add_to_physmap, ) != 0)
-BUG();
-HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
+HYPERVISOR_shared_info = map_shared_info(NULL);
 
 /* Fill in start_info */
 get_console(NULL);
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 13633f0..278e88f 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -60,20 +60,6 @@ extern char shared_info[PAGE_SIZE];
 ((pte_t) {(unsigned long)(_x), (unsigned long)(_x>>32)}); })
 #endif
 
-static
-shared_info_t *map_shared_info(unsigned long pa)
-{
-int rc;
-
-   if ( (rc = HYPERVISOR_update_va_mapping(
-  (unsigned long)shared_info, __pte(pa | 7), UVMF_INVLPG)) )
-   {
-   printk("Failed to map shared_info!! rc=%d\n", rc);
-   do_exit();
-   }
-   return (shared_info_t *)shared_info;
-}
-
 static inline void fpu_init(void) {
asm volatile("fninit");
 }
@@ -90,6 +76,21 @@ static inline void sse_init(void) {
 #ifdef CONFIG_PARAVIRT
 #define hpc_init()
 
+shared_info_t *map_shared_info(void *p)
+{
+int rc;
+start_info_t *si = p;
+unsigned long pa = si->shared_info;
+
+if ( (rc = HYPERVISOR_update_va_mapping((unsigned long)shared_info,
+__pte(pa | 7), UVMF_INVLPG)) )
+{
+printk("Failed to map shared_info!! rc=%d\n", rc);
+do_exit();
+}
+return (shared_info_t *)shared_info;
+}
+
 static void get_cmdline(void *p)
 {
 start_info_t *si = p;
@@ -156,6 +157,10 @@ arch_init(void *par)
get_console(par);
get_xenbus(par);
get_cmdline(par);
+
+   /* Grab the shared_info pointer and put it in a safe place. */
+   HYPERVISOR_shared_info = map_shared_info(par);
+
si = par;
memcpy(_info, si, sizeof(*si));
 
@@ -163,7 +168,7 @@ arch_init(void *par)
printk("Xen Minimal OS!\n");
printk("  start_info: %p(VA)\n", si);
printk("nr_pages: 0x%lx\n", si->nr_pages);
-   printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
+   printk("  shared_inf: %p(VA)\n", HYPERVISOR_shared_info);
printk(" pt_base: %p(VA)\n", (void *)si->pt_base);
printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
printk("mfn_list: %p(VA)\n", (void *)si->mfn_list);
@@ -173,9 +178,6 @@ arch_init(void *par)
printk("cmd_line: %s\n", cmdline);
printk("   stack: %p-%p\n", stack, stack + sizeof(stack));
 
-   /* Grab the shared_info pointer and put it in a safe place. */
-   HYPERVISOR_shared_info = map_shared_info(start_info.shared_info);
-
start_kernel();
 }
 
diff --git a/hypervisor.c b/hypervisor.c
index 715cfe8..1647121 100644
--- a/hypervisor.c
+++ b/hypervisor.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define active_evtchns(cpu,sh,idx)  \
 ((sh)->evtchn_pending[idx] &\
@@ -37,6 +38,8 @@
 int in_callback;
 
 #ifndef CONFIG_PARAVIRT
+extern shared_info_t shared_info;
+
 int hvm_get_parameter(int idx, uint64_t *value)
 {
 struct xen_hvm_param xhv;
@@ -61,6 +64,20 @@ int hvm_set_parameter(int idx, uint64_t value)
 xhv.value = value;
 return HYPERVISOR_hvm_op(HVMOP_set_param, );
 }
+
+shared_info_t *map_shared_info(void *p)
+{
+ 

[Xen-devel] [PATCH v2 01/22] mini-os: resync xen headers

[Juergen Gross]

Use the latest Xen headers.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 include/xen/arch-x86/hvm/start_info.h | 98 +++
 include/xen/elfnote.h | 12 -
 2 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100644 include/xen/arch-x86/hvm/start_info.h

diff --git a/include/xen/arch-x86/hvm/start_info.h 
b/include/xen/arch-x86/hvm/start_info.h
new file mode 100644
index 000..6484159
--- /dev/null
+++ b/include/xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,98 @@
+/*
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 0. New
+ *|| versions are guaranteed to be backwards-compatible.
+ *  8 ++
+ *| flags  | SIF_xxx flags.
+ * 12 ++
+ *| nr_modules | Number of modules passed to the kernel.
+ * 16 ++
+ *| modlist_paddr  | Physical address of an array of modules
+ *|| (layout of the structure below).
+ * 24 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 32 ++
+ *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 ++
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ *  0 ++
+ *| paddr  | Physical address of the module.
+ *  8 ++
+ *| size   | Size of the module in bytes.
+ * 16 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 24 ++
+ *| reserved   |
+ * 32 ++
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data below the 4GiB
+ * boundary.
+ */
+#define XEN_HVM_START_MAGIC_VALUE 0x336ec578
+
+/*
+ * C representation of the x86/HVM start info layout.
+ *
+ * The canonical definition of this layout is above, this is just a way to
+ * represent the layout described there using C types.
+ */
+struct hvm_start_info {
+uint32_t magic; /* Contains the magic value 0x336ec578   */
+/* ("xEn3" with the 0x80 bit of the "E" set).*/
+uint32_t version;   /* Version of this structure.*/
+uint32_t flags; /* SIF_xxx flags.*/
+uint32_t nr_modules;/* Number of modules passed to the kernel.   */
+uint64_t modlist_paddr; /* Physical address of an array of   */
+/* hvm_modlist_entry.*/
+uint64_t cmdline_paddr; /* Physical address of the command line. */
+uint64_t rsdp_paddr;/* Physical address of the RSDP ACPI data*/
+/* structure.*/
+};
+
+struct hvm_modlist_entry {
+uint64_t paddr; /* Physical address of the module.   */
+uint64_t size;  /* Size of the module in bytes.  */
+uint64_t cmdline_paddr; /* Physical address of the command 

[Xen-devel] [PATCH v2 00/22] mini-os: support HVMlite mode

[Juergen Gross]

This patch series adds HVMlite support for Mini-OS. Setting
CONFIG_PARAVIRT to "n" (default is "y") will build mini-os as a
HVMlite domain on x86. Both 32- and 64-bit builds are supported.

Tested with plain Mini-OS configuration to work in 32- and 64-bit
mode either paravirtualized or as HVM domain (device-model none).

Ballooning should basically work, too, but there is some support for
a sparse memory map missing in HVMlite mode.

Changes in V2:
- some minor changes requested by Samuel Thibault (added comments,
  moved sone code to another position in file, add one print)

Juergen Gross (22):
  mini-os: resync xen headers
  mini-os: make dump_regs() work in early boot
  mini-os: add CONFIG_PARAVIRT
  mini-os: make some memory management related macros usable from
assembler
  mini-os: add boot code for HVMlite support
  mini-os: setup hypercall page for HVMlite
  mini-os: support hvm_op hypercall
  mini-os: initialize trap handling for HVMlite
  mini-os: support HVMlite traps
  mini-os: make p2m related code depend on CONFIG_PARAVIRT
  mini-os: add static page tables for virtual kernel area for HVMlite
  mini-os: add x86 native page table handling
  mini-os: correct wrong calculation of alloc bitmap size
  mini-os: add map_frame_virt() function
  mini-os: setup console interface parameters
  mini-os: setup xenbus interface parameters
  mini-os: add get_cmdline() function
  mini-os: map shared info page for HVMlite
  mini-os: remove using start_info in architecture independent code
  mini-os: print start of day messages depending on domain type
  mini-os: get physical memory map
  mini-os: support idle for HVMlite

 Config.mk |   6 +
 Makefile  |   2 +-
 arch/arm/arm32.S  |   4 +-
 arch/arm/balloon.c|   7 -
 arch/arm/mm.c |  17 +-
 arch/arm/setup.c  |  66 +-
 arch/x86/arch.mk  |   4 +
 arch/x86/balloon.c|  26 ++-
 arch/x86/events.c |   4 +-
 arch/x86/mm.c | 347 +++-
 arch/x86/setup.c  | 156 +--
 arch/x86/time.c   |  11 +-
 arch/x86/traps.c  | 108 +-
 arch/x86/x86_32.S |  50 -
 arch/x86/x86_64.S |  66 +-
 arch/x86/x86_hvm.S|  88 
 balloon.c |  12 +-
 console/xencons_ring.c|  38 +++-
 daytime.c |   2 +-
 events.c  |   3 +-
 hypervisor.c  |  44 
 include/arm/arch_mm.h |   3 -
 include/balloon.h |   4 -
 include/compiler.h|   1 +
 include/console.h |   3 +-
 include/e820.h|  48 +
 include/hypervisor.h  |  17 +-
 include/kernel.h  |   3 +
 include/mm.h  |   3 +-
 include/paravirt.h|  81 
 include/x86/arch_mm.h | 101 +-
 include/x86/desc.h| 367 ++
 include/x86/os.h  | 110 --
 include/x86/x86_32/hypercall-x86_32.h |   6 +
 include/x86/x86_64/hypercall-x86_64.h |   6 +
 include/xen/arch-x86/hvm/start_info.h |  98 +
 include/xen/arch-x86/xen-x86_32.h |   2 +
 include/xen/arch-x86/xen-x86_64.h |   2 +
 include/xen/elfnote.h |  12 +-
 include/xenbus.h  |   3 +
 kernel.c  |   7 +-
 main.c|  11 +-
 minios.mk |   2 +-
 mm.c  |  80 +---
 test.c|  20 +-
 xenbus/xenbus.c   |  40 +++-
 46 files changed, 1713 insertions(+), 378 deletions(-)
 create mode 100644 arch/x86/x86_hvm.S
 create mode 100644 include/e820.h
 create mode 100644 include/paravirt.h
 create mode 100644 include/x86/desc.h
 create mode 100644 include/xen/arch-x86/hvm/start_info.h

-- 
2.6.6


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

[Xen-devel] [PATCH v2 10/22] mini-os: make p2m related code depend on CONFIG_PARAVIRT

[Juergen Gross]

All handling related to p2m is needed for paravirtualized environment
only. So put all functions operating on p2m list in #ifdef
CONFIG_PARAVIRT sections. Add a paravirt.h header defining dummy
functions for non-paravirtualized environments. Instead of using
references to start_info use dedicated variables initialized from
start_info on boot.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/balloon.c|  5 ---
 arch/arm/mm.c |  4 ---
 arch/x86/balloon.c| 13 
 arch/x86/mm.c | 67 +--
 arch/x86/setup.c  |  6 ++--
 arch/x86/traps.c  |  6 ++--
 balloon.c |  1 +
 include/arm/arch_mm.h |  3 --
 include/balloon.h |  3 --
 include/mm.h  |  2 +-
 include/paravirt.h| 48 
 include/x86/arch_mm.h | 40 +--
 include/xen/arch-x86/xen-x86_32.h |  2 ++
 include/xen/arch-x86/xen-x86_64.h |  2 ++
 mm.c  |  1 +
 15 files changed, 133 insertions(+), 70 deletions(-)

diff --git a/arch/arm/balloon.c b/arch/arm/balloon.c
index 7f35328..958ecba 100644
--- a/arch/arm/balloon.c
+++ b/arch/arm/balloon.c
@@ -27,11 +27,6 @@
 
 unsigned long virt_kernel_area_end;   /* TODO: find a virtual area */
 
-int arch_expand_p2m(unsigned long max_pfn)
-{
-return 0;
-}
-
 void arch_pfn_add(unsigned long pfn, unsigned long mfn)
 {
 }
diff --git a/arch/arm/mm.c b/arch/arm/mm.c
index fc8d4bc..4f58fc7 100644
--- a/arch/arm/mm.c
+++ b/arch/arm/mm.c
@@ -72,10 +72,6 @@ void arch_init_mm(unsigned long *start_pfn_p, unsigned long 
*max_pfn_p)
 *max_pfn_p = to_phys(new_device_tree) >> PAGE_SHIFT;
 }
 
-void arch_init_p2m(unsigned long max_pfn)
-{
-}
-
 void arch_init_demand_mapping_area(void)
 {
 }
diff --git a/arch/x86/balloon.c b/arch/x86/balloon.c
index 42389e4..16aaae4 100644
--- a/arch/x86/balloon.c
+++ b/arch/x86/balloon.c
@@ -26,11 +26,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_BALLOON
 
 unsigned long virt_kernel_area_end = VIRT_KERNEL_AREA;
 
+#ifdef CONFIG_PARAVIRT
 static void p2m_invalidate(unsigned long *list, unsigned long start_idx)
 {
 unsigned long idx;
@@ -143,5 +145,16 @@ void arch_pfn_add(unsigned long pfn, unsigned long mfn)
 do_exit();
 }
 }
+#else
+void arch_pfn_add(unsigned long pfn, unsigned long mfn)
+{
+pgentry_t *pgt;
+
+pgt = need_pgt((unsigned long)pfn_to_virt(pfn));
+ASSERT(pgt);
+if ( !(*pgt & _PAGE_PSE) )
+*pgt = (pgentry_t)(mfn << PAGE_SHIFT) | _PAGE_PRESENT | _PAGE_RW;
+}
+#endif
 
 #endif
diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index fe18f53..0543017 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -53,10 +54,24 @@
 
 unsigned long *phys_to_machine_mapping;
 unsigned long mfn_zero;
+pgentry_t *pt_base;
+static unsigned long first_free_pfn;
+static unsigned long last_free_pfn;
+
 extern char stack[];
 extern void page_walk(unsigned long va);
 
-#ifndef CONFIG_PARAVIRT
+#ifdef CONFIG_PARAVIRT
+void arch_mm_preinit(void *p)
+{
+start_info_t *si = p;
+
+phys_to_machine_mapping = (unsigned long *)si->mfn_list;
+pt_base = (pgentry_t *)si->pt_base;
+first_free_pfn = PFN_UP(to_phys(pt_base)) + si->nr_pt_frames;
+last_free_pfn = si->nr_pages;
+}
+#else
 #include 
 user_desc gdt[NR_GDT_ENTRIES] =
 {
@@ -85,6 +100,22 @@ desc_ptr idt_ptr =
 .limit = sizeof(idt) - 1,
 .base = (unsigned long),
 };
+
+void arch_mm_preinit(void *p)
+{
+long ret;
+domid_t domid = DOMID_SELF;
+
+pt_base = page_table_base;
+first_free_pfn = PFN_UP(to_phys(&_end));
+ret = HYPERVISOR_memory_op(XENMEM_current_reservation, );
+if ( ret < 0 )
+{
+xprintk("could not get memory size\n");
+do_exit();
+}
+last_free_pfn = ret;
+}
 #endif
 
 /*
@@ -95,7 +126,7 @@ desc_ptr idt_ptr =
 static void new_pt_frame(unsigned long *pt_pfn, unsigned long prev_l_mfn, 
  unsigned long offset, unsigned long level)
 {   
-pgentry_t *tab = (pgentry_t *)start_info.pt_base;
+pgentry_t *tab = pt_base;
 unsigned long pt_page = (unsigned long)pfn_to_virt(*pt_pfn); 
 pgentry_t prot_e, prot_t;
 mmu_update_t mmu_updates[1];
@@ -172,8 +203,8 @@ static void build_pagetable(unsigned long *start_pfn, 
unsigned long *max_pfn)
 unsigned long start_address, end_address;
 unsigned long pfn_to_map, pt_pfn = *start_pfn;
 static mmu_update_t mmu_updates[L1_PAGETABLE_ENTRIES + 1];
-pgentry_t *tab = (pgentry_t *)start_info.pt_base, page;
-unsigned long pt_mfn = pfn_to_mfn(virt_to_pfn(start_info.pt_base));
+pgentry_t *tab = pt_base, page;
+unsigned long pt_mfn = pfn_to_mfn(virt_to_pfn(pt_base));
 

[Xen-devel] [PATCH v2 09/22] mini-os: support HVMlite traps

[Juergen Gross]

Trap handling in HVMlite domain is different from pv one.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/traps.c  |  2 --
 arch/x86/x86_32.S | 19 ++--
 arch/x86/x86_64.S | 22 +-
 include/x86/os.h  | 67 +++
 4 files changed, 101 insertions(+), 9 deletions(-)

diff --git a/arch/x86/traps.c b/arch/x86/traps.c
index 3b1fffb..0b3d85b 100644
--- a/arch/x86/traps.c
+++ b/arch/x86/traps.c
@@ -191,8 +191,6 @@ static void dump_mem(unsigned long addr)
 }
 printk("\n");
 }
-#define read_cr2() \
-(HYPERVISOR_shared_info->vcpu_info[smp_processor_id()].arch.cr2)
 
 static int handling_pg_fault = 0;
 
diff --git a/arch/x86/x86_32.S b/arch/x86/x86_32.S
index 6f38708..9241418 100644
--- a/arch/x86/x86_32.S
+++ b/arch/x86/x86_32.S
@@ -8,6 +8,9 @@
 #include 
 
 #ifdef CONFIG_PARAVIRT
+
+#define KERNEL_DS __KERNEL_DS
+
 ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz "Mini-OS")
 ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
 ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _WORD hypercall_page)
@@ -21,6 +24,8 @@ _start:
 lss stack_start,%esp
 #else
 
+#define KERNEL_DS __KERN_DS
+
 #include "x86_hvm.S"
 movl stack_start,%esp
 
@@ -61,7 +66,7 @@ CS= 0x2C
pushl %edx; \
pushl %ecx; \
pushl %ebx; \
-   movl $(__KERNEL_DS),%edx; \
+   movl $(KERNEL_DS),%edx; \
movl %edx,%ds; \
movl %edx,%es;
 
@@ -98,7 +103,7 @@ do_exception:
movl ORIG_EAX(%esp), %edx   # get the error code
movl %eax, ORIG_EAX(%esp)
movl %ecx, ES(%esp)
-   movl $(__KERNEL_DS), %ecx
+   movl $(KERNEL_DS), %ecx
movl %ecx, %ds
movl %ecx, %es
movl %esp,%eax  # pt_regs pointer
@@ -112,6 +117,7 @@ ret_from_exception:
 addl $8,%esp
 RESTORE_ALL
 
+#ifdef CONFIG_PARAVIRT
 # A note on the "critical region" in our callback handler.
 # We want to avoid stacking callback handlers due to events occurring
 # during handling of the last event. To do this, we keep events disabled
@@ -189,6 +195,15 @@ critical_fixup_table:
 .byte 0x28# iret
 .byte 0x00,0x00,0x00,0x00 # movb $1,1(%esi)
 .byte 0x00,0x00   # jmp  11b
+
+#else
+
+ENTRY(hypervisor_callback)
+   pushl $0
+   pushl $do_hypervisor_callback
+   jmp do_exception
+
+#endif

 # Hypervisor uses this for application faults while it executes.
 ENTRY(failsafe_callback)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index e725c63..17a9ead 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -78,9 +78,11 @@ KERNEL_CS_MASK = 0xfc
 
 /* Macros */
 .macro zeroentry sym
+#ifdef CONFIG_PARAVIRT
movq (%rsp),%rcx
movq 8(%rsp),%r11
addq $0x10,%rsp /* skip rcx and r11 */
+#endif
pushq $0/* push error code/oldrax */
pushq %rax  /* push real oldrax to the rdi slot */
leaq  \sym(%rip),%rax
@@ -88,9 +90,11 @@ KERNEL_CS_MASK = 0xfc
 .endm
 
 .macro errorentry sym
+#ifdef CONFIG_PARAVIRT
movq (%rsp),%rcx
movq 8(%rsp),%r11
addq $0x10,%rsp /* rsp points to the error code */
+#endif
pushq %rax
leaq  \sym(%rip),%rax
jmp error_entry
@@ -133,11 +137,11 @@ KERNEL_CS_MASK = 0xfc
 #ifdef CONFIG_PARAVIRT
testl $NMI_MASK,2*8(%rsp)
jnz   2f
-#endif
 
/* Direct iret to kernel space. Correct CS and SS. */
orb   $3,1*8(%rsp)
orb   $3,4*8(%rsp)
+#endif
iretq
 
 #ifdef CONFIG_PARAVIRT
@@ -182,6 +186,7 @@ error_call_handler:
jmp error_exit
 
 
+#ifdef CONFIG_PARAVIRT
 /*
  * Xen event (virtual interrupt) entry point.
  */
@@ -285,11 +290,26 @@ critical_region_fixup:
andb $KERNEL_CS_MASK,CS(%rsp)  # CS might have changed
jmp  11b
 
+#else
+error_exit:
+   RESTORE_REST
+   RESTORE_ALL
+   HYPERVISOR_IRET 0
 
+/*
+ * Xen event (virtual interrupt) entry point.
+ */
+ENTRY(hypervisor_callback)
+   zeroentry do_hypervisor_callback
+
+
+#endif
 
 ENTRY(failsafe_callback)
+#ifdef CONFIG_PARAVIRT
 popq  %rcx
 popq  %r11
+#endif
 iretq
 
 
diff --git a/include/x86/os.h b/include/x86/os.h
index db1389a..8ccff21 100644
--- a/include/x86/os.h
+++ b/include/x86/os.h
@@ -31,6 +31,8 @@
 #define X86_CR4_PAE   0x0020/* enable physical address extensions 
*/
 #define X86_CR4_OSFXSR0x0200/* enable fast FPU save and restore */
 
+#define X86_EFLAGS_IF 0x0200
+
 #define __KERNEL_CS  FLAT_KERNEL_CS
 #define __KERNEL_DS  FLAT_KERNEL_DS
 #define __KERNEL_SS  FLAT_KERNEL_SS
@@ -70,7 +72,7 @@ void arch_fini(void);
 
 
 
-
+#ifdef CONFIG_PARAVIRT
 
 /* 
  * The use of 'barrier' in the following reflects their use as local-lock
@@ -129,15 +131,57 @@ do {  

[Xen-devel] [PATCH v2 15/22] mini-os: setup console interface parameters

[Juergen Gross]

In order to support HVMlite we need to get the ring page and event
channel from the hypervisor via hypercalls. Move the already existing
get_console() function from arm specific coding to
console/xencons_ring.c and provide a similar paravirtualized function.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/setup.c   | 16 +---
 arch/x86/setup.c   |  1 +
 console/xencons_ring.c | 38 ++
 events.c   |  2 +-
 include/console.h  |  3 ++-
 5 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index cbe67c6..a021616 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -25,20 +25,6 @@ extern char shared_info_page[PAGE_SIZE];
 
 void *device_tree;
 
-static void get_console(void)
-{
-uint64_t v = -1;
-
-hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, );
-start_info.console.domU.evtchn = v;
-
-hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
-start_info.console.domU.mfn = v;
-
-printk("Console is on port %d\n", start_info.console.domU.evtchn);
-printk("Console ring is at mfn %lx\n", (unsigned long) 
start_info.console.domU.mfn);
-}
-
 void get_xenbus(void)
 {
 uint64_t value;
@@ -85,7 +71,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
 HYPERVISOR_shared_info = (struct shared_info *)shared_info_page;
 
 /* Fill in start_info */
-get_console();
+get_console(NULL);
 get_xenbus();
 
 gic_init();
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 8b6bb6e..0c1f2ec 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -137,6 +137,7 @@ arch_init(void *par)
/* Copy the start_info struct to a globally-accessible area. */
/* WARN: don't do printk before here, it uses information from
   shared_info. Use xprintk instead. */
+   get_console(par);
si = par;
memcpy(_info, si, sizeof(*si));
 
diff --git a/console/xencons_ring.c b/console/xencons_ring.c
index 81c8e99..dd64a41 100644
--- a/console/xencons_ring.c
+++ b/console/xencons_ring.c
@@ -9,27 +9,49 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "console.h"
 
 DECLARE_WAIT_QUEUE_HEAD(console_queue);
 
+static struct xencons_interface *console_ring;
+uint32_t console_evtchn;
+
+#ifdef CONFIG_PARAVIRT
+void get_console(void *p)
+{
+start_info_t *si = p;
+
+console_ring = mfn_to_virt(si->console.domU.mfn);
+console_evtchn = si->console.domU.evtchn;
+}
+#else
+void get_console(void *p)
+{
+uint64_t v = -1;
+
+hvm_get_parameter(HVM_PARAM_CONSOLE_EVTCHN, );
+console_evtchn = v;
+
+hvm_get_parameter(HVM_PARAM_CONSOLE_PFN, );
+console_ring = (struct xencons_interface *)map_frame_virt(v);
+}
+#endif
+
 static inline void notify_daemon(struct consfront_dev *dev)
 {
 /* Use evtchn: this is called early, before irq is set up. */
 if (!dev)
-notify_remote_via_evtchn(start_info.console.domU.evtchn);
+notify_remote_via_evtchn(console_evtchn);
 else
 notify_remote_via_evtchn(dev->evtchn);
 }
 
 static inline struct xencons_interface *xencons_interface(void)
 {
-if (start_info.console.domU.evtchn)
-return mfn_to_virt(start_info.console.domU.mfn);
-else
-return NULL;
+return console_evtchn ? console_ring : NULL;
 } 
  
 int xencons_ring_send_no_notify(struct consfront_dev *dev, const char *data, 
unsigned len)
@@ -158,7 +180,7 @@ struct consfront_dev *xencons_ring_init(void)
int err;
struct consfront_dev *dev;
 
-   if (!start_info.console.domU.evtchn)
+   if (!console_evtchn)
return 0;
 
dev = malloc(sizeof(struct consfront_dev));
@@ -171,8 +193,8 @@ struct consfront_dev *xencons_ring_init(void)
 #ifdef HAVE_LIBC
dev->fd = -1;
 #endif
-   dev->evtchn = start_info.console.domU.evtchn;
-   dev->ring = (struct xencons_interface *) 
mfn_to_virt(start_info.console.domU.mfn);
+   dev->evtchn = console_evtchn;
+   dev->ring = xencons_interface();
 
err = bind_evtchn(dev->evtchn, console_handle_input, dev);
if (err <= 0) {
diff --git a/events.c b/events.c
index 2a23042..76ea617 100644
--- a/events.c
+++ b/events.c
@@ -46,7 +46,7 @@ void unbind_all_ports(void)
 
 for ( i = 0; i < NR_EVS; i++ )
 {
-if ( i == start_info.console.domU.evtchn ||
+if ( i == console_evtchn ||
  i == start_info.store_evtchn)
 continue;
 
diff --git a/include/console.h b/include/console.h
index a77f47f..eb327a8 100644
--- a/include/console.h
+++ b/include/console.h
@@ -61,7 +61,7 @@ struct consfront_dev {
 #endif
 };
 
-
+extern uint32_t console_evtchn;
 
 void print(int direct, const char *fmt, va_list args);
 void printk(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
@@ -72,6 +72,7 @@ void xprintk(const char *fmt, ...) __attribute__ ((format 

[Xen-devel] [PATCH v2 06/22] mini-os: setup hypercall page for HVMlite

[Juergen Gross]

When running in HVMlite mode we need to setup the hypercall page by
ourself.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V2: move wrmsr definitions as requested by Samuel Thibault
---
 arch/x86/events.c |  4 ++--
 arch/x86/setup.c  | 26 ++
 include/x86/os.h  | 28 
 3 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/arch/x86/events.c b/arch/x86/events.c
index 5198cf3..342662d 100644
--- a/arch/x86/events.c
+++ b/arch/x86/events.c
@@ -16,7 +16,7 @@ void arch_init_events(void)
 {
 #if defined(__x86_64__)
 asm volatile("movl %0,%%fs ; movl %0,%%gs" :: "r" (0));
-wrmsrl(0xc101, _pda); /* 0xc101 is MSR_GS_BASE */
+wrmsrl(0xc101, (uint64_t)_pda); /* 0xc101 is MSR_GS_BASE */
 cpu0_pda.irqcount = -1;
 cpu0_pda.irqstackptr = (void*) (((unsigned long)irqstack + 2 * STACK_SIZE)
 & ~(STACK_SIZE - 1));
@@ -30,6 +30,6 @@ void arch_unbind_ports(void)
 void arch_fini_events(void)
 {
 #if defined(__x86_64__)
-wrmsrl(0xc101, NULL); /* 0xc101 is MSR_GS_BASE */
+wrmsrl(0xc101, 0); /* 0xc101 is MSR_GS_BASE */
 #endif
 }
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 30a9143..edc4ca4 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -30,6 +30,7 @@
 #include  /* for printk, memcpy */
 #include 
 #include 
+#include 
 
 /*
  * Shared page for communicating with the hypervisor.
@@ -89,6 +90,30 @@ static inline void sse_init(void) {
 #define sse_init()
 #endif
 
+#ifdef CONFIG_PARAVIRT
+#define hpc_init()
+#else
+static void hpc_init(void)
+{
+uint32_t eax, ebx, ecx, edx, base;
+
+for ( base = XEN_CPUID_FIRST_LEAF;
+  base < XEN_CPUID_FIRST_LEAF + 0x1; base += 0x100 )
+{
+cpuid(base, , , , );
+
+if ( (ebx == XEN_CPUID_SIGNATURE_EBX) &&
+ (ecx == XEN_CPUID_SIGNATURE_ECX) &&
+ (edx == XEN_CPUID_SIGNATURE_EDX) &&
+ ((eax - base) >= 2) )
+break;
+}
+
+cpuid(base + 2, , , , );
+wrmsrl(ebx, (unsigned long)_page);
+barrier();
+}
+#endif
 
 /*
  * INITIAL C ENTRY POINT.
@@ -99,6 +124,7 @@ arch_init(void *par)
static char hello[] = "Bootstrapping...\n";
start_info_t *si;
 
+   hpc_init();
(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
 
trap_init();
diff --git a/include/x86/os.h b/include/x86/os.h
index eeefbe2..7b7869a 100644
--- a/include/x86/os.h
+++ b/include/x86/os.h
@@ -440,20 +440,23 @@ static __inline__ unsigned long __ffs(unsigned long word)
  (val) = ((unsigned long)__a) | (((unsigned long)__d)<<32); \
 } while(0)
 
-#define wrmsr(msr,val1,val2) \
-  __asm__ __volatile__("wrmsr" \
-   : /* no outputs */ \
-   : "c" (msr), "a" (val1), "d" (val2))
-
-#define wrmsrl(msr,val) 
wrmsr(msr,(uint32_t)((uint64_t)(val)),((uint64_t)(val))>>32)
-
-
 #else /* ifdef __x86_64__ */
 #error "Unsupported architecture"
 #endif
+
 #endif /* ifdef __INSIDE_MINIOS */
 
 /* common i386 and x86_64  /
+#define wrmsr(msr,val1,val2) \
+  __asm__ __volatile__("wrmsr" \
+   : /* no outputs */ \
+   : "c" (msr), "a" (val1), "d" (val2))
+
+static inline void wrmsrl(unsigned msr, uint64_t val)
+{
+wrmsr(msr, (uint32_t)(val & 0xULL), (uint32_t)(val >> 32));
+}
+
 struct __synch_xchg_dummy { unsigned long a[100]; };
 #define __synch_xg(x) ((struct __synch_xchg_dummy *)(x))
 
@@ -571,6 +574,15 @@ HYPERVISOR_xsm_op(
 return _hypercall1(int, xsm_op, op);
 }
 
+static inline void cpuid(uint32_t leaf,
+ uint32_t *eax, uint32_t *ebx,
+ uint32_t *ecx, uint32_t *edx)
+{
+asm volatile ("cpuid"
+  : "=a" (*eax), "=b" (*ebx), "=c" (*ecx), "=d" (*edx)
+  : "0" (leaf));
+}
+
 #undef ADDR
 
 #endif /* not assembly */
-- 
2.6.6


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

[Xen-devel] [PATCH v2 14/22] mini-os: add map_frame_virt() function

[Juergen Gross]

Add a function map_frame_virt() to map a given frame and return its
virtual address.

On arm we just use the frame physical address, while on x86 we take a
page from the virtual kernel area. For this purpose make this area
available even in case of undefined CONFIG_BALLOON.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/balloon.c|  2 --
 arch/arm/mm.c |  5 +
 arch/x86/balloon.c| 13 -
 arch/x86/mm.c | 23 +++
 balloon.c |  9 -
 include/balloon.h |  1 -
 include/mm.h  |  1 +
 include/x86/arch_mm.h |  1 +
 8 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/arch/arm/balloon.c b/arch/arm/balloon.c
index 958ecba..1df7d1c 100644
--- a/arch/arm/balloon.c
+++ b/arch/arm/balloon.c
@@ -25,8 +25,6 @@
 
 #ifdef CONFIG_BALLOON
 
-unsigned long virt_kernel_area_end;   /* TODO: find a virtual area */
-
 void arch_pfn_add(unsigned long pfn, unsigned long mfn)
 {
 }
diff --git a/arch/arm/mm.c b/arch/arm/mm.c
index 4f58fc7..dbde162 100644
--- a/arch/arm/mm.c
+++ b/arch/arm/mm.c
@@ -141,3 +141,8 @@ grant_entry_t *arch_init_gnttab(int nr_grant_frames)
 
 return to_virt(gnttab_table);
 }
+
+unsigned long map_frame_virt(unsigned long mfn)
+{
+return mfn_to_virt(mfn);
+}
diff --git a/arch/x86/balloon.c b/arch/x86/balloon.c
index 16aaae4..10b440c 100644
--- a/arch/x86/balloon.c
+++ b/arch/x86/balloon.c
@@ -29,9 +29,6 @@
 #include 
 
 #ifdef CONFIG_BALLOON
-
-unsigned long virt_kernel_area_end = VIRT_KERNEL_AREA;
-
 #ifdef CONFIG_PARAVIRT
 static void p2m_invalidate(unsigned long *list, unsigned long start_idx)
 {
@@ -53,7 +50,7 @@ static inline unsigned long *p2m_to_virt(unsigned long p2m)
 
 void arch_remap_p2m(unsigned long max_pfn)
 {
-unsigned long pfn;
+unsigned long pfn, new_p2m;
 unsigned long *l3_list, *l2_list, *l1_list;
 
 l3_list = p2m_l3list();
@@ -67,17 +64,15 @@ void arch_remap_p2m(unsigned long max_pfn)
 if ( p2m_pages(nr_max_pages) <= p2m_pages(max_pfn) )
 return;
 
+new_p2m = alloc_virt_kernel(p2m_pages(nr_max_pages));
 for ( pfn = 0; pfn < max_pfn; pfn += P2M_ENTRIES )
 {
-map_frame_rw(virt_kernel_area_end + PAGE_SIZE * (pfn / P2M_ENTRIES),
+map_frame_rw(new_p2m + PAGE_SIZE * (pfn / P2M_ENTRIES),
  virt_to_mfn(phys_to_machine_mapping + pfn));
 }
 
-phys_to_machine_mapping = (unsigned long *)virt_kernel_area_end;
+phys_to_machine_mapping = (unsigned long *)new_p2m;
 printk("remapped p2m list to %p\n", phys_to_machine_mapping);
-
-virt_kernel_area_end += PAGE_SIZE * p2m_pages(nr_max_pages);
-ASSERT(virt_kernel_area_end <= VIRT_DEMAND_AREA);
 }
 
 int arch_expand_p2m(unsigned long max_pfn)
diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index f5248a4..762599d 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -57,6 +57,7 @@ unsigned long mfn_zero;
 pgentry_t *pt_base;
 static unsigned long first_free_pfn;
 static unsigned long last_free_pfn;
+static unsigned long virt_kernel_area_end = VIRT_KERNEL_AREA;
 
 extern char stack[];
 extern void page_walk(unsigned long va);
@@ -829,3 +830,25 @@ grant_entry_t *arch_init_gnttab(int nr_grant_frames)
 HYPERVISOR_grant_table_op(GNTTABOP_setup_table, , 1);
 return map_frames(frames, nr_grant_frames);
 }
+
+unsigned long alloc_virt_kernel(unsigned n_pages)
+{
+unsigned long addr;
+
+addr = virt_kernel_area_end;
+virt_kernel_area_end += PAGE_SIZE * n_pages;
+ASSERT(virt_kernel_area_end <= VIRT_DEMAND_AREA);
+
+return addr;
+}
+
+unsigned long map_frame_virt(unsigned long mfn)
+{
+unsigned long addr;
+
+addr = alloc_virt_kernel(1);
+if ( map_frame_rw(addr, mfn) )
+return 0;
+
+return addr;
+}
diff --git a/balloon.c b/balloon.c
index 8669edb..b0d0230 100644
--- a/balloon.c
+++ b/balloon.c
@@ -50,20 +50,19 @@ void get_max_pages(void)
 
 void mm_alloc_bitmap_remap(void)
 {
-unsigned long i;
+unsigned long i, new_bitmap;
 
 if ( mm_alloc_bitmap_size >= ((nr_max_pages + 1) >> 3) )
 return;
 
+new_bitmap = alloc_virt_kernel(PFN_UP((nr_max_pages + 1) >> 3));
 for ( i = 0; i < mm_alloc_bitmap_size; i += PAGE_SIZE )
 {
-map_frame_rw(virt_kernel_area_end + i,
+map_frame_rw(new_bitmap + i,
  virt_to_mfn((unsigned long)(mm_alloc_bitmap) + i));
 }
 
-mm_alloc_bitmap = (unsigned long *)virt_kernel_area_end;
-virt_kernel_area_end += round_pgup((nr_max_pages + 1) >> 3);
-ASSERT(virt_kernel_area_end <= VIRT_DEMAND_AREA);
+mm_alloc_bitmap = (unsigned long *)new_bitmap;
 }
 
 #define N_BALLOON_FRAMES 64
diff --git a/include/balloon.h b/include/balloon.h
index 8cd41af..6cfec4f 100644
--- a/include/balloon.h
+++ b/include/balloon.h
@@ -33,7 +33,6 @@
 #define BALLOON_EMERGENCY_PAGES   64
 
 extern unsigned long nr_max_pages;
-extern unsigned long virt_kernel_area_end;
 extern unsigned 

[Xen-devel] [PATCH v2 11/22] mini-os: add static page tables for virtual kernel area for HVMlite

[Juergen Gross]

In HVMlite mode we need the virtual kernel area for mapping of the
console and xenbus ring pages as especially on 32 bit architecture
their pfns might be above the supported maximum memory size.

Add the page tables needed for doing the mapping.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/mm.c | 11 +++
 arch/x86/x86_64.S |  7 +++
 2 files changed, 18 insertions(+)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 0543017..cbb5617 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -733,6 +733,17 @@ void arch_init_mm(unsigned long* start_pfn_p, unsigned 
long* max_pfn_p)
 
 *start_pfn_p = start_pfn;
 *max_pfn_p = max_pfn;
+
+#ifndef CONFIG_PARAVIRT
+#ifdef __x86_64__
+BUILD_BUG_ON(l4_table_offset(VIRT_KERNEL_AREA) != 1 ||
+ l3_table_offset(VIRT_KERNEL_AREA) != 0 ||
+ l2_table_offset(VIRT_KERNEL_AREA) != 0);
+#else
+BUILD_BUG_ON(l3_table_offset(VIRT_KERNEL_AREA) != 0 ||
+ l2_table_offset(VIRT_KERNEL_AREA) == 0);
+#endif
+#endif
 }
 
 grant_entry_t *arch_init_gnttab(int nr_grant_frames)
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 17a9ead..5932bfb 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -418,10 +418,17 @@ ENTRY(__arch_switch_threads)
 .data
 .globl page_table_base
 .align __PAGE_SIZE
+page_table_virt_l2:
+PTE(page_table_virt_l1 + L2_PROT)
+.align __PAGE_SIZE, 0
+page_table_virt_l3:
+PTE(page_table_virt_l2 + L3_PROT)
+.align __PAGE_SIZE, 0
 page_table_l3:
 PTE(page_table_l2 + L3_PROT)
 .align __PAGE_SIZE, 0
 page_table_base:
 PTE(page_table_l3 + L4_PROT)
+PTE(page_table_virt_l3 + L4_PROT)
 .align __PAGE_SIZE, 0
 #endif
-- 
2.6.6


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

[Xen-devel] [PATCH v2 07/22] mini-os: support hvm_op hypercall

[Juergen Gross]

Support the HYPERVISOR_hvm_op() hypercall which is needed for HVMlite.
Add convenience functions hvm_get_parameter() and hvm_set_parameter().

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/setup.c  | 15 ---
 hypervisor.c  | 27 +++
 include/hypervisor.h  |  5 +
 include/x86/x86_32/hypercall-x86_32.h |  6 ++
 include/x86/x86_64/hypercall-x86_64.h |  6 ++
 5 files changed, 44 insertions(+), 15 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 06afe46..cbe67c6 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -25,21 +25,6 @@ extern char shared_info_page[PAGE_SIZE];
 
 void *device_tree;
 
-static int hvm_get_parameter(int idx, uint64_t *value)
-{
-struct xen_hvm_param xhv;
-int ret;
-
-xhv.domid = DOMID_SELF;
-xhv.index = idx;
-ret = HYPERVISOR_hvm_op(HVMOP_get_param, );
-if (ret < 0) {
-BUG();
-}
-*value = xhv.value;
-return ret;
-}
-
 static void get_console(void)
 {
 uint64_t v = -1;
diff --git a/hypervisor.c b/hypervisor.c
index 1b61d9b..715cfe8 100644
--- a/hypervisor.c
+++ b/hypervisor.c
@@ -36,6 +36,33 @@
 
 int in_callback;
 
+#ifndef CONFIG_PARAVIRT
+int hvm_get_parameter(int idx, uint64_t *value)
+{
+struct xen_hvm_param xhv;
+int ret;
+
+xhv.domid = DOMID_SELF;
+xhv.index = idx;
+ret = HYPERVISOR_hvm_op(HVMOP_get_param, );
+if ( ret < 0 )
+BUG();
+
+*value = xhv.value;
+return ret;
+}
+
+int hvm_set_parameter(int idx, uint64_t value)
+{
+struct xen_hvm_param xhv;
+
+xhv.domid = DOMID_SELF;
+xhv.index = idx;
+xhv.value = value;
+return HYPERVISOR_hvm_op(HVMOP_set_param, );
+}
+#endif
+
 void do_hypervisor_callback(struct pt_regs *regs)
 {
 unsigned long  l1, l2, l1i, l2i;
diff --git a/include/hypervisor.h b/include/hypervisor.h
index 21b3566..6e421b1 100644
--- a/include/hypervisor.h
+++ b/include/hypervisor.h
@@ -23,6 +23,7 @@
 #else
 #error "Unsupported architecture"
 #endif
+#include 
 #include 
 
 /*
@@ -37,6 +38,10 @@ extern union start_info_union start_info_union;
 #define start_info (start_info_union.start_info)
 
 /* hypervisor.c */
+#ifndef CONFIG_PARAVIRT
+int hvm_get_parameter(int idx, uint64_t *value);
+int hvm_set_parameter(int idx, uint64_t value);
+#endif
 void force_evtchn_callback(void);
 void do_hypervisor_callback(struct pt_regs *regs);
 void mask_evtchn(uint32_t port);
diff --git a/include/x86/x86_32/hypercall-x86_32.h 
b/include/x86/x86_32/hypercall-x86_32.h
index 99a4ee3..5c93464 100644
--- a/include/x86/x86_32/hypercall-x86_32.h
+++ b/include/x86/x86_32/hypercall-x86_32.h
@@ -324,6 +324,12 @@ HYPERVISOR_domctl(
return _hypercall1(int, domctl, op);
 }
 
+static inline unsigned long
+HYPERVISOR_hvm_op(int op, void *arg)
+{
+   return _hypercall2(unsigned long, hvm_op, op, arg);
+}
+
 #endif /* __HYPERCALL_X86_32_H__ */
 
 /*
diff --git a/include/x86/x86_64/hypercall-x86_64.h 
b/include/x86/x86_64/hypercall-x86_64.h
index e00b3bd..6171812 100644
--- a/include/x86/x86_64/hypercall-x86_64.h
+++ b/include/x86/x86_64/hypercall-x86_64.h
@@ -331,6 +331,12 @@ HYPERVISOR_domctl(
return _hypercall1(int, domctl, op);
 }
 
+static inline unsigned long
+HYPERVISOR_hvm_op(int op, void *arg)
+{
+   return _hypercall2(unsigned long, hvm_op, op, arg);
+}
+
 #endif /* __HYPERCALL_X86_64_H__ */
 
 /*
-- 
2.6.6


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

[Xen-devel] [PATCH v2 08/22] mini-os: initialize trap handling for HVMlite

[Juergen Gross]

Trap handling for HVMlite domains requires an initialized IDT.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/setup.c  | 15 --
 arch/x86/traps.c  | 88 +++
 arch/x86/x86_64.S |  4 +++
 include/x86/os.h  |  1 +
 4 files changed, 93 insertions(+), 15 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index edc4ca4..efecefb 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -52,10 +52,6 @@ char stack[2*STACK_SIZE];
 
 extern char shared_info[PAGE_SIZE];
 
-/* Assembler interface fns in entry.S. */
-void hypervisor_callback(void);
-void failsafe_callback(void);
-
 #if defined(__x86_64__)
 #define __pte(x) ((pte_t) { (x) } )
 #else
@@ -162,17 +158,6 @@ arch_init(void *par)
/* Grab the shared_info pointer and put it in a safe place. */
HYPERVISOR_shared_info = map_shared_info(start_info.shared_info);
 
-   /* Set up event and failsafe callback addresses. */
-#ifdef __i386__
-   HYPERVISOR_set_callbacks(
-   __KERNEL_CS, (unsigned long)hypervisor_callback,
-   __KERNEL_CS, (unsigned long)failsafe_callback);
-#else
-   HYPERVISOR_set_callbacks(
-   (unsigned long)hypervisor_callback,
-   (unsigned long)failsafe_callback, 0);
-#endif
-
start_kernel();
 }
 
diff --git a/arch/x86/traps.c b/arch/x86/traps.c
index 307a14c..3b1fffb 100644
--- a/arch/x86/traps.c
+++ b/arch/x86/traps.c
@@ -1,10 +1,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /*
  * These are assembler stubs in entry.S.
@@ -293,6 +295,11 @@ void do_spurious_interrupt_bug(struct pt_regs * regs)
 {
 }
 
+/* Assembler interface fns in entry.S. */
+void hypervisor_callback(void);
+void failsafe_callback(void);
+
+#ifdef CONFIG_PARAVIRT
 /*
  * Submit a virtual IDT to teh hypervisor. This consists of tuples
  * (interrupt vector, privilege ring, CS:EIP of handler).
@@ -325,9 +332,90 @@ static trap_info_t trap_table[] = {
 void trap_init(void)
 {
 HYPERVISOR_set_trap_table(trap_table);
+
+#ifdef __i386__
+HYPERVISOR_set_callbacks(
+__KERNEL_CS, (unsigned long)hypervisor_callback,
+__KERNEL_CS, (unsigned long)failsafe_callback);
+#else
+HYPERVISOR_set_callbacks(
+(unsigned long)hypervisor_callback,
+(unsigned long)failsafe_callback, 0);
+#endif
 }
 
 void trap_fini(void)
 {
 HYPERVISOR_set_trap_table(NULL);
 }
+#else
+
+#define INTR_STACK_SIZE PAGE_SIZE
+static uint8_t intr_stack[INTR_STACK_SIZE] __attribute__((aligned(16)));
+
+hw_tss tss __attribute__((aligned(16))) =
+{
+#if defined(__i386__)
+.esp0 = (unsigned long)_stack[INTR_STACK_SIZE],
+.ss0  = __KERN_DS,
+#elif defined(__x86_64__)
+.rsp0 = (unsigned long)_stack[INTR_STACK_SIZE],
+#endif
+.iopb = X86_TSS_INVALID_IO_BITMAP,
+};
+
+static void setup_gate(unsigned int entry, void *addr, unsigned int dpl)
+{
+idt[entry].offset0 = (unsigned long)addr & 0x;
+idt[entry].selector = __KERN_CS;
+idt[entry]._r0 = 0;
+idt[entry].type = 14;
+idt[entry].s = 0;
+idt[entry].dpl = dpl;
+idt[entry].p = 1;
+idt[entry].offset1 = ((unsigned long)addr >> 16) & 0x;
+#if defined(__x86_64__)
+idt[entry].ist = 0;
+idt[entry].offset2 = ((unsigned long)addr >> 32) & 0xu;
+idt[entry]._r1 = 0;
+#endif
+}
+
+void trap_init(void)
+{
+setup_gate(TRAP_divide_error, _error, 0);
+setup_gate(TRAP_debug, , 0);
+setup_gate(TRAP_int3, , 3);
+setup_gate(TRAP_overflow, , 3);
+setup_gate(TRAP_bounds, , 0);
+setup_gate(TRAP_invalid_op, _op, 0);
+setup_gate(TRAP_no_device, _not_available, 0);
+setup_gate(TRAP_copro_seg, _segment_overrun, 0);
+setup_gate(TRAP_invalid_tss, _TSS, 0);
+setup_gate(TRAP_no_segment, _not_present, 0);
+setup_gate(TRAP_stack_error, _segment, 0);
+setup_gate(TRAP_gp_fault, _protection, 0);
+setup_gate(TRAP_page_fault, _fault, 0);
+setup_gate(TRAP_spurious_int, _interrupt_bug, 0);
+setup_gate(TRAP_copro_error, _error, 0);
+setup_gate(TRAP_alignment_check, _check, 0);
+setup_gate(TRAP_simd_error, _coprocessor_error, 0);
+setup_gate(TRAP_xen_callback, hypervisor_callback, 0);
+
+asm volatile ("lidt idt_ptr");
+
+gdt[GDTE_TSS] = (typeof(*gdt))INIT_GDTE((unsigned long), 0x67, 0x89);
+asm volatile ("ltr %w0" :: "rm" (GDTE_TSS * 8));
+
+if ( hvm_set_parameter(HVM_PARAM_CALLBACK_IRQ,
+   (2ULL << 56) | TRAP_xen_callback) )
+{
+xprintk("Request for Xen HVM callback vector failed\n");
+do_exit();
+}
+}
+
+void trap_fini(void)
+{
+}
+#endif
diff --git a/arch/x86/x86_64.S b/arch/x86/x86_64.S
index 373f400..e725c63 100644
--- a/arch/x86/x86_64.S
+++ b/arch/x86/x86_64.S
@@ -130,18 +130,22 @@ KERNEL_CS_MASK = 0xfc
 .endm
 
 .macro HYPERVISOR_IRET flag
+#ifdef CONFIG_PARAVIRT
testl 

[Xen-devel] [PATCH v2 04/22] mini-os: make some memory management related macros usable from assembler

[Juergen Gross]

Especially page table entry definitions are currently not usable from
assembler sources on x86 as the constants are defined with ULL suffix.
Change this by adding the suffix only when the header is included from
a C source.

Hide some C prototypes when in assembler environment.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 include/x86/arch_mm.h | 56 +++
 1 file changed, 34 insertions(+), 22 deletions(-)

diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h
index 690a919..2b18b34 100644
--- a/include/x86/arch_mm.h
+++ b/include/x86/arch_mm.h
@@ -29,11 +29,16 @@
 #include 
 #if defined(__i386__)
 #include 
+#define __CONST(x) x ## ULL
 #elif defined(__x86_64__)
 #include 
+#define __CONST(x) x ## UL
 #else
 #error "Unsupported architecture"
 #endif
+#define CONST(x) __CONST(x)
+#else
+#define CONST(x) x
 #endif
 
 /*
@@ -81,14 +86,16 @@
 #define PRIpte "016llx"
 #ifndef __ASSEMBLY__
 typedef uint64_t pgentry_t;
+#else
+#define PTE(val) .long val; .long 0
 #endif
 
-#define MAX_MEM_SIZE0x3f00UL
-#define VIRT_KERNEL_AREA0x3f00UL
-#define VIRT_DEMAND_AREA0x4000UL
-#define VIRT_HEAP_AREA  0xb000UL
+#define MAX_MEM_SIZECONST(0x3f00)
+#define VIRT_KERNEL_AREACONST(0x3f00)
+#define VIRT_DEMAND_AREACONST(0x4000)
+#define VIRT_HEAP_AREA  CONST(0xb000)
 
-#define DEMAND_MAP_PAGES0x6UL
+#define DEMAND_MAP_PAGESCONST(0x6)
 #define HEAP_PAGES_MAX  ((HYPERVISOR_VIRT_START - VIRT_HEAP_AREA) / \
  PAGE_SIZE - 1)
 
@@ -115,15 +122,17 @@ typedef uint64_t pgentry_t;
 #define PRIpte "016lx"
 #ifndef __ASSEMBLY__
 typedef unsigned long pgentry_t;
+#else
+#define PTE(val) .quad val
 #endif
 
-#define MAX_MEM_SIZE(512ULL << 30)
-#define VIRT_KERNEL_AREA0x0080UL
-#define VIRT_DEMAND_AREA0x1000UL
-#define VIRT_HEAP_AREA  0x2000UL
+#define MAX_MEM_SIZE(CONST(512) << 30)
+#define VIRT_KERNEL_AREACONST(0x0080)
+#define VIRT_DEMAND_AREACONST(0x1000)
+#define VIRT_HEAP_AREA  CONST(0x2000)
 
-#define DEMAND_MAP_PAGES0x800UL
-#define HEAP_PAGES_MAX  0x800UL
+#define DEMAND_MAP_PAGESCONST(0x800)
+#define HEAP_PAGES_MAX  CONST(0x800)
 
 #endif
 
@@ -147,16 +156,16 @@ typedef unsigned long pgentry_t;
   (((_a) >> L4_PAGETABLE_SHIFT) & (L4_PAGETABLE_ENTRIES - 1))
 #endif
 
-#define _PAGE_PRESENT  0x001ULL
-#define _PAGE_RW   0x002ULL
-#define _PAGE_USER 0x004ULL
-#define _PAGE_PWT  0x008ULL
-#define _PAGE_PCD  0x010ULL
-#define _PAGE_ACCESSED 0x020ULL
-#define _PAGE_DIRTY0x040ULL
-#define _PAGE_PAT  0x080ULL
-#define _PAGE_PSE  0x080ULL
-#define _PAGE_GLOBAL   0x100ULL
+#define _PAGE_PRESENT  CONST(0x001)
+#define _PAGE_RW   CONST(0x002)
+#define _PAGE_USER CONST(0x004)
+#define _PAGE_PWT  CONST(0x008)
+#define _PAGE_PCD  CONST(0x010)
+#define _PAGE_ACCESSED CONST(0x020)
+#define _PAGE_DIRTYCONST(0x040)
+#define _PAGE_PAT  CONST(0x080)
+#define _PAGE_PSE  CONST(0x080)
+#define _PAGE_GLOBAL   CONST(0x100)
 
 #if defined(__i386__)
 #define L1_PROT (_PAGE_PRESENT|_PAGE_RW|_PAGE_ACCESSED)
@@ -191,12 +200,14 @@ typedef unsigned long pgentry_t;
 #define L3_P2M_IDX(pfn) (((pfn) >> L2_P2M_SHIFT) & P2M_MASK)
 #define INVALID_P2M_ENTRY (~0UL)
 
+#ifndef __ASSEMBLY__
 void p2m_chk_pfn(unsigned long pfn);
 
 static inline unsigned long p2m_pages(unsigned long pages)
 {
 return (pages + P2M_ENTRIES - 1) >> L1_P2M_SHIFT;
 }
+#endif
 
 #include "arch_limits.h"
 #define PAGE_SIZE   __PAGE_SIZE
@@ -239,7 +250,6 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine)
phys = (phys << PAGE_SHIFT) | (machine & ~PAGE_MASK);
return phys;
 }
-#endif
 
 #define VIRT_START ((unsigned long)&_text)
 
@@ -288,4 +298,6 @@ static __inline__ paddr_t machine_to_phys(maddr_t machine)
 
 pgentry_t *need_pgt(unsigned long addr);
 
+#endif
+
 #endif /* _ARCH_MM_H_ */
-- 
2.6.6


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

[Xen-devel] [PATCH v2 03/22] mini-os: add CONFIG_PARAVIRT

[Juergen Gross]

Add a new config macro CONFIG_PARAVIRT which defaults to be defined on
x86. This is the first step for supporting a HVMlite Mini-OS.

Doing this via CONFIG_PARAVIRT instead of something like CONFIG_HVMLITE
was chosen as the arm port can then drop some dummy routines needed for
para-virtualization only.

Add include/paravirt.h for future support of paravirt specific
handling.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 Config.mk  |  6 ++
 include/paravirt.h | 33 +
 2 files changed, 39 insertions(+)
 create mode 100644 include/paravirt.h

diff --git a/Config.mk b/Config.mk
index 8ab1a7e..aa36761 100644
--- a/Config.mk
+++ b/Config.mk
@@ -153,6 +153,11 @@ LDFLAGS-$(clang) += -plugin LLVMgold.so
 endif
 
 # Configuration defaults
+ifeq ($(TARGET_ARCH_FAM),x86)
+CONFIG_PARAVIRT ?= y
+else
+CONFIG_PARAVIRT ?= n
+endif
 CONFIG_START_NETWORK ?= y
 CONFIG_SPARSE_BSS ?= y
 CONFIG_QEMU_XS_ARGS ?= n
@@ -172,6 +177,7 @@ CONFIG_LWIP ?= $(lwip)
 CONFIG_BALLOON ?= n
 
 # Export config items as compiler directives
+DEFINES-$(CONFIG_PARAVIRT) += -DCONFIG_PARAVIRT
 DEFINES-$(CONFIG_START_NETWORK) += -DCONFIG_START_NETWORK
 DEFINES-$(CONFIG_SPARSE_BSS) += -DCONFIG_SPARSE_BSS
 DEFINES-$(CONFIG_QEMU_XS_ARGS) += -DCONFIG_QEMU_XS_ARGS
diff --git a/include/paravirt.h b/include/paravirt.h
new file mode 100644
index 000..7852e16
--- /dev/null
+++ b/include/paravirt.h
@@ -0,0 +1,33 @@
+/* -*-  Mode:C; c-basic-offset:4; tab-width:4 -*-
+ *
+ * (C) 2016 - Juergen Gross, SUSE Linux GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef _PARAVIRT_H
+#define _PARAVIRT_H
+
+#if defined(CONFIG_PARAVIRT)
+
+#else
+
+#endif
+
+#endif /* _PARAVIRT_H */
-- 
2.6.6


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

[Xen-devel] [PATCH v2 05/22] mini-os: add boot code for HVMlite support

[Juergen Gross]

A HVMlite domain is always starting in 32 bit mode. Add the appropriate
boot code to arch/x86 for the non-paravirtualized case.

For this boot code to become active we need to suppress the pv related
elfnotes and add an appropriate elfnote for HVMlite.

As the HVMlite boot code is more or less the same for 32- and 64-bit
Mini-OS #include the new code from x86_[32|64].S in order to avoid
error prone code duplication. The specific parts of 32- or 64-bit code
are added to x86_[32|64].S

This enables Mini-OS to start the boot process in HVMlite mode until it
enters C code. This is working for 32- and for 64-bit mode.

Signed-off-by: Juergen Gross 
---
V2: add some comments as requested by Samuel Thibault
---
 Makefile   |   2 +-
 arch/x86/arch.mk   |   4 +
 arch/x86/mm.c  |  31 +
 arch/x86/setup.c   |   4 +-
 arch/x86/x86_32.S  |  31 -
 arch/x86/x86_64.S  |  35 -
 arch/x86/x86_hvm.S |  88 +
 include/compiler.h |   1 +
 include/x86/desc.h | 367 +
 include/x86/os.h   |   5 +
 minios.mk  |   2 +-
 11 files changed, 556 insertions(+), 14 deletions(-)
 create mode 100644 arch/x86/x86_hvm.S
 create mode 100644 include/x86/desc.h

diff --git a/Makefile b/Makefile
index 779bc91..b783684 100644
--- a/Makefile
+++ b/Makefile
@@ -24,7 +24,7 @@ include minios.mk
 LDLIBS := 
 APP_LDLIBS := 
 LDARCHLIB := -L$(OBJ_DIR)/$(TARGET_ARCH_DIR) -l$(ARCH_LIB_NAME)
-LDFLAGS_FINAL := -T $(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds
+LDFLAGS_FINAL := -T $(TARGET_ARCH_DIR)/minios-$(MINIOS_TARGET_ARCH).lds 
$(ARCH_LDFLAGS_FINAL)
 
 # Prefix for global API names. All other symbols are localised before
 # linking with EXTRA_OBJS.
diff --git a/arch/x86/arch.mk b/arch/x86/arch.mk
index 81e8118..673a19d 100644
--- a/arch/x86/arch.mk
+++ b/arch/x86/arch.mk
@@ -20,3 +20,7 @@ EXTRA_INC += $(TARGET_ARCH_FAM)/$(MINIOS_TARGET_ARCH)
 EXTRA_SRC += arch/$(EXTRA_INC)
 endif
 
+ifeq ($(CONFIG_PARAVIRT),n)
+ARCH_LDFLAGS_FINAL := --oformat=elf32-i386
+ARCH_AS_DEPS += x86_hvm.S
+endif
diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 88a928d..fe18f53 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -56,6 +56,37 @@ unsigned long mfn_zero;
 extern char stack[];
 extern void page_walk(unsigned long va);
 
+#ifndef CONFIG_PARAVIRT
+#include 
+user_desc gdt[NR_GDT_ENTRIES] =
+{
+[GDTE_CS64_DPL0] = INIT_GDTE_SYM(0, 0xf, COMMON, CODE, DPL0, R, L),
+[GDTE_CS32_DPL0] = INIT_GDTE_SYM(0, 0xf, COMMON, CODE, DPL0, R, D),
+[GDTE_DS32_DPL0] = INIT_GDTE_SYM(0, 0xf, COMMON, DATA, DPL0, B, W),
+
+[GDTE_CS64_DPL3] = INIT_GDTE_SYM(0, 0xf, COMMON, CODE, DPL3, R, L),
+[GDTE_CS32_DPL3] = INIT_GDTE_SYM(0, 0xf, COMMON, CODE, DPL3, R, D),
+[GDTE_DS32_DPL3] = INIT_GDTE_SYM(0, 0xf, COMMON, DATA, DPL3, B, W),
+
+/* [GDTE_TSS] */
+/* [GDTE_TSS + 1] */
+};
+
+desc_ptr gdt_ptr =
+{
+.limit = sizeof(gdt) - 1,
+.base = (unsigned long),
+};
+
+gate_desc idt[256] = { };
+
+desc_ptr idt_ptr =
+{
+.limit = sizeof(idt) - 1,
+.base = (unsigned long),
+};
+#endif
+
 /*
  * Make pt_pfn a new 'level' page table frame and hook it into the page
  * table at offset in previous level MFN (pref_l_mfn). pt_pfn is a guest
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 5e87dd1..30a9143 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -94,9 +94,10 @@ static inline void sse_init(void) {
  * INITIAL C ENTRY POINT.
  */
 void
-arch_init(start_info_t *si)
+arch_init(void *par)
 {
static char hello[] = "Bootstrapping...\n";
+   start_info_t *si;
 
(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
 
@@ -111,6 +112,7 @@ arch_init(start_info_t *si)
/* Copy the start_info struct to a globally-accessible area. */
/* WARN: don't do printk before here, it uses information from
   shared_info. Use xprintk instead. */
+   si = par;
memcpy(_info, si, sizeof(*si));
 
/* print out some useful information  */
diff --git a/arch/x86/x86_32.S b/arch/x86/x86_32.S
index 6dc985a..6f38708 100644
--- a/arch/x86/x86_32.S
+++ b/arch/x86/x86_32.S
@@ -1,20 +1,31 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
+#ifdef CONFIG_PARAVIRT
 ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS, .asciz "Mini-OS")
 ELFNOTE(Xen, XEN_ELFNOTE_LOADER, .asciz "generic")
 ELFNOTE(Xen, XEN_ELFNOTE_HYPERCALL_PAGE, _WORD hypercall_page)
 ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION, .asciz "xen-3.0")
 ELFNOTE(Xen, XEN_ELFNOTE_PAE_MODE, .asciz "yes")
+.text
 
-.globl _start, shared_info, hypercall_page
+.globl _start
 
 _start:
-cld
 lss stack_start,%esp
+#else
+
+#include "x86_hvm.S"
+movl stack_start,%esp
+
+#endif
+cld
 andl $(~(__STACK_SIZE-1)), %esp
 push %esi 
 call arch_init
@@ -22,14 +33,15 @@ _start:
 stack_start:
.long stack+(2*__STACK_SIZE), __KERNEL_SS
 

[Xen-devel] [PATCH v2 02/22] mini-os: make dump_regs() work in early boot

[Juergen Gross]

dump_regs() will result in page fault in early boot as there is no
current thread pointer. Handle this case.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/x86/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/traps.c b/arch/x86/traps.c
index 6353718..307a14c 100644
--- a/arch/x86/traps.c
+++ b/arch/x86/traps.c
@@ -32,7 +32,7 @@ void machine_check(void);
 
 void dump_regs(struct pt_regs *regs)
 {
-printk("Thread: %s\n", current->name);
+printk("Thread: %s\n", current ? current->name : "*NONE*");
 #ifdef __i386__
 printk("EIP: %lx, EFLAGS %lx.\n", regs->eip, regs->eflags);
 printk("EBX: %08lx ECX: %08lx EDX: %08lx\n",
-- 
2.6.6


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

[Xen-devel] [PATCH v2 19/22] mini-os: remove using start_info in architecture independent code

[Juergen Gross]

The start_info structure should be used only in case of CONFIG_PARAVIRT
defined. Remove it from being used in other places. Especially the
usage as parameter for applications linked to the kernel is no good
idea.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/setup.c |  8 
 arch/x86/setup.c |  8 
 daytime.c|  2 +-
 include/hypervisor.h | 11 ---
 kernel.c |  6 +++---
 main.c   |  6 +++---
 test.c   | 20 ++--
 7 files changed, 17 insertions(+), 44 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index 05b405b..b65023c 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -9,13 +9,6 @@
 #include 
 
 /*
- * This structure contains start-of-day info, such as pagetable base pointer,
- * address of the shared_info structure, and things like that.
- * On x86, the hypervisor passes it to us. On ARM, we fill it in ourselves.
- */
-union start_info_union start_info_union;
-
-/*
  * Shared page for communicating with the hypervisor.
  * Events flags go here, for example.
  */
@@ -47,7 +40,6 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
 /* Map shared_info page */
 HYPERVISOR_shared_info = map_shared_info(NULL);
 
-/* Fill in start_info */
 get_console(NULL);
 get_xenbus(NULL);
 
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 278e88f..50aa504 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -40,12 +40,6 @@
 shared_info_t *HYPERVISOR_shared_info;
 
 /*
- * This structure contains start-of-day info, such as pagetable base pointer,
- * address of the shared_info structure, and things like that.
- */
-union start_info_union start_info_union;
-
-/*
  * Just allocate the kernel stack here. SS:ESP is set up to point here
  * in head.S.
  */
@@ -151,7 +145,6 @@ arch_init(void *par)
/* Setup memory management info from start_info. */
arch_mm_preinit(par);
 
-   /* Copy the start_info struct to a globally-accessible area. */
/* WARN: don't do printk before here, it uses information from
   shared_info. Use xprintk instead. */
get_console(par);
@@ -162,7 +155,6 @@ arch_init(void *par)
HYPERVISOR_shared_info = map_shared_info(par);
 
si = par;
-   memcpy(_info, si, sizeof(*si));
 
/* print out some useful information  */
printk("Xen Minimal OS!\n");
diff --git a/daytime.c b/daytime.c
index 7dc0de0..6049e78 100644
--- a/daytime.c
+++ b/daytime.c
@@ -60,7 +60,7 @@ void run_server(void *p)
 }
 
 
-int app_main(start_info_t *si)
+int app_main(void *p)
 {
 create_thread("server", run_server, NULL);
 return 0;
diff --git a/include/hypervisor.h b/include/hypervisor.h
index 7c44702..3073a8a 100644
--- a/include/hypervisor.h
+++ b/include/hypervisor.h
@@ -26,17 +26,6 @@
 #include 
 #include 
 
-/*
- * a placeholder for the start of day information passed up from the hypervisor
- */
-union start_info_union
-{
-start_info_t start_info;
-char padding[512];
-};
-extern union start_info_union start_info_union;
-#define start_info (start_info_union.start_info)
-
 /* hypervisor.c */
 #ifndef CONFIG_PARAVIRT
 int hvm_get_parameter(int idx, uint64_t *value);
diff --git a/kernel.c b/kernel.c
index f22997e..0d84a9b 100644
--- a/kernel.c
+++ b/kernel.c
@@ -110,9 +110,9 @@ static void shutdown_thread(void *p)
 
 
 /* This should be overridden by the application we are linked against. */
-__attribute__((weak)) int app_main(start_info_t *si)
+__attribute__((weak)) int app_main(void *p)
 {
-printk("kernel.c: dummy main: start_info=%p\n", si);
+printk("kernel.c: dummy main: par=%p\n", p);
 return 0;
 }
 
@@ -149,7 +149,7 @@ void start_kernel(void)
 #endif
 
 /* Call (possibly overridden) app_main() */
-app_main(_info);
+app_main(NULL);
 
 /* Everything initialised, start idle thread */
 run_idle_thread();
diff --git a/main.c b/main.c
index 71e3be3..263364c 100644
--- a/main.c
+++ b/main.c
@@ -185,10 +185,10 @@ void _exit(int ret)
 do_exit();
 }
 
-int app_main(start_info_t *si)
+int app_main(void *p)
 {
-printk("main.c: dummy main: start_info=%p\n", si);
-main_thread = create_thread("main", call_main, si);
+printk("main.c: dummy main: par=%p\n", p);
+main_thread = create_thread("main", call_main, p);
 return 0;
 }
 #endif
diff --git a/test.c b/test.c
index 154af49..42a2666 100644
--- a/test.c
+++ b/test.c
@@ -552,28 +552,28 @@ static void shutdown_thread(void *p)
 }
 #endif
 
-int app_main(start_info_t *si)
+int app_main(void *p)
 {
-printk("Test main: start_info=%p\n", si);
+printk("Test main: par=%p\n", p);
 #ifdef CONFIG_XENBUS
-create_thread("xenbus_tester", xenbus_tester, si);
+create_thread("xenbus_tester", xenbus_tester, p);
 #endif
-create_thread("periodic_thread", periodic_thread, si);
+create_thread("periodic_thread", periodic_thread, p);

[Xen-devel] [PATCH v2 21/22] mini-os: get physical memory map

[Juergen Gross]

On HVMlite we have to look at the physical memory map to know which
memory frames are usable.

In order to make life easier we define a dummy memory map for other
domain types (pv and arm) which has just one entry with a maximum
memory size.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/mm.c |  8 ++
 arch/x86/mm.c | 72 ++
 arch/x86/setup.c  |  1 +
 include/e820.h| 48 +++
 include/x86/arch_mm.h |  4 +++
 mm.c  | 79 ---
 6 files changed, 183 insertions(+), 29 deletions(-)
 create mode 100644 include/e820.h

diff --git a/arch/arm/mm.c b/arch/arm/mm.c
index dbde162..8c156c4 100644
--- a/arch/arm/mm.c
+++ b/arch/arm/mm.c
@@ -7,6 +7,14 @@
 #include 
 
 uint32_t physical_address_offset;
+struct e820entry e820_map[1] = {
+{
+.addr = 0,
+.size = ULONG_MAX - 1,
+.type = E820_RAM
+}
+};
+unsigned e820_entries = 1;
 
 unsigned long allocate_ondemand(unsigned long n, unsigned long alignment)
 {
diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 762599d..8dd90b8 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef MM_DEBUG
@@ -63,6 +64,15 @@ extern char stack[];
 extern void page_walk(unsigned long va);
 
 #ifdef CONFIG_PARAVIRT
+struct e820entry e820_map[1] = {
+{
+.addr = 0,
+.size = ULONG_MAX - 1,
+.type = E820_RAM
+}
+};
+unsigned e820_entries = 1;
+
 void arch_mm_preinit(void *p)
 {
 start_info_t *si = p;
@@ -102,10 +112,25 @@ desc_ptr idt_ptr =
 .base = (unsigned long),
 };
 
+struct e820entry e820_map[E820_MAX];
+unsigned e820_entries;
+
+static char *e820_types[E820_TYPES] = {
+[E820_RAM]  = "RAM",
+[E820_RESERVED] = "Reserved",
+[E820_ACPI] = "ACPI",
+[E820_NVS]  = "NVS",
+[E820_UNUSABLE] = "Unusable",
+[E820_PMEM] = "PMEM"
+};
+
 void arch_mm_preinit(void *p)
 {
 long ret;
 domid_t domid = DOMID_SELF;
+struct xen_memory_map memmap;
+int i;
+unsigned long pfn, max = 0;
 
 pt_base = page_table_base;
 first_free_pfn = PFN_UP(to_phys(&_end));
@@ -116,6 +141,53 @@ void arch_mm_preinit(void *p)
 do_exit();
 }
 last_free_pfn = ret;
+
+memmap.nr_entries = E820_MAX;
+set_xen_guest_handle(memmap.buffer, e820_map);
+ret = HYPERVISOR_memory_op(XENMEM_memory_map, );
+if ( ret < 0 )
+{
+xprintk("could not get memory map\n");
+do_exit();
+}
+e820_entries = memmap.nr_entries;
+
+for ( i = 0; i < e820_entries; i++ )
+{
+if ( e820_map[i].type != E820_RAM )
+continue;
+pfn = (e820_map[i].addr + e820_map[i].size) >> PAGE_SHIFT;
+if ( pfn > max )
+max = pfn;
+}
+
+if ( max < last_free_pfn )
+last_free_pfn = max;
+}
+
+void arch_print_memmap(void)
+{
+int i;
+unsigned long from, to;
+char *type;
+char buf[12];
+
+printk("Memory map:\n");
+for ( i = 0; i < e820_entries; i++ )
+{
+if ( e820_map[i].type >= E820_TYPES || !e820_types[e820_map[i].type] )
+{
+snprintf(buf, sizeof(buf), "%8x", e820_map[i].type);
+type = buf;
+}
+else
+{
+type = e820_types[e820_map[i].type];
+}
+from = e820_map[i].addr;
+to = from + e820_map[i].size - 1;
+printk("%012lx-%012lx: %s\n", from, to, type);
+}
 }
 #endif
 
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index f422a96..86955cf 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -151,6 +151,7 @@ static void print_start_of_day(void *p)
 printk("   flags: 0x%x\n", (unsigned int)si->flags);
 printk("cmd_line: %s\n", cmdline);
 printk("   stack: %p-%p\n", stack, stack + sizeof(stack));
+arch_print_memmap();
 }
 #endif
 
diff --git a/include/e820.h b/include/e820.h
new file mode 100644
index 000..920551c
--- /dev/null
+++ b/include/e820.h
@@ -0,0 +1,48 @@
+/* -*-  Mode:C; c-basic-offset:4; tab-width:4 -*-
+ *
+ * (C) 2016 - Juergen Gross, SUSE Linux GmbH
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING 

[Xen-devel] [PATCH v2 13/22] mini-os: correct wrong calculation of alloc bitmap size

[Juergen Gross]

When remapping the page allocator's bitmap for the ballooning support
the calculation of the needed size is wrong. This doesn't really
matter today as nothing is allocated after that bitmap, but it should
be corrected nevertheless.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 balloon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/balloon.c b/balloon.c
index 8d2f151..8669edb 100644
--- a/balloon.c
+++ b/balloon.c
@@ -52,7 +52,7 @@ void mm_alloc_bitmap_remap(void)
 {
 unsigned long i;
 
-if ( mm_alloc_bitmap_size >= ((nr_max_pages + 1) >> (PAGE_SHIFT + 3)) )
+if ( mm_alloc_bitmap_size >= ((nr_max_pages + 1) >> 3) )
 return;
 
 for ( i = 0; i < mm_alloc_bitmap_size; i += PAGE_SIZE )
@@ -62,7 +62,7 @@ void mm_alloc_bitmap_remap(void)
 }
 
 mm_alloc_bitmap = (unsigned long *)virt_kernel_area_end;
-virt_kernel_area_end += round_pgup((nr_max_pages + 1) >> (PAGE_SHIFT + 3));
+virt_kernel_area_end += round_pgup((nr_max_pages + 1) >> 3);
 ASSERT(virt_kernel_area_end <= VIRT_DEMAND_AREA);
 }
 
-- 
2.6.6


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

[Xen-devel] [PATCH v2 16/22] mini-os: setup xenbus interface parameters

[Juergen Gross]

In order to support HVMlite we need to get the ring page and event
channel from the hypervisor via hypercalls. Move the already existing
get_xenbus() function from arm specific coding to xenbus/xenbus.c and
provide a similar paravirtualized function.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
 arch/arm/setup.c | 16 +---
 arch/x86/setup.c |  1 +
 events.c |  3 +--
 include/xenbus.h |  3 +++
 xenbus/xenbus.c  | 40 +++-
 5 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/arch/arm/setup.c b/arch/arm/setup.c
index a021616..72e025a 100644
--- a/arch/arm/setup.c
+++ b/arch/arm/setup.c
@@ -25,20 +25,6 @@ extern char shared_info_page[PAGE_SIZE];
 
 void *device_tree;
 
-void get_xenbus(void)
-{
-uint64_t value;
-
-if (hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, ))
-BUG();
-
-start_info.store_evtchn = (int)value;
-
-if(hvm_get_parameter(HVM_PARAM_STORE_PFN, ))
-BUG();
-start_info.store_mfn = (unsigned long)value;
-}
-
 /*
  * INITIAL C ENTRY POINT.
  */
@@ -72,7 +58,7 @@ void arch_init(void *dtb_pointer, uint32_t physical_offset)
 
 /* Fill in start_info */
 get_console(NULL);
-get_xenbus();
+get_xenbus(NULL);
 
 gic_init();
 
diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 0c1f2ec..6645784 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -138,6 +138,7 @@ arch_init(void *par)
/* WARN: don't do printk before here, it uses information from
   shared_info. Use xprintk instead. */
get_console(par);
+   get_xenbus(par);
si = par;
memcpy(_info, si, sizeof(*si));
 
diff --git a/events.c b/events.c
index 76ea617..e8ef8aa 100644
--- a/events.c
+++ b/events.c
@@ -46,8 +46,7 @@ void unbind_all_ports(void)
 
 for ( i = 0; i < NR_EVS; i++ )
 {
-if ( i == console_evtchn ||
- i == start_info.store_evtchn)
+if ( i == console_evtchn || i == xenbus_evtchn )
 continue;
 
 if ( test_and_clear_bit(i, bound_ports) )
diff --git a/include/xenbus.h b/include/xenbus.h
index d3bb7af..5646a25 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@ -29,6 +29,9 @@ struct xenbus_event {
 };
 typedef struct xenbus_event *xenbus_event_queue;
 
+extern uint32_t xenbus_evtchn;
+
+void get_xenbus(void *p);
 char *xenbus_watch_path_token(xenbus_transaction_t xbt, const char *path, 
const char *token, xenbus_event_queue *events);
 char *xenbus_unwatch_path_token(xenbus_transaction_t xbt, const char *path, 
const char *token);
 extern struct wait_queue_head xenbus_watch_queue;
diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
index 0ab387a..636786c 100644
--- a/xenbus/xenbus.c
+++ b/xenbus/xenbus.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -62,6 +63,31 @@ struct xenbus_req_info
 #define NR_REQS 32
 static struct xenbus_req_info req_info[NR_REQS];
 
+uint32_t xenbus_evtchn;
+
+#ifdef CONFIG_PARAVIRT
+void get_xenbus(void *p)
+{
+start_info_t *si = p;
+
+xenbus_evtchn = si->store_evtchn;
+xenstore_buf = mfn_to_virt(si->store_mfn);
+}
+#else
+void get_xenbus(void *p)
+{
+uint64_t v;
+
+if ( hvm_get_parameter(HVM_PARAM_STORE_EVTCHN, ) )
+BUG();
+xenbus_evtchn = v;
+
+if( hvm_get_parameter(HVM_PARAM_STORE_PFN, ) )
+BUG();
+xenstore_buf = (struct xenstore_domain_interface *)map_frame_virt(v);
+}
+#endif
+
 static void memcpy_from_ring(const void *Ring,
 void *Dest,
 int off,
@@ -269,7 +295,7 @@ static void xenbus_thread_func(void *ign)
 }
 
 wmb();
-notify_remote_via_evtchn(start_info.store_evtchn);
+notify_remote_via_evtchn(xenbus_evtchn);
 }
 }
 }
@@ -335,15 +361,11 @@ void init_xenbus(void)
 {
 int err;
 DEBUG("init_xenbus called.\n");
-xenstore_buf = mfn_to_virt(start_info.store_mfn);
 create_thread("xenstore", xenbus_thread_func, NULL);
 DEBUG("buf at %p.\n", xenstore_buf);
-err = bind_evtchn(start_info.store_evtchn,
- xenbus_evtchn_handler,
-  NULL);
-unmask_evtchn(start_info.store_evtchn);
-printk("xenbus initialised on irq %d mfn %#llx\n",
-  err, (unsigned long long) start_info.store_mfn);
+err = bind_evtchn(xenbus_evtchn, xenbus_evtchn_handler, NULL);
+unmask_evtchn(xenbus_evtchn);
+printk("xenbus initialised on irq %d\n", err);
 }
 
 void fini_xenbus(void)
@@ -425,7 +447,7 @@ static void xb_write(int type, int req_id, 
xenbus_transaction_t trans_id,
 xenstore_buf->req_prod += len;
 
 /* Send evtchn to notify remote */
-notify_remote_via_evtchn(start_info.store_evtchn);
+notify_remote_via_evtchn(xenbus_evtchn);
 }
 
 /* Send a mesasge to xenbus, in the same fashion as xb_write, and
-- 
2.6.6


___
Xen-devel mailing list

[Xen-devel] [PATCH v2 20/22] mini-os: print start of day messages depending on domain type

[Juergen Gross]

Select what to print in arch_init() depending on the domain type.

Signed-off-by: Juergen Gross 
Reviewed-by: Samuel Thibault 
---
V2: add printing nr_modules as requested by Samuel Thibault
---
 arch/x86/setup.c | 48 +---
 1 file changed, 33 insertions(+), 15 deletions(-)

diff --git a/arch/x86/setup.c b/arch/x86/setup.c
index 50aa504..f422a96 100644
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -91,6 +91,24 @@ static void get_cmdline(void *p)
 
 strncpy(cmdline, (char *)si->cmd_line, MAX_CMDLINE_SIZE - 1);
 }
+
+static void print_start_of_day(void *p)
+{
+start_info_t *si = p;
+
+printk("Xen Minimal OS (pv)!\n");
+printk("  start_info: %p(VA)\n", si);
+printk("nr_pages: 0x%lx\n", si->nr_pages);
+printk("  shared_inf: 0x%08lx(MA)\n", si->shared_info);
+printk(" pt_base: %p(VA)\n", (void *)si->pt_base);
+printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
+printk("mfn_list: %p(VA)\n", (void *)si->mfn_list);
+printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
+printk(" mod_len: %lu\n", si->mod_len);
+printk("   flags: 0x%x\n", (unsigned int)si->flags);
+printk("cmd_line: %s\n", cmdline);
+printk("   stack: %p-%p\n", stack, stack + sizeof(stack));
+}
 #else
 static void hpc_init(void)
 {
@@ -120,6 +138,20 @@ static void get_cmdline(void *p)
 if ( si->cmdline_paddr )
 strncpy(cmdline, to_virt(si->cmdline_paddr), MAX_CMDLINE_SIZE - 1);
 }
+
+static void print_start_of_day(void *p)
+{
+struct hvm_start_info *si = p;
+
+printk("Xen Minimal OS (hvm)!\n");
+printk("  start_info: %p(VA)\n", si);
+printk("  shared_inf: %p(VA)\n", HYPERVISOR_shared_info);
+printk(" modlist: 0x%lx(PA)\n", (unsigned long)si->modlist_paddr);
+printk("  nr_modules: %u\n", si->nr_modules);
+printk("   flags: 0x%x\n", (unsigned int)si->flags);
+printk("cmd_line: %s\n", cmdline);
+printk("   stack: %p-%p\n", stack, stack + sizeof(stack));
+}
 #endif
 
 /*
@@ -129,7 +161,6 @@ void
 arch_init(void *par)
 {
static char hello[] = "Bootstrapping...\n";
-   start_info_t *si;
 
hpc_init();
(void)HYPERVISOR_console_io(CONSOLEIO_write, strlen(hello), hello);
@@ -154,21 +185,8 @@ arch_init(void *par)
/* Grab the shared_info pointer and put it in a safe place. */
HYPERVISOR_shared_info = map_shared_info(par);
 
-   si = par;
-
/* print out some useful information  */
-   printk("Xen Minimal OS!\n");
-   printk("  start_info: %p(VA)\n", si);
-   printk("nr_pages: 0x%lx\n", si->nr_pages);
-   printk("  shared_inf: %p(VA)\n", HYPERVISOR_shared_info);
-   printk(" pt_base: %p(VA)\n", (void *)si->pt_base);
-   printk("nr_pt_frames: 0x%lx\n", si->nr_pt_frames);
-   printk("mfn_list: %p(VA)\n", (void *)si->mfn_list);
-   printk("   mod_start: 0x%lx(VA)\n", si->mod_start);
-   printk(" mod_len: %lu\n", si->mod_len);
-   printk("   flags: 0x%x\n", (unsigned int)si->flags);
-   printk("cmd_line: %s\n", cmdline);
-   printk("   stack: %p-%p\n", stack, stack + sizeof(stack));
+   print_start_of_day(par);
 
start_kernel();
 }
-- 
2.6.6


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

Re: [Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files

[Wei Liu]

On Fri, Aug 12, 2016 at 06:32:35PM +0100, Lars Kurth wrote:
> Added a COPYING file as a boilerplate to explain license oddities in
> this directory
> 
> Added a vtpm/COPYING file which contains MIT licensed files only
> 
> Added a vtpmmgr/README.source file which contains many BSD-3-Clause
> files that originally came from tools/vtpm_manager
> 
> Signed-off-by: Lars Kurth 
> ---
>  stubdom/COPYING   | 31 +++
>  stubdom/vtpm/COPYING  | 26 ++
>  stubdom/vtpmmgr/README.source | 23 +++
>  3 files changed, 80 insertions(+)
>  create mode 100644 stubdom/COPYING
>  create mode 100644 stubdom/vtpm/COPYING
>  create mode 100644 stubdom/vtpmmgr/README.source
> 
> diff --git a/stubdom/COPYING b/stubdom/COPYING
> new file mode 100644
> index 000..a5071b3
> --- /dev/null
> +++ b/stubdom/COPYING
> @@ -0,0 +1,31 @@
> +Most files in this directory are covered by version 2 of the 
> +GNU General Public License except where explicitly stated.
> +See the main COPYING file in xen.git for more information.
> +
> +Notable exceptions are in the following directories
> +
> +vtpm
> + 
> +Exclusively contains code licensed under a MIT license
> +Also see vtpm/COPYING
> +
> +vtpmmgr
> +===
> +Contains a significant portion of files which are licensed
> +under a BSD-3-Clause license. These files were imported from
> +elsewhere and are copyrighted as follows:
> +
> +Copyright (c) 2005, Intel Corp.
> +All rights reserved.
> +
> +See README.source for a complete list of files
> +
> +Otherwise, this directory contains several files licensed under
> +GPLv2+, or without copyright headers. 
> +
> +*.patch and *.diff files
> +
> +This directory contains a number of *.patch and *.diff files. 
> +These files describe changes to source files and are thus 
> +licensed under the license from which the *.patch and *.diff
> +were generated.
> diff --git a/stubdom/vtpm/COPYING b/stubdom/vtpm/COPYING
> new file mode 100644
> index 000..80780b8
> --- /dev/null
> +++ b/stubdom/vtpm/COPYING
> @@ -0,0 +1,26 @@
> +This copyright applies to all files within this subdirectory and its
> +subdirectories, unless explicitly stated otherwise within individual 
> +source files.
> +
> +All other files in the Xen source distribution are covered by version
> +2 of the GNU General Public License except where explicitly stated.
> +See the main COPYING file in xen.git for more information.
> +
> +=
> +
> +Permission is hereby granted, free of charge, to any person obtaining a copy
> +of this software and associated documentation files (the "Software"), to
> +deal in the Software without restriction, including without limitation the
> +rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
> +sell copies of the Software, and to permit persons to whom the Software is
> +furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice shall be included in
> +all copies or substantial portions of the Software.
> +
> +THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
> +ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
> +INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
> +FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
> +DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
> +SOFTWARE.
> \ No newline at end of file

Here, please add a new line.

> diff --git a/stubdom/vtpmmgr/README.source b/stubdom/vtpmmgr/README.source
> new file mode 100644
> index 000..1b45997
> --- /dev/null
> +++ b/stubdom/vtpmmgr/README.source
> @@ -0,0 +1,23 @@
> +About
> +=
> +This documents the upstream sources for files in this directory.
> +
> +The following files are based off of the original 
> +tools/vtpm_manager code base in xen.git, which has since been 
> +deleted: 
> +

It doesn't seem obvious to me during my archeology.

tools/vtpm_manager was deleted in
b918dce5bb2a665a34ff893a9df5392fb8ea429d, but it is not clear whether
your claim (the new code based off the deleted files) is true.

For one, there is no uuid.h in the deleted code -- apparently vtpm
wouldn't have to ship its own uuid library because OS has one. But then,
there is such claim in the new uuid.h, so I'm rather confused. I'm
inclined to believe that this uuid.h is either written afresh or
imported from somewhere else.

It would also be helpful if you can post your methodology for getting
the list of file so that I can check if there is something either you or
I miss.

> +init.c
> +log.c
> +log.h
> +marshal.h
> +tcg.h
> +tpm.c
> +tpm.h
> +tpm2.c
> +tpm2.h
> +tpm2_marshal.h
> +uuid.h
> +vtpm_cmd_handler.c
> +vtpm_manager.h
> +vtpmmgr.c
> +vtpmmgr.h
> \ No newline at end of file

New line please.

> -- 
> 2.5.4 (Apple Git-61)
> 

[Xen-devel] mkelf32 incorrectly filling out the program headers for NOTE

[Sylvain Munaut]

Hi,

Here's the readelf output (snipped) on a xen-4.7 build :

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .text PROGBITS0010 80 1d0220 00 WAX  0   0 64
  [ 2] .shstrtab STRTAB   1d0340 18 00  0   0  1
  [ 3] .note NOTE00168e58 168ed8 24 00  0   0  4

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD   0x80 0x0010 0x0010 0x1d0220 0x216000 RWE 0x40
  NOTE   0x168e58 0x00168e58 0x00168e58 0x00024 0x00024 R   0x4

If you look at the "offset" value for the .note section and the NOTE
program headers, they don't match ... but both should represent an
offset inside the file image and to the same thing, so they should
match.

The correct one is the one of the .note and the incorrect value of the
program header one causes kexec to parse the header wrongly and just
plain crash. (granted it should be more robust and not segfault, but
still)


Cheers,

Sylvain Munaut,
Whatever s.a.

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

Re: [Xen-devel] [PATCH v3] xen: support enabling SMEP/SMAP for HVM only

[Jan Beulich]

>>> On 19.08.16 at 12:20,  wrote:
> Changes in v3:
> * Fix boot options.
> * Fix CR4 & mmu_cr4_features operations.
> * Disable SMEP/SMAP for Dom0.
> * Commit message refinement.

Several of my comments on v3 did not get taken care of (neither in
code nor verbally). I'm not going to repeat them here.

> @@ -1403,12 +1437,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> -if ( cpu_has_smep )
> +if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )
>  set_in_cr4(X86_CR4_SMEP);
>  
>  if ( !opt_smap )
>  setup_clear_cpu_cap(X86_FEATURE_SMAP);
> -if ( cpu_has_smap )
> +if ( cpu_has_smap && opt_smap != SMAP_HVM_ONLY )
>  set_in_cr4(X86_CR4_SMAP);

So this avoids setting the flags in CR4, but also in mmu_cr4_features.

> @@ -1430,8 +1464,19 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  arch_init_memory();
>  
> +/*
> + * Temporarily clear SMAP in internal feature bitmap to avoid
> + * patching unnecessary SMAP instructions when SMAP is disabled in
> + * Xen hypervisor.
> + */
> +if ( opt_smap == SMAP_HVM_ONLY )
> +__clear_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
> +
>  alternative_instructions();
>  
> +if ( opt_smap == SMAP_HVM_ONLY )
> +__set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);

I think the better approach would be to introduce a synthetic
feature, which gets set only when SMAP gets used by Xen for
itself. Even if not needed for alternative patching, I think for
symmetry reasons the same should then also be done for SMEP.

> @@ -1098,6 +1099,12 @@ void pv_cpuid(struct cpu_user_regs *regs)
>  b |= (host_featureset[FEATURESET_7b0] &
>special_features[FEATURESET_7b0]);
>  
> +if ( opt_smep == SMEP_HVM_ONLY )
> +b &= ~cpufeat_mask(X86_FEATURE_SMEP);
> +
> +if ( opt_smap == SMAP_HVM_ONLY )
> +b &= ~cpufeat_mask(X86_FEATURE_SMAP);

While you changed the place where you do the adjustment, my
previous comment holds: "These flags already can't be set in
pv_featureset, so the change is pointless."

> --- a/xen/include/asm-x86/setup.h
> +++ b/xen/include/asm-x86/setup.h
> @@ -51,6 +51,12 @@ void microcode_grab_module(
>  
>  extern uint8_t kbd_shift_flags;
>  
> +#define SMEP_HVM_ONLY -1
> +extern int opt_smep;
> +
> +#define SMAP_HVM_ONLY -1
> +extern int opt_smap;

Which then means that these still don't need to become non-static.
The #define-s, if you mean to retain them (in setup.c) would of
course need proper parenthesization.

Jan


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

Re: [Xen-devel] [PATCH 4/4] blktap2: Added COPYING file

[Wei Liu]

On Fri, Aug 12, 2016 at 06:32:36PM +0100, Lars Kurth wrote:
> Blktap2 has some complexity, as some files do not have (c) headers
> and the directory did not have a COPYING file. At this stage, we
> have not verified the intention of (c) holders. We may do this in
> future, if the need arises.
> 
> Signed-off-by: Lars Kurth 

I think this is going to be dropped since I'm going to remove blktap2
altogether.

Wei.

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

Re: [Xen-devel] [PATCH 2/4] Added source of ax_compare_version.m4 to import log

[Wei Liu]

On Fri, Aug 12, 2016 at 06:32:34PM +0100, Lars Kurth wrote:
> In addition:
> - fixed a reference, which was incorrect
> 
> Signed-off-by: Lars Kurth 

Reviewed-by: Wei Liu 

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

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

[Olaf Hering]

Does anyone remember why the the vbd frontend drivers also claim the
SCSI disks, but the vbd backend in qemu has no unplug support for SCSI?

The current situation for qemu-xen and qemu-xen-traditional is that both
will create an emulated LSI controller with disk=[vdev=sda]. The
xenlinux and pvops frontend drivers will claim the disk, but the
sym53c8xx will see and claim it as well. As a result each disk is
visible twice. One has to blacklist the sym53c8xx driver to avoid that.

What should be done to fix this?
#1 new unplug protocol for SCSI, but old guests dont know about it
#2 reuse IDE flag to also unplug SCSI. This would cover pvops and guests
   where xenlinux based xen-platform-pci.ko is loaded before
   sym53c8xx.ko. It would break guests with frontend drivers that do not
   claim SCSI disks, the SCSI disk would disappear (if such frontends
   really exist).
#3 do not provide SCSI if guest has PV drivers

Olaf


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

Re: [Xen-devel] [PATCH v8 05/13] libxl: Load guest BIOS from file

[Wei Liu]

On Tue, Aug 23, 2016 at 04:00:24PM -0400, Doug Goldstein wrote:
> On 8/18/16 10:13 AM, Wei Liu wrote:
> 
> >  
> > +if (info->device_model_version == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) 
> > {
> > +if (info->u.hvm.system_firmware) {
> > +bios_filename = info->u.hvm.system_firmware;
> > +} else {
> > +switch (info->u.hvm.bios) {
> > +case LIBXL_BIOS_TYPE_SEABIOS:
> > +bios_filename = libxl__seabios_path();
> > +break;
> > +case LIBXL_BIOS_TYPE_OVMF:
> > +bios_filename = libxl__ovmf_path();
> > +break;
> > +case LIBXL_BIOS_TYPE_ROMBIOS:
> > +default:
> > +abort();
> 
> Wei,
> 
> Please consider another solution. I've been trying to use libxl from
> Rust and the calls to abort() are just really hard to deal with. I know
> libxl has 50+ calls currently but let's work on reducing these as much
> as possible so that its possible to consume libxl in other languages.
> 
> abort() is just bad form for libraries because you don't give the caller
> the ability to catch the error and handle it appropriately (which could
> be as simple as displaying it to the user or potentially work around the
> issue.
> 
> I know you and Anthony have gone through 8 revisions but please consider
> changing this. I'm sorry for not speaking up sooner.

As said, the abort() in internal function marks an impossible situation
to get into -- much like BUG_ON in hypervisor. I would expect the error
to be handled in some other places in libxl. In this particular
instance, I haven't checked, but if there is no such check elsewhere, I
will either fix it here or somewhere else appropriate.

Furthermore, I'm not averse to systematically removing abort(), but I
would like to at least have a rough idea how upper layer would want to
handle that, and what is the implication on other parts of libxl.

Wei.

> -- 
> Doug Goldstein
> 




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

Re: [Xen-devel] [PATCH v4 8/9] symbols: Generate an xen-sym.map

[Jan Beulich]

>>> On 24.08.16 at 04:22,  wrote:
> You could construct _most_ of the names of the functions
> by doing 'nm --defined' but unfortunatly you do not get the
>  prefix that is added on in Xen . For example:
> 
> $ cat xen-syms.symbols |grep do_domain_pause
> 0x82d080104920 t domain.c#do_domain_pause
> $ nm --defined xen-syms|grep do_domain_pause
> 82d080104920 t do_domain_pause
> 
> This is normally not an issue, but if one is doing livepatching and
> wants during build-time verify that the symbols the livepatch payloads
> will patch do correspond to the one the hypervisor has built - this helps a 
> lot.
> 
> Note that during runtime one can do:
> [root@localhost xen]# cat /proc/xen/xensyms |grep do_domain_pause
> 82d080104920 t domain.c#do_domain_pause
> 
> But one may not want to build and verify a livepatch on the same host.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 7/9] livepatch: NOP if func->new_[addr] is zero.

[Jan Beulich]

>>> On 24.08.16 at 04:22,  wrote:
> 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.
> But on x86 we could NOP instructions that are much
> shorter or longer (up to 15 bytes).

And we could NOP multiple instructions in one go, i.e. the new
boundary you introduce is still arbitrary.

Jan


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

Re: [Xen-devel] [PATCH v4 6/9] livepatch: Add parsing for the symbol+0x

[Jan Beulich]

>>> On 24.08.16 at 04:22,  wrote:
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -237,13 +237,34 @@ static const char *livepatch_symbols_lookup(unsigned 
> long addr,
>  static int resolve_old_address(struct livepatch_func *f,
> const struct livepatch_elf *elf)
>  {
> +const char *s;
> +char *plus = NULL;

Pointless initializer.

> +unsigned long offset = 0;
> +
>  if ( f->old_addr )
>  return 0;
>  
> -f->old_addr = (void *)symbols_lookup_by_name(f->name);
> +s = f->name;

Otoh this could become s'es initializer.

> +/* + */
> +plus = strchr(f->name, '+');

And I think you should prefer using the local variable here.

Furthermore you're losing const here - does f->name really point
to memory that doesn't get mapped r/o?

> +if ( plus )
> +{
> +const char *endp = NULL;

Pointless initializer again (or else ...

> +offset = simple_strtoul(plus + 1, , 16);
> +
> +if ( *endp != '\0' )

... the deref here couldn't be unconditional).

> +return -EINVAL;
> +
> +/* So that symbol lookup works. */
> +*plus = '\0';
> +s = f->name;

Why? f->name didn't change afaict.

Overall - are you sure you want to disallow symbol names containing
+ characters? I.e. you don't want to add support for some form of
quoting?

Jan


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

Re: [Xen-devel] [PATCH v4 4/9] version: Print build-id at bootup.

[Jan Beulich]

>>> On 24.08.16 at 04:22,  wrote:
> Livepatch expected at some point to be able to print the
> build-id during bootup, which it did not.  The reason is
> that xen_build_init and livepatch_init are both __initcall
> type routines. This meant that when livepatch_init called
> xen_build_id, it would return -ENODATA as build_id_len was
> not setup yet (b/c xen_build_init would be called later).
> 
> The original patch fixed this by calling xen_build_init in
> livepatch_init which allows us to print the build-id of
> the hypervisor.
> 
> However the x86 maintainers pointed out that build-id
> is independent of Livepatch and in fact should print
> regardless whether Livepatch is enabled or not.
> 
> Therefore this patch moves the logic of printing the build-id
> to version.c.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Jan Beulich 


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

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

[Jan Beulich]

>>> On 24.08.16 at 04:22,  wrote:
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -70,6 +70,9 @@ struct payload {
>  unsigned int nsyms;  /* Nr of entries in .strtab and 
> symbols. */
>  struct livepatch_build_id id;/* ELFNOTE_DESC(.note.gnu.build-id) 
> of the payload. */
>  struct livepatch_build_id dep;   /* 
> ELFNOTE_DESC(.livepatch.depends). */
> +void **bss;  /* .bss's of the payload. */
> +size_t *bss_size;/* and their sizes. */

Is size_t wide enough in the extreme case? Perhaps yes, because I
don't think we'll ever load 64-bit ELF on a 32-bit platform.

> +size_t n_bss;/* Size of the array. */

As opposed to that, I think this one could be unsigned int (or else
you end up with inconsistencies in {move,apply}_payload()).

> @@ -374,14 +392,24 @@ static int move_payload(struct payload *payload, struct 
> livepatch_elf *elf)
>  elf->name, elf->sec[i].name, elf->sec[i].load_addr);
>  }
>  else
> -memset(elf->sec[i].load_addr, 0, elf->sec[i].sec->sh_size);
> +{
> +payload->bss[n_bss] = elf->sec[i].load_addr;
> +payload->bss_size[n_bss++] = elf->sec[i].sec->sh_size;
> +}
>  }
>  }
> +ASSERT(n_bss == payload->n_bss);
>  
>   out:
>  xfree(offset);
>  
>  return rc;
> +
> + out_mem:
> +dprintk(XENLOG_ERR, LIVEPATCH "%s: Could not allocate memory for 
> payload!\n",
> +elf->name);
> +rc = -ENOMEM;
> +goto out;

You leak any of the three buffers here which you managed to
successfully allocate.

Jan


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

[Xen-devel] [PATCH v3] gnttab: Add gntdev device mappings for FreeBSD

[Akshay Jaggi]

Add grant table userspace device mappings for
FreeBSD (enables support for qdisk backend
on FreeBSD Dom0).

Signed-off-by: Akshay Jaggi 

---
Changed since v1:
 * fix coding style
 * remove O_CLOEXEC
 * remove SET_MAX_GRANTS ioctl
 * update freebsd/gntdev.h to latest version
 * replace alloca with malloc

Changed since v2:
 * fix overflow bug
---
 tools/include/xen-sys/FreeBSD/gntdev.h | 191 
 tools/libs/gnttab/Makefile |   2 +-
 tools/libs/gnttab/freebsd.c| 318 +
 3 files changed, 510 insertions(+), 1 deletion(-)
 create mode 100644 tools/include/xen-sys/FreeBSD/gntdev.h
 create mode 100644 tools/libs/gnttab/freebsd.c

diff --git a/tools/include/xen-sys/FreeBSD/gntdev.h 
b/tools/include/xen-sys/FreeBSD/gntdev.h
new file mode 100644
index 000..5f31e21
--- /dev/null
+++ b/tools/include/xen-sys/FreeBSD/gntdev.h
@@ -0,0 +1,191 @@
+/*-
+ * Copyright (c) 2016 Akshay Jaggi 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * gntdev.h
+ *
+ * Interface to /dev/xen/gntdev.
+ *
+ * This device provides the user with two kinds of functionalities:
+ * 1. Grant Allocation
+ *Allocate a page of our own memory, and share it with a foreign domain.
+ * 2. Grant Mapping
+ *Map a grant allocated by a foreign domain, into our own memory.
+ *
+ *
+ * Grant Allocation
+ *
+ * Steps to allocate a grant:
+ * 1. Do an `IOCTL_GNTDEV_ALLOC_GREF ioctl`, with
+ * - `domid`, as the domain-id of the foreign domain
+ * - `flags`, ORed with GNTDEV_ALLOC_FLAG_WRITABLE if you want the foreign
+ *   domain to have write access to the shared memory
+ * - `count`, with the number of pages to share with the foreign domain
+ *
+ *Ensure that the structure you allocate has enough memory to store
+ *all the allocated grant-refs, i.e., you need to allocate
+ *(sizeof(struct ioctl_gntdev_alloc_gref) + (count - 1)*sizeof(uint32_t))
+ *bytes of memory.
+ *
+ * 2. Mmap the address given in `index` after a successful ioctl.
+ *This will give you access to the granted pages.
+ *
+ * Note:
+ * 1. The grant is not removed until all three of the following conditions
+ *are met
+ * - The region is not mmaped. That is, munmap() has been called if
+ *   the region was mmapped previously.
+ * - IOCTL_GNTDEV_DEALLOC_GREF ioctl has been performed. After you
+ *   perform this ioctl, you can no longer mmap or set notify on
+ *   the grant.
+ * - The foreign domain has stopped using the grant.
+ * 2. Granted pages can only belong to one mmap region.
+ * 3. Every page of granted memory is a unit in itself. What this means
+ *is that you can set a unmap notification for each of the granted
+ *pages, individually; you can mmap and dealloc-ioctl a contiguous
+ *range of allocated grants (even if alloc-ioctls were performed
+ *individually), etc.
+ *
+ *
+ * Grant Mapping
+ *
+ * Steps to map a grant:
+ * 1. Do a `IOCTL_GNTDEV_MAP_GRANT_REF` ioctl, with
+ * - `count`, as the number of foreign grants to map
+ * - `refs[i].domid`, as the domain id of the foreign domain
+ * - `refs[i].ref`, as the grant-ref for the grant to be mapped
+ *
+ * 2. Mmap the address given in `index` after a successful ioctl.
+ *This will give you access to the mapped pages.
+ *
+ * Note:
+ * 1. The map hypercall is not made till the region is mmapped.
+ * 2. The unit is defined by the map ioctl. This means that only one
+ *unmap notification can be set on a group of pages that were
+ *mapped together in one ioctl, and also no single mmaping of contiguous
+ *grant-maps is possible.
+ * 3. You 

Re: [Xen-devel] [PATCH 3/3] x86/levelling: Provide architectural OSXSAVE handling to masked native CPUID

[Jan Beulich]

>>> On 23.08.16 at 19:26,  wrote:
> Contrary to c/s b2507fe7 "x86/domctl: Update PV domain cpumasks when setting
> cpuid policy", Intel CPUID masks are applied after fast forwarding hardware
> state, rather than before.  (All behaviour in this regard appears completely
> undocumented by both Intel and AMD).
> 
> Therefore, a set bit in the MSR causes hardware to be fast-forwarded, while a
> clear bit forces the guests view to 0, even if CR4.OSXSAVE is actually set.
> 
> This allows Xen to provide an architectural view of a guest kernels
> CR4.OSXSAVE setting to any CPUID instruction issused by guest kernel or
> userspace.

Perhaps worth saying "non-PV CPUID instruction issued"?

> The masking value defaults to 1 (if the guest has XSAVE available) to cause
> fast-forwarding to occur for the HVM and idle vcpus.

Is the latter part actually true? I don't think idle vCPU-s get through
update_domain_cpuid_info(), as that gets called solely from a domctl
handler.

> Repored-by: Jan Beulich 

Reported-...

> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -211,6 +211,24 @@ static void amd_ctxt_switch_levelling(const struct vcpu 
> *next)
>   (nextd && is_pv_domain(nextd) && 
> nextd->arch.pv_domain.cpuidmasks)
>   ? nextd->arch.pv_domain.cpuidmasks : _defaults;
>  
> + if ((levelling_caps & LCAP_1cd) == LCAP_1cd) {
> + uint64_t val = masks->_1cd;
> +
> + /*
> +  * OSXSAVE defaults to 1, which causes fast-forwarding of
> +  * Xen's real setting.  Clobber it if disabled by the guest

Tab inside the comment?

> +  * kernel.
> +  */
> + if (next && is_pv_vcpu(next) &&
> + !(next->arch.pv_vcpu.ctrlreg[4] & X86_CR4_OSXSAVE))
> + val &= ~((uint64_t)cpufeat_mask(X86_FEATURE_OSXSAVE) << 
> 32);

I don't think idle vCPU-s would ever have their ctrlreg[4] updated, so
other than the description says you hide the flag here for them. Since
that shouldn't matter much except for the number of cases the
WRMSR below gets executed because the masks didn't match, I'm
not sure whether it's better to fix it here or to alter the description.
One might guess that fixing it would be better, as likely going forward
most (all?) guests will enable xsave, and hence we might save the
WRMSR in most of the cases if not needed for any other reason.

> @@ -218,6 +235,11 @@ static void __init noinline intel_init_levelling(void)
>   ecx &= opt_cpuid_mask_ecx;
>   edx &= opt_cpuid_mask_edx;
>  
> + /* Fast-forward bits - Must be set. */
> + if (ecx & cpufeat_mask(X86_FEATURE_XSAVE))
> + ecx |= cpufeat_mask(X86_FEATURE_OSXSAVE);
> + edx |= cpufeat_mask(X86_FEATURE_APIC);
> +
>   cpuidmask_defaults._1cd &= ((u64)edx << 32) | ecx;
>   }

Do we really want to rely on the mask MSRs to have all interesting
bits (and namely the two ones relevant here) set by the firmware?
I.e. don't you want to instead OR in the two bits after the &=?

Jan


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