Re: [Xen-devel] [PATCH v2] PVH Dom0 RMRR IOMMU mapping regression fix

[Jan Beulich]

>>> On 25.09.15 at 22:59,  wrote:
> From: Elena Ufimtseva 
> 
> This patch addresses a regression introduced by commit 
> 5ae03990c120a7b3067a52d9784c9aa72c0705a6 in new set_identity_p2m_entry.
> RMRRs are not being mapped in IOMMU for PVH Dom0. This causes pages faults 
> and
> some long 'hang-like' delays during Dom0 PVH boot and device assignments.
> 
> During construct_dom0, in PVH path p2m is being constructed and identity 
> mapped
> in IOMMU. The p2m type is p2m_mmio_direct and p2m access p2m_rwx.
> New code used to map RMRRs invoked from rmrr_identity_mapping
> checks if p2m entry exists with same type and access and if yes, skips iommu
> mapping. Since there are p2m entries for pvh dom0 iomem, RMRRs are not being
> mapped in IOMMU.
> 
> As was mentioned in the earlier discussion, the PVH Dom0 construction code
> should be modified to properly map RMRR regions in IOMMU. Since change will 
> be
> too invasive, this solution is a temporary fix at this time before better
> solution is in. Also as Jan mentioned, there is no need in having 'x' 
> permissions
> for p2m entry of a mmio region, thus changed here.

Well, now that I look at this again I think there could be reasons for
execute permission to be needed: Code placed in ROM may require
this. But then again Dom0 shouldn't on its own (i.e. without
involving the hypervisor) invoke such code, which usually would be
expecting to be run in root mode ring 0 anyway. So I think not
defaulting to include X is the right thing. Hence ...

> Signed-off-by: Elena Ufimtseva 

Reviewed-by: Jan Beulich 


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38018

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

version targeted for testing:
 qemuu8a47d575dfac0f6675e2ac56c5921cc520d021a6
baseline version:
 qemuu18640989a9f5e4d2e84b566c52ff1fccfa0dbf4a

Last test of basis38018  2015-09-22 15:28:43 Z5 days
Testing same since38083  2015-09-27 08:49:53 Z0 days1 attempts


People who touched revisions under test:
  Alex Williamson 
  Alexander Graf 
  Alexey Kardashevskiy 
  Andrew Jones 
  Anton Blanchard 
  Ashok kumar 
  Aurelien Jarno 
  Beniamino Galvani 
  Bharata B Rao 
  Daniel P. Berrange 
  David Gibson 
  Gavin Shan 
  Gerd Hoffmann 
  Graeme Gregory 
  James Hogan 
  Laurent Vivier 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Markus Armbruster 
  Michael Roth 
  Paolo Bonzini 
  Pavel Fedin 
  Peter Maydell 
  Richard W.M. Jones 
  Rudolf Marek 
  Rudolf Marek 
  Sam Bobroff 
  Shannon Zhao 
  Shlomo Pongratz 
  Stefan Weil 
  Thomas Huth 

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

[Xen-devel] [PATCH 00/13] Add VMX TSC scaling support

[Haozhong Zhang]

This patchset adds support for VMX TSC scaling feature which is
available on Intel Skylake CPU. The specification of VMX TSC scaling
can be found at
http://www.intel.com/content/www/us/en/processors/timestamp-counter-scaling-virtualization-white-paper.html

VMX TSC scaling allows guest TSC which is read by guest rdtsc(p)
instructions increases in a rate that is customized by the hypervisor
and can be different than the host TSC rate. Basically, VMX TSC
scaling adds a 64-bit field called TSC multiplier in VMCS so that, if
VMX TSC scaling is enabled, TSC read by guest rdtsc(p) instructions
will be calculated by the following formula:

  guest EDX:EAX = (Host TSC * TSC multiplier) >> 48 + VMX TSC Offset

where, Host TSC = Host MSR_IA32_TSC + Host MSR_IA32_TSC_ADJUST.

This patchset is composed of following four parts.
  1. PATCH 01 - 02 fix bugs in tsc_get_info() which could result in
 errors when VMX TSC scaling is used.
 
  2. PATCH 03 - 09 add/move the common parts of VMX TSC scaling and
 SVM TSC ratio to hvm.c and x86/time.c.
 
  3. PATCH 10 - 12 implement the VMX-specific code for supporting VMX
 TSC scaling.
 
  4. PATCH 13 adapts libxl for VMX TSC scaling (as well as SVM TSC
 ratio).

Haozhong Zhang (13):
  x86/time.c: Use system time to calculate elapsed_nsec in
tsc_get_info()
  x86/time.c: Get the correct guest TSC rate in tsc_get_info()
  x86/hvm: Collect information of TSC scaling ratio
  x86/hvm: Setup TSC scaling ratio
  x86/hvm: Replace architecture TSC scaling by a common function
  x86/hvm: Scale host TSC when setting/getting guest TSC
  x86/hvm: Move saving/loading vcpu's TSC to common code
  x86/hvm: Detect TSC scaling through hvm_funcs in tsc_set_info()
  x86/time.c: Scale host TSC in pvclock properly
  vmx: Detect and initialize VMX RDTSC(P) scaling
  vmx: Use scaled host TSC to calculate TSC offset
  vmx: Add a call-back to apply TSC scaling ratio to hardware
  tools/libxl: Add 'vtsc_khz' option to set guest TSC rate

 tools/libxl/libxl_types.idl|   1 +
 tools/libxl/libxl_x86.c|   4 +-
 tools/libxl/xl_cmdimpl.c   |  22 
 xen/arch/x86/hvm/hvm.c | 110 +
 xen/arch/x86/hvm/svm/svm.c |  25 ++---
 xen/arch/x86/hvm/vmx/vmcs.c|  11 +++-
 xen/arch/x86/hvm/vmx/vmx.c |  39 +++--
 xen/arch/x86/time.c|  33 ---
 xen/include/asm-x86/domain.h   |   2 +
 xen/include/asm-x86/hvm/hvm.h  |  19 +++
 xen/include/asm-x86/hvm/svm/svm.h  |   4 +-
 xen/include/asm-x86/hvm/vmx/vmcs.h |   7 +++
 12 files changed, 240 insertions(+), 37 deletions(-)

--
2.4.8


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

[Xen-devel] [PATCH 01/13] x86/time.c: Use system time to calculate elapsed_nsec in tsc_get_info()

[Haozhong Zhang]

When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, the existing tsc_get_info() calculates elapsed_nsec by scaling
the host TSC with a ratio between guest TSC rate and
nanoseconds. However, the result will be incorrect if the guest TSC rate
differs from the host TSC rate. This patch fixes this problem by using
the system time as elapsed_nsec.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/time.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index bbb7e6c..a345efb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1868,8 +1868,7 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
 *gtsc_khz = d->arch.tsc_khz;
 break;
 }
-tsc = rdtsc();
-*elapsed_nsec = scale_delta(tsc, &d->arch.vtsc_to_ns);
+*elapsed_nsec = get_s_time();
 *gtsc_khz = cpu_khz;
 break;
 case TSC_MODE_PVRDTSCP:
-- 
2.4.8


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

[Xen-devel] [PATCH 05/13] x86/hvm: Replace architecture TSC scaling by a common function

[Haozhong Zhang]

This patch implements a common function hvm_scale_tsc() to calculate the
scaling of TSC by using TSC scaling information which is collected by
architecture code.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/hvm.c| 53 +++
 xen/arch/x86/hvm/svm/svm.c|  4 +--
 xen/include/asm-x86/hvm/hvm.h |  1 +
 xen/include/asm-x86/hvm/svm/svm.h |  3 ---
 4 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 63ce4de..2d55a36 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -297,6 +297,59 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
 return 1;
 }
 
+/*
+ * Multiply tsc by a fixed point number represented by ratio.
+ *
+ * The most significant 64-N bits (mult) of ratio represent the
+ * integral part of the fixed point number; the remaining N bits
+ * (frac) represent the fractional part, ie. ratio represents a fixed
+ * point number (mult + frac * 2^(-N)).
+ *
+ * N equals to hvm_funcs.tsc_scaling_ratio_frac_bits.
+ */
+static u64 __scale_tsc(u64 tsc, u64 ratio)
+{
+u64 mult, frac, mask, _tsc;
+int width, nr;
+
+BUG_ON(hvm_funcs.tsc_scaling_ratio_frac_bits >= 64);
+
+mult  = ratio >> hvm_funcs.tsc_scaling_ratio_frac_bits;
+mask  = (1ULL << hvm_funcs.tsc_scaling_ratio_frac_bits) - 1;
+frac  = ratio & mask;
+
+width = 64 - hvm_funcs.tsc_scaling_ratio_frac_bits;
+mask  = (1ULL << width) - 1;
+nr= hvm_funcs.tsc_scaling_ratio_frac_bits;
+
+_tsc  = tsc;
+_tsc *= mult;
+_tsc += (tsc >> hvm_funcs.tsc_scaling_ratio_frac_bits) * frac;
+
+while ( nr >= width )
+{
+_tsc += (((tsc >> (nr - width)) & mask) * frac) >> (64 - nr);
+nr   -= width;
+}
+
+if ( nr > 0 )
+_tsc += ((tsc & ((1ULL << nr) - 1)) * frac) >>
+hvm_funcs.tsc_scaling_ratio_frac_bits;
+
+return _tsc;
+}
+
+u64 hvm_scale_tsc(struct vcpu *v, u64 tsc)
+{
+u64 _tsc = tsc;
+u64 ratio = v->arch.tsc_scaling_ratio;
+
+if ( ratio != hvm_funcs.default_tsc_scaling_ratio )
+_tsc = __scale_tsc(ratio, tsc);
+
+return _tsc;
+}
+
 void hvm_setup_tsc_scaling(struct vcpu *v)
 {
 u64 ratio, khz;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index a7465c6..0984021 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -804,7 +804,7 @@ static void svm_set_tsc_offset(struct vcpu *v, u64 offset, 
u64 at_tsc)
 host_tsc = at_tsc;
 else
 host_tsc = rdtsc();
-offset = svm_get_tsc_offset(host_tsc, guest_tsc, vcpu_tsc_ratio(v));
+offset = guest_tsc - hvm_scale_tsc(v, host_tsc);
 }
 
 if ( !nestedhvm_enabled(d) ) {
@@ -965,7 +965,7 @@ static inline void svm_tsc_ratio_save(struct vcpu *v)
 static inline void svm_tsc_ratio_load(struct vcpu *v)
 {
 if ( cpu_has_tsc_ratio && !v->domain->arch.vtsc ) 
-wrmsrl(MSR_AMD64_TSC_RATIO, vcpu_tsc_ratio(v));
+wrmsrl(MSR_AMD64_TSC_RATIO, v->arch.tsc_scaling_ratio);
 }
 
 static void svm_ctxt_switch_from(struct vcpu *v)
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 55e7f64..f63fe93 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -261,6 +261,7 @@ void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, 
u64 at_tsc);
 u64 hvm_get_guest_tsc_fixed(struct vcpu *v, u64 at_tsc);
 #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
 
+u64 hvm_scale_tsc(struct vcpu *v, u64 tsc);
 void hvm_setup_tsc_scaling(struct vcpu *v);
 
 int hvm_set_mode(struct vcpu *v, int mode);
diff --git a/xen/include/asm-x86/hvm/svm/svm.h 
b/xen/include/asm-x86/hvm/svm/svm.h
index a4832d9..42aa6e8 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -98,9 +98,6 @@ extern u32 svm_feature_flags;
 #define DEFAULT_TSC_RATIO   0x0001ULL
 #define MAX_TSC_RATIO   0x00ffULL
 #define TSC_RATIO_RSVD_BITS 0xff00ULL
-#define TSC_RATIO(g_khz, h_khz) ( (((u64)(g_khz)<<32)/(u64)(h_khz)) & \
-  ~TSC_RATIO_RSVD_BITS )
-#define vcpu_tsc_ratio(v)   TSC_RATIO((v)->domain->arch.tsc_khz, cpu_khz)
 
 extern void svm_host_osvw_reset(void);
 extern void svm_host_osvw_init(void);
-- 
2.4.8


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

[Xen-devel] [PATCH 06/13] x86/hvm: Scale host TSC when setting/getting guest TSC

[Haozhong Zhang]

The existing hvm_set_guest_tsc_fixed() and hvm_get_guest_tsc_fixed()
calculate the guest TSC by adding the TSC offset to the host TSC. When
the TSC scaling is enabled, the host TSC should be scaled first. This
patch adds the scaling logic to those two functions.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/hvm.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2d55a36..568c9ef 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -388,13 +388,12 @@ void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 
guest_tsc, u64 at_tsc)
 tsc = hvm_get_guest_time_fixed(v, at_tsc);
 tsc = gtime_to_gtsc(v->domain, tsc);
 }
-else if ( at_tsc )
-{
-tsc = at_tsc;
-}
 else
 {
-tsc = rdtsc();
+tsc = at_tsc ? at_tsc : rdtsc();
+
+if ( hvm_funcs.tsc_scaling_supported )
+tsc = hvm_scale_tsc(v, tsc);
 }
 
 delta_tsc = guest_tsc - tsc;
@@ -422,13 +421,12 @@ u64 hvm_get_guest_tsc_fixed(struct vcpu *v, uint64_t 
at_tsc)
 tsc = hvm_get_guest_time_fixed(v, at_tsc);
 tsc = gtime_to_gtsc(v->domain, tsc);
 }
-else if ( at_tsc )
-{
-tsc = at_tsc;
-}
 else
 {
-tsc = rdtsc();
+tsc = at_tsc ? at_tsc : rdtsc();
+
+if ( hvm_funcs.tsc_scaling_supported )
+tsc = hvm_scale_tsc(v, tsc);
 }
 
 return tsc + v->arch.hvm_vcpu.cache_tsc_offset;
-- 
2.4.8


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

[Xen-devel] [PATCH 04/13] x86/hvm: Setup TSC scaling ratio

[Haozhong Zhang]

This patch adds a field tsc_scaling_ratio in struct arch_vcpu to
represent the TSC scaling ratio, and sets it up when tsc_set_info() is
called for a vcpu or a vcpu is restored or reset.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/hvm.c| 34 ++
 xen/arch/x86/hvm/svm/svm.c|  2 ++
 xen/arch/x86/time.c   | 10 +-
 xen/include/asm-x86/domain.h  |  2 ++
 xen/include/asm-x86/hvm/hvm.h |  2 ++
 5 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6afc344..63ce4de 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -297,6 +297,34 @@ int hvm_set_guest_pat(struct vcpu *v, u64 guest_pat)
 return 1;
 }
 
+void hvm_setup_tsc_scaling(struct vcpu *v)
+{
+u64 ratio, khz;
+   s8 shift;
+
+if ( !hvm_funcs.tsc_scaling_supported )
+return;
+
+khz = v->domain->arch.tsc_khz;
+shift = (hvm_funcs.tsc_scaling_ratio_frac_bits <= 32) ?
+hvm_funcs.tsc_scaling_ratio_frac_bits : 32;
+ratio = khz << shift;
+do_div(ratio, cpu_khz);
+ratio <<= hvm_funcs.tsc_scaling_ratio_frac_bits - shift;
+
+if ( ratio == 0 ||
+ ratio > hvm_funcs.max_tsc_scaling_ratio ||
+ ratio & hvm_funcs.tsc_scaling_ratio_rsvd )
+{
+printk(XENLOG_WARNING
+   "Invalid TSC scaling ratio - virtual tsc khz=%lu\n",
+   khz);
+return;
+}
+
+v->arch.tsc_scaling_ratio = ratio;
+}
+
 void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, u64 at_tsc)
 {
 uint64_t tsc;
@@ -2023,6 +2051,9 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 if ( hvm_funcs.load_cpu_ctxt(v, &ctxt) < 0 )
 return -EINVAL;
 
+if ( !v->domain->arch.vtsc && hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(v);
+
 v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
 
 seg.limit = ctxt.idtr_limit;
@@ -5458,6 +5489,9 @@ void hvm_vcpu_reset_state(struct vcpu *v, uint16_t cs, 
uint16_t ip)
 hvm_set_segment_register(v, x86_seg_gdtr, ®);
 hvm_set_segment_register(v, x86_seg_idtr, ®);
 
+if ( !v->domain->arch.vtsc && hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(v);
+
 /* Sync AP's TSC with BSP's. */
 v->arch.hvm_vcpu.cache_tsc_offset =
 v->domain->vcpu[0]->arch.hvm_vcpu.cache_tsc_offset;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 94b9618..a7465c6 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1170,6 +1170,8 @@ static int svm_vcpu_initialise(struct vcpu *v)
 
 svm_guest_osvw_init(v);
 
+v->arch.tsc_scaling_ratio = DEFAULT_TSC_RATIO;
+
 return 0;
 }
 
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 92dd8a1..64f4e31 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1956,6 +1956,8 @@ void tsc_set_info(struct domain *d,
 {
 case TSC_MODE_NEVER_EMULATE:
 d->arch.vtsc = 0;
+if ( tsc_mode == TSC_MODE_NEVER_EMULATE )
+d->arch.tsc_khz = cpu_khz;
 break;
 }
 d->arch.vtsc = 1;
@@ -1981,8 +1983,14 @@ void tsc_set_info(struct domain *d,
 if ( is_hvm_domain(d) )
 {
 hvm_set_rdtsc_exiting(d, d->arch.vtsc);
-if ( d->vcpu && d->vcpu[0] && incarnation == 0 )
+if ( d->vcpu && d->vcpu[0] )
 {
+if ( !d->arch.vtsc && hvm_funcs.tsc_scaling_supported )
+hvm_setup_tsc_scaling(d->vcpu[0]);
+
+if ( incarnation )
+return;
+
 /*
  * set_tsc_offset() is called from hvm_vcpu_initialise() before
  * tsc_set_info(). New vtsc mode may require recomputing TSC
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f0aeade..fffd519 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -533,6 +533,8 @@ struct arch_vcpu
 XEN_GUEST_HANDLE(vcpu_time_info_t) time_info_guest;
 
 struct arch_vm_event *vm_event;
+
+uint64_t tsc_scaling_ratio;
 };
 
 smap_check_policy_t smap_policy_change(struct vcpu *v,
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 7dddfa0..55e7f64 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -261,6 +261,8 @@ void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, 
u64 at_tsc);
 u64 hvm_get_guest_tsc_fixed(struct vcpu *v, u64 at_tsc);
 #define hvm_get_guest_tsc(v) hvm_get_guest_tsc_fixed(v, 0)
 
+void hvm_setup_tsc_scaling(struct vcpu *v);
+
 int hvm_set_mode(struct vcpu *v, int mode);
 void hvm_init_guest_time(struct domain *d);
 void hvm_set_guest_time(struct vcpu *v, u64 guest_time);
-- 
2.4.8


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

[Xen-devel] [PATCH 02/13] x86/time.c: Get the correct guest TSC rate in tsc_get_info()

[Haozhong Zhang]

When the TSC mode of a domain is TSC_MODE_DEFAULT and no TSC emulation
is used, the existing tsc_get_info() returns the host TSC rate (cpu_khz)
as the guest TSC rate. However, tsc_set_info() may set the guest TSC
rate of a domain in TSC_MODE_DEFAULT to a value different than the host
TSC rate. In order to keep consistent to tsc_set_info(), this patch make
tsc_get_info() use the value set by tsc_set_info() as the guest TSC
rate.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/time.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index a345efb..92dd8a1 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1869,7 +1869,7 @@ void tsc_get_info(struct domain *d, uint32_t *tsc_mode,
 break;
 }
 *elapsed_nsec = get_s_time();
-*gtsc_khz = cpu_khz;
+*gtsc_khz = d->arch.tsc_khz;
 break;
 case TSC_MODE_PVRDTSCP:
 if ( d->arch.vtsc )
-- 
2.4.8


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

[Xen-devel] [PATCH 08/13] x86/hvm: Detect TSC scaling through hvm_funcs in tsc_set_info()

[Haozhong Zhang]

This patch uses hvm_funcs.tsc_scaling_supported instead of the
architecture code to detect the TSC scaling support.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/time.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 64f4e31..4b5402c 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -37,7 +37,6 @@
 #include 
 #include 
 #include  /* for early_time_init */
-#include  /* for cpu_has_tsc_ratio */
 #include 
 
 /* opt_clocksource: Force clocksource to one of: pit, hpet, acpi. */
@@ -1951,7 +1950,7 @@ void tsc_set_info(struct domain *d,
  */
 if ( tsc_mode == TSC_MODE_DEFAULT && host_tsc_is_safe() &&
  (has_hvm_container_domain(d) ?
-  d->arch.tsc_khz == cpu_khz || cpu_has_tsc_ratio :
+  d->arch.tsc_khz == cpu_khz || hvm_funcs.tsc_scaling_supported :
   incarnation == 0) )
 {
 case TSC_MODE_NEVER_EMULATE:
-- 
2.4.8


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

[Xen-devel] [PATCH 03/13] x86/hvm: Collect information of TSC scaling ratio

[Haozhong Zhang]

Both VMX TSC scaling and SVM TSC ratio use the 64-bit TSC scaling ratio,
but the number of fractional bits of the ratio is different between VMX
and SVM. This patch makes the architecture code to collect the number of
fractional bits and other related information into fields of struct
hvm_function_table so that they can be used in the common code.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/svm/svm.c|  9 +
 xen/arch/x86/hvm/vmx/vmx.c|  2 ++
 xen/include/asm-x86/hvm/hvm.h | 13 +
 xen/include/asm-x86/hvm/svm/svm.h |  1 +
 4 files changed, 25 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 8de41fa..94b9618 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1428,6 +1428,9 @@ const struct hvm_function_table * __init start_svm(void)
 if ( !cpu_has_svm_nrips )
 clear_bit(SVM_FEATURE_DECODEASSISTS, &svm_feature_flags);
 
+if ( cpu_has_tsc_ratio )
+svm_function_table.tsc_scaling_supported = 1;
+
 #define P(p,s) if ( p ) { printk(" - %s\n", s); printed = 1; }
 P(cpu_has_svm_npt, "Nested Page Tables (NPT)");
 P(cpu_has_svm_lbrv, "Last Branch Record (LBR) Virtualisation");
@@ -2283,6 +2286,12 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .nhvm_vmcx_hap_enabled = nsvm_vmcb_hap_enabled,
 .nhvm_intr_blocked = nsvm_intr_blocked,
 .nhvm_hap_walk_L1_p2m = nsvm_hap_walk_L1_p2m,
+
+.tsc_scaling_supported   = 0,
+.default_tsc_scaling_ratio   = DEFAULT_TSC_RATIO,
+.max_tsc_scaling_ratio   = MAX_TSC_RATIO,
+.tsc_scaling_ratio_frac_bits = 32,
+.tsc_scaling_ratio_rsvd  = TSC_RATIO_RSVD_BITS,
 };
 
 void svm_vmexit_handler(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index bbec0e8..4edb099 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1968,6 +1968,8 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .altp2m_vcpu_update_vmfunc_ve = vmx_vcpu_update_vmfunc_ve,
 .altp2m_vcpu_emulate_ve = vmx_vcpu_emulate_ve,
 .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
+/* support for VMX RDTSC(P) scaling */
+.tsc_scaling_supported   = 0,
 };
 
 const struct hvm_function_table * __init start_vmx(void)
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 0693706..7dddfa0 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -99,6 +99,19 @@ struct hvm_function_table {
 /* Indicate HAP capabilities. */
 int hap_capabilities;
 
+/*
+ * Parameters of hardware-assisted TSC scaling.
+ */
+/* is TSC scaling supported? */
+bool_t   tsc_scaling_supported;
+/* number of bits of the fractional part of TSC scaling ratio */
+uint8_t  tsc_scaling_ratio_frac_bits;
+/* mask of reserved bits of TSC scaling ratio */
+uint64_t tsc_scaling_ratio_rsvd;
+/* default TSC scaling ratio (no scaling) */
+uint64_t default_tsc_scaling_ratio;
+/* maxmimum-allowed TSC scaling ratio */
+uint64_t max_tsc_scaling_ratio;
 
 /*
  * Initialise/destroy HVM domain/vcpu resources
diff --git a/xen/include/asm-x86/hvm/svm/svm.h 
b/xen/include/asm-x86/hvm/svm/svm.h
index d60ec23..a4832d9 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -96,6 +96,7 @@ extern u32 svm_feature_flags;
 
 /* TSC rate */
 #define DEFAULT_TSC_RATIO   0x0001ULL
+#define MAX_TSC_RATIO   0x00ffULL
 #define TSC_RATIO_RSVD_BITS 0xff00ULL
 #define TSC_RATIO(g_khz, h_khz) ( (((u64)(g_khz)<<32)/(u64)(h_khz)) & \
   ~TSC_RATIO_RSVD_BITS )
-- 
2.4.8


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

[Xen-devel] [PATCH 07/13] x86/hvm: Move saving/loading vcpu's TSC to common code

[Haozhong Zhang]

Both VMX and SVM saves/loads vcpu's TSC when saving/loading vcpu's
context, so this patch moves saving/loading vcpu's TSC to the common
function hvm_save_cpu_ctxt()/hvm_load_cpu_ctxt().

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/hvm.c | 4 
 xen/arch/x86/hvm/svm/svm.c | 5 -
 xen/arch/x86/hvm/vmx/vmx.c | 5 -
 3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 568c9ef..3522d20 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1813,6 +1813,8 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 /* Architecture-specific vmcs/vmcb bits */
 hvm_funcs.save_cpu_ctxt(v, &ctxt);
 
+ctxt.tsc = hvm_get_guest_tsc_fixed(v, d->arch.hvm_domain.sync_tsc);
+
 ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
 
 hvm_get_segment_register(v, x86_seg_idtr, &seg);
@@ -2105,6 +2107,8 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 if ( !v->domain->arch.vtsc && hvm_funcs.tsc_scaling_supported )
 hvm_setup_tsc_scaling(v);
 
+hvm_set_guest_tsc_fixed(v, ctxt.tsc, d->arch.hvm_domain.sync_tsc);
+
 v->arch.hvm_vcpu.msr_tsc_aux = ctxt.msr_tsc_aux;
 
 seg.limit = ctxt.idtr_limit;
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0984021..73bc863 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -357,9 +357,6 @@ static void svm_save_cpu_state(struct vcpu *v, struct 
hvm_hw_cpu *data)
 data->msr_syscall_mask = vmcb->sfmask;
 data->msr_efer = v->arch.hvm_vcpu.guest_efer;
 data->msr_flags= -1ULL;
-
-data->tsc = hvm_get_guest_tsc_fixed(v,
-v->domain->arch.hvm_domain.sync_tsc);
 }
 
 
@@ -374,8 +371,6 @@ static void svm_load_cpu_state(struct vcpu *v, struct 
hvm_hw_cpu *data)
 vmcb->sfmask = data->msr_syscall_mask;
 v->arch.hvm_vcpu.guest_efer = data->msr_efer;
 svm_update_guest_efer(v);
-
-hvm_set_guest_tsc_fixed(v, data->tsc, v->domain->arch.hvm_domain.sync_tsc);
 }
 
 static void svm_save_vmcb_ctxt(struct vcpu *v, struct hvm_hw_cpu *ctxt)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 4edb099..624db1c 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -581,9 +581,6 @@ static void vmx_save_cpu_state(struct vcpu *v, struct 
hvm_hw_cpu *data)
 data->msr_lstar= guest_state->msrs[VMX_INDEX_MSR_LSTAR];
 data->msr_star = guest_state->msrs[VMX_INDEX_MSR_STAR];
 data->msr_syscall_mask = guest_state->msrs[VMX_INDEX_MSR_SYSCALL_MASK];
-
-data->tsc = hvm_get_guest_tsc_fixed(v,
-v->domain->arch.hvm_domain.sync_tsc);
 }
 
 static void vmx_load_cpu_state(struct vcpu *v, struct hvm_hw_cpu *data)
@@ -598,8 +595,6 @@ static void vmx_load_cpu_state(struct vcpu *v, struct 
hvm_hw_cpu *data)
 
 v->arch.hvm_vmx.cstar = data->msr_cstar;
 v->arch.hvm_vmx.shadow_gs = data->shadow_gs;
-
-hvm_set_guest_tsc_fixed(v, data->tsc, v->domain->arch.hvm_domain.sync_tsc);
 }
 
 
-- 
2.4.8


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

[Xen-devel] [PATCH 10/13] vmx: Detect and initialize VMX RDTSC(P) scaling

[Haozhong Zhang]

This patch adds the detection and initialization code for VMX TSC
scaling.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/vmx/vmcs.c| 11 +--
 xen/arch/x86/hvm/vmx/vmx.c |  9 +
 xen/include/asm-x86/hvm/vmx/vmcs.h |  7 +++
 3 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 08f2078..7172b27 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -144,6 +144,7 @@ static void __init vmx_display_features(void)
 P(cpu_has_vmx_vmfunc, "VM Functions");
 P(cpu_has_vmx_virt_exceptions, "Virtualisation Exceptions");
 P(cpu_has_vmx_pml, "Page Modification Logging");
+P(cpu_has_vmx_tsc_scaling, "RDTSC(P) Scaling");
 #undef P
 
 if ( !printed )
@@ -236,7 +237,8 @@ static int vmx_init_vmcs_config(void)
SECONDARY_EXEC_PAUSE_LOOP_EXITING |
SECONDARY_EXEC_ENABLE_INVPCID |
SECONDARY_EXEC_ENABLE_VM_FUNCTIONS |
-   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS);
+   SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS |
+   SECONDARY_EXEC_TSC_SCALING);
 rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap);
 if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL )
 opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING;
@@ -965,7 +967,7 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(PIN_BASED_VM_EXEC_CONTROL, vmx_pin_based_exec_control);
 
 v->arch.hvm_vmx.exec_control = vmx_cpu_based_exec_control;
-if ( d->arch.vtsc )
+if ( d->arch.vtsc && !cpu_has_vmx_tsc_scaling )
 v->arch.hvm_vmx.exec_control |= CPU_BASED_RDTSC_EXITING;
 
 v->arch.hvm_vmx.secondary_exec_control = vmx_secondary_exec_control;
@@ -1239,6 +1241,9 @@ static int construct_vmcs(struct vcpu *v)
 __vmwrite(GUEST_PAT, guest_pat);
 }
 
+if ( cpu_has_vmx_tsc_scaling )
+__vmwrite(TSC_MULTIPLIER, VMX_TSC_MULTIPLIER_DEFAULT);
+
 vmx_vmcs_exit(v);
 
 /* PVH: paging mode is updated by arch_set_info_guest(). */
@@ -1805,6 +1810,8 @@ void vmcs_dump_vcpu(struct vcpu *v)
 printk("IDTVectoring: info=%08x errcode=%08x\n",
vmr32(IDT_VECTORING_INFO), vmr32(IDT_VECTORING_ERROR_CODE));
 printk("TSC Offset = 0x%016lx\n", vmr(TSC_OFFSET));
+if ( v->arch.hvm_vmx.secondary_exec_control & SECONDARY_EXEC_TSC_SCALING )
+printk("TSC Multiplier = 0x%016lx\n", vmr(TSC_MULTIPLIER));
 if ( (v->arch.hvm_vmx.exec_control & CPU_BASED_TPR_SHADOW) ||
  (vmx_pin_based_exec_control & PIN_BASED_POSTED_INTERRUPT) )
 printk("TPR Threshold = 0x%02x  PostedIntrVec = 0x%02x\n",
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 624db1c..454440e 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -151,6 +151,8 @@ static int vmx_vcpu_initialise(struct vcpu *v)
 if ( v->vcpu_id == 0 )
 v->arch.user_regs.eax = 1;
 
+v->arch.tsc_scaling_ratio = VMX_TSC_MULTIPLIER_DEFAULT;
+
 return 0;
 }
 
@@ -1965,6 +1967,10 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .altp2m_vcpu_emulate_vmfunc = vmx_vcpu_emulate_vmfunc,
 /* support for VMX RDTSC(P) scaling */
 .tsc_scaling_supported   = 0,
+.default_tsc_scaling_ratio   = VMX_TSC_MULTIPLIER_DEFAULT,
+.max_tsc_scaling_ratio   = VMX_TSC_MULTIPLIER_MAX,
+.tsc_scaling_ratio_frac_bits = 48,
+.tsc_scaling_ratio_rsvd  = 0x0ULL,
 };
 
 const struct hvm_function_table * __init start_vmx(void)
@@ -2017,6 +2023,9 @@ const struct hvm_function_table * __init start_vmx(void)
  && cpu_has_vmx_secondary_exec_control )
 vmx_function_table.pvh_supported = 1;
 
+if ( cpu_has_vmx_tsc_scaling )
+vmx_function_table.tsc_scaling_supported = 1;
+
 setup_vmcs_dump();
 
 return &vmx_function_table;
diff --git a/xen/include/asm-x86/hvm/vmx/vmcs.h 
b/xen/include/asm-x86/hvm/vmx/vmcs.h
index f1126d4..d478584 100644
--- a/xen/include/asm-x86/hvm/vmx/vmcs.h
+++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
@@ -225,6 +225,7 @@ extern u32 vmx_vmentry_control;
 #define SECONDARY_EXEC_ENABLE_VMCS_SHADOWING0x4000
 #define SECONDARY_EXEC_ENABLE_PML   0x0002
 #define SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS   0x0004
+#define SECONDARY_EXEC_TSC_SCALING  0x0200
 extern u32 vmx_secondary_exec_control;
 
 #define VMX_EPT_EXEC_ONLY_SUPPORTED 0x0001
@@ -248,6 +249,9 @@ extern u32 vmx_secondary_exec_control;
 
 #define VMX_MISC_CR3_TARGET 0x1ff
 
+#define VMX_TSC_MULTIPLIER_DEFAULT 0x0001ULL
+#define VMX_TSC_MULTIPLIER_MAX 0xULL
+
 #define cpu_has_wbinvd_exiting \
 (vmx_secondary_exec_control & SECONDARY_EXEC_WBINVD_EXITING)
 #define cpu_has_vmx_virtualize_apic_accesses \
@@ -291,6 +295,8 @@ extern u32 vmx_secondary_exec_control;
 (vmx_secondary_exec_control & SECONDARY_EXEC_ENABLE_VIRT_EXCEPTIONS)
 #define cpu_has_vmx_pml

[Xen-devel] [PATCH 13/13] tools/libxl: Add 'vtsc_khz' option to set guest TSC rate

[Haozhong Zhang]

This patch adds an option 'vtsc_khz' to allow users to set vcpu's TSC
rate in KHz. In the case that tsc_mode = 'default', the default value of
'vtsc_khz' option is the host TSC rate which is used when 'vtsc_khz'
option is set to 0 or does not appear in the configuration. In all other
cases of tsc_mode, 'vtsc_khz' option is just ignored.

Another purpose of adding this option is to keep vcpu's TSC rate across
guest reboot. In existing code, a new domain is created from the
configuration of the previous domain which was just rebooted. vcpu's TSC
rate is not stored in the configuration and the host TSC rate is the
used as vcpu's TSC rate. This works fine unless the previous domain was
migrated from another host machine with a different host TSC rate than
the current one.

Signed-off-by: Haozhong Zhang 
---
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/libxl_x86.c |  4 +++-
 tools/libxl/xl_cmdimpl.c| 22 ++
 3 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9f6ec00..91cb0be 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -413,6 +413,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
 ("vcpu_soft_affinity", Array(libxl_bitmap, "num_vcpu_soft_affinity")),
 ("numa_placement",  libxl_defbool),
 ("tsc_mode",libxl_tsc_mode),
+("vtsc_khz",uint32),
 ("max_memkb",   MemKB),
 ("target_memkb",MemKB),
 ("video_memkb", MemKB),
diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
index 896f34c..7baaee4 100644
--- a/tools/libxl/libxl_x86.c
+++ b/tools/libxl/libxl_x86.c
@@ -276,6 +276,7 @@ int libxl__arch_domain_create(libxl__gc *gc, 
libxl_domain_config *d_config,
 {
 int ret = 0;
 int tsc_mode;
+uint32_t vtsc_khz;
 uint32_t rtc_timeoffset;
 libxl_ctx *ctx = libxl__gc_owner(gc);
 
@@ -300,7 +301,8 @@ int libxl__arch_domain_create(libxl__gc *gc, 
libxl_domain_config *d_config,
 default:
 abort();
 }
-xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
+vtsc_khz = d_config->b_info.vtsc_khz;
+xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, vtsc_khz, 0);
 if (libxl_defbool_val(d_config->b_info.disable_migrate))
 xc_domain_disable_migrate(ctx->xch, domid);
 rtc_timeoffset = d_config->b_info.rtc_timeoffset;
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2706759..5fabda7 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1462,6 +1462,28 @@ static void parse_config_data(const char *config_source,
 }
 }
 
+/* "vtsc_khz" option works only if "tsc_mode" option is
+ * "default". In this case, if "vtsc_khz" option is set to 0, we
+ * will reset it to the host TSC rate. In all other cases, we just
+ * ignore any given value and always set it to 0.
+ */
+if (!xlu_cfg_get_long(config, "vtsc_khz", &l, 0))
+b_info->vtsc_khz = l;
+if (b_info->tsc_mode == LIBXL_TSC_MODE_DEFAULT) {
+if (b_info->vtsc_khz == 0) {
+libxl_physinfo physinfo;
+if (!libxl_get_physinfo(ctx, &physinfo))
+b_info->vtsc_khz = physinfo.cpu_khz;
+else
+fprintf(stderr, "WARNING: cannot get host TSC rate.\n");
+}
+} else {
+fprintf(stderr, "WARNING: ignoring \"vtsc_khz\" option. "
+"\"vtsc_khz\" option works only if "
+"\"tsc_mode\" option is \"default\".\n");
+b_info->vtsc_khz = 0;
+}
+
 if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0))
 b_info->rtc_timeoffset = l;
 
-- 
2.4.8


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

[Xen-devel] [PATCH 12/13] vmx: Add a call-back to apply TSC scaling ratio to hardware

[Haozhong Zhang]

This patch adds a new call-back setup_tsc_scaling in struct
hvm_function_table to apply the TSC scaling ratio to hardware. For VMX,
it writes the TSC scaling ratio to VMCS field TSC_MULTIPLIER.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/hvm.c| 1 +
 xen/arch/x86/hvm/svm/svm.c| 5 +
 xen/arch/x86/hvm/vmx/vmx.c| 8 
 xen/include/asm-x86/hvm/hvm.h | 3 +++
 4 files changed, 17 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3522d20..2d8a148 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -376,6 +376,7 @@ void hvm_setup_tsc_scaling(struct vcpu *v)
 }
 
 v->arch.tsc_scaling_ratio = ratio;
+hvm_funcs.setup_tsc_scaling(v);
 }
 
 void hvm_set_guest_tsc_fixed(struct vcpu *v, u64 guest_tsc, u64 at_tsc)
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 73bc863..d890c1f 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2236,6 +2236,10 @@ static void svm_invlpg_intercept(unsigned long vaddr)
 svm_asid_g_invlpg(curr, vaddr);
 }
 
+static void svm_setup_tsc_scaling(struct vcpu *v)
+{
+}
+
 static struct hvm_function_table __initdata svm_function_table = {
 .name = "SVM",
 .cpu_up_prepare   = svm_cpu_up_prepare,
@@ -2289,6 +2293,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .max_tsc_scaling_ratio   = MAX_TSC_RATIO,
 .tsc_scaling_ratio_frac_bits = 32,
 .tsc_scaling_ratio_rsvd  = TSC_RATIO_RSVD_BITS,
+.setup_tsc_scaling   = svm_setup_tsc_scaling,
 };
 
 void svm_vmexit_handler(struct cpu_user_regs *regs)
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 163974d..c4a7b81 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1100,6 +1100,13 @@ static void vmx_handle_cd(struct vcpu *v, unsigned long 
value)
 }
 }
 
+static void vmx_setup_tsc_scaling(struct vcpu *v)
+{
+vmx_vmcs_enter(v);
+__vmwrite(TSC_MULTIPLIER, v->arch.tsc_scaling_ratio);
+vmx_vmcs_exit(v);
+}
+
 static void vmx_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc)
 {
 uint64_t host_tsc, guest_tsc;
@@ -1986,6 +1993,7 @@ static struct hvm_function_table __initdata 
vmx_function_table = {
 .max_tsc_scaling_ratio   = VMX_TSC_MULTIPLIER_MAX,
 .tsc_scaling_ratio_frac_bits = 48,
 .tsc_scaling_ratio_rsvd  = 0x0ULL,
+.setup_tsc_scaling   = vmx_setup_tsc_scaling,
 };
 
 const struct hvm_function_table * __init start_vmx(void)
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index f63fe93..9f8b6d5 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -226,6 +226,9 @@ struct hvm_function_table {
 void (*altp2m_vcpu_update_vmfunc_ve)(struct vcpu *v);
 bool_t (*altp2m_vcpu_emulate_ve)(struct vcpu *v);
 int (*altp2m_vcpu_emulate_vmfunc)(struct cpu_user_regs *regs);
+
+/* setup TSC scaling */
+void (*setup_tsc_scaling)(struct vcpu *v);
 };
 
 extern struct hvm_function_table hvm_funcs;
-- 
2.4.8


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

[Xen-devel] [PATCH 11/13] vmx: Use scaled host TSC to calculate TSC offset

[Haozhong Zhang]

If VMX TSC scaling is enabled and no TSC emulation is used,
vmx_set_tsc_offset() will calculate the TSC offset by substracting the
scaled host TSC from the current guest TSC.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/hvm/vmx/vmx.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 454440e..163974d 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1102,11 +1102,26 @@ static void vmx_handle_cd(struct vcpu *v, unsigned long 
value)
 
 static void vmx_set_tsc_offset(struct vcpu *v, u64 offset, u64 at_tsc)
 {
+uint64_t host_tsc, guest_tsc;
+struct domain *d = v->domain;
+
+guest_tsc = hvm_get_guest_tsc_fixed(v, at_tsc);
+
+if ( cpu_has_vmx_tsc_scaling && !d->arch.vtsc )
+{
+host_tsc = at_tsc ? at_tsc : rdtsc();
+offset = guest_tsc - hvm_scale_tsc(v, host_tsc);
+}
+
 vmx_vmcs_enter(v);
 
+if ( !nestedhvm_enabled(d) )
+goto out;
+
 if ( nestedhvm_vcpu_in_guestmode(v) )
 offset += nvmx_get_tsc_offset(v);
 
+out:
 __vmwrite(TSC_OFFSET, offset);
 vmx_vmcs_exit(v);
 }
-- 
2.4.8


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

[Xen-devel] [PATCH 09/13] x86/time.c: Scale host TSC in pvclock properly

[Haozhong Zhang]

This patch makes the pvclock return the scaled host TSC and
corresponding scaling parameters to HVM domains if guest TSC is not
emulated and TSC scaling is enabled.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/time.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 4b5402c..54eab6e 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -832,10 +832,19 @@ static void __update_vcpu_system_time(struct vcpu *v, int 
force)
 }
 else
 {
-_u.tsc_timestamp = t->local_tsc_stamp;
+if ( is_hvm_domain(d) && hvm_funcs.tsc_scaling_supported )
+{
+_u.tsc_timestamp = hvm_scale_tsc(v, t->local_tsc_stamp);
+_u.tsc_to_system_mul = d->arch.vtsc_to_ns.mul_frac;
+_u.tsc_shift = d->arch.vtsc_to_ns.shift;
+}
+else
+{
+_u.tsc_timestamp = t->local_tsc_stamp;
+_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
+_u.tsc_shift = (s8)t->tsc_scale.shift;
+}
 _u.system_time   = t->stime_local_stamp;
-_u.tsc_to_system_mul = t->tsc_scale.mul_frac;
-_u.tsc_shift = (s8)t->tsc_scale.shift;
 }
 if ( is_hvm_domain(d) )
 _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
-- 
2.4.8


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 18 guest-start.2 fail REGR. vs. 62168
 test-amd64-i386-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail REGR. vs. 
62168

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start.2 fail REGR. vs. 62168
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 62168
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62168
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62168
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62168

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-raw  13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  9bed9188dd5b0923988615021b3bec17522ec985
baseline version:
 xen  bbbd29a25d090f1180d14210358c6d7ccdebef85

Last test of basis62168  2015-09-19 17:21:29 Z8 days
Failing since 62288  2015-09-22 18:12:03 Z5 days2 attempts
Testing same since62353  2015-09-25 10:50:05 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kouya Shimura 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH 5/5] xen: clean up VPF flags macros

[Juergen Gross]

On 09/28/2015 08:22 AM, Jan Beulich wrote:

On 28.09.15 at 07:23,  wrote:

On 09/25/2015 05:42 PM, Jan Beulich wrote:

On 25.09.15 at 13:54,  wrote:

Per-VCPU pause flags in sched.h are defined as bit positions and as
values derived from the bit defines. There is only one user of a value
which can be easily converted to use a bit number as well.


I'm not convinced:


--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct

xen_domctl_getdomaininfo *info)

   info->max_vcpu_id = v->vcpu_id;
   if ( !test_bit(_VPF_down, &v->pause_flags) )
   {
-if ( !(v->pause_flags & VPF_blocked) )
+if ( !test_bit(_VPF_blocked, &v->pause_flags) )


test_bit() is quite a bit more complex an operation than a simple &,
and with (on x86) even constant_test_bit() involving a cast to
a pointer to volatile I'm afraid we can't even hope that compilers
would produce identical code for both in cases like this one (as that
casts limits freedom of the compiler). IOW I'd rather see other
test_bit(_VPF_...) uses converted the inverse way (which as a nice
but minor side effect would yield slightly smaller source code).


What about introducing __test_bit() being a variant which can be
reordered by omitting the volatile modifier? I think this would have
the same effect.


I'm not convinced it always would - the inline function is still more
complex than the plain operation.


Depends on the way it is done. What about:

#define __test_bit(nr, addr) ({ \
if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
(__builtin_constant_p(nr) ? \
 !!(*(addr) & ((typeof)(*(addr))1 << (nr))) :   \
 __variable_test_bit((nr),(addr))); \
})

It would even be possible to drop the test for bitop_bad_size(addr) in
the constant case.


And we could still get rid of many double definitions
of the same bit. Even if the mask definition of a bit is not error prone
by relying on the definition of the bit position, it makes it harder to
find all users of this bit.


Why so? Just omit the leading underscore when grep-ing, and you'll
find all instances (less preprocessor token concatenation, but that's
orthogonal).


I do use grep for this purpose occasionally, but I prefer tools like
cscope. BTW: IMO using grep the way you are suggesting here is annoying
for cases where the search string is contained in other items.

Juergen


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

Re: [Xen-devel] [PATCH 5/5] xen: clean up VPF flags macros

[Jan Beulich]

>>> On 28.09.15 at 09:29,  wrote:
> On 09/28/2015 08:22 AM, Jan Beulich wrote:
> On 28.09.15 at 07:23,  wrote:
>>> On 09/25/2015 05:42 PM, Jan Beulich wrote:
>>> On 25.09.15 at 13:54,  wrote:
> Per-VCPU pause flags in sched.h are defined as bit positions and as
> values derived from the bit defines. There is only one user of a value
> which can be easily converted to use a bit number as well.

 I'm not convinced:

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct
>>> xen_domctl_getdomaininfo *info)
>info->max_vcpu_id = v->vcpu_id;
>if ( !test_bit(_VPF_down, &v->pause_flags) )
>{
> -if ( !(v->pause_flags & VPF_blocked) )
> +if ( !test_bit(_VPF_blocked, &v->pause_flags) )

 test_bit() is quite a bit more complex an operation than a simple &,
 and with (on x86) even constant_test_bit() involving a cast to
 a pointer to volatile I'm afraid we can't even hope that compilers
 would produce identical code for both in cases like this one (as that
 casts limits freedom of the compiler). IOW I'd rather see other
 test_bit(_VPF_...) uses converted the inverse way (which as a nice
 but minor side effect would yield slightly smaller source code).
>>>
>>> What about introducing __test_bit() being a variant which can be
>>> reordered by omitting the volatile modifier? I think this would have
>>> the same effect.
>>
>> I'm not convinced it always would - the inline function is still more
>> complex than the plain operation.
> 
> Depends on the way it is done. What about:
> 
> #define __test_bit(nr, addr) ({ \
>  if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
>  (__builtin_constant_p(nr) ? \
>   !!(*(addr) & ((typeof)(*(addr))1 << (nr))) :   \
>   __variable_test_bit((nr),(addr))); \
> })

But that's not correct - addr may point to wider than a single entry
array, irrespective of whether nr is a compile time constant.

> It would even be possible to drop the test for bitop_bad_size(addr) in
> the constant case.

In which case 1 << nr may reference a bit beyond the type
of *addr.

>>> And we could still get rid of many double definitions
>>> of the same bit. Even if the mask definition of a bit is not error prone
>>> by relying on the definition of the bit position, it makes it harder to
>>> find all users of this bit.
>>
>> Why so? Just omit the leading underscore when grep-ing, and you'll
>> find all instances (less preprocessor token concatenation, but that's
>> orthogonal).
> 
> I do use grep for this purpose occasionally, but I prefer tools like
> cscope. BTW: IMO using grep the way you are suggesting here is annoying
> for cases where the search string is contained in other items.

There may be cases, yes, but surely not this one: How likely is it for
some other variable name to include, say, VPF_blocked?

Jan


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

Re: [Xen-devel] [PATCH 5/5] xen: clean up VPF flags macros

[Juergen Gross]

On 09/28/2015 09:52 AM, Jan Beulich wrote:

On 28.09.15 at 09:29,  wrote:

On 09/28/2015 08:22 AM, Jan Beulich wrote:

On 28.09.15 at 07:23,  wrote:

On 09/25/2015 05:42 PM, Jan Beulich wrote:

On 25.09.15 at 13:54,  wrote:

Per-VCPU pause flags in sched.h are defined as bit positions and as
values derived from the bit defines. There is only one user of a value
which can be easily converted to use a bit number as well.


I'm not convinced:


--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct

xen_domctl_getdomaininfo *info)

info->max_vcpu_id = v->vcpu_id;
if ( !test_bit(_VPF_down, &v->pause_flags) )
{
-if ( !(v->pause_flags & VPF_blocked) )
+if ( !test_bit(_VPF_blocked, &v->pause_flags) )


test_bit() is quite a bit more complex an operation than a simple &,
and with (on x86) even constant_test_bit() involving a cast to
a pointer to volatile I'm afraid we can't even hope that compilers
would produce identical code for both in cases like this one (as that
casts limits freedom of the compiler). IOW I'd rather see other
test_bit(_VPF_...) uses converted the inverse way (which as a nice
but minor side effect would yield slightly smaller source code).


What about introducing __test_bit() being a variant which can be
reordered by omitting the volatile modifier? I think this would have
the same effect.


I'm not convinced it always would - the inline function is still more
complex than the plain operation.


Depends on the way it is done. What about:

#define __test_bit(nr, addr) ({ \
  if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
  (__builtin_constant_p(nr) ? \
   !!(*(addr) & ((typeof)(*(addr))1 << (nr))) :   \
   __variable_test_bit((nr),(addr))); \
})


But that's not correct - addr may point to wider than a single entry
array, irrespective of whether nr is a compile time constant.


It would even be possible to drop the test for bitop_bad_size(addr) in
the constant case.


In which case 1 << nr may reference a bit beyond the type
of *addr.


Hmm, yes, you are right, of course.

It could be fixed, however.

The question is: does it make sense to follow this path any longer,
or would you reject it even in case of correctness? I wouldn't mind
either way, I just don't want to waste time (mine and yours).


And we could still get rid of many double definitions
of the same bit. Even if the mask definition of a bit is not error prone
by relying on the definition of the bit position, it makes it harder to
find all users of this bit.


Why so? Just omit the leading underscore when grep-ing, and you'll
find all instances (less preprocessor token concatenation, but that's
orthogonal).


I do use grep for this purpose occasionally, but I prefer tools like
cscope. BTW: IMO using grep the way you are suggesting here is annoying
for cases where the search string is contained in other items.


There may be cases, yes, but surely not this one: How likely is it for
some other variable name to include, say, VPF_blocked?


I think we both agree that [_]VPF_blocked poses no problem using grep.

It's more a matter of taste and what people are used to. If someone
is using cscope for that purpose on a regular basis he will either have
to search for two different variables or he will have to use another
tool, possibly after seeing the definition of VPF_blocked depending on
_VPF_blocked. Both cases will be annoying as an extra action is required
for him.


Juergen

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

[Xen-devel] [PATCH v5 0/3] detect and initialize CDP (Code/Data Prioritization) feature

[He Chen]

Changes in v5:
- x86: address Andrew's and Jan's coments.
- tools: refine options parsing in psr-cat-cbm-set and invalidate passing -c
  and -d at the same time
- merge tools and docs patches.
- code style

Changes in v4:
- x86:
  * remove union member name in struct `psr_cat_cbm` (suggested by Jan)
  * fix log info of CAT & CDP (suggested by Chao & Jan)
  * add a helper `cdp_is_enabled` to tell the status of CDP and CDP initialize
failed is considered (Jan's comment)
  * XEN_SYSCTL_INTERFACE_VERSION 0x000C -> 0x000D (suggested by Jan)
  * refine CBM type check logic in get/set CBM function (suggested by Jan)
  * loop optimization in function `find_cos` (suggested by Jan)
- tools: address Chao's comments.
- docs: address Chao's comments.
- code style

Changes in v3:
- x86: remove redundant CDP field in cat_socket_enable (suggested by Chao)
- tools: simplify CBM setting function in tools (suggested by Jan)
- docs: add boot parameter description (suggested by Chao & Ian)
- code style

Changes in v2:
- x86: enable CDP by boot parameter instead of enabling/disabling CDP at
   runtime (suggested by Andrew)
- tools: remove psr-cat-cdp-enable/disable xl commands
- code style

Code/Data Prioritization(CDP) is offered in Intel Broadwell and later server
platforms, which is an extension of CAT. CDP enables isolation and separate
prioritization of code and data fetches to the L3 cache in a software
configurable manner, which can enable workload prioritization and tuning of
cache capacity to the characteristics of the workload. CDP extends Cache
Allocation Technology (CAT) by providing separate code and data capacity bit
masks(CBM) per Class of Service (COS). CDP is used on VM basis in the Xen
implementation.

More information about CDP, please refer to Intel SDM, Volumn 3, section 17.16
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf

This patch series enables CDP feature in Xen based on CAT code, and extends
CBM operation functions to support CDP. For all the changes, please see in
each patch.

This v5 patchset has been tested on Intel Broadwell server platform.

To make this patchset better, any comment or suggestion is welcomed, I would
really appreciate it.

Thanks.

He Chen (3):
  x86: Support enable CDP by boot parameter and add get CDP status
  x86: add domctl cmd to set/get CDP code/data CBM
  tools & docs: add tools and docs support for Intel CDP

 docs/man/xl.pod.1   |  15 +++
 docs/misc/xen-command-line.markdown |  11 +-
 docs/misc/xl-psr.markdown   |  47 ++-
 tools/libxc/include/xenctrl.h   |   7 +-
 tools/libxc/xc_psr.c|  17 ++-
 tools/libxl/libxl.h |   7 ++
 tools/libxl/libxl_psr.c |   5 +-
 tools/libxl/libxl_types.idl |   3 +
 tools/libxl/xl_cmdimpl.c|  56 +++--
 tools/libxl/xl_cmdtable.c   |   2 +
 xen/arch/x86/domctl.c   |  32 -
 xen/arch/x86/psr.c  | 237 +---
 xen/arch/x86/sysctl.c   |   5 +-
 xen/include/asm-x86/msr-index.h |   3 +
 xen/include/asm-x86/psr.h   |  20 ++-
 xen/include/public/domctl.h |   4 +
 xen/include/public/sysctl.h |   4 +-
 17 files changed, 398 insertions(+), 77 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v5 3/3] tools & docs: add tools and docs support for Intel CDP

[He Chen]

This is the xl/xc changes to support Intel Code/Data Prioritization.
CAT xl commands to set/get CBMs are extended to support CDP.
Add new CDP options with CAT commands in xl interface man page.
Add description of CDP in xl-psr.markdown.

Signed-off-by: He Chen 
---
Changes in v5:
* merge tools and docs patches
* replace EINVAL with ENXIO in libxl__psr_cat_log_err_msg
* revise options parsing in psr-cat-cbm-set and invalidate passing -c
  and -d at the same time
* refine CDP status output codes in psr_cat_hwinfo
* adjust CBM output format in command xl psr-cat-show
* docs revision

Example of new output format for command xl psr-cat-show:

CAT-only:

Socket ID   : 0
L3 Cache: 56320KB
Default CBM : 0xf
   ID NAME   CBM
0 Domain-0   0xf
1   centos.hvm   0xf

CDP enabled:

Socket ID   : 0
L3 Cache: 56320KB
Default CBM : 0xf
   ID NAME   CBM
0 Domain-0 code: 0xf data: 0xf
1   centos.hvm code: 0xf data: 0xf
---
 docs/man/xl.pod.1 | 15 
 docs/misc/xl-psr.markdown | 47 +++-
 tools/libxc/include/xenctrl.h |  7 --
 tools/libxc/xc_psr.c  | 17 -
 tools/libxl/libxl.h   |  7 ++
 tools/libxl/libxl_psr.c   |  5 +++-
 tools/libxl/libxl_types.idl   |  3 +++
 tools/libxl/xl_cmdimpl.c  | 56 +--
 tools/libxl/xl_cmdtable.c |  2 ++
 9 files changed, 137 insertions(+), 22 deletions(-)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index f22c3f3..6388351 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1530,6 +1530,13 @@ 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.
 
+Intel Broadwell and later server platforms also offer Code/Data Prioritization
+(CDP) for cache allocations, which support specifying code or data cache for
+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.
+
 =over 4
 
 =item B [I] I I
@@ -1545,6 +1552,14 @@ B
 
 Specify the socket to process, otherwise all sockets are processed.
 
+=item B<-c>, B<--code>
+
+Set code CBM when CDP is enabled.
+
+=item B<-d>, B<--data>
+
+Set data CBM when CDP is enabled.
+
 =back
 
 =item B [I]
diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index 3545912..0527211 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -14,7 +14,7 @@ tracks cache utilization of memory accesses according to the 
RMID and reports
 monitored data via a counter register.
 
 For more detailed information please refer to Intel SDM chapter
-"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
+"Platform Shared Resource Monitoring: Cache Monitoring Technology".
 
 In Xen's implementation, each domain in the system can be assigned a RMID
 independently, while RMID=0 is reserved for monitoring domains that don't
@@ -52,7 +52,7 @@ event type to monitor system total/local memory bandwidth. 
The same RMID can
 be used to monitor both cache usage and memory bandwidth at the same time.
 
 For more detailed information please refer to Intel SDM chapter
-"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
+"Platform Shared Resource Monitoring: Cache Monitoring Technology".
 
 In Xen's implementation, MBM shares the same set of underlying monitoring
 service with CMT and can be used to monitor memory bandwidth on a per domain
@@ -91,17 +91,42 @@ For example, assuming a system with 8 portions and 3 
domains:
first domain exclusive access to half the cache, and the other two exclusive
access to one quarter each.
 
-For more detailed information please refer to Intel SDM chapter
-"17.15 - Platform Shared Resource Control: Cache Allocation Technology".
-
 In Xen's implementation, CBM can be configured with libxl/xl interfaces but
 COS is maintained in hypervisor only. The cache partition granularity is per
 domain, each domain has COS=0 assigned by default, the corresponding CBM is
 all-ones, which means all the cache resource can be used by default.
 
+Code/Data Prioritization (CDP) Technology is an extension of CAT, which is
+available on Intel Broadwell and later server platforms. CDP enables isolation
+and separate prioritization of code and data fetches to the L3 cache in a
+software configurable manner, which can enable workload prioritization and
+tuning of cache capacity to the characteristics of the workload. CDP extends
+Cache Allocation Technology (CAT) by providing 

[Xen-devel] [PATCH v5 1/3] x86: Support enable CDP by boot parameter and add get CDP status

[He Chen]

Add boot parameter `psr=cdp` to enable CDP at boot time.
Intel Code/Data Prioritization (CDP) feature is based on CAT. Note that
cos_max would be half when CDP is on. struct psr_cat_cbm is extended to
support CDP operation. Extend psr_get_cat_l3_info sysctl to get CDP
status.

Signed-off-by: He Chen 
Reviewed-by: Andrew Cooper 
---
Changes in v5
* remove unnecessary u in psr_cat_cbm structure
* revert write_l3_cbm and put the modification to next patch
* remove duplicate PSR_CAT_FLAG_L3_CDP
---
 docs/misc/xen-command-line.markdown | 11 +++--
 xen/arch/x86/psr.c  | 49 ++---
 xen/arch/x86/sysctl.c   |  5 ++--
 xen/include/asm-x86/msr-index.h |  3 +++
 xen/include/asm-x86/psr.h   |  8 +-
 xen/include/public/sysctl.h |  4 ++-
 6 files changed, 70 insertions(+), 10 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index a2e427c..d92e323 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1165,9 +1165,9 @@ This option can be specified more than once (up to 8 
times at present).
 > `= `
 
 ### psr (Intel)
-> `= List of ( cmt: | rmid_max: | cat: | 
cos_max: )`
+> `= List of ( cmt: | rmid_max: | cat: | 
cos_max: | cdp: )`
 
-> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255`
+> Default: `psr=cmt:0,rmid_max:255,cat:0,cos_max:255,cdp:0`
 
 Platform Shared Resource(PSR) Services.  Intel Haswell and later server
 platforms offer information about the sharing of resources.
@@ -1197,6 +1197,13 @@ The following resources are available:
   the cache allocation.
   * `cat` instructs Xen to enable/disable Cache Allocation Technology.
   * `cos_max` indicates the max value for COS ID.
+* Code and Data Prioritization Technology (Broadwell and later). Information
+  regarding the code cache and the data cache allocation. CDP is based on CAT.
+  * `cdp` instructs Xen to enable/disable Code and Data Prioritization. Note
+that `cos_max` of CDP is a little different from `cos_max` of CAT. With
+CDP, one COS will corespond two CBMs other than one with CAT, due to the
+sum of CBMs is fixed, that means actual `cos_max` in use will automatically
+reduce to half when CDP is enabled.
 
 ### reboot
 > `= t[riple] | k[bd] | a[cpi] | p[ci] | P[ower] | e[fi] | n[o] [, [w]arm | 
 > [c]old]`
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index c0daa2e..37e77d1 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -21,9 +21,16 @@
 
 #define PSR_CMT(1<<0)
 #define PSR_CAT(1<<1)
+#define PSR_CDP(1<<2)
 
 struct psr_cat_cbm {
-uint64_t cbm;
+union {
+uint64_t cbm;
+struct {
+uint64_t code;
+uint64_t data;
+};
+};
 unsigned int ref;
 };
 
@@ -43,6 +50,7 @@ struct psr_cmt *__read_mostly psr_cmt;
 
 static unsigned long *__read_mostly cat_socket_enable;
 static struct psr_cat_socket_info *__read_mostly cat_socket_info;
+static unsigned long *__read_mostly cdp_socket_enable;
 
 static unsigned int __initdata opt_psr;
 static unsigned int __initdata opt_rmid_max = 255;
@@ -94,6 +102,7 @@ static void __init parse_psr_param(char *s)
 
 parse_psr_bool(s, val_str, "cmt", PSR_CMT);
 parse_psr_bool(s, val_str, "cat", PSR_CAT);
+parse_psr_bool(s, val_str, "cdp", PSR_CDP);
 
 if ( val_str && !strcmp(s, "rmid_max") )
 opt_rmid_max = simple_strtoul(val_str, NULL, 0);
@@ -261,8 +270,14 @@ static struct psr_cat_socket_info 
*get_cat_socket_info(unsigned int socket)
 return cat_socket_info + socket;
 }
 
+static inline bool_t cdp_is_enabled(unsigned int socket,
+unsigned long *cdp_socket_enable)
+{
+return cdp_socket_enable && test_bit(socket, cdp_socket_enable);
+}
+
 int psr_get_cat_l3_info(unsigned int socket, uint32_t *cbm_len,
-uint32_t *cos_max)
+uint32_t *cos_max, uint32_t *flags)
 {
 struct psr_cat_socket_info *info = get_cat_socket_info(socket);
 
@@ -272,6 +287,10 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t 
*cbm_len,
 *cbm_len = info->cbm_len;
 *cos_max = info->cos_max;
 
+*flags = 0;
+if ( cdp_is_enabled(socket, cdp_socket_enable) )
+*flags |= XEN_SYSCTL_PSR_CAT_L3_CDP;
+
 return 0;
 }
 
@@ -470,6 +489,7 @@ static void cat_cpu_init(void)
 struct psr_cat_socket_info *info;
 unsigned int socket;
 unsigned int cpu = smp_processor_id();
+uint64_t val;
 const struct cpuinfo_x86 *c = cpu_data + cpu;
 
 if ( !cpu_has(c, X86_FEATURE_CAT) || c->cpuid_level < PSR_CPUID_LEVEL_CAT )
@@ -495,8 +515,27 @@ static void cat_cpu_init(void)
 spin_lock_init(&info->cbm_lock);
 
 set_bit(socket, cat_socket_enable);
-printk(XENLOG_INFO "CAT: enabled on socket %u, cos_max:%u, 
cbm_len:%u\n",
-   socket, info->cos_max, info->cbm_len);
+
+   

[Xen-devel] [PATCH v5 2/3] x86: add domctl cmd to set/get CDP code/data CBM

[He Chen]

CDP extends CAT and provides the capacity to control L3 code & data
cache. With CDP, one COS corresponds to two CMBs(code & data). cbm_type
is added to distinguish different CBM operations. Besides, new domctl
cmds are introdunced to support set/get CDP CBM. Some CAT functions to
operation CBMs are extended to support CDP.

Signed-off-by: He Chen 
Reviewed-by: Andrew Cooper 
---
Changes in v5:
* replace -EINVAL with -ENXIO when setting code/data CBM on CDP
  disabled.
---
 xen/arch/x86/domctl.c   |  32 +++-
 xen/arch/x86/psr.c  | 188 ++--
 xen/include/asm-x86/psr.h   |  12 ++-
 xen/include/public/domctl.h |   4 +
 4 files changed, 191 insertions(+), 45 deletions(-)

diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index bf62a88..734fddb 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1167,12 +1167,40 @@ long arch_do_domctl(
 {
 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);
+ domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3);
+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);
+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);
 break;
 
 case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CBM:
 ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
- &domctl->u.psr_cat_op.data);
+ &domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3);
+copyback = 1;
+break;
+
+case XEN_DOMCTL_PSR_CAT_OP_GET_L3_CODE:
+ret = psr_get_l3_cbm(d, domctl->u.psr_cat_op.target,
+ &domctl->u.psr_cat_op.data,
+ PSR_CBM_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,
+ &domctl->u.psr_cat_op.data,
+ PSR_CBM_TYPE_L3_DATA);
 copyback = 1;
 break;
 
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index 37e77d1..8bfcccb 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -294,14 +294,40 @@ int psr_get_cat_l3_info(unsigned int socket, uint32_t 
*cbm_len,
 return 0;
 }
 
-int psr_get_l3_cbm(struct domain *d, unsigned int socket, uint64_t *cbm)
+int psr_get_l3_cbm(struct domain *d, unsigned int socket,
+   uint64_t *cbm, enum cbm_type type)
 {
 struct psr_cat_socket_info *info = get_cat_socket_info(socket);
+bool_t cdp_enabled = cdp_is_enabled(socket, cdp_socket_enable);
 
 if ( IS_ERR(info) )
 return PTR_ERR(info);
 
-*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+switch ( type )
+{
+case PSR_CBM_TYPE_L3:
+if ( type == PSR_CBM_TYPE_L3 && cdp_enabled )
+return -EXDEV;
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+break;
+
+case PSR_CBM_TYPE_L3_CODE:
+if ( !cdp_enabled )
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+else
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].code;
+break;
+
+case PSR_CBM_TYPE_L3_DATA:
+if ( !cdp_enabled )
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].cbm;
+else
+*cbm = info->cos_to_cbm[d->arch.psr_cos_ids[socket]].data;
+break;
+
+default:
+ASSERT_UNREACHABLE();
+}
 
 return 0;
 }
@@ -332,19 +358,34 @@ static bool_t psr_check_cbm(unsigned int cbm_len, 
uint64_t cbm)
 struct cos_cbm_info
 {
 unsigned int cos;
-uint64_t cbm;
+uint64_t cbm_code;
+uint64_t cbm_data;
+bool_t cdp;
 };
 
 static void do_write_l3_cbm(void *data)
 {
 struct cos_cbm_info *info = data;
 
-wrmsrl(MSR_IA32_PSR_L3_MASK(info->cos), info->cbm);
+if ( info->cdp )
+{
+wrmsrl(MSR_IA32_PSR_L3_MASK_CODE(info->cos), info->cbm_code);
+wrmsrl(MSR_IA32_PSR_L3_MASK_DATA(info->cos), info->cbm_data);
+}
+else
+wrmsrl(MSR_IA32_PSR_L3_MASK(info->cos), info->cbm_code);
 }
 
-static int write_l3_cbm(unsigned int socket, unsigned int cos, uint64_t cbm)
+static int write_l3_cbm(unsigned int socket, unsigned int cos,
+uint64_t cbm_code, uint64_t cbm_data, bool_t cdp)
 {
-struct cos_cbm_info info = { .c

[Xen-devel] [PATCH linux-2.6.18] usbback: correct copy length for partial transfers

[Juergen Gross]

Commit 72387b3c2252 ("usbback: copy only filled buffers to guest") has
introduced an error leading to copying the wrong amount of data to the
guest in case of read I/Os with not the complete buffer filled.

Depending on the amount of data read either too much or not enough
data was copied: if a buffer segment was filled less than half still
some data of the backend kernel could leak into the guest, while a
buffer segment filled more than half of it's size wouldn't be copied
completely.

Correct this by limiting the to be copied data amount to the rest
length of the read data.

Signed-off-by: Juergen Gross 

diff -r b4bb467e5c07 drivers/xen/usbback/usbback.c
--- a/drivers/xen/usbback/usbback.c Wed Sep 09 09:52:22 2015 +0200
+++ b/drivers/xen/usbback/usbback.c Mon Sep 28 09:47:41 2015 +0200
@@ -213,7 +213,7 @@ static void copy_buff_to_pages(void *buf
buf_off += offset - buf_off;
}
if (buf_off + len > offset + length)
-   len -= offset + length - buf_off;
+   len = offset + length - buf_off;
memcpy((void *)vaddr(pending_req, i) + off,
   buff + buf_off, len);
}

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

Re: [Xen-devel] [PATCH 5/5] xen: clean up VPF flags macros

[Jan Beulich]

>>> On 28.09.15 at 10:15,  wrote:
> On 09/28/2015 09:52 AM, Jan Beulich wrote:
> On 28.09.15 at 09:29,  wrote:
>>> On 09/28/2015 08:22 AM, Jan Beulich wrote:
>>> On 28.09.15 at 07:23,  wrote:
> On 09/25/2015 05:42 PM, Jan Beulich wrote:
> On 25.09.15 at 13:54,  wrote:
>>> --- a/xen/common/domctl.c
>>> +++ b/xen/common/domctl.c
>>> @@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct
> xen_domctl_getdomaininfo *info)
>>> info->max_vcpu_id = v->vcpu_id;
>>> if ( !test_bit(_VPF_down, &v->pause_flags) )
>>> {
>>> -if ( !(v->pause_flags & VPF_blocked) )
>>> +if ( !test_bit(_VPF_blocked, &v->pause_flags) )
>>
>> test_bit() is quite a bit more complex an operation than a simple &,
>> and with (on x86) even constant_test_bit() involving a cast to
>> a pointer to volatile I'm afraid we can't even hope that compilers
>> would produce identical code for both in cases like this one (as that
>> casts limits freedom of the compiler). IOW I'd rather see other
>> test_bit(_VPF_...) uses converted the inverse way (which as a nice
>> but minor side effect would yield slightly smaller source code).
>
> What about introducing __test_bit() being a variant which can be
> reordered by omitting the volatile modifier? I think this would have
> the same effect.

 I'm not convinced it always would - the inline function is still more
 complex than the plain operation.
>>>
>>> Depends on the way it is done. What about:
>>>
>>> #define __test_bit(nr, addr) ({ \
>>>   if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
>>>   (__builtin_constant_p(nr) ? \
>>>!!(*(addr) & ((typeof)(*(addr))1 << (nr))) :   \
>>>__variable_test_bit((nr),(addr))); \
>>> })
>>
>> But that's not correct - addr may point to wider than a single entry
>> array, irrespective of whether nr is a compile time constant.
>>
>>> It would even be possible to drop the test for bitop_bad_size(addr) in
>>> the constant case.
>>
>> In which case 1 << nr may reference a bit beyond the type
>> of *addr.
> 
> Hmm, yes, you are right, of course.
> 
> It could be fixed, however.
> 
> The question is: does it make sense to follow this path any longer,
> or would you reject it even in case of correctness? I wouldn't mind
> either way, I just don't want to waste time (mine and yours).

I continue to think that the better route would be to get rid of the
unnecessary test_bit() uses in favor of the shorter and less
restrictive (to the compiler) & operation.

Jan


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

[Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Shameerali Kolothum Thodi]

Hi All,

I am working on enabling Xen on our HIPO5 
board(http://lists.xenproject.org/archives/html/xen-users/2015-07/msg00090.html)

Since the board has got GIC/ITS, tried this ITS  patch series 
(https://github.com/vijaykilari/its_v6/commits/stating_its_v6). 

The board has got 16 cores. The dts file for the GIC is as below.


gic: interrupt-controller@8d00 {
compatible = "hisilicon,gic-v3";
#interrupt-cells = <3>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
interrupt-controller;
#redistributor-regions = <1>;
redistributor-stride = <0x0 0x3>;
reg = <0x0 0x8d00 0 0x1>,   /* GICD */
  <0x0 0x8d10 0 0x30>,  /* GICR c */
  <0x0 0xfe00 0 0x1>,   /* GICC */
  <0x0 0xfe01 0 0x1>,   /* GICH */
  <0x0 0xfe02 0 0x1>;   /* GICV */
interrupts = <1 9 0xff04>;

its_pc: interrupt-controller@8c00 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0x8c00 0x0 0x100>;
};

its_dsa: interrupt-controller@c600 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0xc600 0x0 0x100>;
};

its_m3: interrupt-controller@a300 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0xa300 0x0 0x100>;
};

its_pcie: interrupt-controller@b700 {
compatible = "arm,gic-v3-its";
msi-controller;
reg = <0x0 0xb700 0x0 0x100>;
};


};


It has got the re-distributor base as 0x8d100 and stride size as 0x3.I 
have seen couple of issues that blocks my Dom0 boot attempt. The first issue is 
related to the Dom0 secondary cpu boot failure.

This is what I believe is happening(Please correct me if my understanding is 
wrong).
-Dom0 make the CPU1 on.
-gic_secondary_init() -->gic_populate_rdist()  (irq-gic-v3.c)

Here it tries to find the re-distributor address by reading the GICR_TYPER 
register.  Since we have the rdbase as 0x8d10 and stride size as 0x3, a 
read is issued at 0x8d130008.

Please find the Xen log below(Full log is attached at the end).

(XEN) d0v0: vGICR: unknown gpa read address 8d130008
(XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffc00032362c 
gva=0xff8b0008 gpa=0x008d130008
(XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
(XEN) DOM0: CPU1: failed to come online

vgic_v3_rdistr_mmio_read()
{

v = get_vcpu_from_rdist(info->gpa, v, &offset);

}
I think the function returns the offset as 0x20008 and vcpu as 0, instead what 
I am expecting is offset 0x8 and vcpu 1. I am not sure this is because our GIC 
implementation is non std or a bug in get_vcpu_from_rdist().(I checked with our 
GIC team and they don't think we have any deviation from GIC std as far as this 
board re-distributor is concerned. As a matter of fact the linux kernel boots 
fine with GIC/ITS on this board).

Any pointers highly appreciated.

Many thanks,
Shameer


(XEN) Checking for initrd in /chosen
(XEN) RAM:  - 7fff
(XEN)
(XEN) MODULE[0]: 00192e00 - 00196b80 Device Tree
(XEN) MODULE[1]: 0700 - 07a0 Kernel
(XEN)
(XEN) Command line: dom0_mem=128M console=dtuart dtuart=serial0
(XEN) Placing Xen at 0x7fe0-0x8000
(XEN) Update BOOTMOD_XEN from 0008-00192e01 => 
7fe0-7ff12e01
(XEN) Domain heap initialised
(XEN) Platform: Generic System
(XEN) Looking for dtuart at "serial0", options ""
 Xen 4.6.0-rc
(XEN) Xen version 4.6.0-rc (root@) (aarch64-linux-gnu-gcc (crosstool-NG 
linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 4.9.2 20140904 
(prerelease)) debug=y Wed Sep 23 11:58:54 BST 2015
(XEN) Latest ChangeSet: Wed Jul 8 14:20:59 2015 +0530 git:71e9d3c-dirty
(XEN) Processor: 411fd071: "ARM Limited", variant: 0x1, part 0xd07, rev 0x1
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1124 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 0131:100110

Re: [Xen-devel] [PATCH 5/5] xen: clean up VPF flags macros

[Juergen Gross]

On 09/28/2015 10:34 AM, Jan Beulich wrote:

On 28.09.15 at 10:15,  wrote:

On 09/28/2015 09:52 AM, Jan Beulich wrote:

On 28.09.15 at 09:29,  wrote:

On 09/28/2015 08:22 AM, Jan Beulich wrote:

On 28.09.15 at 07:23,  wrote:

On 09/25/2015 05:42 PM, Jan Beulich wrote:

On 25.09.15 at 13:54,  wrote:

--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -172,7 +172,7 @@ void getdomaininfo(struct domain *d, struct

xen_domctl_getdomaininfo *info)

 info->max_vcpu_id = v->vcpu_id;
 if ( !test_bit(_VPF_down, &v->pause_flags) )
 {
-if ( !(v->pause_flags & VPF_blocked) )
+if ( !test_bit(_VPF_blocked, &v->pause_flags) )


test_bit() is quite a bit more complex an operation than a simple &,
and with (on x86) even constant_test_bit() involving a cast to
a pointer to volatile I'm afraid we can't even hope that compilers
would produce identical code for both in cases like this one (as that
casts limits freedom of the compiler). IOW I'd rather see other
test_bit(_VPF_...) uses converted the inverse way (which as a nice
but minor side effect would yield slightly smaller source code).


What about introducing __test_bit() being a variant which can be
reordered by omitting the volatile modifier? I think this would have
the same effect.


I'm not convinced it always would - the inline function is still more
complex than the plain operation.


Depends on the way it is done. What about:

#define __test_bit(nr, addr) ({ \
   if ( bitop_bad_size(addr) ) __bitop_bad_size(); \
   (__builtin_constant_p(nr) ? \
!!(*(addr) & ((typeof)(*(addr))1 << (nr))) :   \
__variable_test_bit((nr),(addr))); \
})


But that's not correct - addr may point to wider than a single entry
array, irrespective of whether nr is a compile time constant.


It would even be possible to drop the test for bitop_bad_size(addr) in
the constant case.


In which case 1 << nr may reference a bit beyond the type
of *addr.


Hmm, yes, you are right, of course.

It could be fixed, however.

The question is: does it make sense to follow this path any longer,
or would you reject it even in case of correctness? I wouldn't mind
either way, I just don't want to waste time (mine and yours).


I continue to think that the better route would be to get rid of the
unnecessary test_bit() uses in favor of the shorter and less
restrictive (to the compiler) & operation.


Okay, I'll follow that route then.


Juergen


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

Re: [Xen-devel] [PATCH for-4.6] p2m/ept: Set the A bit only if PML is enabled

[Kai Huang]

On 09/24/2015 05:10 PM, Tim Deegan wrote:

At 01:02 -0600 on 24 Sep (1443056566), Jan Beulich wrote:

On 23.09.15 at 17:46,  wrote:

At 16:18 +0100 on 23 Sep (1443025126), Wei Liu wrote:

With the discussion still not finalised I'm a bit worried that this
issue will block the release.

I think we have a few options here. I will list them in order of my
preference. Please correct me if I'm talking non-sense, and feel free to
add more options if I miss anything.

1. Disable PML on broken chips, gate access to A bit (or AD) with PML.

I don't much like tying this to PML: this is not a PML-related bug and
there may be CPUs that have A/D but not PML.

Better to have a global read-mostly bool cpu_has_vmx_ept_broken_access_bit,
or whatever name the maintainers prefer. :)

Actually I'd suggest a positive identification (e.g. cpu_has_ept_ad),
which would get forced off on known broken chips. And then, in a
slight variation of the previously proposed patch, at least for the
immediate 4.6 needs do

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -130,14 +130,18 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
  break;
  case p2m_ram_rw:
  entry->r = entry->w = entry->x = 1;
-entry->a = entry->d = 1;
+entry->a = entry->d = cpu_has_ept_ad;
  break;
  case p2m_mmio_direct:
  entry->r = entry->x = 1;
  entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
  entry->mfn);
-entry->a = 1;
-entry->d = entry->w;
+entry->a = cpu_has_ept_ad;
+entry->d = entry->w && cpu_has_ept_ad;
  break;
  case p2m_ram_logdirty:
  entry->r = entry->x = 1;


Sure, that works.  I still prefer putting the workaround on the CR3
operation, so all the cost happens on the broken chip, but I'll shut
up about that now. :)
Sorry for late response on this issue. This is good to me too as it 
avoids the "if" gate.





etc along with adjusting the existing gating of PML on AD being
available (perhaps by simply stripping the respective bit from what
we read from MSR_IA32_VMX_EPT_VPID_CAP). Of course this
then ignores the fact that the erratum only affects the A bit, but
I think we can live with that.

I also think the currently slightly strange setting of the ept_ad bit
should be changed: There's no point setting the bit for domains
not getting PML enabled (and incurring the overhead of the
hardware updating the bits); imo this should instead be done in
ept_enable_pml() / vmx_domain_enable_pml() (and undone in
the respective disable function).

Yep.
Yes this is slight better. But I don't think keeping current code of 
setting ept_ad in ept_p2m_init would cause any performance regression, 
as we'll unconditionally set A/D bits to 1 in ept_p2m_type_to_flags to 
avoid having CPU to set them later. Right?


For the erratum we are talking about here, the ept_ad bit simply won't 
be set as PML is simply not supported.


Thanks,
-Kai



2. Implement general framework to detect broken chips and apply quirks.

I take that there is no general framework at the moment, otherwise the
patch would have used that.

We already have code that detects specific chips and adjusts things,
e.g. init_intel() in arch/x86/cpu/intel.c.  That seems like a good
place to set the global flag above, or...

Together with the above I'm not sure that would be the best place
to deal with this (EPT specific) erratum; I think this would better be
contained to VMX/EPT code.

Agreed.

Tim.

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




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

Re: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU mapping updates

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 21, 2015 10:03 PM
> 
> In the EPT case permission changes should also result in updates or
> TLB flushes.
> 
> In the NPT case the old MFN does not depend on the new entry being
> valid (but solely on the old one), and the need to update or TLB-flush
> again also depends on permission changes.
> 
> In the shadow mode case, iommu_hap_pt_share should be ignored.
> 
> Furthermore in the NPT/shadow case old intermediate page tables must
> be freed only after IOMMU side updates/flushes have got carried out.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Kevin Tian 

Thanks
Kevin

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

Re: [Xen-devel] [PATCH 3/3] x86/p2m‑ept: adjust some types in ept_set_entry()

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, September 21, 2015 10:04 PM
> 
> Use unsigned and bool_t as appropriate.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Kevin Tian 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [V5 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Jan Beulich]

>>> On 21.09.15 at 13:33,  wrote:
> This patch add basic definitions/helpers which will be used in
> later patches.
> 
> Signed-off-by: Shuai Ruan 
> ---

Missing brief description of changes in v5 here.

> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -29,12 +29,21 @@ static u32 __read_mostly xsave_cntxt_size;
>  /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
>  u64 __read_mostly xfeature_mask;
>  
> +unsigned int * __read_mostly xstate_offsets;
> +unsigned int * __read_mostly xstate_sizes;
> +static unsigned int __read_mostly xstate_features;
> +static unsigned int __read_mostly 
> xstate_comp_offsets[sizeof(xfeature_mask)*8];
> +
> +/* Cached msr_xss for fast read */
> +static DEFINE_PER_CPU(uint64_t, msr_xss);

Any reason not to call this just xss?

>  /* Cached xcr0 for fast read */
>  static DEFINE_PER_CPU(uint64_t, xcr0);
>  
>  /* Because XCR0 is cached for each CPU, xsetbv() is not exposed. Users 
> should 
>   * use set_xcr0() instead.
>   */
> +
>  static inline bool_t xsetbv(u32 index, u64 xfeatures)

Stray addition of a blank line.

> +bool_t xsave_area_compressed(const struct xsave_struct *xsave_area)
> +{
> +if ( xsave_area && (xsave_area->xsave_hdr.xcomp_bv
> +  & XSTATE_COMPACTION_ENABLED))
> + return 1;
> +return 0;
> +}

The body of the function could a single return statement.

> +static int setup_xstate_features(bool_t bsp)
> +{
> +unsigned int leaf, tmp, eax, ebx;
> +
> +if ( bsp )
> +xstate_features = fls(xfeature_mask);
> +
> +if ( bsp )

The two if()s should be combined.

> +{
> +xstate_offsets = xzalloc_array(unsigned int, xstate_features);
> +if( !xstate_offsets )
> +return -ENOMEM;
> +
> +xstate_sizes = xzalloc_array(unsigned int, xstate_features);
> +if( !xstate_sizes )
> +return -ENOMEM;
> +}
> +
> +for (leaf = 2; leaf < xstate_features; leaf++)

Coding style.

> +{
> +if( bsp )

Again.

> +cpuid_count(XSTATE_CPUID, leaf, &xstate_sizes[leaf],
> +&xstate_offsets[leaf], &tmp, &tmp);
> +else
> +{
> + cpuid_count(XSTATE_CPUID, leaf, &eax,
> +&ebx, &tmp, &tmp);
> + BUG_ON(eax != xstate_sizes[leaf]);
> + BUG_ON(ebx != xstate_offsets[leaf]);
> +}
> + }
> + return 0;

Blank line before final return statement please.

> +}
> +
> +static void setup_xstate_comp(void)
> +{
> +unsigned int i;
> +
> +/*
> + * The FP xstates and SSE xstates are legacy states. They are always
> + * in the fixed offsets in the xsave area in either compacted form
> + * or standard form.
> + */
> +xstate_comp_offsets[0] = 0;
> +xstate_comp_offsets[1] = XSAVE_SSE_OFFSET;
> +
> +xstate_comp_offsets[2] = FXSAVE_SIZE + XSAVE_HDR_SIZE;
> +
> +for (i = 3; i < xstate_features; i++)

Coding style again.

> +{
> +xstate_comp_offsets[i] = xstate_comp_offsets[i-1] + (((1ul << i)
> + & xfeature_mask) ? xstate_sizes[i-1] : 0);

Indentation should match up with the parentheses. Which likely
means you'll want to break the line after the +.

> +ASSERT(xstate_comp_offsets[i] <= xsave_cntxt_size);

How about the last component's offset + size exceeding
xsave_cntxt_size?

Also just considering what the function does, it looks like it ought to
be __init.

> +void save_xsave_states(struct vcpu *v, void *dest, unsigned int size)

Iirc it was suggested before that the function's name isn't adequate:
There's no saving of anything here. You're expanding already saved
state.

> +{
> +struct xsave_struct *xsave = v->arch.xsave_area;

const?

> +u64 xstate_bv = xsave->xsave_hdr.xstate_bv;
> +u64 valid;
> +
> +ASSERT(xsave_area_compressed(xsave));
> +/*
> + * Copy legacy XSAVE area, to avoid complications with CPUID
> + * leaves 0 and 1 in the loop below.
> + */
> +memcpy(dest, xsave, FXSAVE_SIZE);
> +
> +/* Set XSTATE_BV */
> +*(u64 *)(dest + XSAVE_HDR_OFFSET) = xstate_bv;

Can't you avoid fragile casts like this by using a proper structure
type for dest?

> +/*
> + * Copy each region from the possibly compacted offset to the
> + * non-compacted offset.
> + */
> +valid = xstate_bv & ~XSTATE_FP_SSE;
> +while ( valid )
> +{
> +u64 feature = valid & -valid;
> +int index = fls(feature) - 1;

unsigned int

> +void *src = get_xsave_addr(xsave, index);

const

> +if ( src )
> +{
> +ASSERT((xstate_offsets[index] + xstate_sizes[index]) <= size);
> +memcpy(dest + xstate_offsets[index], src, xstate_sizes[index]);
> +}
> +
> +valid -= feature;

While correct this way, I would consider "&= ~feature" more natural.

> +}
> +
> +}
> +
> +void load_xsave_states(struct vcpu *v, const void *src, unsigned in

Re: [Xen-devel] [PATCH 1/3] x86/p2m: tighten conditions of IOMMU mapping updates

[Jan Beulich]

>>> On 28.09.15 at 10:55,  wrote:
>>  From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, September 21, 2015 10:03 PM
>> 
>> In the EPT case permission changes should also result in updates or
>> TLB flushes.
>> 
>> In the NPT case the old MFN does not depend on the new entry being
>> valid (but solely on the old one), and the need to update or TLB-flush
>> again also depends on permission changes.
>> 
>> In the shadow mode case, iommu_hap_pt_share should be ignored.
>> 
>> Furthermore in the NPT/shadow case old intermediate page tables must
>> be freed only after IOMMU side updates/flushes have got carried out.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Acked-by: Kevin Tian 

Thanks, but quite a bit more important would have been a reply
to this

>>In addition to the fixes here it looks to me as if both EPT and
>>NPT/shadow code lack invalidation of IOMMU side paging structure
>>caches, i.e. further changes may be needed. Am I overlooking something?

as it may require the patch to be extended (and hence the ack to
be dropped again).

Thanks, Jan


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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2

[Ian Campbell]

On Sat, 2015-09-26 at 10:30 -0700, Greg Kroah-Hartman wrote:
> On Fri, Sep 11, 2015 at 04:55:00PM +0100, Ian Campbell wrote:
> > On Fri, 2015-09-11 at 08:51 -0700, Greg Kroah-Hartman wrote:
> > > On Fri, Sep 11, 2015 at 04:10:46PM +0100, Ian Campbell wrote:
> > > > ping for 3.10.y and 3.14.y
> > > 
> > > My stable queue is huge at the moment, and I've been on vacation and
> > > am
> > > now just finally catching up with it, don't worry, it's not lost,
> > > just
> > > might take a few weeks...
> > 
> > Understood & thanks!
> 
> Should now be resolved, if not, please let me know.

Thanks, but I don't see a backport of 1401c00e59ea in either 3.10.89 or
3.14.53.

30b03d05e074 was in 3.10.87 and 3.14.51 and causes breakage in those trees
when 1401c00e59ea is not also present.

Ian.

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

Re: [Xen-devel] [PATCH 1/5] libxc: remove allocate member from struct xc_dom_image

[Ian Campbell]

On Mon, 2015-09-28 at 05:55 +0200, Juergen Gross wrote:
> On 09/25/2015 05:39 PM, Ian Campbell wrote:
> > On Fri, 2015-09-11 at 13:44 +0100, Ian Jackson wrote:
> > > Juergen Gross writes ("[PATCH 1/5] libxc: remove allocate member from
> > > struct xc_dom_image"):
> > > > The allocate() callback in struct xc_dom_image is never set. Remove
> > > > it.
> > > 
> > > Acked-by: Ian Jackson 
> > 
> > Applied to staging.
> 
> Really? Can't see it there.

Indeed, I seem to have somehow not actually applied it. I've put it back in
my queue folder and I'll pick it up when I next go over that.

Sorry for the noise.

Ian.

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

Re: [Xen-devel] [PATCH] Add missing license and copyright statements to public interface headers.

[Mike Belopuhov]

On Fri, Sep 25, 2015 at 01:12 -0600, Jan Beulich wrote:
> >>> On 22.09.15 at 16:02,  wrote:
> > --- xen/include/public/arch-x86/pmu.h
> > +++ xen/include/public/arch-x86/pmu.h
> 
> I fixed this up for you this time, but in the future please make sure
> you send patches in conventional format (applicable with patch's -p1
> or whatever tool's equivalent).
> 
> Thanks, Jan
> 

Thanks, Jan.  I'll keep that in mind.

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

Re: [Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Julien Grall]

On 28/09/2015 09:36, Shameerali Kolothum Thodi wrote:

Hi All,


Hi,



I am working on enabling Xen on our HIPO5 
board(http://lists.xenproject.org/archives/html/xen-users/2015-07/msg00090.html)

Since the board has got GIC/ITS, tried this ITS  patch series 
(https://github.com/vijaykilari/its_v6/commits/stating_its_v6).


The ITS series is not upstream and unless your PCI device can't work 
without MSI I would advise you to first boot Xen and DOM0 without ITS. 
Once you have a working base, you can add the ITS series.


Although, use the latest version i.e v7: 
https://github.com/vijaykilari/its_v6/tree/staging_its_v7.




The board has got 16 cores. The dts file for the GIC is as below.


 gic: interrupt-controller@8d00 {
 compatible = "hisilicon,gic-v3";


This compatible string is not supported by Xen and below your log shows 
that your tree is dirty. What's the difference between staging and your 
tree?



 #interrupt-cells = <3>;
 #address-cells = <2>;
 #size-cells = <2>;
 ranges;
 interrupt-controller;
 #redistributor-regions = <1>;
 redistributor-stride = <0x0 0x3>;


The GICv3 driver reads an 32 byte value for this field. It seems to be a 
mistake in our implementation (will send a patch for it).


Although I don't think it's affecting your problem because Xen seems to 
retrieve the correct stride:


 (XEN) GICv3 initialization:
 (XEN)   gic_dist_addr=0x008d00
 (XEN)   gic_maintenance_irq=25
 (XEN)   gic_rdist_stride=3


 reg = <0x0 0x8d00 0 0x1>,   /* GICD */
   <0x0 0x8d10 0 0x30>,  /* GICR c */
   <0x0 0xfe00 0 0x1>,   /* GICC */
   <0x0 0xfe01 0 0x1>,   /* GICH */
   <0x0 0xfe02 0 0x1>;   /* GICV */
 interrupts = <1 9 0xff04>;


[...]


 };


It has got the re-distributor base as 0x8d100 and stride size as 0x3.I 
have seen couple of issues that blocks my Dom0 boot attempt. The first issue is 
related to the Dom0 secondary cpu boot failure.

This is what I believe is happening(Please correct me if my understanding is 
wrong).
-Dom0 make the CPU1 on.
-gic_secondary_init() -->gic_populate_rdist()  (irq-gic-v3.c)

Here it tries to find the re-distributor address by reading the GICR_TYPER 
register.  Since we have the rdbase as 0x8d10 and stride size as 0x3, a 
read is issued at 0x8d130008.

Please find the Xen log below(Full log is attached at the end).

(XEN) d0v0: vGICR: unknown gpa read address 8d130008
(XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffc00032362c 
gva=0xff8b0008 gpa=0x008d130008
(XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the idle 
task!
(XEN) DOM0: CPU1: failed to come online

vgic_v3_rdistr_mmio_read()
{

v = get_vcpu_from_rdist(info->gpa, v, &offset);

}
I think the function returns the offset as 0x20008 and vcpu as 0, instead what 
I am expecting is offset 0x8 and vcpu 1.


It seems that you are right. To get the offset in the region, we use 
stride - 1 which will give 0x2 for your platform.


The code to get the vCPU is only valid when there is only a bit set in 
the stride.


I'm not sure if we can turn the mask into modulo and division. I will 
try to see how I can fix it.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2

[Ian Campbell]

On Mon, 2015-09-28 at 10:27 +0100, Ian Campbell wrote:
> On Sat, 2015-09-26 at 10:30 -0700, Greg Kroah-Hartman wrote:
> > On Fri, Sep 11, 2015 at 04:55:00PM +0100, Ian Campbell wrote:
> > > On Fri, 2015-09-11 at 08:51 -0700, Greg Kroah-Hartman wrote:
> > > > On Fri, Sep 11, 2015 at 04:10:46PM +0100, Ian Campbell wrote:
> > > > > ping for 3.10.y and 3.14.y
> > > > 
> > > > My stable queue is huge at the moment, and I've been on vacation
> > > > and
> > > > am
> > > > now just finally catching up with it, don't worry, it's not lost,
> > > > just
> > > > might take a few weeks...
> > > 
> > > Understood & thanks!
> > 
> > Should now be resolved, if not, please let me know.
> 
> Thanks, but I don't see a backport of 1401c00e59ea in either 3.10.89 or
> 3.14.53.

Ah, I was confused into thinking you meant resolved in the releases you did
at the weekend.

I spotted these in stable-queue.git now and will expect them in 3.10.90 and
3.14.54, thanks.

Ian.


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

Re: [Xen-devel] [PATCH] cleanup domain builder declarations and related users

[Andrew Cooper]

On 28/09/15 06:02, Juergen Gross wrote:
> There are several unused function and structure declarations in the
> hypervisor related to domain building. Remove them.
>
> Use an enum for elf_dom_parms.pae instead of just hard codiint pae; /* some 
> kind of enum apparently */
> ng the
> values when setting the information and adjust the code to use those
> instead of own macros (hypervisor and tools).
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Xen, ACPI and Linux

[Ian Campbell]

On Fri, 2015-09-25 at 21:20 +0100, Stefano Stabellini wrote:
> On Thu, 24 Sep 2015, Stefano Stabellini wrote:
> > On Wed, 23 Sep 2015, Stefano Stabellini wrote:
> > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > On Wed, 2015-09-23 at 01:18 -0700, Ard Biesheuvel wrote:
> > > > > On 23 September 2015 at 01:12, Jan Beulich 
> > > > > wrote:
> > > > > > > > > On 23.09.15 at 02:49, 
> > > > > > > > > wrote:
> > > > > > > Regarding Runtime Services, the EFI spec doesn't allow a NULL
> > > > > > > pointer
> > > > > > > to
> > > > > > > the Runtime Services table, so Mark would like to see a
> > > > > > > proper
> > > > > > > pointer
> > > > > > > being passed there.  The function table could be populated
> > > > > > > with
> > > > > > > hypercall wrappers in assembly, keeping the same interface to
> > > > > > > Xen
> > > > > > > that
> > > > > > > we have today in drivers/xen/efi.c. It should be part of the
> > > > > > > initial
> > > > > > > patch series.
> > > > > > 
> > > > > > I'm confused by the "interface to Xen" part: Aren't we talking
> > > > > > about
> > > > > > what is being presented to Dom0?
> > > > > > 
> > > > > 
> > > > > Yes we are.
> > > > > 
> > > > > > In any event, the versioning question that I raised earlier
> > > > > > remains:
> > > > > > Which version would you intend the Runtime Services table to
> > > > > > carry
> > > > > > - the host one, or a Xen set one? In the latter case, won't you
> > > > > > risk
> > > > > > wrong implications from the kernel looking at other version
> > > > > > numbers
> > > > > > (yes, with proper coding it ought to be possible to avoid such,
> > > > > > but
> > > > > > the multitude of version numbers in EFI doesn't exactly help to
> > > > > > avoid mistakes)? While in the former case you'd have to deal
> > > > > > with
> > > > > > the table needing entries Xen may not know about.
> > > > > > 
> > > > > 
> > > > > This is simply addressed by populating the fake EFI system table
> > > > > according to the UEFI spec version field that you put in the
> > > > > header.
> > > > > No reason at all to base this on whatever the host provides, it
> > > > > should
> > > > > simply be a version that is supported by arm64 (2.00 or greater)
> > > > 
> > > > This doesn't address Jan's concern wrt the multiple other places
> > > > UEFI
> > > > exposes version numbers which may reflect the host and not this
> > > > fake EFI
> > > > table.
> > > 
> > > The Runtime Services table has its own version field. I think that
> > > theoretically it could be different from the other version fields,
> > > but I
> > > don't know if it ever happens with real hardware.
> > > 
> > > If we don't want to support the case where Runtime Services have a
> > > different revision version than the other tables, then I think that
> > > going for the NULL Runtime Services table pointer approach might be
> > > better.
> > 
> > Looking again at the spec, it includes this line:
> > 
> > #define EFI_RUNTIME_SERVICES_REVISION EFI_SPECIFICATION_VERSION
> > 
> > the only way I can read it is that the EFI Runtime Services version
> > needs to match the EFI specification version.
> > 
> > Unfortunately it looks like that we cannot, according to spec, expose a
> > different version of Runtime Services.
> > 
> > Given that trying to emulate a set of Runtime Services which matches
> > the
> > version of the ones on the host would be undesirable from Xen point of
> > view, would it be OK if we went ahead and added to the Xen-Dom0
> > interface on EFI, which we are about to introduce and document, that
> > the
> > Runtime Services table pointer can be NULL?
> 
> Mark, Christoffer and I had another chat.  Given that it is difficult to
> provide a consistent set of tables to Dom0 (the Runtime Services version
> could differ from the native tables version and that is not allowed by
> the EFI spec), Mark would like to see EFI support being introduced in a
> Xen specific manner in Dom0, so that it is very clear that it might
> differ from the native EFI tables and spec.
> 
> This is what we need to do:
> 
> - xen_early_init() should be moved before efi_init() in
>   arch/arm64/kernel/setup.c. This will cause the device tree parsing in
>   xen_early_init to be changed because it will have to operate on the
>   flatten device tree.
> - xen_early_init should discover the EFI tables. It could do that via
>   hypercalls or via device tree attributes under the Xen hypervisor node
>   on device tree. The nodes under /chosen, described by
>   Documentation/arm/uefi.txt, should not be reused.
> - xen_early_init could call the efi initialization functions directly or
>   could setup some data structures (to be defined) so that efi_init will
>   later detect that we are running on Xen making the initialization
>   slightly different.
> - acpi will be initialized as usual
> 
> 
> This is what Mark, Christoffer and I agreed, I hope that this plan works
> for everybody else too.

My only question is whether, given this early i

[Xen-devel] OutreachY Proposed candidate selection process and FAQ

[Lars Kurth]

Hi,

I have been getting a few questions related to the Outreachy program from 
mentors. So I put together an FAQ

Q: How many slots do we have (across Xen, Mirage OS, XAPI)
A: We have two slots. But we do have quite *a lot* of interest both in Xen as 
well as in Mirage OS so far. I have funds for an extra slot and can ask the 
board to use 3.

Q: Who qualifies? Has the program been extended?
A: It has been extended. The program is open internationally to women (cis and 
trans), trans men, and genderqueer people. Additionally, it's open to residents 
and nationals of the United States of any gender who are Black/African 
American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or 
Pacific Islander. For more details, see https://www.gnome.org/outreachy.

Q: What is the program timeline
A: The timeline is - o denotes an outreachy milestone, x a Xen Project 
milestone ...

o September 28 organizations' landing pages need to be ready with project ideas
o September 29 application process opens
o November 2 application deadline
x November 6 xen project mentors get together and 
x November 9 xen project decides who to put forward
o November 17 accepted applicants announced
o December 7 - March 7 internship dates

Q: How will we select our applicants?
A: On Nov 6th, we will have all the mentors get together and agree who we 
select across Xen and Mirage. This worked in the past. Given the volume of 
interest, I believe we will need some optimizations
- Each mentor can only be the *advocate for 1 applicant* in the Nov 6th meeting 
(if you have several, you have to choose 1) prior to the meeting
- I will require mentors to fill out a questionnaire by Nov 6 that evaluates 
the interaction you had with the applicant, the community had with the 
applicant, and how well the "Small Contribution" requirement went (see 
https://wiki.gnome.org/Outreachy#Make_a_Small_Contribution)

If you have further questions, just ask.

Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v7 21/28] xen/arm: ITS: Add GICR register emulation

[Ian Campbell]

On Sat, 2015-09-26 at 21:38 +0530, Vijay Kilari wrote:

>  LPI property table is accessed in interrupt context. So interrupts
> are disabled.

Interrupts a reenabled while handling an interrupt, so a higher priority
interrupt can still interrupt things.

See the use of local_irq_enable in gic_interrupt.

Ian.

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

[Xen-devel] [linux-3.10 test] 62397: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qcow2 9 debian-di-install fail REGR. vs. 60670
 test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-xl-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-i386-freebsd10-i386 13 guest-saverestore   fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-installfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
60670
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-i386-qemut-rhel6hvm-amd 10 guest-stop  fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 60670
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install fail REGR. vs. 60670
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install  fail REGR. vs. 60670
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 60670
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 60670
 test-amd64-i386-xl-vhd   10 guest-start  fail in 62313 REGR. vs. 60670
 test-amd64-i386-qemuu-rhel6hvm-intel 10 guest-stop fail in 62313 REGR. vs. 
60670
 test-amd64-i386-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 62313 
REGR. vs. 60670

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt  14 guest-saverestore  fail in 62313 pass in 62397
 test-amd64-i386-freebsd10-amd64 13 guest-saverestore fail in 62313 pass in 
62397
 test-amd64-i386-qemut-rhel6hvm-amd 9 redhat-install fail in 62313 pass in 62397
 test-amd64-i386-xl-vhd9 debian-di-install   fail pass in 62313
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-install  fail pass in 62313
 test-amd64-i386-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail pass in 
62313

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail REGR. vs. 60670
 test-amd64-amd64-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 60670
 test-amd64-i386-libvirt-vhd   9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 60670
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60670
 test-amd64-i386-libvirt  15 guest-saverestore.2   fail REGR. vs. 60670
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2   fail REGR. vs. 60670
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60670
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60670
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60670
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2   fail REGR. vs. 60670
 test-amd64-i386-libvirt-raw   9 debian-di-install fail REGR. vs. 60670
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10  fail like 60656

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-xsm   6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl-raw   6 xen-boot fail   never pass
 test-armhf-armhf-xl-rtds  6 xen-boot fail   never pass
 test-ar

Re: [Xen-devel] [MirageOS-devel] OutreachY Proposed candidate selection process and FAQ

[Anil Madhavapeddy]

> On 28 Sep 2015, at 10:50, Lars Kurth  wrote:
> 
> Hi,
> 
> I have been getting a few questions related to the Outreachy program from 
> mentors. So I put together an FAQ
> 
> Q: How many slots do we have (across Xen, Mirage OS, XAPI)
> A: We have two slots. But we do have quite *a lot* of interest both in Xen as 
> well as in Mirage OS so far. I have funds for an extra slot and can ask the 
> board to use 3.

I'm seeing more enquiries in my inbox than any year in the past (this is 
awesome!).  So asking the board for 3 would be a good use of funds if it's an 
option...

> 
> Q: Who qualifies? Has the program been extended?
> A: It has been extended. The program is open internationally to women (cis 
> and trans), trans men, and genderqueer people. Additionally, it's open to 
> residents and nationals of the United States of any gender who are 
> Black/African American, Hispanic/Latin@, American Indian, Alaska Native, 
> Native Hawaiian, or Pacific Islander. For more details, see 
> https://www.gnome.org/outreachy.
> 
> Q: What is the program timeline
> A: The timeline is - o denotes an outreachy milestone, x a Xen Project 
> milestone ...
> 
> o September 28 organizations' landing pages need to be ready with project 
> ideas

I think we're set for this with the Pioneer Projects page.  Please do 
add/update your projects there though..

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

Re: [Xen-devel] [OSSTEST PATCH 10/26] cs-adjust-flight: Add some missing doc comment info

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 
[...]

> +# :
> +#   
> +#   new:

I had no idea this latter syntax existed, how useful!


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

Re: [Xen-devel] [OSSTEST PATCH 12/26] selecthost: Minor cleanups

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> Document the syntax for $ident.
> 
> Log the ident as well as the selected hostname.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 11/26] cs-adjust-flight: Allow adjusting "this" flight

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> This allows cs-adjust-flight to be run by hand to adjust runvars, in a
> flight being used with hand-invocation of ./ts-* scripts.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [Qemu-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

No, unfortunately it is not possible at this stage of the release cycle.
But users can still use QEMU 2.5 (as soon as it is released, which
should be in a couple of months) with Xen 4.6 as there is not a strong
tie between QEMU releases and Xen releases.

On Mon, 28 Sep 2015, Chen, Tiejun wrote:
> On 9/22/2015 12:03 AM, Stefano Stabellini wrote:
> > It is going to be in QEMU 2.5 and qemu-xen 4.7.
> 
> Thanks for your reply.
> 
> Do we have any possibility of just merging this series into qemu-xen 4.6? We
> really want to support IGD passthrough on xen 4.6 if possible :)
> 
> Thanks
> Tiejun
> 
> > 
> > On Mon, 21 Sep 2015, Chen, Tiejun wrote:
> > > Stefano,
> > > 
> > > I have two questions,
> > > 
> > > #1. Which qemu version is this igd stuff going into? 2.6?
> > > #2. Is this igd stuff going into qemu-xen inside xen? Any plan to go into
> > > xen
> > > 4.6?
> > > 
> > > Thanks
> > > Tiejun
> > > 
> > > On 9/9/2015 1:21 AM, Stefano Stabellini wrote:
> > > > The following changes since commit
> > > 8611280505119e296757a60711a881341603fa5a:
> > > >
> > > >target-microblaze: Use setcond for pcmp* (2015-09-08 08:49:33 +0200)
> > > >
> > > > are available in the git repository at:
> > > >
> > > >git://xenbits.xen.org/people/sstabellini/qemu-dm.git
> > > > tags/xen-2015-09-08-tag
> > > >
> > > > for you to fetch changes up to ba2250ad148997b1352aba976aac66b55410e7e4:
> > > >
> > > >xen/pt: Use XEN_PT_LOG properly to guard against compiler warnings.
> > > > (2015-09-08 15:21:56 +)
> > > >
> > > > 
> > > > Xen branch xen-2015-09-08
> > > >
> > > > 
> > > > Don Slutz (1):
> > > >xen-hvm: Add trace to ioreq
> > > >
> > > > Jan Beulich (1):
> > > >xen/HVM: atomically access pointers in bufioreq handling
> > > >
> > > > Konrad Rzeszutek Wilk (7):
> > > >xen-hvm: When using xc_domain_add_to_physmap also include errno
> > > when
> > > > reporting
> > > >xen/pt: Update comments with proper function name.
> > > >xen/pt: Make xen_pt_msi_set_enable static
> > > >xen/pt: xen_host_pci_config_read returns -errno, not -1 on
> > > failure
> > > >xen: use errno instead of rc for xc_domain_add_to_physmap
> > > >xen/pt/msi: Add the register value when printing logging and
> > > error
> > > > messages
> > > >xen/pt: Use XEN_PT_LOG properly to guard against compiler
> > > warnings.
> > > >
> > > > Michael S. Tsirkin (1):
> > > >i440fx: make types configurable at run-time
> > > >
> > > > Tiejun Chen (9):
> > > >pc_init1: pass parameters just with types
> > > >piix: create host bridge to passthrough
> > > >hw/pci-assign: split pci-assign.c
> > > >xen, gfx passthrough: basic graphics passthrough support
> > > >xen, gfx passthrough: retrieve VGA BIOS to work
> > > >igd gfx passthrough: create a isa bridge
> > > >xen, gfx passthrough: register a isa bridge
> > > >xen, gfx passthrough: register host bridge specific to
> > > passthrough
> > > >xen, gfx passthrough: add opregion mapping
> > > >
> > > >   configure |   28 +
> > > >   hw/core/machine.c |   20 +++
> > > >   hw/i386/Makefile.objs |1 +
> > > >   hw/i386/kvm/pci-assign.c  |   82 ++---
> > > >   hw/i386/pc_piix.c |  139 -
> > > >   hw/i386/pci-assign-load-rom.c |   93 ++
> > > >   hw/pci-host/piix.c|   91 +-
> > > >   hw/xen/Makefile.objs  |1 +
> > > >   hw/xen/xen-host-pci-device.c  |5 +
> > > >   hw/xen/xen-host-pci-device.h  |1 +
> > > >   hw/xen/xen_pt.c   |   42 ++-
> > > >   hw/xen/xen_pt.h   |   22 +++-
> > > >   hw/xen/xen_pt_config_init.c   |   59 -
> > > >   hw/xen/xen_pt_graphics.c  |  272
> > > > +
> > > >   hw/xen/xen_pt_msi.c   |2 +-
> > > >   include/hw/boards.h   |1 +
> > > >   include/hw/i386/pc.h  |9 +-
> > > >   include/hw/pci/pci-assign.h   |   27 
> > > >   include/hw/xen/xen_common.h   |   34 +-
> > > >   qemu-options.hx   |3 +
> > > >   trace-events  |7 ++
> > > >   vl.c  |   10 ++
> > > >   xen-hvm.c |   55 +++--
> > > >   23 files changed, 891 insertions(+), 113 deletions(-)
> > > >   create mode 100644 hw/i386/pci-assign-load-rom.c
> > > >   create mode 100644 hw/xen/xen_pt_graphics.c
> > > >   create mode 100644 include/hw/pci/pci-assign.h
> > > >
> > > > ___
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xen.org
> > > > http://lists.xen.org/xen-devel
> > > >
> > > 
> > 
> > 
> 

___
Xen-devel mailing list
Xen-devel@lis

Re: [Xen-devel] Xen, ACPI and Linux

[Stefano Stabellini]

On Mon, 28 Sep 2015, Ian Campbell wrote:
> On Fri, 2015-09-25 at 21:20 +0100, Stefano Stabellini wrote:
> > On Thu, 24 Sep 2015, Stefano Stabellini wrote:
> > > On Wed, 23 Sep 2015, Stefano Stabellini wrote:
> > > > On Wed, 23 Sep 2015, Ian Campbell wrote:
> > > > > On Wed, 2015-09-23 at 01:18 -0700, Ard Biesheuvel wrote:
> > > > > > On 23 September 2015 at 01:12, Jan Beulich 
> > > > > > wrote:
> > > > > > > > > > On 23.09.15 at 02:49, 
> > > > > > > > > > wrote:
> > > > > > > > Regarding Runtime Services, the EFI spec doesn't allow a NULL
> > > > > > > > pointer
> > > > > > > > to
> > > > > > > > the Runtime Services table, so Mark would like to see a
> > > > > > > > proper
> > > > > > > > pointer
> > > > > > > > being passed there.  The function table could be populated
> > > > > > > > with
> > > > > > > > hypercall wrappers in assembly, keeping the same interface to
> > > > > > > > Xen
> > > > > > > > that
> > > > > > > > we have today in drivers/xen/efi.c. It should be part of the
> > > > > > > > initial
> > > > > > > > patch series.
> > > > > > > 
> > > > > > > I'm confused by the "interface to Xen" part: Aren't we talking
> > > > > > > about
> > > > > > > what is being presented to Dom0?
> > > > > > > 
> > > > > > 
> > > > > > Yes we are.
> > > > > > 
> > > > > > > In any event, the versioning question that I raised earlier
> > > > > > > remains:
> > > > > > > Which version would you intend the Runtime Services table to
> > > > > > > carry
> > > > > > > - the host one, or a Xen set one? In the latter case, won't you
> > > > > > > risk
> > > > > > > wrong implications from the kernel looking at other version
> > > > > > > numbers
> > > > > > > (yes, with proper coding it ought to be possible to avoid such,
> > > > > > > but
> > > > > > > the multitude of version numbers in EFI doesn't exactly help to
> > > > > > > avoid mistakes)? While in the former case you'd have to deal
> > > > > > > with
> > > > > > > the table needing entries Xen may not know about.
> > > > > > > 
> > > > > > 
> > > > > > This is simply addressed by populating the fake EFI system table
> > > > > > according to the UEFI spec version field that you put in the
> > > > > > header.
> > > > > > No reason at all to base this on whatever the host provides, it
> > > > > > should
> > > > > > simply be a version that is supported by arm64 (2.00 or greater)
> > > > > 
> > > > > This doesn't address Jan's concern wrt the multiple other places
> > > > > UEFI
> > > > > exposes version numbers which may reflect the host and not this
> > > > > fake EFI
> > > > > table.
> > > > 
> > > > The Runtime Services table has its own version field. I think that
> > > > theoretically it could be different from the other version fields,
> > > > but I
> > > > don't know if it ever happens with real hardware.
> > > > 
> > > > If we don't want to support the case where Runtime Services have a
> > > > different revision version than the other tables, then I think that
> > > > going for the NULL Runtime Services table pointer approach might be
> > > > better.
> > > 
> > > Looking again at the spec, it includes this line:
> > > 
> > > #define EFI_RUNTIME_SERVICES_REVISION EFI_SPECIFICATION_VERSION
> > > 
> > > the only way I can read it is that the EFI Runtime Services version
> > > needs to match the EFI specification version.
> > > 
> > > Unfortunately it looks like that we cannot, according to spec, expose a
> > > different version of Runtime Services.
> > > 
> > > Given that trying to emulate a set of Runtime Services which matches
> > > the
> > > version of the ones on the host would be undesirable from Xen point of
> > > view, would it be OK if we went ahead and added to the Xen-Dom0
> > > interface on EFI, which we are about to introduce and document, that
> > > the
> > > Runtime Services table pointer can be NULL?
> > 
> > Mark, Christoffer and I had another chat.  Given that it is difficult to
> > provide a consistent set of tables to Dom0 (the Runtime Services version
> > could differ from the native tables version and that is not allowed by
> > the EFI spec), Mark would like to see EFI support being introduced in a
> > Xen specific manner in Dom0, so that it is very clear that it might
> > differ from the native EFI tables and spec.
> > 
> > This is what we need to do:
> > 
> > - xen_early_init() should be moved before efi_init() in
> >   arch/arm64/kernel/setup.c. This will cause the device tree parsing in
> >   xen_early_init to be changed because it will have to operate on the
> >   flatten device tree.
> > - xen_early_init should discover the EFI tables. It could do that via
> >   hypercalls or via device tree attributes under the Xen hypervisor node
> >   on device tree. The nodes under /chosen, described by
> >   Documentation/arm/uefi.txt, should not be reused.
> > - xen_early_init could call the efi initialization functions directly or
> >   could setup some data structures (to be defined) so that efi_init will
> >   later detect that we are r

Re: [Xen-devel] [OSSTEST PATCH 13/26] selecthost: Support nested hosts (guests which are also hosts)

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> We introduce a new syntax: instead of a hostname (which might appear
> in a command line argument to a ts-* script and hence be passed to
> selecthost, or which might be in a runvar), we now support
> :.
> 
> Such `hosts' (let us refer to such a thing as an L1, although in
> principle further nesting may be possible) are expected to be
> dynamically created.  So they do not have flags and properties in the
> configuration (or in an Executive instance's database).
> 
> The IP address is determined dynamically from the leases file.  If the
> L1 is not running, then no IP address may be found.  This is not an
> error.  Users of this facility will need to make sure that ts-*
> scripts which are unaware of the L1's special status are only invoked
> when it is known that the L1 is up and has obtained its IP address.
> 
> `Power cycling' the L1 will be done by VM control operations in the
> L0; this will come in a subsequent patch.
> 
> `Serial access' to the L1 guest will likewise need to be done via the
> console arrangements in L0.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 14/26] Nested hosts: Provide PDU power method

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> This `guest' power method uses VM create/destroy.  It is automatically
> used for nested hosts.  It would not make much sense to configure it
> manually.
> 
> For nested host/guest, its power on/off method shall be
> its host invoke $(toolstack)->create/destroy method.
> 
> XXX Missing Signed-off-by from Robert Hu
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

> ---
> v14: Mostly rewritten by iwj
> ---
>  Osstest/PDU/guest.pm   |   59
> 
>  Osstest/TestSupport.pm |2 +-
>  2 files changed, 60 insertions(+), 1 deletion(-)
>  create mode 100755 Osstest/PDU/guest.pm
> 
> diff --git a/Osstest/PDU/guest.pm b/Osstest/PDU/guest.pm
> new file mode 100755
> index 000..b6bf9a1
> --- /dev/null
> +++ b/Osstest/PDU/guest.pm
> @@ -0,0 +1,59 @@
> +# This is part of "osstest", an automated testing framework for Xen.
> +# Copyright (C) 2015 Intel.
> +# 
> +# This program is free software: you can redistribute it and/or modify
> +# it under the terms of the GNU Affero General Public License as
> published by
> +# the Free Software Foundation, either version 3 of the License, or
> +# (at your option) any later version.
> +# 
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU Affero General Public License for more details.
> +# 
> +# You should have received a copy of the GNU Affero General Public
> License
> +# along with this program.  If not, see .
> +
> +
> +package Osstest::PDU::guest;
> +
> +use strict;
> +use warnings;
> +use Switch;
> +
> +use Osstest;
> +use Osstest::TestSupport;
> +use IO::File;
> +
> +BEGIN {
> +use Exporter ();
> +our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
> +$VERSION = 1.00;
> +@ISA = qw(Exporter);
> +@EXPORT  = qw();
> +%EXPORT_TAGS = ( );
> +
> +@EXPORT_OK   = qw();
> +}
> +
> +sub new {
> +my ($class, $ho) = @_;
> +return bless { Target => $ho }, $class;
> +}
> +
> +sub pdu_power_state {
> +my ($mo, $on) = @_;
> +
> +my $child = $mo->{Target};
> +my $parent = $child->{Host};
> +die "$child->{Name} ?" unless $parent;
> +
> +logm("power $child->{Name} nested on $parent->{Name} ".($on+0));
> +if ($on) {
> + toolstack($parent)->create($child);
> +} else {
> + toolstack($parent)->destroy($child);
> +}
> +}
> +
> +1;
> diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> index 9b10602..3025c9f 100644
> --- a/Osstest/TestSupport.pm
> +++ b/Osstest/TestSupport.pm
> @@ -855,7 +855,7 @@ sub selecthost ($) {
>   $child->{Info} = [ "in", $parent->{Name}, @{ $parent->{Info} }
> ];
>   $child->{NestingLevel} = $parent->{NestingLevel}+1;
>  
> - # $child->{Power} = 'guest';   todo
> + $child->{Power} = 'guest';
>   power_cycle_host_setup($child);
>  
>   $child->{Properties}{Serial} = 'noop'; # todo

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

Re: [Xen-devel] [OSSTEST PATCH 15/26] DhcpWatch::leases: Fix a reporting message

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> This talks about `guest_check_ip', but this code is now factored out
> into a method.  Use the correct method name in reporting.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 17/26] await_tcp(): Run check_ip on each loop iteration

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> await_tcp is often invoked after a reboot.
> 
> In this situation the target's IP address may change.  If this happens
> while await_tcp is running, we would continue to poll the old IP address.
> Fix this by running target_check_ip on each iteration.
> 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

[Xen-devel] [OSSTEST PATCH] crontabs: Provide way to install crontabs, with a safety catch

[Ian Jackson]

With this setup you can say
  ./mg-crontab-install CRONTAB
or even
  ./crontab
  ./crontab-cambridge

And you can't accidentally install the intended crontab on the wrong
host, etc.  (As I did recently!)

Signed-off-by: Ian Jackson 
---
 crontab|3 +++
 crontab-cambridge  |3 +++
 mg-crontab-install |   28 
 3 files changed, 34 insertions(+)
 mode change 100644 => 100755 crontab
 mode change 100644 => 100755 crontab-cambridge
 create mode 100755 mg-crontab-install

diff --git a/crontab b/crontab
old mode 100644
new mode 100755
index b9d4ad1..6fd5704
--- a/crontab
+++ b/crontab
@@ -1,3 +1,6 @@
+#!/bin/bash ./mg-crontab-install
+#@@ osst...@osstest.test-lab.xenproject.org
+
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
 # mh   dom mon dow command
diff --git a/crontab-cambridge b/crontab-cambridge
old mode 100644
new mode 100755
index b45c0dd..2ababb0
--- a/crontab-cambridge
+++ b/crontab-cambridge
@@ -1,3 +1,6 @@
+#!/bin/bash ./mg-crontab-install
+#@@ osst...@osstest.xs.citrite.net
+
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com
 # mh   dom mon dow command
diff --git a/mg-crontab-install b/mg-crontab-install
new file mode 100755
index 000..5a59d45
--- /dev/null
+++ b/mg-crontab-install
@@ -0,0 +1,28 @@
+#!/bin/bash
+# usage: ./mg-crontab-install CRONTAB
+#
+# where CRONTAB is a file containing a line
+#  #@@ USER@HOSTFQDN
+
+set -e -o posix
+
+case "$#.$1" in
+1.[^-]*) crontab="$1"; shift ;;
+*) echo >&2 "bad usage"; exit 1 ;;
+esac
+
+expect="#@@ "
+expect+="`whoami`"
+expect+="@"
+expect+="`hostname -f`"
+
+if ! grep -xF "$expect" "$crontab" >/dev/null; then
+   exec >&2
+   echo "running as: $expect"
+   printf "file is for: "
+   grep '^#@@' "$crontab" || echo "no #@@ line?"
+   exit 2
+fi
+
+crontab "$crontab"
+echo "crontab installed ($expect)"
-- 
1.7.10.4


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

Re: [Xen-devel] [OSSTEST PATCH 16/26] target_check_ip: Rename and improve from guest_check_ip

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> Make this function suitable for running on targets with static IP
> addresses.  (Ie, on physical hosts.)  Accordingly, rename it and
> adjust all call sites.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

[Xen-devel] [PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Razvan Cojocaru]

A previous version of this patch dealing with support for skipping
the current instruction when a vm_event response requested it
computed the instruction length in the hypervisor, adding non-trivial
code dependencies. This patch allows a userspace vm_event client to
simply request that the guest's EIP is set to an arbitary value,
computed by the introspection application. The registers that can
now be set are EAX-EDX, ESP, EBP, ESI, EDI, R8-R15, EFLAGS, and EIP.
CR0, CR3 and CR4 are not set, as at the time of vm_event_resume()
we can't call hvm_set_cr{0,3,4}() and simply setting
v->arch.hvm_vcpu.guest_cr[{0,3,4}] is unlikely to have the desired
effect. The rest of the vm_event registers are not set because
they're not being filled by hvm_event_fill_regs(), but only by
p2m_vm_event_fill_regs().
The VCPU needs to be paused for this flag to take effect.

Signed-off-by: Razvan Cojocaru 

---
Changes since V2:
 - Now setting more registers than just EIP.
 - Updated the header comment to state cleary which registers are
   now affected.
---
 xen/arch/x86/vm_event.c|   24 
 xen/common/vm_event.c  |3 +++
 xen/include/asm-arm/vm_event.h |6 ++
 xen/include/asm-x86/vm_event.h |2 ++
 xen/include/public/vm_event.h  |6 ++
 5 files changed, 41 insertions(+)

diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index c38d37b..9677ecc 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -97,6 +97,30 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 }
 }
 
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
+{
+v->arch.user_regs.eax = rsp->data.regs.x86.rax;
+v->arch.user_regs.ebx = rsp->data.regs.x86.rbx;
+v->arch.user_regs.ecx = rsp->data.regs.x86.rcx;
+v->arch.user_regs.edx = rsp->data.regs.x86.rdx;
+v->arch.user_regs.esp = rsp->data.regs.x86.rsp;
+v->arch.user_regs.ebp = rsp->data.regs.x86.rbp;
+v->arch.user_regs.esi = rsp->data.regs.x86.rsi;
+v->arch.user_regs.edi = rsp->data.regs.x86.rdi;
+
+v->arch.user_regs.r8 = rsp->data.regs.x86.r8;
+v->arch.user_regs.r9 = rsp->data.regs.x86.r9;
+v->arch.user_regs.r10 = rsp->data.regs.x86.r10;
+v->arch.user_regs.r11 = rsp->data.regs.x86.r11;
+v->arch.user_regs.r12 = rsp->data.regs.x86.r12;
+v->arch.user_regs.r13 = rsp->data.regs.x86.r13;
+v->arch.user_regs.r14 = rsp->data.regs.x86.r14;
+v->arch.user_regs.r15 = rsp->data.regs.x86.r15;
+
+v->arch.user_regs.eflags = rsp->data.regs.x86.rflags;
+v->arch.user_regs.eip = rsp->data.regs.x86.rip;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index ef84b0f..e1f9580 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -417,6 +417,9 @@ void vm_event_resume(struct domain *d, struct 
vm_event_domain *ved)
 
 if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
 {
+if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
+vm_event_set_registers(v, &rsp);
+
 if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
 vm_event_toggle_singlestep(d, v);
 
diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index 976fdf1..4d0fbf7 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -47,4 +47,10 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
 /* Not supported on ARM. */
 }
 
+static inline
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
+{
+/* Not supported on ARM. */
+}
+
 #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 2ff2cab..5aff834 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -42,4 +42,6 @@ void vm_event_toggle_singlestep(struct domain *d, struct vcpu 
*v);
 
 void vm_event_register_write_resume(struct vcpu *v, vm_event_response_t *rsp);
 
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
+
 #endif /* __ASM_X86_VM_EVENT_H__ */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index ff2f217..3e4efad 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -89,6 +89,12 @@
  * by the altp2m_idx response field if possible.
  */
 #define VM_EVENT_FLAG_ALTERNATE_P2M  (1 << 7)
+/*
+ * Set the vCPU registers to the values in the  vm_event response.
+ * Applies to EAX-EDX, ESP, EBP, ESI, EDI, R8-R15, EFLAGS, and EIP.
+ * Requires the vCPU to be paused already (synchronous events only).
+ */
+#define VM_EVENT_FLAG_SET_REGISTERS  (1 << 8)
 
 /*
  * Reasons for the vm event request
-- 
1.7.9.5


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

Re: [Xen-devel] [PATCH] cleanup domain builder declarations and related users

[Wei Liu]

On Mon, Sep 28, 2015 at 07:02:29AM +0200, Juergen Gross wrote:
> There are several unused function and structure declarations in the
> hypervisor related to domain building. Remove them.
> 
> Use an enum for elf_dom_parms.pae instead of just hard coding the
> values when setting the information and adjust the code to use those
> instead of own macros (hypervisor and tools).
> 
> Signed-off-by: Juergen Gross 

Tools bits:

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH V3 0/2] Introspection optimization helpers

[Razvan Cojocaru]

Hello,

This series adds two minor patches. The first one allows finer-grained
control over the emulation behaviour of REP instructions. Previously,
once vm_event-based emulation was enabled, no optimizations were allowed.
However, this has a performance impact on the monitored guest, so I've
added a new libxc function to enable / disable this at will at any point.

The second patch addresses an older issue: in my initial series a few
years back, there was a (longish) patch that computed the length of the
current instruction, and advanced the instruction pointer past it if
it was required by the vm_event reply. However, integrating that code
has not been trivial, and so the second patch in this series simply
allows a vm_event reply to say that the instruction pointer should be
set to whatever value it sends back to the hypervisor. This way, the
computation of the instruction length is left to the userspace
application.

This version addresses comments received for the previous version,
the specific changes are described in the change log for each patch.

[PATCH V3 1/2] xen, libxc: Fine grained control of REP emulation
[PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS


Thanks,
Razvan

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

[Xen-devel] [PATCH V3 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Razvan Cojocaru]

Previously, if vm_event emulation support was enabled, then REP
optimizations were disabled when emulating REP-compatible
instructions. This patch allows fine-tuning of this behaviour by
providing a dedicated libxc helper function.

Signed-off-by: Razvan Cojocaru 
Acked-by: Ian Campbell 

---
Changes since V2:
 - Now only checking ->arch.mem_access_emulate_each_rep in
   hvmemul_virtual_to_linear() (previously was also checking
   ->arch.mem_access_emulate_enabled.
 - Disabling ->arch.mem_access_emulate_enabled when monitoring
   is disabled.
 - Changed the if()s in vm_event_resume() to a switch().
 - Added Ian Campbell's ack.
---
 tools/libxc/include/xenctrl.h |   12 
 tools/libxc/xc_monitor.c  |   13 +
 xen/arch/x86/hvm/emulate.c|2 +-
 xen/arch/x86/monitor.c|7 ++-
 xen/arch/x86/vm_event.c   |2 ++
 xen/include/asm-x86/domain.h  |1 +
 xen/include/public/domctl.h   |1 +
 7 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3482544..3bfa00b 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2428,6 +2428,18 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
  bool enable, bool sync);
 
+/**
+ * This function enables / disables emulation for each REP for a
+ * REP-compatible instruction.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domain_id the domain id one wants to get the node affinity of.
+ * @parm enable if 0 optimize when possible, else emulate each REP.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
+bool enable);
+
 /***
  * Memory sharing operations.
  *
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 065669c..b1705dd 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -143,3 +143,16 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id, bool enable,
 
 return do_domctl(xch, &domctl);
 }
+
+int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
+bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP;
+domctl.u.monitor_op.event = enable;
+
+return do_domctl(xch, &domctl);
+}
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 5934c72..39774b7 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -514,7 +514,7 @@ static int hvmemul_virtual_to_linear(
  * being triggered for repeated writes to a whole page.
  */
 *reps = min_t(unsigned long, *reps,
-  unlikely(current->domain->arch.mem_access_emulate_enabled)
+  unlikely(current->domain->arch.mem_access_emulate_each_rep)
? 1 : 4096);
 
 reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 3d52135..7611f7b 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -73,10 +73,15 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 if ( rc )
 return rc;
 
-if ( mop->op == XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES )
+switch ( mop->op )
 {
+case XEN_DOMCTL_MONITOR_OP_GET_CAPABILITIES:
 mop->event = capabilities;
 return 0;
+
+case XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP:
+d->arch.mem_access_emulate_each_rep = !!mop->event;
+return 0;
 }
 
 /*
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index e4e0aa4..c38d37b 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -54,6 +54,8 @@ void vm_event_cleanup_domain(struct domain *d)
 xfree(v->arch.vm_event);
 v->arch.vm_event = NULL;
 }
+
+d->arch.mem_access_emulate_each_rep = 0;
 }
 
 void vm_event_toggle_singlestep(struct domain *d, struct vcpu *v)
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f0aeade..f1d7ed6 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -386,6 +386,7 @@ struct arch_domain
 
 /* Mem_access emulation control */
 bool_t mem_access_emulate_enabled;
+bool_t mem_access_emulate_each_rep;
 } __cacheline_aligned;
 
 #define has_arch_pdevs(d)(!list_empty(&(d)->arch.pdev_list))
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 794d4d5..ae241f2 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1007,6 +1007,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cmt_op_t);
 #define XEN_DOMCTL_MONITOR_OP_ENABLE0
 #define XEN_DOMCTL_MONITOR_OP_DISABLE   1
 #define XEN_DOMCTL_

Re: [Xen-devel] [OSSTEST PATCH 18/26] LVM: Break out lv_create

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> We are going to want to reuse this.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 19/26] Toolstack::xl: Provide block_attach method

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> It is possible that this may work some of the time with xm, so I have
> taken no measures to prevent it running then.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [OSSTEST PATCH 20/26] sg-run-job: Break out per-host-prep and per-host-finish

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> No functional change.
> 
> We now call the per-host-ts finish steps unconditionally, rather than
> only if !$need_build_host, per-host-ts is (complicated) no-op if
> $need_build_host, since in that case $need_xen_hosts is {}.
> 
> Signed-off-by: Ian Jackson 
> Signed-off-by: Robert Ho 
> Tested by: Robert Ho 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 21/26] sg-run-job: Provide infrastructure for layers of nesting

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> Provides nested-layer-descend, which can be called in an individual
> test job at the appropriate point (after the L1 has been set up).
> 
> The inner host is a guest of the outer host; powering it off means
> destroying it.  Putting the poweroff at this point in the loop, rather
> than in per-host-finish, avoids powering off physical servers.  The
> use of `.'  rather than `!.' for iffail means we do not power off
> after failures (as we might want to preserve the state for debugging
> etc).
> 
> Signed-off-by: Ian Jackson 
> Tested-by: Robert Ho 
> Signed-off-by: Robert Ho 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@citrix.com]
> Sent: 28 September 2015 10:43
> To: Shameerali Kolothum Thodi; xen-de...@lists.xenproject.org
> Cc: Ian Campbell; Vijay Kilari
> Subject: Re: unknown gpa read address error for GICv3 re-distributor
> register access.
> 
> 
> 
> On 28/09/2015 09:36, Shameerali Kolothum Thodi wrote:
> > Hi All,
> 
> Hi,
> 
> 
> > I am working on enabling Xen on our HIPO5
> > board(http://lists.xenproject.org/archives/html/xen-users/2015-
> 07/msg0
> > 0090.html)
> >
> > Since the board has got GIC/ITS, tried this ITS  patch series
> (https://github.com/vijaykilari/its_v6/commits/stating_its_v6).
> 
> The ITS series is not upstream and unless your PCI device can't work
> without MSI I would advise you to first boot Xen and DOM0 without ITS.
> Once you have a working base, you can add the ITS series.
> 
> Although, use the latest version i.e v7:
> https://github.com/vijaykilari/its_v6/tree/staging_its_v7.

Sure. But I think as you mentioned below this is not related to ITS patch.

> 
> >
> > The board has got 16 cores. The dts file for the GIC is as below.
> >
> >
> >  gic: interrupt-controller@8d00 {
> >  compatible = "hisilicon,gic-v3";
> 
> This compatible string is not supported by Xen and below your log shows
> that your tree is dirty. What's the difference between staging and your
> tree?
> 
> >  #interrupt-cells = <3>;
> >  #address-cells = <2>;
> >  #size-cells = <2>;
> >  ranges;
> >  interrupt-controller;
> >  #redistributor-regions = <1>;
> >  redistributor-stride = <0x0 0x3>;
> 
> The GICv3 driver reads an 32 byte value for this field. It seems to be
> a mistake in our implementation (will send a patch for it).

Sorry, forgot to mention, I have the compatible string changes and stride size 
64 changes in the xen code.

> Although I don't think it's affecting your problem because Xen seems to
> retrieve the correct stride:
> 
>   (XEN) GICv3 initialization:
>   (XEN)   gic_dist_addr=0x008d00
>   (XEN)   gic_maintenance_irq=25
>   (XEN)   gic_rdist_stride=3
> 
> >  reg = <0x0 0x8d00 0 0x1>,   /* GICD */
> ><0x0 0x8d10 0 0x30>,  /* GICR c */
> ><0x0 0xfe00 0 0x1>,   /* GICC */
> ><0x0 0xfe01 0 0x1>,   /* GICH */
> ><0x0 0xfe02 0 0x1>;   /* GICV */
> >  interrupts = <1 9 0xff04>;
> 
> [...]
> 
> >  };
> >
> >
> > It has got the re-distributor base as 0x8d100 and stride size as
> 0x3.I have seen couple of issues that blocks my Dom0 boot attempt.
> The first issue is related to the Dom0 secondary cpu boot failure.
> >
> > This is what I believe is happening(Please correct me if my
> understanding is wrong).
> > -Dom0 make the CPU1 on.
> > -gic_secondary_init() -->gic_populate_rdist()  (irq-gic-v3.c)
> >
> > Here it tries to find the re-distributor address by reading the
> GICR_TYPER register.  Since we have the rdbase as 0x8d10 and stride
> size as 0x3, a read is issued at 0x8d130008.
> >
> > Please find the Xen log below(Full log is attached at the end).
> >
> > (XEN) d0v0: vGICR: unknown gpa read address 8d130008
> > (XEN) traps.c:2447:d0v1 HSR=0x93c08006 pc=0xffc00032362c
> > gva=0xff8b0008 gpa=0x008d130008
> > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill
> the idle task!
> > (XEN) DOM0: CPU1: failed to come online
> >
> > vgic_v3_rdistr_mmio_read()
> > {
> > 
> > v = get_vcpu_from_rdist(info->gpa, v, &offset);
> > 
> > }
> > I think the function returns the offset as 0x20008 and vcpu as 0,
> instead what I am expecting is offset 0x8 and vcpu 1.
> 
> It seems that you are right. To get the offset in the region, we use
> stride - 1 which will give 0x2 for your platform.
> 
> The code to get the vCPU is only valid when there is only a bit set in
> the stride.
> 
> I'm not sure if we can turn the mask into modulo and division. I will
> try to see how I can fix it.
>
Thanks for confirming this. Yes, the offset and base address calculation is 
wrong in our scenario.
I will have some workaround on this for now and move on to the staging_its_v7.
 
> Regards,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH] crontabs: Provide way to install crontabs, with a safety catch

[Ian Campbell]

On Mon, 2015-09-28 at 11:15 +0100, Ian Jackson wrote:
> With this setup you can say
>   ./mg-crontab-install CRONTAB
> or even
>   ./crontab
>   ./crontab-cambridge
> 
> And you can't accidentally install the intended crontab on the wrong
> host, etc.  (As I did recently!)
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Andrew Cooper]

On 28/09/15 11:16, Razvan Cojocaru wrote:
> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
> index ff2f217..3e4efad 100644
> --- a/xen/include/public/vm_event.h
> +++ b/xen/include/public/vm_event.h
> @@ -89,6 +89,12 @@
>   * by the altp2m_idx response field if possible.
>   */
>  #define VM_EVENT_FLAG_ALTERNATE_P2M  (1 << 7)
> +/*
> + * Set the vCPU registers to the values in the  vm_event response.
> + * Applies to EAX-EDX, ESP, EBP, ESI, EDI, R8-R15, EFLAGS, and EIP.
> + * Requires the vCPU to be paused already (synchronous events only).
> + */

The set registers are architecture specific, or will be if/when ARM
gains support.

It is fine to list the architecture specific bits here (as there are no
more appropriate places for it to live) but do explicitly call out that
the 2nd sentence in x86 specific.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 4/5] xen: remove unused macros from sched.h

[George Dunlap]

On Fri, Sep 25, 2015 at 12:54 PM, Juergen Gross  wrote:
> The macros num_cpupool_cpus() and domain_is_locked() aren't used by
> anyone. Remove them.
>
> Signed-off-by: Juergen Gross 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [OSSTEST PATCH 22/26] Nested HVM: Provide ts-nested-setup to help make L1 usable as a host

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> * Provide the L1 with some storage for its own guests' disks
> * Install some packages in the L1
> * Optionally, set a runvar defining the L1 for the rest of the job
> 
> The recipe is going to run ts-xen-install etc.
> 
> Signed-off-by: longtao.pang 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 23/26] Nested HVM: Provide test-nested recipe

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 24/26] Nested HVM: Add test job to appropriate flights

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> Signed-off-by: longtao.pang 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 

[...]
> +  job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested \
> +test-nested xl $xenarch $dom0arch $qemuu_runvar\
> +l1_image=debian-7.2.0-amd64-CD-1.iso   \
> +l1_vifmodel='e1000'\
> +l1_memsize='3072'  \
> +l1_enable_nestedhvm='true' \
> +l2_image=debian-7.2.0-amd64-CD-1.iso   \
> +bios=$bios \

This is a preexisting quirk, but I suppose this really ought to be
_bios. As it is it affects both l1 and l2, which is what we want.

Ian.


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

Re: [Xen-devel] [OSSTEST PATCH 25/26] ts-xen-install: Properly handle hosts without a static IP address

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> From: Robert Ho 
> 
> Check IpStatic, and if it is not set, provide a dhcp stanza in
> /etc/network/interfaces, rather than an `inet static' one.
> 
> This is necessary for L1 nested hosts, because they don't have a
> static IP address.
> 
> In principle this makes matters more correct for physical hosts
> without static IP addresses, but these are currently not supported
> by selecthost().
> 
> Signed-off-by: Robert Ho 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> This function does not (now) always undo the DHCP configuration.
> Sometimes it leaves it.  Its main function is to ensure that we have
> a bridge for use by guests.
> 
> So rename the function.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH v6 22/29] elfnotes: intorduce a new PHYS_ENTRY elfnote

[Roger Pau Monné]

El 21/09/15 a les 16.47, Jan Beulich ha escrit:
 On 04.09.15 at 14:09,  wrote:
>> --- a/xen/include/public/elfnote.h
>> +++ b/xen/include/public/elfnote.h
>> @@ -200,9 +200,18 @@
>>  #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
>>  
>>  /*
>> + * Physical entry point into the kernel.
>> + *
>> + * 32bit entry point into the kernel. Xen will use this entry point
>> + * in order to launch the guest kernel in 32bit protected mode
>> + * with paging disabled.
>> + */
>> +#define XEN_ELFNOTE_PHYS32_ENTRY 18
> 
> The comment reads as if this was the case for all kinds of guests,
> yet I suppose it doesn't apply to PV ones. This should be made
> explicit if so.

Yes, what about the following:

32bit entry point into the kernel. Xen will use this entry point
in order to launch the guest kernel in 32bit protected mode with paging
disabled inside of an HVM container.

Roger.


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

Re: [Xen-devel] [PATCH v7 21/28] xen/arm: ITS: Add GICR register emulation

[Vijay Kilari]

On Mon, Sep 28, 2015 at 3:23 PM, Ian Campbell  wrote:
> On Sat, 2015-09-26 at 21:38 +0530, Vijay Kilari wrote:
>
>>  LPI property table is accessed in interrupt context. So interrupts
>> are disabled.
>
> Interrupts a reenabled while handling an interrupt, so a higher priority
> interrupt can still interrupt things.
>
> See the use of local_irq_enable in gic_interrupt.

true, for this reason, I have taken spin lock with disabled
interrrupts when reading guest LPI table.

Question is to avoid disabling interrupts for a  long time for about 8K/16K lpis
state update.

The LPI state update from guest LPI property table is done when guest
updates GICR_CTLR.EnableLPIs to 1.
(I am doing this in next revision).

So we can make a check for guest's GICR_CTLR.EnableLPIs field before
injecting LPIs to the domain. As per design
GICR_CTLR.EnableLPIs should be 0 when updating guest property table.
i.e updating GICR_PROPBASER.
So that we don't need to disable interrupts(LPIs are already disabled)
while reading guest LPI table.

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

Re: [Xen-devel] [PATCH V3 1/2] xen, libxc: Fine grained control of REP emulation optimizations

[Andrew Cooper]

On 28/09/15 11:16, Razvan Cojocaru wrote:
> Previously, if vm_event emulation support was enabled, then REP
> optimizations were disabled when emulating REP-compatible
> instructions. This patch allows fine-tuning of this behaviour by
> providing a dedicated libxc helper function.
>
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Ian Campbell 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH] x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

[Malcolm Crossley]

Sanitizing the e820 map may produce extra E820 entries which would result in
the topmost E820 entries being removed. The removed entries would typically
include the top E820 usable RAM region and thus result in the domain having
signicantly less RAM available to it.

Fix by allowing sanitize_e820_map to use the full size of the allocated E820
array.

Signed-off-by: Malcolm Crossley 
---
 arch/x86/xen/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index f5ef674..415a55f 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -798,7 +798,7 @@ char * __init xen_memory_setup(void)
xen_ignore_unusable();
 
/* Make sure the Xen-supplied memory map is well-ordered. */
-   sanitize_e820_map(xen_e820_map, xen_e820_map_entries,
+   sanitize_e820_map(xen_e820_map, ARRAY_SIZE(xen_e820_map),
  &xen_e820_map_entries);
 
max_pages = xen_get_max_pages();
-- 
1.7.12.4


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

Re: [Xen-devel] [OSSTEST PATCH v14 PART 2 10-26/26] Nested HVM testing

[Ian Campbell]

On Fri, 2015-09-25 at 20:15 +0100, Ian Jackson wrote:
> Ian Campbell: You probably want to defer re-reviewing this until
> Robert reports back.

I really ought to have started by reading this intro mail. Oh well.



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

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 38084: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 38084 qemu-upstream-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38084/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c
baseline version:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0

Last test of basis38063  2015-09-25 17:07:36 Z2 days
Testing same since38084  2015-09-27 08:50:46 Z1 days1 attempts


People who touched revisions under test:

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 pass
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-xl-raw  pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-i386-libvirt-vhd  pass
 test-amd64-amd64-xl-vhd  pass
 test-amd64-i386-xl-vhd   pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



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

Logs, config files, etc. are avai

Re: [Xen-devel] [PATCH v1 5/8] xen/arm: vgic: Optimize the way to store GICD_IPRIORITYR in the rank

[Ian Campbell]

On Fri, 2015-09-25 at 15:51 +0100, Julien Grall wrote:
> Xen is currently directly storing the value of register GICD_IPRIORITYR

"of the GICD_... register"

> in the rank. This makes emulation of the register access very simple
> but makes the code to get the priority for a given IRQ more complex.
> 
> While the priority of an IRQ is retrieved everytime an IRQ is injected

"every time".

> to the guest, the access to register occurs less often.
> 
> So the data structure should be optimized for the most common case
> rather than the inverse.
> 
> This patch introduces the usage of an array to store the priority for
> every interrupt in the rank. This will make the code to get the priority
> very quick. The emulation code will now have to generate the
> GICD_PRIORITYR
> register for read access and split it to store in a convenient way.
> 
> Signed-off-by: Julien Grall 
> ---
> 
> The real reason is I'd like to drop vgic_byte_* helpers in favors of more
> generic access helper. Although it would make the code to retrieve the
> priority more complex. So reworking the way to get the priority was the
> best solution.
> 
> Changes in v2:
> - Patch added
> ---
>  xen/arch/arm/vgic-v2.c | 24 ++--
>  xen/arch/arm/vgic-v3.c | 27 ---
>  xen/arch/arm/vgic.c| 46
> ++
>  xen/include/asm-arm/vgic.h | 18 +-
>  4 files changed, 93 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index 47f9da9..23d1982 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -139,8 +139,8 @@ static int vgic_v2_distr_mmio_read(struct vcpu *v, 
> mmio_info_t *info,
>  if ( rank == NULL) goto read_as_zero;
>  
>  vgic_lock_rank(v, rank, flags);
> -*r = rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR,
> -DABT_WORD)];
> +/* Recreate the IPRIORITYR register */
> +*r = vgic_generate_ipriorityr(rank, gicd_reg - GICD_IPRIORITYR);
>  if ( dabt.size == DABT_BYTE )
>  *r = vgic_byte_read(*r, gicd_reg);
>  vgic_unlock_rank(v, rank, flags);
> @@ -400,18 +400,25 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, 
> mmio_info_t *info,
>  }
>  
>  case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
> +{
> +uint32_t ipriorityr;
> +
>  if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto 
> bad_width;
>  rank = vgic_rank_offset(v, 8, gicd_reg - GICD_IPRIORITYR, DABT_WORD);
>  if ( rank == NULL) goto write_ignore;
>  vgic_lock_rank(v, rank, flags);
>  if ( dabt.size == DABT_WORD )
> -rank->ipriority[REG_RANK_INDEX(8, gicd_reg - GICD_IPRIORITYR,
> -   DABT_WORD)] = r;
> +ipriorityr = r;
>  else
> -vgic_byte_write(&rank->ipriority[REG_RANK_INDEX(8,
> -gicd_reg - GICD_IPRIORITYR, DABT_WORD)], r, 
> gicd_reg);
> +{
> +ipriorityr = vgic_generate_ipriorityr(rank,
> +  gicd_reg - 
> GICD_IPRIORITYR);
> +vgic_byte_write(&ipriorityr, r, gicd_reg);
> +}
> +vgic_store_ipriorityr(rank, gicd_reg - GICD_IPRIORITYR, ipriorityr);
>  vgic_unlock_rank(v, rank, flags);
>  return 1;
> +}
>  
>  case GICD_ICFGR: /* SGIs */
>  goto write_ignore_32;
> @@ -516,14 +523,11 @@ static struct vcpu *vgic_v2_get_target_vcpu(struct vcpu 
> *v, unsigned int irq)
>  
>  static int vgic_v2_get_irq_priority(struct vcpu *v, unsigned int irq)
>  {
> -int priority;
>  struct vgic_irq_rank *rank = vgic_rank_irq(v, irq);
>  
>  ASSERT(spin_is_locked(&rank->lock));
> -priority = vgic_byte_read(rank->ipriority[REG_RANK_INDEX(8,
> -  irq, DABT_WORD)], irq & 0x3);
>  
> -return priority;
> +return rank->priority[irq & INTERRUPT_RANK_MASK];
>  }
>  
>  static int vgic_v2_vcpu_init(struct vcpu *v)
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index c013200..2787507 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -430,18 +430,26 @@ static int __vgic_v3_distr_common_mmio_write(const char 
> *name, struct vcpu *v,
>  return 0;
>  
>  case GICD_IPRIORITYR ... GICD_IPRIORITYRN:
> +{
> +uint32_t ipriorityr;
> +
>  if ( dabt.size != DABT_BYTE && dabt.size != DABT_WORD ) goto 
> bad_width;
>  rank = vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
> -if ( rank == NULL ) goto write_ignore;
> +if ( rank == NULL) goto write_ignore;
> +
>  vgic_lock_rank(v, rank, flags);
>  if ( dabt.size == DABT_WORD )
> -rank->ipriority[REG_RANK_INDEX(8, reg - GICD_IPRIORITYR,
> -  

[Xen-devel] Fwd: Contributing to Xen for Outreachy 2015

[Shivangi Dhir]

Hi,

I am an Outreachy 2015 Applicant. I have a background in C, C++ and shell
scripting. I am also familiar with concepts of Operating Systems.

I would like to contribute to the Xen project and it would be very helpful
if I could get some help getting started.

I have gone through the beginner's guide [0] and cloned the git repository
[1].

-- 
Regards,
Shivangi Dhir

[0] http://wiki.xenproject.org/wiki/Xen_Beginners_Guide
[1] git://xenbits.xen.org/xen.git
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/13] Add VMX TSC scaling support

[Andrew Cooper]

On 28/09/15 08:13, Haozhong Zhang wrote:
> This patchset adds support for VMX TSC scaling feature which is
> available on Intel Skylake CPU. The specification of VMX TSC scaling
> can be found at
> http://www.intel.com/content/www/us/en/processors/timestamp-counter-scaling-virtualization-white-paper.html
>
> VMX TSC scaling allows guest TSC which is read by guest rdtsc(p)
> instructions increases in a rate that is customized by the hypervisor
> and can be different than the host TSC rate. Basically, VMX TSC
> scaling adds a 64-bit field called TSC multiplier in VMCS so that, if
> VMX TSC scaling is enabled, TSC read by guest rdtsc(p) instructions
> will be calculated by the following formula:
>
>   guest EDX:EAX = (Host TSC * TSC multiplier) >> 48 + VMX TSC Offset
>
> where, Host TSC = Host MSR_IA32_TSC + Host MSR_IA32_TSC_ADJUST.
>
> This patchset is composed of following four parts.
>   1. PATCH 01 - 02 fix bugs in tsc_get_info() which could result in
>  errors when VMX TSC scaling is used.
>  
>   2. PATCH 03 - 09 add/move the common parts of VMX TSC scaling and
>  SVM TSC ratio to hvm.c and x86/time.c.
>  
>   3. PATCH 10 - 12 implement the VMX-specific code for supporting VMX
>  TSC scaling.
>  
>   4. PATCH 13 adapts libxl for VMX TSC scaling (as well as SVM TSC
>  ratio).

Thankyou for this series.  I have had a brief look over it and it
appears to be in good shape, but have not done a thorough review yet.

Konrad/Boris: As Oracle are the main users of the more interesting guest
timing modes, do you have tests to verify correct functioning?

~Andrew

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

Re: [Xen-devel] [PATCH v1 5/8] xen/arm: vgic: Optimize the way to store GICD_IPRIORITYR in the rank

[Ian Campbell]

On Fri, 2015-09-25 at 15:51 +0100, Julien Grall wrote:

>  rank = vgic_rank_offset(v, 8, reg - GICD_IPRIORITYR, DABT_WORD);
> -if ( rank == NULL ) goto write_ignore;
> +if ( rank == NULL) goto write_ignore;

Accidental change I think.


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

Re: [Xen-devel] [PATCH v6 22/29] elfnotes: intorduce a new PHYS_ENTRY elfnote

[Jan Beulich]

>>> On 28.09.15 at 12:35,  wrote:
> El 21/09/15 a les 16.47, Jan Beulich ha escrit:
> On 04.09.15 at 14:09,  wrote:
>>> --- a/xen/include/public/elfnote.h
>>> +++ b/xen/include/public/elfnote.h
>>> @@ -200,9 +200,18 @@
>>>  #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
>>>  
>>>  /*
>>> + * Physical entry point into the kernel.
>>> + *
>>> + * 32bit entry point into the kernel. Xen will use this entry point
>>> + * in order to launch the guest kernel in 32bit protected mode
>>> + * with paging disabled.
>>> + */
>>> +#define XEN_ELFNOTE_PHYS32_ENTRY 18
>> 
>> The comment reads as if this was the case for all kinds of guests,
>> yet I suppose it doesn't apply to PV ones. This should be made
>> explicit if so.
> 
> Yes, what about the following:
> 
> 32bit entry point into the kernel. Xen will use this entry point
> in order to launch the guest kernel in 32bit protected mode with paging
> disabled inside of an HVM container.

Depends: If the note's presence means this and only this entry point
will be used, then okay. If, however, normal PV and/or HVM operation
of such a guest is still intended to be possible, then I think this is still
too vague. Perhaps

32bit entry point into the kernel. When requested to launch the
guest kernel in a HVM container, Xen will use this entry point to
launch the guest in 32bit protected mode with paging disabled.
Ignored otherwise.

Jan


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

Re: [Xen-devel] [PATCH v6 22/29] elfnotes: intorduce a new PHYS_ENTRY elfnote

[Andrew Cooper]

On 28/09/15 11:56, Jan Beulich wrote:
 On 28.09.15 at 12:35,  wrote:
>> El 21/09/15 a les 16.47, Jan Beulich ha escrit:
>> On 04.09.15 at 14:09,  wrote:
 --- a/xen/include/public/elfnote.h
 +++ b/xen/include/public/elfnote.h
 @@ -200,9 +200,18 @@
  #define XEN_ELFNOTE_SUPPORTED_FEATURES 17
  
  /*
 + * Physical entry point into the kernel.
 + *
 + * 32bit entry point into the kernel. Xen will use this entry point
 + * in order to launch the guest kernel in 32bit protected mode
 + * with paging disabled.
 + */
 +#define XEN_ELFNOTE_PHYS32_ENTRY 18
>>> The comment reads as if this was the case for all kinds of guests,
>>> yet I suppose it doesn't apply to PV ones. This should be made
>>> explicit if so.
>> Yes, what about the following:
>>
>> 32bit entry point into the kernel. Xen will use this entry point
>> in order to launch the guest kernel in 32bit protected mode with paging
>> disabled inside of an HVM container.
> Depends: If the note's presence means this and only this entry point
> will be used, then okay. If, however, normal PV and/or HVM operation
> of such a guest is still intended to be possible, then I think this is still
> too vague. Perhaps
>
> 32bit entry point into the kernel. When requested to launch the
> guest kernel in a HVM container, Xen will use this entry point to
> launch the guest in 32bit protected mode with paging disabled.
> Ignored otherwise.

A multi-mode binary seems very likely, certainly for the near future.

As such, this param is an indication of supporting DMLite.  The guest
kernel knows it was started in DMLite mode if this is the entry point used.

If another entry point is used, the guest was not started in DMLite mode.

~Andrew

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

Re: [Xen-devel] [PATCH v7 21/28] xen/arm: ITS: Add GICR register emulation

[Julien Grall]

On 28/09/15 11:37, Vijay Kilari wrote:
> On Mon, Sep 28, 2015 at 3:23 PM, Ian Campbell  wrote:
>> On Sat, 2015-09-26 at 21:38 +0530, Vijay Kilari wrote:
>>
>>>  LPI property table is accessed in interrupt context. So interrupts
>>> are disabled.
>>
>> Interrupts a reenabled while handling an interrupt, so a higher priority
>> interrupt can still interrupt things.
>>
>> See the use of local_irq_enable in gic_interrupt.
> 
> true, for this reason, I have taken spin lock with disabled
> interrrupts when reading guest LPI table.
> 
> Question is to avoid disabling interrupts for a  long time for about 8K/16K 
> lpis
> state update.

Why only 8K/16K LPIs? From the ITS spec, the number of LPIs is encoded
on 32bit so it would be possible to have 500K LPIs...

> The LPI state update from guest LPI property table is done when guest
> updates GICR_CTLR.EnableLPIs to 1.
> (I am doing this in next revision).
> 
> So we can make a check for guest's GICR_CTLR.EnableLPIs field before
> injecting LPIs to the domain. As per design
> GICR_CTLR.EnableLPIs should be 0 when updating guest property table.
> i.e updating GICR_PROPBASER.

GICR_CTLR is per vCPU and the property table is per domain. How would
you know when to parse the property table?

> So that we don't need to disable interrupts(LPIs are already disabled)
> while reading guest LPI table.

That won't help. As already said on a previous mail, it was for command
emulation, the vCPU will monopolize the physical CPU for a very long
time. That means that no other vCPU can run this physical CPU.

I think the best solution would be tasklet which will divide the parsing
in small chunk. This would avoid to get Xen stuck on the physical CPU
for a long time.

A tasklet would be created when GICR_PROPBASER is written. Any vCPU
sending an INV command would get block until the tasklet is finished.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Julien Grall]

On 28/09/15 11:24, Shameerali Kolothum Thodi wrote:
>>> I am working on enabling Xen on our HIPO5
>>> board(http://lists.xenproject.org/archives/html/xen-users/2015-
>> 07/msg0
>>> 0090.html)
>>>
>>> Since the board has got GIC/ITS, tried this ITS  patch series
>> (https://github.com/vijaykilari/its_v6/commits/stating_its_v6).
>>
>> The ITS series is not upstream and unless your PCI device can't work
>> without MSI I would advise you to first boot Xen and DOM0 without ITS.
>> Once you have a working base, you can add the ITS series.
>>
>> Although, use the latest version i.e v7:
>> https://github.com/vijaykilari/its_v6/tree/staging_its_v7.
> 
> Sure. But I think as you mentioned below this is not related to ITS patch.

Well, we are not free from an other error in the GICv3 code ;).

>>
>>>
>>> The board has got 16 cores. The dts file for the GIC is as below.
>>>
>>>
>>>  gic: interrupt-controller@8d00 {
>>>  compatible = "hisilicon,gic-v3";
>>
>> This compatible string is not supported by Xen and below your log shows
>> that your tree is dirty. What's the difference between staging and your
>> tree?
>>
>>>  #interrupt-cells = <3>;
>>>  #address-cells = <2>;
>>>  #size-cells = <2>;
>>>  ranges;
>>>  interrupt-controller;
>>>  #redistributor-regions = <1>;
>>>  redistributor-stride = <0x0 0x3>;
>>
>> The GICv3 driver reads an 32 byte value for this field. It seems to be
>> a mistake in our implementation (will send a patch for it).
> 
> Sorry, forgot to mention, I have the compatible string changes and stride 
> size 64 changes in the xen code.

Can you send the patch to fix the stride size change? As it should be
fairly small, we may be able to get this into Xen 4.6.

I'm not sure it will be the case for the other bug.


Regards,

-- 
Julien Grall

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

Re: [Xen-devel] unknown gpa read address error for GICv3 re-distributor register access.

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@citrix.com]
> Sent: 28 September 2015 12:11
> To: Shameerali Kolothum Thodi; xen-de...@lists.xenproject.org
> Cc: Ian Campbell; Vijay Kilari
> Subject: Re: unknown gpa read address error for GICv3 re-distributor
> register access.
> 
> 
> Can you send the patch to fix the stride size change? As it should be
> fairly small, we may be able to get this into Xen 4.6.

Ok. I will do that.

> I'm not sure it will be the case for the other bug.
> 
> 
> Regards,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/3] x86: further P2M adjustments

[Jan Beulich]

>>> On 21.09.15 at 15:57,  wrote:
> 1: p2m: tighten conditions of IOMMU mapping updates
> 2: p2m-pt: use pre-calculated IOMMU flags
> 3: p2m-ept: adjust some types in ept_set_entry()
> 
> Signed-off-by: Jan Beulich 

George,

any chance I could get an ack or otherwise on this series? Despite
the open question raised in patch 1 I think rather than rev-ing that
patch we should follow up with another one, should further
adjustments indeed turn out necessary.

Thanks, Jan


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

Re: [Xen-devel] Fwd: Contributing to Xen for Outreachy 2015

[Julien Grall]

On 28/09/15 11:50, Shivangi Dhir wrote:
> Hi,

Hello,

> I am an Outreachy 2015 Applicant. I have a background in C, C++ and
> shell scripting. I am also familiar with concepts of Operating Systems.
> 
> I would like to contribute to the Xen project and it would be very
> helpful if I could get some help getting started.
> 
> I have gone through the beginner's guide [0] and cloned the git
> repository [1].

To complete your application, you have to pick up to make a small
contribution to Xen [1].

We don't seem to have many small task on bugs.xenproject.org/xen, so
I've CCed a few people who may know if we have small coverity issue to fix.

Regards,

[1] http://wiki.xenproject.org/wiki/Outreachy/Round11

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 13/13] tools/libxl: Add 'vtsc_khz' option to set guest TSC rate

[Julien Grall]

Hi,

On 28/09/15 08:13, Haozhong Zhang wrote:
> This patch adds an option 'vtsc_khz' to allow users to set vcpu's TSC
> rate in KHz. In the case that tsc_mode = 'default', the default value of
> 'vtsc_khz' option is the host TSC rate which is used when 'vtsc_khz'
> option is set to 0 or does not appear in the configuration. In all other
> cases of tsc_mode, 'vtsc_khz' option is just ignored.
> 
> Another purpose of adding this option is to keep vcpu's TSC rate across
> guest reboot. In existing code, a new domain is created from the
> configuration of the previous domain which was just rebooted. vcpu's TSC
> rate is not stored in the configuration and the host TSC rate is the
> used as vcpu's TSC rate. This works fine unless the previous domain was
> migrated from another host machine with a different host TSC rate than
> the current one.
> 
> Signed-off-by: Haozhong Zhang 
> ---
>  tools/libxl/libxl_types.idl |  1 +
>  tools/libxl/libxl_x86.c |  4 +++-
>  tools/libxl/xl_cmdimpl.c| 22 ++
>  3 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 9f6ec00..91cb0be 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -413,6 +413,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
>  ("vcpu_soft_affinity", Array(libxl_bitmap, "num_vcpu_soft_affinity")),
>  ("numa_placement",  libxl_defbool),
>  ("tsc_mode",libxl_tsc_mode),
> +("vtsc_khz",uint32),

This is x86 specific, can we begin to move anything arch-specific under
arch_foo? See arch_arm for instance.

Also, you would need to add a new define LIBXL_HAVE_foo to let allow
developer writing app on top of libxl support multiple version of Xen.
See libxl.h

>  ("max_memkb",   MemKB),
>  ("target_memkb",MemKB),
>  ("video_memkb", MemKB),
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index 896f34c..7baaee4 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -276,6 +276,7 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> libxl_domain_config *d_config,
>  {
>  int ret = 0;
>  int tsc_mode;
> +uint32_t vtsc_khz;
>  uint32_t rtc_timeoffset;
>  libxl_ctx *ctx = libxl__gc_owner(gc);
>  
> @@ -300,7 +301,8 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> libxl_domain_config *d_config,
>  default:
>  abort();
>  }
> -xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
> +vtsc_khz = d_config->b_info.vtsc_khz;
> +xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, vtsc_khz, 0);
>  if (libxl_defbool_val(d_config->b_info.disable_migrate))
>  xc_domain_disable_migrate(ctx->xch, domid);
>  rtc_timeoffset = d_config->b_info.rtc_timeoffset;
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 2706759..5fabda7 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1462,6 +1462,28 @@ static void parse_config_data(const char 
> *config_source,
>  }
>  }
>  
> +/* "vtsc_khz" option works only if "tsc_mode" option is
> + * "default". In this case, if "vtsc_khz" option is set to 0, we
> + * will reset it to the host TSC rate. In all other cases, we just
> + * ignore any given value and always set it to 0.
> + */
> +if (!xlu_cfg_get_long(config, "vtsc_khz", &l, 0))

This option has to be documented docs/man/xl.cfg.pod.5.

> +b_info->vtsc_khz = l;
> +if (b_info->tsc_mode == LIBXL_TSC_MODE_DEFAULT) {
> +if (b_info->vtsc_khz == 0) {
> +libxl_physinfo physinfo;
> +if (!libxl_get_physinfo(ctx, &physinfo))
> +b_info->vtsc_khz = physinfo.cpu_khz;
> +else
> +fprintf(stderr, "WARNING: cannot get host TSC rate.\n");
> +}
> +} else {
> +fprintf(stderr, "WARNING: ignoring \"vtsc_khz\" option. "
> +"\"vtsc_khz\" option works only if "
> +"\"tsc_mode\" option is \"default\".\n");
> +b_info->vtsc_khz = 0;
> +}
> +
>  if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0))
>  b_info->rtc_timeoffset = l;
>  
> 

Regards,


-- 
Julien Grall

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

[Xen-devel] [PATCH for Xen 4.6 2/5] tools/libxl: fix socket display error for CMT

[Chao Peng]

When displaying the CMT information for all the sockets, we assume socket
number is continuous. This is not true in the hotplug case. For instance,
when the 3rd socket is plugged out on a 4-socket system, the available
sockets numbers are 1,2,4 but current we will display the CMT
information for socket 1,2,3.

The fix is getting the socket bitmap for all the sockets on the system
first and then displaying CMT information for_each_set_bit in that bitmap.

Signed-off-by: Chao Peng 
---
 tools/libxl/xl_cmdimpl.c | 42 ++
 1 file changed, 22 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2706759..c72d3df 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -8192,7 +8192,7 @@ static int psr_cmt_get_mem_bandwidth(uint32_t domid,
 
 static void psr_cmt_print_domain_info(libxl_dominfo *dominfo,
   libxl_psr_cmt_type type,
-  uint32_t nr_sockets)
+  libxl_bitmap *socketmap)
 {
 char *domain_name;
 uint32_t socketid;
@@ -8205,7 +8205,7 @@ static void psr_cmt_print_domain_info(libxl_dominfo 
*dominfo,
 printf("%-40s %5d", domain_name, dominfo->domid);
 free(domain_name);
 
-for (socketid = 0; socketid < nr_sockets; socketid++) {
+libxl_for_each_set_bit(socketid, *socketmap) {
 switch (type) {
 case LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY:
 if (!libxl_psr_cmt_get_sample(ctx, dominfo->domid, type, socketid,
@@ -8228,9 +8228,9 @@ static void psr_cmt_print_domain_info(libxl_dominfo 
*dominfo,
 
 static int psr_cmt_show(libxl_psr_cmt_type type, uint32_t domid)
 {
-uint32_t i, socketid, nr_sockets, total_rmid;
+uint32_t i, socketid, total_rmid;
 uint32_t l3_cache_size;
-libxl_physinfo info;
+libxl_bitmap socketmap;
 int rc, nr_domains;
 
 if (!libxl_psr_cmt_enabled(ctx)) {
@@ -8244,41 +8244,38 @@ static int psr_cmt_show(libxl_psr_cmt_type type, 
uint32_t domid)
 return -1;
 }
 
-libxl_physinfo_init(&info);
-rc = libxl_get_physinfo(ctx, &info);
+libxl_socket_bitmap_alloc(ctx, &socketmap, 0);
+rc = libxl_socket_bitmap_fill(ctx, &socketmap);
 if (rc < 0) {
-fprintf(stderr, "Failed getting physinfo, rc: %d\n", rc);
-libxl_physinfo_dispose(&info);
-return -1;
+fprintf(stderr, "Failed getting available sockets, rc: %d\n", rc);
+goto out;
 }
-nr_sockets = info.nr_cpus / info.threads_per_core / info.cores_per_socket;
-libxl_physinfo_dispose(&info);
 
 rc = libxl_psr_cmt_get_total_rmid(ctx, &total_rmid);
 if (rc < 0) {
 fprintf(stderr, "Failed to get max RMID value\n");
-return -1;
+goto out;
 }
 
 printf("Total RMID: %d\n", total_rmid);
 
 /* Header */
 printf("%-40s %5s", "Name", "ID");
-for (socketid = 0; socketid < nr_sockets; socketid++)
+libxl_for_each_set_bit(socketid, socketmap)
 printf("%14s %d", "Socket", socketid);
 printf("\n");
 
 if (type == LIBXL_PSR_CMT_TYPE_CACHE_OCCUPANCY) {
 /* Total L3 cache size */
 printf("%-46s", "Total L3 Cache Size");
-for (socketid = 0; socketid < nr_sockets; socketid++) {
+libxl_for_each_set_bit(socketid, socketmap) {
 rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid,
  &l3_cache_size);
 if (rc < 0) {
 fprintf(stderr,
 "Failed to get system l3 cache size for 
socket:%d\n",
 socketid);
-return -1;
+goto out;
 }
 printf("%13u KB", l3_cache_size);
 }
@@ -8292,9 +8289,10 @@ static int psr_cmt_show(libxl_psr_cmt_type type, 
uint32_t domid)
 libxl_dominfo_init(&dominfo);
 if (libxl_domain_info(ctx, &dominfo, domid)) {
 fprintf(stderr, "Failed to get domain info for %d\n", domid);
-return -1;
+rc = -1;
+goto out;
 }
-psr_cmt_print_domain_info(&dominfo, type, nr_sockets);
+psr_cmt_print_domain_info(&dominfo, type, &socketmap);
 libxl_dominfo_dispose(&dominfo);
 }
 else
@@ -8302,13 +8300,17 @@ static int psr_cmt_show(libxl_psr_cmt_type type, 
uint32_t domid)
 libxl_dominfo *list;
 if (!(list = libxl_list_domain(ctx, &nr_domains))) {
 fprintf(stderr, "Failed to get domain info for domain list.\n");
-return -1;
+rc = -1;
+goto out;
 }
 for (i = 0; i < nr_domains; i++)
-psr_cmt_print_domain_info(list + i, type, nr_sockets);
+psr_cmt_print_domain_info(list + i, type, &socketmap);
 libxl_dominfo_list_free(list, nr_domains);
 }
-return 0;
+
+out:
+   

[Xen-devel] [PATCH for Xen 4.6 1/5] tools/libxl: introduce libxl_socket_bitmap_fill

[Chao Peng]

It sets the bit on the given bitmap if the corresponding socket is
available and clears the bit when the corresponding socket is not
available.

Signed-off-by: Chao Peng 
---
 tools/libxl/libxl.h   |  7 ---
 tools/libxl/libxl_utils.c | 21 +
 tools/libxl/libxl_utils.h |  2 ++
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 5f9047c..5a91687 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -807,11 +807,12 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
libxl_mac *src);
 #define LIBXL_HAVE_PCITOPOLOGY 1
 
 /*
- * LIBXL_HAVE_SOCKET_BITMAP_ALLOC
+ * LIBXL_HAVE_SOCKET_BITMAP
  *
- * If this is defined, then libxl_socket_bitmap_alloc exists.
+ * If this is defined, then libxl_socket_bitmap_alloc and
+ * libxl_socket_bitmap_Fill exist.
  */
-#define LIBXL_HAVE_SOCKET_BITMAP_ALLOC 1
+#define LIBXL_HAVE_SOCKET_BITMAP 1
 
 /*
  * LIBXL_HAVE_SRM_V2
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index bfc9699..557f279 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -886,6 +886,27 @@ int libxl_socket_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap 
*socketmap,
 
 }
 
+int libxl_socket_bitmap_fill(libxl_ctx *ctx, libxl_bitmap *socketmap)
+{
+libxl_cputopology *tinfo = NULL;
+int nr_cpus = 0, i, rc = 0;
+
+tinfo = libxl_get_cpu_topology(ctx, &nr_cpus);
+if (tinfo == NULL) {
+rc = ERROR_FAIL;
+goto out;
+}
+
+libxl_bitmap_set_none(socketmap);
+for (i = 0; i < nr_cpus; i++)
+if (tinfo[i].socket != XEN_INVALID_SOCKET_ID
+&& !libxl_bitmap_test(socketmap, tinfo[i].socket))
+libxl_bitmap_set(socketmap, tinfo[i].socket);
+ out:
+libxl_cputopology_list_free(tinfo, nr_cpus);
+return rc;
+
+}
 int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
 const libxl_bitmap *nodemap,
 libxl_bitmap *cpumap)
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 1e5ca8a..b55099a 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -143,6 +143,8 @@ int libxl_node_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap 
*nodemap,
 int max_nodes);
 int libxl_socket_bitmap_alloc(libxl_ctx *ctx, libxl_bitmap *socketmap,
   int max_sockets);
+/* Fill socketmap with the CPU topology information on the system. */
+int libxl_socket_bitmap_fill(libxl_ctx *ctx, libxl_bitmap *socketmap);
 
 /* Populate cpumap with the cpus spanned by the nodes in nodemap */
 int libxl_nodemap_to_cpumap(libxl_ctx *ctx,
-- 
1.9.1


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

[Xen-devel] [PATCH for Xen 4.6 0/5] Several PSR fixes in libxl

[Chao Peng]

The patch basically contains several PSR fixes in libxl.
patch1-3: fix the socket display error in certain hotplug case.
patch4:   fix a minor range check.
patch5:   improve the PSR document.

Detailed problem and fix please see commit message.

Chao Peng (5):
  tools/libxl: introduce libxl_socket_bitmap_fill
  tools/libxl: fix socket display error for CMT
  tools/libxl: return socket id from libxl_psr_cat_get_l3_info
  tools/libxl: fix range check in main_psr_cat_cbm_set
  docs: make xl-psr.markdown more precise

 docs/misc/xl-psr.markdown   |  8 ++---
 tools/libxl/libxl.h |  7 ++--
 tools/libxl/libxl_psr.c | 21 +---
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/libxl_utils.c   | 21 
 tools/libxl/libxl_utils.h   |  2 ++
 tools/libxl/xl_cmdimpl.c| 81 +++--
 7 files changed, 90 insertions(+), 51 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH for Xen 4.6 5/5] docs: make xl-psr.markdown more precise

[Chao Peng]

Make the chapter name and reference url more precise. The chapter number
is dropped as it can be confusing when it gets changed in the referred
document.

Signed-off-by: Chao Peng 
---
 docs/misc/xl-psr.markdown | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/misc/xl-psr.markdown b/docs/misc/xl-psr.markdown
index 3545912..737f0f7 100644
--- a/docs/misc/xl-psr.markdown
+++ b/docs/misc/xl-psr.markdown
@@ -14,7 +14,7 @@ tracks cache utilization of memory accesses according to the 
RMID and reports
 monitored data via a counter register.
 
 For more detailed information please refer to Intel SDM chapter
-"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
+"Platform Shared Resource Monitoring: Cache Monitoring Technology".
 
 In Xen's implementation, each domain in the system can be assigned a RMID
 independently, while RMID=0 is reserved for monitoring domains that don't
@@ -52,7 +52,7 @@ event type to monitor system total/local memory bandwidth. 
The same RMID can
 be used to monitor both cache usage and memory bandwidth at the same time.
 
 For more detailed information please refer to Intel SDM chapter
-"17.14 - Platform Shared Resource Monitoring: Cache Monitoring Technology".
+"Overview of Cache Monitoring Technology and Memory Bandwidth Monitoring".
 
 In Xen's implementation, MBM shares the same set of underlying monitoring
 service with CMT and can be used to monitor memory bandwidth on a per domain
@@ -92,7 +92,7 @@ For example, assuming a system with 8 portions and 3 domains:
access to one quarter each.
 
 For more detailed information please refer to Intel SDM chapter
-"17.15 - Platform Shared Resource Control: Cache Allocation Technology".
+"Platform Shared Resource Control: Cache Allocation Technology".
 
 In Xen's implementation, CBM can be configured with libxl/xl interfaces but
 COS is maintained in hypervisor only. The cache partition granularity is per
@@ -130,4 +130,4 @@ Per domain CBM settings can be shown by:
 ## Reference
 
 [1] Intel SDM
-(http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html).
+(http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf).
-- 
1.9.1


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

[Xen-devel] [PATCH for Xen 4.6 3/5] tools/libxl: return socket id from libxl_psr_cat_get_l3_info

[Chao Peng]

The entries returned from libxl_psr_cat_get_l3_info are assumed
to be socket-continuous. But this is not true in the hotplug case.

This patch gets the socket bitmap for all the sockets on the system
first and stores the socket id in the structure libxl_psr_cat_info in
libxl_psr_cat_get_l3_info. The xl or similar consumers then can display
socket information correctly. For the sake of future extention, the
field added to libxl_psr_cat_info is named as target_id.

Signed-off-by: Chao Peng 
---
 tools/libxl/libxl_psr.c | 21 -
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c| 37 +++--
 3 files changed, 36 insertions(+), 23 deletions(-)

diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 3378239..10e1113 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -339,7 +339,8 @@ int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, 
libxl_psr_cat_info **info,
 {
 GC_INIT(ctx);
 int rc;
-int i, nr_sockets;
+int i = 0, socket, nr_sockets;
+libxl_bitmap socketmap;
 libxl_psr_cat_info *ptr;
 
 rc = libxl__count_physical_sockets(gc, &nr_sockets);
@@ -348,21 +349,31 @@ int libxl_psr_cat_get_l3_info(libxl_ctx *ctx, 
libxl_psr_cat_info **info,
 goto out;
 }
 
+libxl_socket_bitmap_alloc(ctx, &socketmap, nr_sockets);
+rc = libxl_socket_bitmap_fill(ctx, &socketmap);
+if (rc < 0) {
+LOGE(ERROR, "failed to get available sockets");
+goto out;
+}
+
 ptr = libxl__malloc(NOGC, nr_sockets * sizeof(libxl_psr_cat_info));
 
-for (i = 0; i < nr_sockets; i++) {
-if (xc_psr_cat_get_l3_info(ctx->xch, i, &ptr[i].cos_max,
-&ptr[i].cbm_len)) {
+libxl_for_each_set_bit(socket, socketmap) {
+ptr[i].target_id = socket;
+if (xc_psr_cat_get_l3_info(ctx->xch, socket, &ptr[i].cos_max,
+ &ptr[i].cbm_len)) {
 libxl__psr_cat_log_err_msg(gc, errno);
 rc = ERROR_FAIL;
 free(ptr);
 goto out;
 }
+i++;
 }
 
 *info = ptr;
-*nr = nr_sockets;
+*nr = i;
 out:
+libxl_bitmap_dispose(&socketmap);
 GC_FREE;
 return rc;
 }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 9f6ec00..c7bd425 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -792,6 +792,7 @@ libxl_psr_cbm_type = Enumeration("psr_cbm_type", [
 ])
 
 libxl_psr_cat_info = Struct("psr_cat_info", [
+("target_id", uint32),
 ("cos_max", uint32),
 ("cbm_len", uint32),
 ])
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c72d3df..cec0d2c 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -8383,35 +8383,37 @@ int main_psr_cmt_show(int argc, char **argv)
 static int psr_cat_hwinfo(void)
 {
 int rc;
-int socketid, nr_sockets;
+int i, nr;
 uint32_t l3_cache_size;
 libxl_psr_cat_info *info;
 
 printf("Cache Allocation Technology (CAT):\n");
 
-rc = libxl_psr_cat_get_l3_info(ctx, &info, &nr_sockets);
+rc = libxl_psr_cat_get_l3_info(ctx, &info, &nr);
 if (rc) {
 fprintf(stderr, "Failed to get cat info\n");
 return rc;
 }
 
-for (socketid = 0; socketid < nr_sockets; socketid++) {
-rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid, &l3_cache_size);
+for (i = 0; i < nr; i++) {
+rc = libxl_psr_cmt_get_l3_cache_size(ctx, info->target_id,
+ &l3_cache_size);
 if (rc) {
 fprintf(stderr, "Failed to get l3 cache size for socket:%d\n",
-socketid);
+info->target_id);
 goto out;
 }
-printf("%-16s: %u\n", "Socket ID", socketid);
+printf("%-16s: %u\n", "Socket ID", info->target_id);
 printf("%-16s: %uKB\n", "L3 Cache", l3_cache_size);
 printf("%-16s: %u\n", "Maximum COS", info->cos_max);
 printf("%-16s: %u\n", "CBM length", info->cbm_len);
 printf("%-16s: %#llx\n", "Default CBM",
(1ull << info->cbm_len) - 1);
+info++;
 }
 
 out:
-libxl_psr_cat_info_list_free(info, nr_sockets);
+libxl_psr_cat_info_list_free(info, nr);
 return rc;
 }
 
@@ -8453,47 +8455,46 @@ static int psr_cat_print_domain_cbm(uint32_t domid, 
uint32_t socketid)
 return 0;
 }
 
-static int psr_cat_print_socket(uint32_t domid, uint32_t socketid,
-libxl_psr_cat_info *info)
+static int psr_cat_print_socket(uint32_t domid, libxl_psr_cat_info *info)
 {
 int rc;
 uint32_t l3_cache_size;
 
-rc = libxl_psr_cmt_get_l3_cache_size(ctx, socketid, &l3_cache_size);
+rc = libxl_psr_cmt_get_l3_cache_size(ctx, info->target_id, &l3_cache_size);
 if (rc) {
 fprintf(stderr, "Failed to get l3 cache size for socket:%d\n",
-  

Re: [Xen-devel] [PATCH V3 2/2] xen: Introduce VM_EVENT_FLAG_SET_REGISTERS

[Razvan Cojocaru]

On 09/28/2015 01:26 PM, Andrew Cooper wrote:
> On 28/09/15 11:16, Razvan Cojocaru wrote:
>> diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
>> index ff2f217..3e4efad 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -89,6 +89,12 @@
>>   * by the altp2m_idx response field if possible.
>>   */
>>  #define VM_EVENT_FLAG_ALTERNATE_P2M  (1 << 7)
>> +/*
>> + * Set the vCPU registers to the values in the  vm_event response.
>> + * Applies to EAX-EDX, ESP, EBP, ESI, EDI, R8-R15, EFLAGS, and EIP.
>> + * Requires the vCPU to be paused already (synchronous events only).
>> + */
> 
> The set registers are architecture specific, or will be if/when ARM
> gains support.
> 
> It is fine to list the architecture specific bits here (as there are no
> more appropriate places for it to live) but do explicitly call out that
> the 2nd sentence in x86 specific.
> 
> Otherwise, Reviewed-by: Andrew Cooper 

Will do in the next version.


Thanks for the review,
Razvan

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

Re: [Xen-devel] [PATCH 13/13] tools/libxl: Add 'vtsc_khz' option to set guest TSC rate

[Haozhong Zhang]

Hi Julien,

Thank you for the comments!

On Mon, Sep 28, 2015 at 12:47:24PM +0100, Julien Grall wrote:
> Hi,
> 
> On 28/09/15 08:13, Haozhong Zhang wrote:
> > This patch adds an option 'vtsc_khz' to allow users to set vcpu's TSC
> > rate in KHz. In the case that tsc_mode = 'default', the default value of
> > 'vtsc_khz' option is the host TSC rate which is used when 'vtsc_khz'
> > option is set to 0 or does not appear in the configuration. In all other
> > cases of tsc_mode, 'vtsc_khz' option is just ignored.
> > 
> > Another purpose of adding this option is to keep vcpu's TSC rate across
> > guest reboot. In existing code, a new domain is created from the
> > configuration of the previous domain which was just rebooted. vcpu's TSC
> > rate is not stored in the configuration and the host TSC rate is the
> > used as vcpu's TSC rate. This works fine unless the previous domain was
> > migrated from another host machine with a different host TSC rate than
> > the current one.
> > 
> > Signed-off-by: Haozhong Zhang 
> > ---
> >  tools/libxl/libxl_types.idl |  1 +
> >  tools/libxl/libxl_x86.c |  4 +++-
> >  tools/libxl/xl_cmdimpl.c| 22 ++
> >  3 files changed, 26 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index 9f6ec00..91cb0be 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -413,6 +413,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
> >  ("vcpu_soft_affinity", Array(libxl_bitmap, "num_vcpu_soft_affinity")),
> >  ("numa_placement",  libxl_defbool),
> >  ("tsc_mode",libxl_tsc_mode),
> > +("vtsc_khz",uint32),
> 
> This is x86 specific, can we begin to move anything arch-specific under
> arch_foo? See arch_arm for instance.
>

I'll have a look at arch_arm

> Also, you would need to add a new define LIBXL_HAVE_foo to let allow
> developer writing app on top of libxl support multiple version of Xen.
> See libxl.h
>

I'll add this

> >  ("max_memkb",   MemKB),
> >  ("target_memkb",MemKB),
> >  ("video_memkb", MemKB),
> > diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> > index 896f34c..7baaee4 100644
> > --- a/tools/libxl/libxl_x86.c
> > +++ b/tools/libxl/libxl_x86.c
> > @@ -276,6 +276,7 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> > libxl_domain_config *d_config,
> >  {
> >  int ret = 0;
> >  int tsc_mode;
> > +uint32_t vtsc_khz;
> >  uint32_t rtc_timeoffset;
> >  libxl_ctx *ctx = libxl__gc_owner(gc);
> >  
> > @@ -300,7 +301,8 @@ int libxl__arch_domain_create(libxl__gc *gc, 
> > libxl_domain_config *d_config,
> >  default:
> >  abort();
> >  }
> > -xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, 0, 0);
> > +vtsc_khz = d_config->b_info.vtsc_khz;
> > +xc_domain_set_tsc_info(ctx->xch, domid, tsc_mode, 0, vtsc_khz, 0);
> >  if (libxl_defbool_val(d_config->b_info.disable_migrate))
> >  xc_domain_disable_migrate(ctx->xch, domid);
> >  rtc_timeoffset = d_config->b_info.rtc_timeoffset;
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 2706759..5fabda7 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -1462,6 +1462,28 @@ static void parse_config_data(const char 
> > *config_source,
> >  }
> >  }
> >  
> > +/* "vtsc_khz" option works only if "tsc_mode" option is
> > + * "default". In this case, if "vtsc_khz" option is set to 0, we
> > + * will reset it to the host TSC rate. In all other cases, we just
> > + * ignore any given value and always set it to 0.
> > + */
> > +if (!xlu_cfg_get_long(config, "vtsc_khz", &l, 0))
> 
> This option has to be documented docs/man/xl.cfg.pod.5.
>

I'll add the document

> > +b_info->vtsc_khz = l;
> > +if (b_info->tsc_mode == LIBXL_TSC_MODE_DEFAULT) {
> > +if (b_info->vtsc_khz == 0) {
> > +libxl_physinfo physinfo;
> > +if (!libxl_get_physinfo(ctx, &physinfo))
> > +b_info->vtsc_khz = physinfo.cpu_khz;
> > +else
> > +fprintf(stderr, "WARNING: cannot get host TSC rate.\n");
> > +}
> > +} else {
> > +fprintf(stderr, "WARNING: ignoring \"vtsc_khz\" option. "
> > +"\"vtsc_khz\" option works only if "
> > +"\"tsc_mode\" option is \"default\".\n");
> > +b_info->vtsc_khz = 0;
> > +}
> > +
> >  if (!xlu_cfg_get_long(config, "rtc_timeoffset", &l, 0))
> >  b_info->rtc_timeoffset = l;
> >  
> > 
> 
> Regards,
> 
> 
> -- 
> Julien Grall

- Haozhong Zhang

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

[Xen-devel] [qemu-upstream-4.4-testing test] 62400: regressions - FAIL

[osstest service owner]

flight 62400 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/62400/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-vhd9 debian-di-install fail REGR. vs. 60565
 test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 60565

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 62316 
pass in 62400
 test-amd64-i386-xl-qemuu-debianhvm-amd64 18 guest-start.2   fail pass in 62316

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-raw   9 debian-di-install fail REGR. vs. 60565
 test-amd64-i386-libvirt  11 guest-start  fail   like 60565
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60565

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  never pass
 test-amd64-amd64-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 20 guest-start/debian   fail   never pass

version targeted for testing:
 qemuu5fe74249f5ab528fe84a26fa60438a6de4c787f0
baseline version:
 qemuu0fc147387f0b683d2dfefec7b1af569f17b72e9c

Last test of basis60565  2015-08-04 01:59:38 Z   55 days
Failing since 61617  2015-09-08 12:10:54 Z   20 days9 attempts
Testing same since62062  2015-09-16 11:15:04 Z   12 days5 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  P J P 
  Peter Lieven 
  Stefan Hajnoczi 
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  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  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 fail
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt fail
 test-amd64-i386-libvirt  fail
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair fail
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-libvirt-qcow2   pass
 test-amd64-i386-libvirt-qcow2fail
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-qcow2 fail
 test-amd64-amd64-libvirt-raw pass
 test-amd64-i386-libvirt-raw

[Xen-devel] [PATCHv2 for-4.6] p2m/ept: Work around hardware errata setting A bit

[Ross Lagerwall]

Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
log-dirty"), the A and D bits of EPT paging entries are set
unconditionally, regardless of whether PML is enabled or not. This
causes a regression in Xen 4.6 on some processors due to Intel Errata
AVR41 -- HVM guests get severe memory corruption when the A bit is set
due to incorrect TLB flushing on mov to cr3. The errata affects the Atom
C2000 family (Avaton).

To fix, do not set the A bit on this processor family.

Signed-off-by: Ross Lagerwall 
---
 xen/arch/x86/mm/p2m-ept.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 2f3df91..1713a97 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -34,6 +34,8 @@
 
 #include "mm-locks.h"
 
+static bool_t __read_mostly cpu_has_ept_ad;
+
 #define atomic_read_ept_entry(__pepte)  \
 ( (ept_entry_t) { .epte = read_atomic(&(__pepte)->epte) } )
 
@@ -130,14 +132,14 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
 break;
 case p2m_ram_rw:
 entry->r = entry->w = entry->x = 1;
-entry->a = entry->d = 1;
+entry->a = entry->d = cpu_has_ept_ad;
 break;
 case p2m_mmio_direct:
 entry->r = entry->x = 1;
 entry->w = !rangeset_contains_singleton(mmio_ro_ranges,
 entry->mfn);
-entry->a = 1;
-entry->d = entry->w;
+entry->a = cpu_has_ept_ad;
+entry->d = entry->w && cpu_has_ept_ad;
 break;
 case p2m_ram_logdirty:
 entry->r = entry->x = 1;
@@ -152,7 +154,7 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
 entry->w = 1;
 else
 entry->w = 0;
-entry->a = 1;
+entry->a = cpu_has_ept_ad;
 /* For both PML or non-PML cases we clear D bit anyway */
 entry->d = 0;
 break;
@@ -160,20 +162,20 @@ static void ept_p2m_type_to_flags(struct p2m_domain *p2m, 
ept_entry_t *entry,
 case p2m_ram_shared:
 entry->r = entry->x = 1;
 entry->w = 0;
-entry->a = 1;
+entry->a = cpu_has_ept_ad;
 entry->d = 0;
 break;
 case p2m_grant_map_rw:
 case p2m_map_foreign:
 entry->r = entry->w = 1;
 entry->x = 0;
-entry->a = entry->d = 1;
+entry->a = entry->d = cpu_has_ept_ad;
 break;
 case p2m_grant_map_ro:
 case p2m_mmio_write_dm:
 entry->r = 1;
 entry->w = entry->x = 0;
-entry->a = 1;
+entry->a = cpu_has_ept_ad;
 entry->d = 0;
 break;
 }
@@ -233,7 +235,7 @@ static int ept_set_middle_entry(struct p2m_domain *p2m, 
ept_entry_t *ept_entry)
 
 ept_entry->r = ept_entry->w = ept_entry->x = 1;
 /* Manually set A bit to avoid overhead of MMU having to write it later. */
-ept_entry->a = 1;
+ept_entry->a = cpu_has_ept_ad;
 
 ept_entry->suppress_ve = 1;
 
@@ -1150,6 +1152,9 @@ int ept_p2m_init(struct p2m_domain *p2m)
 p2m->memory_type_changed = ept_memory_type_changed;
 p2m->audit_p2m = NULL;
 
+/* Work around Errata AVR41 on Avaton processors. */
+cpu_has_ept_ad = boot_cpu_data.x86_model != 0x4d;
+
 /* Set the memory type used when accessing EPT paging structures. */
 ept->ept_mt = EPT_DEFAULT_MT;
 
-- 
2.4.3


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

Re: [Xen-devel] [PATCHv2 for-4.6] p2m/ept: Work around hardware errata setting A bit

[Tim Deegan]

Hi,

At 13:39 +0100 on 28 Sep (1443447574), Ross Lagerwall wrote:
> Since commit 191b3f3344ee ("p2m/ept: enable PML in p2m-ept for
> log-dirty"), the A and D bits of EPT paging entries are set
> unconditionally, regardless of whether PML is enabled or not. This
> causes a regression in Xen 4.6 on some processors due to Intel Errata
> AVR41 -- HVM guests get severe memory corruption when the A bit is set
> due to incorrect TLB flushing on mov to cr3. The errata affects the Atom
> C2000 family (Avaton).
> 
> To fix, do not set the A bit on this processor family.
> 
> Signed-off-by: Ross Lagerwall 

This looks pretty good as a 4.6 fix, though:

> @@ -1150,6 +1152,9 @@ int ept_p2m_init(struct p2m_domain *p2m)
>  p2m->memory_type_changed = ept_memory_type_changed;
>  p2m->audit_p2m = NULL;
>  
> +/* Work around Errata AVR41 on Avaton processors. */
> +cpu_has_ept_ad = boot_cpu_data.x86_model != 0x4d;
> +

Shouldn't this check the family (a.k.a. boot_cpu_data.x86) too?

Cheers,

Tim.

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