Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion
On Tue, Nov 24, 2015 at 03:34:45AM -0700, Jan Beulich wrote: > >>> On 23.11.15 at 17:36, wrote: > > I instrumented detect_extended_topology() and ran again with 4 CPUs. > >[...] > > (XEN) smp_store_cpu_info id=3 > > (XEN) detect_extended_topology cpuid_count op=0xb count=0 eax=0x0 ebx=0x1 > > ecx=0x100 edx=0x6 > > (XEN) detect_extended_topology initial_apicid=6 core_plus_mask_width=0 > > core_level_siblings=1 > > (XEN) detect_extended_topology cpuid_count op=0xb count=1 eax=0x0 ebx=0x1 > > ecx=0x201 edx=0x6 > > (XEN) detect_extended_topology ht_mask_width=0 core_plus_mask_width=0 > > core_select_mask=0x0 core_level_siblings=1 > >[...] > > If cpuid 0xb returned 1 rather than 0 in eax[4:0], we would get > > consecutively-numbered physical processor IDs. > > > > But the only requirement I see in the IA SDM (vol 2A, table 3-17) is that > > the eax[4:0] value yield unique IDs, not necessarily consecutive. Likewise > > while the examples in vol 3A sec 8.9 show physical IDs numbered > > consecutively, the algorithms do not assume this is the case. > > Indeed, and I think I had said so. The algorithm does, however, tell > us that with the above output CPU 3 (APIC ID 6) is on socket 6 (both > shifts being zero), which for the whole system results in sockets 1, > 3, and 5 unused. While not explicitly excluded, I'm not sure how far > we should go in expecting all kinds of odd configurations (along those > lines we e.g. have a limit on the largest APIC ID we allow: MAX_APICS / > MAX_LOCAL_APIC, which for big systems is 4 times the number of > CPUs we support). > > Taking it to set_nr_sockets(), a pretty basic assumption is broken by > the above way of presenting topology: We would have to have more > sockets than there are CPUs. I would have wanted to check what > e.g. Linux does here, but there doesn't seem to be any support of > CAT (and hence any need for per-socket data) there. Actually I checked Linux code when I implementing this but it doesn't exist. Current Linux CAT patch supports only system-level other than per-socket level so it doesn't need that as well. There are people requesting to add per-socket support so Linux need solve this problem eventually. But at this time, we don't have any reference. > > (I am, btw, now also confused by you saying that e.g. for a 3-CPU > config things work. If the topology data gets presented in similar > ways in that case, I can't see why you wouldn't run into the same > problem. Unless memory corruption occurs silently in one case, but > "loudly" in the other.) > > Bottom line - for the moment I do not see a reasonable way of > dealing with that situation. The closest I could see would be what > we iirc had temporarily during the review cycles of the initial CAT > series: A command line option to specify the number of sockets. Or > make all accesses to socket_cpumask[] conditional upon PSR being > enabled (which would have the bad side effect of making future > uses for other purposes more cumbersome), or go through and > range check the socket number on all of those accesses. > > Chao, could you - inside Intel - please check whether there are > any assumptions on the respective CPUID leaf output that aren't > explicitly stated in the SDM right now (like resulting in contiguous > socket numbers), and ask for them getting made explicit (if there > are any), or it being made explicit that no assumptions at all are > to be made at all on the presented values Actually there is already such statement in SDM (ch8.9.1, vol3): "The value of valid APIC_IDs need not be contiguous across package boundary or core boundaries". > (in which case we'd > have to consume MADT parsing data in set_nr_sockets(), e.g. > by replacing num_processors there with one more than the > maximum APIC ID of any non-disabled CPU)? Even with this, we still have problem for hotplug case, the inserted CPU may have a APIC_ID bigger than the maximum APIC_ID here. But let's back to the real world. Most machines that support CAT should have continuous SOCKET_ID so it's not a problem. Giving that CAT is the only feature uses this, I guess this suggestion might be better than other solutions in practice. Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [V12 4/4] libxc: expose xsaves/xgetbv1/xsavec to hvm guest
From: Shuai Ruan This patch exposes xsaves/xgetbv1/xsavec to hvm guest. The reserved bits of eax/ebx/ecx/edx must be cleaned up when call cpuid(0dh) with leaf 1 or 2..63. According to the spec the following bits must be reserved: For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved. For leaf 2...63, bits 01-31 of ecx is reserved, Edx is reserved. But as no XSS festures are currently supported, even in HVM guests, for leaf 2...63, ecx should be zero at the moment. Signed-off-by: Shuai Ruan Acked-by: Ian Campbell --- tools/libxc/xc_cpuid_x86.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c index 031c848..8882c01 100644 --- a/tools/libxc/xc_cpuid_x86.c +++ b/tools/libxc/xc_cpuid_x86.c @@ -282,6 +282,9 @@ static void intel_xc_cpuid_policy(xc_interface *xch, } #define XSAVEOPT(1 << 0) +#define XSAVEC (1 << 1) +#define XGETBV1 (1 << 2) +#define XSAVES (1 << 3) /* Configure extended state enumeration leaves (0x000D for xsave) */ static void xc_cpuid_config_xsave(xc_interface *xch, const struct cpuid_domain_info *info, @@ -318,8 +321,11 @@ static void xc_cpuid_config_xsave(xc_interface *xch, regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */ break; case 1: /* leaf 1 */ -regs[0] &= XSAVEOPT; -regs[1] = regs[2] = regs[3] = 0; +regs[0] &= (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES); +if ( !info->hvm ) +regs[0] &= ~XSAVES; +regs[2] &= info->xfeature_mask; +regs[3] = 0; break; case 2 ... 63: /* sub-leaves */ if ( !(info->xfeature_mask & (1ULL << input[1])) ) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [V12 1/4] x86/xsaves: using named operand instead numbered operand in xrstor
From: Shuai Ruan This is pre-req patch for latter xsaves patch. This patch introduce a macro to handle restor fixup, also use named opreand instead of numbered operand in restor fixup code. Signed-off-by: Shuai Ruan --- xen/arch/x86/xstate.c | 43 +++ 1 file changed, 19 insertions(+), 24 deletions(-) diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c index 827e0e1..bb6d5e11 100644 --- a/xen/arch/x86/xstate.c +++ b/xen/arch/x86/xstate.c @@ -158,6 +158,16 @@ void xsave(struct vcpu *v, uint64_t mask) ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size; } +#define XRSTOR_FIXUP ".section .fixup,\"ax\" \n"\ + "2: mov %[size],%%ecx \n"\ + " xor %[lmask_out],%[lmask_out] \n"\ + " rep stosb \n"\ + " lea %[mem],%[ptr] \n"\ + " mov %[lmask_in],%[lmask_out] \n"\ + " jmp 1b\n"\ + ".previous\n"\ + _ASM_EXTABLE(1b, 2b) + void xrstor(struct vcpu *v, uint64_t mask) { uint32_t hmask = mask >> 32; @@ -188,38 +198,23 @@ void xrstor(struct vcpu *v, uint64_t mask) { default: asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n" - ".section .fixup,\"ax\" \n" - "2: mov %5,%%ecx \n" - " xor %1,%1\n" - " rep stosb\n" - " lea %2,%0\n" - " mov %3,%1\n" - " jmp 1b \n" - ".previous \n" - _ASM_EXTABLE(1b, 2b) - : "+&D" (ptr), "+&a" (lmask) - : "m" (*ptr), "g" (lmask), "d" (hmask), - "m" (xsave_cntxt_size) + XRSTOR_FIXUP + : [ptr] "+&D" (ptr), [lmask_out] "+&a" (lmask) + : [mem] "m" (*ptr), [lmask_in] "g" (lmask), + [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size) : "ecx" ); break; case 4: case 2: asm volatile ( "1: .byte 0x0f,0xae,0x2f\n" - ".section .fixup,\"ax\" \n" - "2: mov %5,%%ecx\n" - " xor %1,%1 \n" - " rep stosb \n" - " lea %2,%0 \n" - " mov %3,%1 \n" - " jmp 1b \n" - ".previous \n" - _ASM_EXTABLE(1b, 2b) - : "+&D" (ptr), "+&a" (lmask) - : "m" (*ptr), "g" (lmask), "d" (hmask), - "m" (xsave_cntxt_size) + XRSTOR_FIXUP + : [ptr] "+&D" (ptr), [lmask_out] "+&a" (lmask) + : [mem] "m" (*ptr), [lmask_in] "g" (lmask), + [hmask] "d" (hmask), [size] "m" (xsave_cntxt_size) : "ecx" ); break; } } +#undef XRSTOR_FIXUP bool_t xsave_enabled(const struct vcpu *v) { -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [V12 0/4] add xsaves/xrstors support
From: Shuai Ruan Changes in v12: * Address comments from Jan: * Add a seperate, pre-req patch to change from using numbered operand to named operand in xrstor. * Using alterive_io in xrstor side. Changes in v11: * Address comments from Jan: * Using alternative asm on xrstor side. For xsave side(alternative asm), I will send a seperate patch to do this. Changes in v10: * Address comments from Jan: * Add two new macros to handle alternative asm with fixup code in patch1. * Fix a coding style error in patch2. Changes in v9: * Address comments from Jan: * Add msr_ia32_xss save/restor support in patch2. * Change xrstor to alternative asm in patch1. * Use memcpy() copy the save header to avoid one ugly cast in patch1. * Fix coding style errors. Changes in v8: * Address comments from Jan/Andrew: * Add optimisation in set_msr_xss in patch1. * Change from black listing feature to white listing in pv_cpuid in patch2. * Add MSR_IA32_XSS save/restore support in patch2. * Fix some code errors and coding style errors. Changes in v7: * Address comments from Jan/Andrew: * Move macro XSTATE_FIXUP into patch3. * Change lazy write to xss_msr in patch1. * Drop inner set of brackets and stray cast in patch2. * Move the condition and memcpy() wouldn't into the new called functions in patch2. * Rebase patch4 base on Andrew's"tools/libxc: Improve efficiency of xc_cpuid_apply_policy()". * For no XSS features are currently supported.For leaf 2...63,ecx remain zero at the moment in patch4. Changes in v6: * Address comments from Jan. * Rebase the code based on Andrew'patch "xen/x86: Record xsave features in c->x86_capabilities". * Re-split the patch to avoid building errors. Move some func definitions from patch1 to patch2. * Change func name load/save_xsave_states to compress/expand_xsave_states in patch2. * Add macro to handle redundancy in xrstor. * Fix some code errors and coding style errors. * Add some descriptions in commit message. Changes in v5: * Address comments from Andrew/Jan,mainly: * Add lazy writes of the xss_msr. * Add xsave_area check when save/restore guest. * Add xsavec support. * Use word 2 in xen/include/asm-x86/cpufeature.h. * Fix some code errors. Changes in v4: * Address comments from Andrew, mainly: * No xsaves suporting for pv guest. * Using xstate_sizes instead of domain_cpuid in hvm_cupid in patch 3. * Add support for format translation when perform pv guest migration in patch 2. * Fix some code errors. Changes in v3: * Address comments from Jan/Konrad * Change the bits of eax/ebx/ecx/edx passed to guest in patch 4. * Add code to verify whether host supports xsaves or not in patch 1. Changes in v2: * Address comments from Andrew/chao/Jan, mainly: * Add details information of xsaves/xrstors feature. * Test migration between xsaves-support machine and none-xsaves-support machine * Remove XGETBV1/XSAVEC/XSAVEOPT out of 'else' in patch 3. * Change macro name XGETBV to XGETBV1 in patch 4. Shuai Ruan (4): x86/xsaves: using named operand instead numbered operand in xrstor x86/xsaves: enable xsaves/xrstors/xsavec in xen x86/xsaves: enable xsaves/xrstors for hvm guest libxc: expose xsaves/xgetbv1/xsavec to hvm guest tools/libxc/xc_cpuid_x86.c | 10 +- xen/arch/x86/domain.c | 8 ++ xen/arch/x86/domctl.c | 30 - xen/arch/x86/hvm/hvm.c | 45 ++- xen/arch/x86/hvm/vmx/vmcs.c| 5 +- xen/arch/x86/hvm/vmx/vmx.c | 35 +- xen/arch/x86/i387.c| 4 + xen/arch/x86/traps.c | 6 +- xen/arch/x86/xstate.c | 246 - xen/include/asm-x86/alternative.h | 3 + xen/include/asm-x86/hvm/vmx/vmcs.h | 4 + xen/include/asm-x86/hvm/vmx/vmx.h | 2 + xen/include/asm-x86/xstate.h | 3 + 13 files changed, 353 insertions(+), 48 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [V12 2/4] x86/xsaves: enable xsaves/xrstors/xsavec in xen
This patch uses xsaves/xrstors/xsavec instead of xsaveopt/xrstor to perform the xsave_area switching so that xen itself can benefit from them when available. For xsaves/xrstors/xsavec only use compact format. Add format conversion support when perform guest os migration. Also, pv guest will not support xsaves/xrstors. Signed-off-by: Shuai Ruan --- xen/arch/x86/domain.c | 8 ++ xen/arch/x86/domctl.c | 30 +- xen/arch/x86/hvm/hvm.c| 18 +++- xen/arch/x86/i387.c | 4 + xen/arch/x86/traps.c | 6 +- xen/arch/x86/xstate.c | 219 +++--- xen/include/asm-x86/alternative.h | 3 + xen/include/asm-x86/xstate.h | 2 + 8 files changed, 262 insertions(+), 28 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 3f9e5d2..9476869 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -910,7 +910,12 @@ int arch_set_info_guest( { memcpy(v->arch.fpu_ctxt, &c.nat->fpu_ctxt, sizeof(c.nat->fpu_ctxt)); if ( v->arch.xsave_area ) +{ v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE; + if ( cpu_has_xsaves || cpu_has_xsavec ) + v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE | + XSTATE_COMPACTION_ENABLED; +} } if ( !compat ) @@ -1594,6 +1599,9 @@ static void __context_switch(void) if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) ) BUG(); + +if ( cpu_has_xsaves && has_hvm_container_vcpu(n) ) +set_msr_xss(n->arch.hvm_vcpu.msr_xss); } vcpu_restore_fpu_eager(n); n->arch.ctxt_switch_to(n); diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index 0f6fdb9..95b0747 100644 --- a/xen/arch/x86/domctl.c +++ b/xen/arch/x86/domctl.c @@ -897,9 +897,29 @@ long arch_do_domctl( ret = -EFAULT; offset += sizeof(v->arch.xcr0_accum); -if ( !ret && copy_to_guest_offset(evc->buffer, offset, - (void *)v->arch.xsave_area, - size - 2 * sizeof(uint64_t)) ) +if ( !ret && (cpu_has_xsaves || cpu_has_xsavec) ) +{ +void *xsave_area; + +xsave_area = xmalloc_bytes(size); +if ( !xsave_area ) +{ +ret = -ENOMEM; +vcpu_unpause(v); +goto vcpuextstate_out; +} + +expand_xsave_states(v, xsave_area, +size - 2 * sizeof(uint64_t)); + +if ( copy_to_guest_offset(evc->buffer, offset, xsave_area, + size - 2 * sizeof(uint64_t)) ) + ret = -EFAULT; +xfree(xsave_area); + } + else if ( !ret && copy_to_guest_offset(evc->buffer, offset, + (void *)v->arch.xsave_area, + size - 2 * sizeof(uint64_t)) ) ret = -EFAULT; vcpu_unpause(v); @@ -955,8 +975,8 @@ long arch_do_domctl( v->arch.xcr0_accum = _xcr0_accum; if ( _xcr0_accum & XSTATE_NONLAZY ) v->arch.nonlazy_xstate_used = 1; -memcpy(v->arch.xsave_area, _xsave_area, - evc->size - 2 * sizeof(uint64_t)); +compress_xsave_states(v, _xsave_area, + evc->size - 2 * sizeof(uint64_t)); vcpu_unpause(v); } else diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index 141a130..c981580 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -2092,6 +2092,9 @@ static int hvm_load_cpu_ctxt(struct domain *d, hvm_domain_context_t *h) memcpy(v->arch.xsave_area, ctxt.fpu_regs, sizeof(ctxt.fpu_regs)); xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE; +if ( cpu_has_xsaves || cpu_has_xsavec ) +xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE | + XSTATE_COMPACTION_ENABLED; } else memcpy(v->arch.fpu_ctxt, ctxt.fpu_regs, sizeof(ctxt.fpu_regs)); @@ -2161,8 +2164,8 @@ static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h) ctxt->xfeature_mask = xfeature_mask; ctxt->xcr0 = v->arch.xcr0; ctxt->xcr0_accum = v->arch.xcr0_accum; -memcpy(&ctxt->save_area, v->arch.xsave_area, - size - offsetof(struct hvm_hw_cpu_xsave, save_area)); +expand_xsave_states(v, &ctxt->save_area, +size - offsetof(typeof(*ctxt), save_area)); } return 0; @@ -2261,9 +2264,9 @@ stati
[Xen-devel] [V12 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest
This patch enables xsaves for hvm guest, includes: 1.handle xsaves vmcs init and vmexit. 2.add logic to write/read the XSS msr. Add IA32_XSS_MSR save/rstore support. Signed-off-by: Shuai Ruan Reviewed-by: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 27 +++ xen/arch/x86/hvm/vmx/vmcs.c| 5 - xen/arch/x86/hvm/vmx/vmx.c | 35 ++- xen/arch/x86/xstate.c | 2 +- xen/include/asm-x86/hvm/vmx/vmcs.h | 4 xen/include/asm-x86/hvm/vmx/vmx.h | 2 ++ xen/include/asm-x86/xstate.h | 1 + 7 files changed, 73 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c index c981580..6c2b512 100644 --- a/xen/arch/x86/hvm/hvm.c +++ b/xen/arch/x86/hvm/hvm.c @@ -4606,6 +4606,20 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx, *ebx = _eax + _ebx; } } +if ( count == 1 ) +{ +if ( cpu_has_xsaves && cpu_has_vmx_xsaves ) +{ +*ebx = XSTATE_AREA_MIN_SIZE; +if ( v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss ) +for ( sub_leaf = 2; sub_leaf < 63; sub_leaf++ ) +if ( (v->arch.xcr0 | v->arch.hvm_vcpu.msr_xss) & + (1ULL << sub_leaf) ) +*ebx += xstate_sizes[sub_leaf]; +} +else +*ebx = *ecx = *edx = 0; +} break; case 0x8001: @@ -4705,6 +4719,12 @@ int hvm_msr_read_intercept(unsigned int msr, uint64_t *msr_content) *msr_content = v->arch.hvm_vcpu.guest_efer; break; +case MSR_IA32_XSS: +if ( !cpu_has_xsaves ) +goto gp_fault; +*msr_content = v->arch.hvm_vcpu.msr_xss; +break; + case MSR_IA32_TSC: *msr_content = _hvm_rdtsc_intercept(); break; @@ -4837,6 +4857,13 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t msr_content, return X86EMUL_EXCEPTION; break; +case MSR_IA32_XSS: +/* No XSS features currently supported for guests. */ +if ( !cpu_has_xsaves || msr_content != 0 ) +goto gp_fault; +v->arch.hvm_vcpu.msr_xss = msr_content; +break; + case MSR_IA32_TSC: hvm_set_guest_tsc(v, msr_content); break; diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 202c0a4..000d06e 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -241,7 +241,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_XSAVES); rdmsrl(MSR_IA32_VMX_MISC, _vmx_misc_cap); if ( _vmx_misc_cap & VMX_MISC_VMWRITE_ALL ) opt |= SECONDARY_EXEC_ENABLE_VMCS_SHADOWING; @@ -1273,6 +1274,8 @@ static int construct_vmcs(struct vcpu *v) __vmwrite(HOST_PAT, host_pat); __vmwrite(GUEST_PAT, guest_pat); } +if ( cpu_has_vmx_xsaves ) +__vmwrite(XSS_EXIT_BITMAP, 0); vmx_vmcs_exit(v); diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index 374eebf..9ad6d82 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -625,7 +625,7 @@ static int vmx_load_vmcs_ctxt(struct vcpu *v, struct hvm_hw_cpu *ctxt) static unsigned int __init vmx_init_msr(void) { -return !!cpu_has_mpx; +return !!cpu_has_mpx + !!cpu_has_xsaves; } static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt) @@ -640,6 +640,13 @@ static void vmx_save_msr(struct vcpu *v, struct hvm_msr *ctxt) } vmx_vmcs_exit(v); + +if ( cpu_has_xsaves ) +{ +ctxt->msr[ctxt->count].val = v->arch.hvm_vcpu.msr_xss; +if ( ctxt->msr[ctxt->count].val ) +ctxt->msr[ctxt->count++].index = MSR_IA32_XSS; +} } static int vmx_load_msr(struct vcpu *v, struct hvm_msr *ctxt) @@ -659,6 +666,12 @@ static int vmx_load_msr(struct vcpu *v, struct hvm_msr *ctxt) else err = -ENXIO; break; +case MSR_IA32_XSS: +if ( cpu_has_xsaves ) +v->arch.hvm_vcpu.msr_xss = ctxt->msr[i].val; +else +err = -ENXIO; +break; default: continue; } @@ -2819,6 +2832,18 @@ static void vmx_idtv_reinject(unsigned long idtv_info) } } +static void vmx_handle_xsaves(void) +{ +gdprintk(XENLOG_ERR, "xsaves should not cause vmexit\n"); +domain_crash(current->domain); +} + +static void vmx_handle_xrstors(void) +{ +gdprintk(XENLOG_ERR, "xrstors should not cause vmexit\n"); +domain_crash(current->domain); +} +
[Xen-devel] [ovmf test] 65085: all pass - PUSHED
flight 65085 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65085/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 3164361121526318f278a7c1b84bdcc475d4ad95 baseline version: ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f Last test of basis65064 2015-11-24 01:12:13 Z1 days Testing same since65085 2015-11-24 21:47:18 Z0 days1 attempts People who touched revisions under test: Ard Biesheuvel Ruiyu Ni Wei Huang jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=ovmf + revision=3164361121526318f278a7c1b84bdcc475d4ad95 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 3164361121526318f278a7c1b84bdcc475d4ad95 + branch=ovmf + revision=3164361121526318f278a7c1b84bdcc475d4ad95 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.6-testing + '[' x3164361121526318f278a7c1b84bdcc475d4ad95 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]' ++ :
[Xen-devel] How to recognize which guest issues the hypercall?
I write a program to intercept all hypercalls happend on a xen hypervisor. How can I know which domain called the hypercall? Is it possible to obtain it from the registers? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-2.5] vnc: fix segfault
Commit "c7628bf vnc: only alloc server surface with clients connected" missed one rarely used codepath (cirrus with guest drivers using 2d accel) where we have to check for the server surface being present, to avoid qemu crashing with a NULL pointer dereference. Add the check. Reported-by: Anthony PERARD Signed-off-by: Gerd Hoffmann --- ui/vnc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/ui/vnc.c b/ui/vnc.c index c9f2fed..7538405 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -931,6 +931,11 @@ static void vnc_dpy_copy(DisplayChangeListener *dcl, int i, x, y, pitch, inc, w_lim, s; int cmp_bytes; +if (!vd->server) { +/* no client connected */ +return; +} + vnc_refresh_server_surface(vd); QTAILQ_FOREACH_SAFE(vs, &vd->clients, next, vn) { if (vnc_has_feature(vs, VNC_FEATURE_COPYRECT)) { -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and Intel
> -Original Message- > From: Ian Campbell [mailto:ian.campb...@citrix.com] > Sent: Monday, November 23, 2015 6:49 PM > To: ian.jack...@eu.citrix.com; xen-devel@lists.xen.org > Cc: Ian Campbell ; Hu, Robert > > Subject: [PATCH OSSTEST] make-flight: Run separate nested jobs on AMD and > Intel > > nested HVM relies heavily on the underlying HVM implementation, which > is different for Intel and AMD and therefore worth testing separately. > > Currently test-amd64-amd64-qemuu-nested is not tied to any specific > vendor, split it into -amd and -intel jobs and set the host flags > appropriately. > > Signed-off-by: Ian Campbell > Cc: "Hu, Robert" > --- > make-flight | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/make-flight b/make-flight > index 6f462ad..6b2b3ea 100755 > --- a/make-flight > +++ b/make-flight > @@ -269,7 +269,9 @@ do_hvm_debian_nested_tests () { > xen-4.3-testing) return;; >esac > > - job_create_test test-$xenarch$kern-$dom0arch$qemuu_suffix-nested \ > + for cpuvendor in amd intel; do > + > +job_create_test > test-$xenarch$kern-$dom0arch$qemuu_suffix-nested-$cpuvendor \ > test-nested xl $xenarch $dom0arch $qemuu_runvar > \ > l1_image=$(usual_debianhvm_image amd64) > \ > l1_vifmodel='e1000' > \ > @@ -277,7 +279,9 @@ do_hvm_debian_nested_tests () { > l1_enable_nestedhvm='true' > \ > l2_image=$(usual_debianhvm_image amd64) > \ > bios=$bios > \ > -all_hostflags=$most_hostflags,hvm > +all_hostflags=$most_hostflags,hvm-$cpuvendor > + > + done > } > > branch_debianhvm_arch () { [Hu, Robert] Aced-by: Robert Hu And thanks! > -- > 2.6.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Rumprun based upstream QEMU stubdom status update
Thanks for taking the time to consider my comments and respond. On Tue, Nov 24, 2015 at 9:44 AM, Wei Liu wrote: > Another chunk of work is teaching QEMU to not initialised some > component or take a different path when initialising some > components. This is the same as Linux-based stubdom. > When I was working on Linux-based stubdom earlier, it was the point where serious QEMU-related work needed to be done (in particular, working out getting the display to work correctly via VNC or otherwise) that I reached the limit of what I could accomplish on my own in a reasonable amount of time. There was simply too much for me to learn about QEMU internals and how they are supposed to interact with Xen. On top of that, getting QMP and save/restore working across domains appears to require some serious effort, and is for the most part outside of what I need QEMU stubdom for. > One lesson learned from QEMU-trad stubdom is that the build system > inevitably turns into a black hole that sucks in effort but yields no > clear return. That's why we would very much prefer doing things "the > right way", i.e. relying on well-established ways to deliver this > feature, and expanding the user base till it is large enough to draw > enough interest for this feature to be self-sustained. > That last bit is where I am interested in bringing this to - having the basic functionality in place, so that others may be encouraged to drive to completion the aspects that they have an interest or stake in. Right now, there is so much that needs to be done, that many would rather not touch any of it. > What is really not clear at the moment is the path to Linux > distributions and BSDs. Xen project doesn't distribute binaries. Also > , to build an image requires specialised toolchain and build system > that distros are not interested in taking in. Building for *BSD is a > no-go at the moment for Linux-based stubdom and QEMU-trad stubdom. > I agree that for the time being, *BSD would be off the table for Linux-based stubdom - it would take a lot of bootstrapping to get an environment up and running under *BSD to build the Linux-based stubdom on *BSD. It could be sensible to modify the no-binaries position if the notion of a reproducible build could be implemented. This could allow distribution of a binary image for Linux-based stubdom (which would not be all that big) for use by *BSD and others, yet demonstrate that the binary image does correspond to the underlying source. However, that is several step down the road from just getting it to work on Linux. > I discussed with Stefano and Anthony to reassess Linux-based stubdom, > with all the issues mentioned above, if we narrow down the scope of > the project -- ignore BSD support for now, integrate build with > Raisin, no distros integration -- it can actually be done within a > finite time frame. > > Here are some issues with the existing patch series: > > 1. It's using Dracut build image, which is Redhat-centric. > That issue was raised before, but I'm not sure how much it really is. FWIW, I was using my updated version of Anthony's work on a Gentoo system, and encountered no issues. Is there a Linux distribution that we know dracut does not work on? It would be helpful to know. Although I have not really dug into dracut, it seemed to be effective for our purposes (collecting the libraries that need to be included in the Linux image for QEMU), and I'd rather not recreate dracut or part of dracut if we don't need to. > 2. Some patches are not yet complete and not suitable to upstream. > What kinds of things are being done by these patches? You mentioned component initialization; however, I did not encounter any problems relating to that when getting QEMU upstream stubdom up to the point of running SSH on a standard Linux distribution, etc. Having to disable such things makes sense as an issue under rumprun, given the likely difficulties in getting certain libraries to run under rumprun, but I would expect it to be less of an issue when QEMU gets run in its native Linux environment. > And these are the steps that need to be done: > > 1. Build with Raisin > 1.1 Build Linux kernel with a customised config. > 1.2 Build QEMU from a customised branch. > 1.3 Extract QEMU libraries dependency with generic tool. > 1.4 Generate a disk image with generic tool. > 2. Toolstack plumbing and make work other components. > 3. Teach OSStest to constantly test it. > > Would you be up for working on Raisin integration? That is, up to the > point of producing an image. We can discuss certain actions in > detailed and will help you with the issues you encounter along the > way. We appreciate help from the community as we're already quite > stretched with other projects. > I believe that is something I can work on, and likely won't be all that bad given where things already are. However, I know essentially nothing about Raisin. What is a good way to get up to speed? One
Re: [Xen-devel] [PATCH] paravirt: remove paravirt ops pmd_update[_defer] and pte_update_defer
Juergen Gross writes: > Ping? Acked-by: Rusty Russell Cheers, Rusty. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] libxl: Introduce a template for devices with a controller
>>> On 11/24/2015 at 10:40 PM, in message <1448376011-20217-1-git-send-email-george.dun...@eu.citrix.com>, George Dunlap wrote: > We have several outstanding patch series which add devices that have > two levels: a controller and individual devices attached to that > controller. > > In the interest of consistency, this patch introduces a section that > sketches out a template for interfaces for such devices. Some typos. Otherwise, agreed. - Chunyan > > Signed-off-by: George Dunlap > --- > CC: Ian Campbell > CC: Ian Jackson > CC: Wei Liu > CC: Juergen Gross > CC: Chun Yan Liu > CC: Olaf Hering > > Changes in v1 (since the RFC): > > - Use rather than , and rather than specifying > controller and device. The idea being to allow SCSI to use > terminology more natural to it (i.e., scsihost, scsitarget, scsilun) > rather than naming things after USB (controller & device). > > - Do not require each to have a deviceid, but just a unique > naming schema. > > - Allow multiple levels. > > - Include the paragraph about domain configuration lists. > --- > tools/libxl/libxl.h | 65 > + > 1 file changed, 65 insertions(+) > > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h > index 6b73848..46bcfe8 100644 > --- a/tools/libxl/libxl.h > +++ b/tools/libxl/libxl.h > @@ -1396,6 +1396,71 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int > nr_vtpms); > * > * This function does not interact with the guest and therefore > * cannot block on the guest. > + * > + * Controllers > + * --- > + * > + * Most devices are treated individually. Some classes of device, > + * however, like USB or SCSI, inherently have the need to have a > + * heiarchy of different levels, with lower-level devices "attached" > + * to higher-level ones. USB for instance has "controllers" at the > + * top, which have busses, on which are devices, which consist of > + * multiple interfaces. SCSI has "hosts" at the top, then busses, > + * targets, and LUNs. > + * > + * In that case, for each , there will be a set of funcitons ^^^ functions > + * and types for each . For example, for =usb, there > + * may be ctrl (controller) and dev (device), with ctrl being > + * level 0. > + * > + * libxl_device__ will act more or > + * less like top-level non-bus devices: they will either create or > + * accept a libxl_devid which will be unique within the > + * libxl_devid namespace. ? > + * > + * Lower-level devices must have a unique way to be identified. One > + * way to do this would be to name it via the name of the next level > + * up plus an index; for instance, . Another > + * way would be to have another devid namespace for that level. This > + * identifier will be used for queries and removals. > + * > + * Lower-level devices will will include in their ^ s/will will/will/ > + * libxl_device_ struct a field referring to the unique > + * index of the level above. For instance, libxl_device_usbdev might > + * contain the controller devid. > + * > + * In the case where there are multiple different ways to implement a > + * given device -- for instance, one which is fully PV and one which > + * uses an emulator -- the controller will contain a field which > + * specifies what type of implementation is used. The implementations > + * of individual devices will be known by the controller to which they > + * are attached. > + * > + * If libxl_device__add receives an empty reference to > + * the level above, it may return an error. Or it may (but is not > + * required to) automatically choose a suitable device in the level > + * above to which to attach the new device at this level. It may also > + * (but is not required to) automatically create a new device at the > + * level above if no suitable devices exist. Each class should > + * document its behavior. > + * > + * libxl_device__list will list all devices of > + * at in the domain. For example, libxl_class_usbctrl_list libxl_device_usbctrl_list > + * will list all usb controllers; libxl_class_usbdev_list will list libxl_device_usbdev_list > + * all usb devices across all controllers. > + * > + * For each class, the domain config file will contain a single list > + * for each level. libxl will first iterate through the list of > + * top-level devices, then iterate through each level down in turn, > + * adding devices to devices in the level above. For instance, there > + * will be one list for all usb controllers, and one list for all usb > + * devices. > + * > + * If libxl_device__add automatically creates > + * higher-level devices as nec
[Xen-devel] [xen-unstable test] 65066: regressions - FAIL
flight 65066 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/65066/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 64035 test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline untested test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 64035 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 64035 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 64035 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail like 64035 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail 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 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-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop 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-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 827db7b26384ce083df7154d77f13379b2cf4121 baseline version: xen 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Last test of basis64035 2015-11-10 08:01:11 Z 14 days Failing since 64149 2015-11-11 19:15:29 Z 13 days9 attempts Testing same since65066 2015-11-24 02:32:19 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Aravind Gopalakrishnan Bob Liu Boris Ostrovsky David Scott Feng Wu Ian Campbell Ian Jackson Jan Beulich Jim Fehlig Jonathan Davies Juergen Gross Oleksandr Tyshchenko Razvan Cojocaru Riku Voipio Roger Pau Monné Shannon Zhao Simon Rowe Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-prev pass build-i386-prev
Re: [Xen-devel] Xen 4.7 Development Update
On Mon, 2015-11-09 at 16:15 +, Wei Liu wrote: > = Timeline = > > We now adopt a fixed cut-off date scheme. We will release twice a > year. The upcoming 4.7 timeline are as followed: > > * Last posting date: March 18, 2016 > * Hard code freeze: April 1, 2016 > * RC1: TBD > * Release: July 1, 2016 > > Note that we don't have freeze exception scheme anymore. All patches > that wish to go into 4.7 must be posted no later than the last > posting > date. All patches posted after that date will be automatically queued > into next release. > > RCs will be arranged immediately after freeze. > > = Projects = == Hypervisor == === x86 === *Memory protection keys for user pages -Huaitong Han I want to see it in 4.7, I have sent the 1st version patchset for review, and continue working on it. Thanks Huaitong ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 65069: regressions - FAIL
flight 65069 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/65069/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 5 kernel-build fail REGR. vs. 60684 build-i386-pvops 5 kernel-build fail REGR. vs. 60684 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-amd64-amd64-pvgrub 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-rtds 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-qemuu-nested 1 build-check(1) blocked n/a test-amd64-amd64-i386-pvgrub 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qcow2 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-pygrub 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a version targeted for testing: linux3c54871e0f73f72bdc4e5ea1f9ab0ad42e3cd5dd baseline version: linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0 Last test of basis60684 2015-
[Xen-devel] [xen-unstable-smoke test] 65090: tolerable all pass - PUSHED
flight 65090 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/65090/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 0c3f24645b07b875bc1294fb4627f01e030690fe baseline version: xen 9b436680f081ae397e8c25ce2c23d3cd1359ce86 Last test of basis65076 2015-11-24 17:02:33 Z0 days Testing same since65083 2015-11-24 20:02:22 Z0 days2 attempts People who touched revisions under test: Boris Ostrovsky Jan Beulich jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable-smoke + revision=0c3f24645b07b875bc1294fb4627f01e030690fe + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 0c3f24645b07b875bc1294fb4627f01e030690fe + branch=xen-unstable-smoke + revision=0c3f24645b07b875bc1294fb4627f01e030690fe + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-unstable + '[' x0c3f24645b07b875bc1294fb4627f01e030690fe = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9419
Re: [Xen-devel] [PATCH v3 12/62] ACPICA: ACPI 6.0: Add changes for FADT table
On 2015/11/24 19:29, Jan Beulich wrote: On 17.11.15 at 10:40, wrote: >> From: Bob Moore >> >> ACPICA commit 72b0b6741990f619f6aaa915302836b7cbb41ac4 >> >> One new 64-bit field at the end of the table. >> FADT version is now 6. >> >> Link: https://github.com/acpica/acpica/commit/72b0b674 >> Signed-off-by: Bob Moore >> Signed-off-by: Lv Zheng >> Signed-off-by: Rafael J. Wysocki >> [Linux commit aeb823bbacc2a3aaee29eda5875b58a049fa1f78] >> Signed-off-by: Shannon Zhao >> --- >> xen/include/acpi/actbl.h | 17 ++--- >> 1 file changed, 10 insertions(+), 7 deletions(-) > > So while I applied this one after fixing it up, I'm not going to do any > further fixups to later patches I also meant to apply. I realize the > fixups may have been necessary because of me applying them in > other than the submitted sequence, but then again such general > imports from ACPICA/Linux should have been independent of > earlier changes. I.e. either earlier patches in the series wrongly > touch these headers, or there's a general problem with the series. > I will split this patch set in several parts and the first part would be the changes and updates of ACPI SPEC 5.0~6.0. So maybe you could apply them at next version. Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 65068: regressions - FAIL
flight 65068 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/65068/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: libvirt eebe58adeb08730d66fc407cf6024cd8ea319447 baseline version: libvirt 3c7590e0a435d833895fc7b5be489e53e223ad95 Last test of basis63340 2015-10-28 04:19:47 Z 27 days Failing since 63352 2015-10-29 04:20:29 Z 26 days 22 attempts Testing same since65068 2015-11-24 04:20:15 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Chen Hanxiao Cole Robinson Daniel P. Berrange Daniel Veillard Guido Günther Jim Fehlig Jiri Denemark Joao Martins John Ferlan Ján Tomko Laine Stump Luyao Huang Maxim Perevedentsev Michal Privoznik Michel Normand Mikhail Feoktistov Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Richard Weinberger Roman Bogorodskiy Stefan Berger Stefan Berger jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt fail build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass test-amd64-amd64-libvirt-xsm pass test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked test-amd64-amd64-libvirt-vhd pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 1591 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
On Mon, 2015-11-23 at 07:42 -0800, Yu-An(Victor) Chen wrote: > Hi all, > Hello, > So I was doing some experiments to evaluate RTDS scheduler > schedubility of real time tasks using 1vm with period of 1 and > budget of 1. The experiment results turn out as expected(perform > better than xen-credit). > > But when I tried to perform similar experiments with 2 vms (both with > now period of 1 and budget of 5000). The schedubility of real > time tasks turn out really bad. Even if I have one vm idling and the > other vm running the real time tasks, the schedubility of that vm is > still really poor(worse than xen-credit). Am I missing some > configuration I should have set for 2vm cases? Thank you > What is it that you are trying to prove with this setup? This is despite all Meng is already saying about the non-work conserving nature of RTDS, and about the LITMUS IPI bug. In fact, in general, real-time schedulers are really good at isolating workloads, with precise time guarantees. If you have stuff that needs to be done in 2 VMs, and you use RTDS for scheduling the 2 VMs, you'll get good and precisely characterized isolation between them. But if you put all the stuff in only 1 VM, and then limit its own utilization, all you are doing is making it hard for the things inside the VM itself to achieve their target performance, with respect to both an instance of RTDS where that VM has 100% utilization, as well as with (almost) any general purpose scheduler. Then, again, as Meng is saying, if you not only have "stuff" to do inside the VM, but you are interested in in-guest real-time, then the scheduling parameters of the VM(s) and the ones of the tasks in the guest(s), should be set according to a proper real-time hierarchical scheduling scheme that allows for guarantees to be met. Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] Restricted VPMU filter flags
This patch series fixes a minor bug with cpuid register usage for fixed PMC counts, and implements two VPMU filter flags. The VPMU feature of Xen is incredibly useful for performance analysis, however, it is currently all counters or nothing. In secure environments, there can be hesitation to enable access to all PMCs. This series introduces two new flags (in addition to the existing "bts"): vpmu=ipc: As the most restricted minimum set. This enables cycles, reference cycles, and instructions only. This is enough to calculate instructions per cycle (IPC). vpm=arch: This enables the 7 pre-defined architectural events as listed in cpuid, and in Table 18-1 of the Intel software developer's manual, vol 3B. There can be additional flags added later on, to allow access to other groups of PMCs. As an example of these flags, here is Linux perf running in a PVHVM guest with the new vpmu=ipc mode: root@vm0hvm:~# perf stat -d ./noploop Performance counter stats for './noploop': 1511.326375 task-clock (msec) #0.999 CPUs utilized 24 context-switches #0.016 K/sec 0 cpu-migrations#0.000 K/sec 113 page-faults #0.075 K/sec 5,028,638,883 cycles#3.327 GHz 0 stalled-cycles-frontend #0.00% frontend cycles idle 0 stalled-cycles-backend#0.00% backend cycles idle 20,043,427,933 instructions #3.99 insns per cycle 0 branches #0.000 K/sec 0 branch-misses #0.00% of all branches 0 L1-dcache-loads #0.000 K/sec 0 L1-dcache-load-misses #0.00% of all L1-dcache hits 0 LLC-loads #0.000 K/sec LLC-load-misses:HG Note that IPC is shown ("insns per cycle"), but other counters are not. Changes in v2: * feature flags can now be combined (eg, "vpmu=ipc,bts") * addressing review comments from Boris: * restrict DS_AREA and PEBS_ENABLE access when filters are in use * better variable types * include MSR_IA32_CMT_EVTSEL_UE_MASK flag Brendan Gregg (2): x86/VPMU: return correct fixed PMC count x86/VPMU: implement ipc and arch filter flags docs/misc/xen-command-line.markdown | 14 +- xen/arch/x86/cpu/vpmu.c | 51 --- xen/arch/x86/cpu/vpmu_intel.c | 54 ++--- xen/include/asm-x86/msr-index.h | 1 + xen/include/public/pmu.h| 14 -- 5 files changed, 118 insertions(+), 16 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] x86/VPMU: return correct fixed PMC count
Fixes a register typo. Signed-off-by: Brendan Gregg --- xen/arch/x86/cpu/vpmu_intel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 12f80ae..8d83a1a 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -166,10 +166,10 @@ static int core2_get_arch_pmc_count(void) */ static int core2_get_fixed_pmc_count(void) { -u32 eax; +u32 edx; -eax = cpuid_eax(0xa); -return MASK_EXTR(eax, PMU_FIXED_NR_MASK); +edx = cpuid_edx(0xa); +return MASK_EXTR(edx, PMU_FIXED_NR_MASK); } /* edx bits 5-12: Bit width of fixed-function performance counters */ -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] x86/VPMU: implement ipc and arch filter flags
This introduces a way to have a restricted VPMU, by specifying one of two predefined groups of PMCs to make available. For secure environments, this allows the VPMU to be used without needing to enable all PMCs. Signed-off-by: Brendan Gregg --- docs/misc/xen-command-line.markdown | 14 +- xen/arch/x86/cpu/vpmu.c | 51 + xen/arch/x86/cpu/vpmu_intel.c | 48 ++ xen/include/asm-x86/msr-index.h | 1 + xen/include/public/pmu.h| 14 -- 5 files changed, 115 insertions(+), 13 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index 70daa84..6055a68 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -1452,7 +1452,7 @@ Use Virtual Processor ID support if available. This prevents the need for TLB flushes on VM entry and exit, increasing performance. ### vpmu -> `= ( bts )` +> `= ( | { bts | ipc | arch [, ...] } )` > Default: `off` @@ -1468,6 +1468,18 @@ wrong behaviour (see handle\_pmc\_quirk()). If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS) feature is switched on on Intel processors supporting this feature. +vpmu=ipc enables performance monitoring, but restricts the counters to the +most minimum set possible: instructions, cycles, and reference cycles. These +can be used to calculate instructions per cycle (IPC). + +vpmu=arch enables performance monitoring, but restricts the counters to the +pre-defined architectural events only. These are exposed by cpuid, and listed +in Table 18-1 from the Intel 64 and IA-32 Architectures Software Developer's +Manual, Volume 3B, System Programming Guide, Part 2. + +If a boolean is not used, combinations of flags are allowed, comma separated. +For example, vpmu=arch,bts. + Note that if **watchdog** option is also specified vpmu will be turned off. *Warning:* diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c index 2f5156a..bb0ca37 100644 --- a/xen/arch/x86/cpu/vpmu.c +++ b/xen/arch/x86/cpu/vpmu.c @@ -43,33 +43,64 @@ CHECK_pmu_data; CHECK_pmu_params; /* - * "vpmu" : vpmu generally enabled - * "vpmu=off" : vpmu generally disabled - * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on. + * "vpmu" : vpmu generally enabled (all counters) + * "vpmu=off" : vpmu generally disabled + * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on. + * "vpmu=ipc" : vpmu enabled for IPC counters only (most restrictive) + * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive) + * flag combinations are allowed, eg, "vpmu=ipc,bts". */ static unsigned int __read_mostly opt_vpmu_enabled; unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF; unsigned int __read_mostly vpmu_features = 0; -static void parse_vpmu_param(char *s); -custom_param("vpmu", parse_vpmu_param); +static void parse_vpmu_params(char *s); +custom_param("vpmu", parse_vpmu_params); static DEFINE_SPINLOCK(vpmu_lock); static unsigned vpmu_count; static DEFINE_PER_CPU(struct vcpu *, last_vcpu); -static void __init parse_vpmu_param(char *s) +static int parse_vpmu_param(char *s, int len) { +if ( ! *s || ! len ) +return 0; +if ( !strncmp(s, "bts", len) ) +vpmu_features |= XENPMU_FEATURE_INTEL_BTS; +else if ( !strncmp(s, "ipc", len) ) +vpmu_features |= XENPMU_FEATURE_IPC_ONLY; +else if ( !strncmp(s, "arch", len) ) +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY; +else if ( *s ) +{ +return 1; +} +return 0; +} + +static void __init parse_vpmu_params(char *s) +{ +bool_t badflag = 0; +char *sep, *p = s; + switch ( parse_bool(s) ) { case 0: break; default: -if ( !strcmp(s, "bts") ) -vpmu_features |= XENPMU_FEATURE_INTEL_BTS; -else if ( *s ) +sep = strchr(p, ','); +while (sep != NULL) +{ +if ( parse_vpmu_param(p, sep - p) ) +badflag = 1; +p = sep + 1; +sep = strchr(p, ','); +} +sep = strchr(p, 0); +parse_vpmu_param(p, sep - p); +if ( badflag ) { -printk("VPMU: unknown flag: %s - vpmu disabled!\n", s); +printk("VPMU: unknown flags: %s - vpmu disabled!\n", s); break; } /* fall through */ diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c index 8d83a1a..b26a20b 100644 --- a/xen/arch/x86/cpu/vpmu_intel.c +++ b/xen/arch/x86/cpu/vpmu_intel.c @@ -602,12 +602,19 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t msr_content, "MSR_PERF_GLOBAL_STATUS(0x38E)!\n"); return -EINVAL; case MSR_IA32_PEBS_ENABLE: +if ( vpmu_features & XENPMU_FEATURE_IPC_ONLY || + vpmu_features & XENPMU_FEATURE_ARCH_ONLY ) +return -EINVAL; if ( ms
[Xen-devel] [ovmf baseline-only test] 38337: all pass
This run is configured for baseline tests only. flight 38337 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38337/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f baseline version: ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6 Last test of basis38327 2015-11-24 01:20:56 Z0 days Testing same since38337 2015-11-24 20:49:54 Z0 days1 attempts People who touched revisions under test: Dandan Bi Eric Dong Heyi Guo Leif Lindholm jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f Author: Leif Lindholm Date: Mon Nov 23 19:34:40 2015 + ShellBinPkg: Arm/AArch64 Shell binary update. The binaries of ShellBinPkg are generated with ShellPkg from r18915. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leif Lindholm Reviewed-by: Jaben Carsey git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18925 6f19259b-4bc3-4df7-8a09-765794883524 commit ce7690e267dc3205357e0d0e3a57e2b6fd1de895 Author: Dandan Bi Date: Mon Nov 23 09:37:24 2015 + MdeModulePkg:Refine the UiApp Use new created libraries(Boot Manager,Device Manager,Boot Maintenance Manager) in UiApp.So remove and refine relative code in UiApp.And update the Nt32Pkg.dsc and MdeModulePkg.dsc. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18924 6f19259b-4bc3-4df7-8a09-765794883524 commit 4af04335ac9aeb1802b995b102117b6f9de46809 Author: Dandan Bi Date: Mon Nov 23 09:34:55 2015 + MdeModulePkg:Create Boot Maintenance Manager Library Split the boot maintenance manager library from UiApp in MdeModulePkg/Application and put the library in MdeModulePkg/Library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18923 6f19259b-4bc3-4df7-8a09-765794883524 commit 32465d9ae7eed891154780f0b13fabf0b15ae7c3 Author: Dandan Bi Date: Mon Nov 23 09:33:42 2015 + MdeModulePkg:Create Device Manager Library Split the device manager library from UiApp in MdeModulePkg/Application and put the library in MdeModulePkg/Library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18922 6f19259b-4bc3-4df7-8a09-765794883524 commit 3a2dc0f5a9e311a840ffd69571a4a264c9e1c3c0 Author: Dandan Bi Date: Mon Nov 23 09:32:08 2015 + MdeModulePkg:Create Boot Manager Library Split the boot manager library from UiApp in MdeModulePkg/Application and put the library in MdeModulePkg/Library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi Reviewed-by: Eric Dong Reviewed-by: Liming Gao git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18921 6f19259b-4bc3-4df7-8a09-765794883524 commit e266db592bd41082349bc6b35be809ff2053a299 Author: Heyi Guo Date: Mon Nov 23 07:48:33 2015 + ArmPkg: Invalidate cache after allocating UC memory It is implied that the memory returned from UncachedMemoryAllocationLib should have cache invalidated. So we invalidate memory range after changing memory attribute to uncached. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-o
[Xen-devel] [xen-unstable-smoke test] 65083: regressions - FAIL
flight 65083 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/65083/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 65076 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 0c3f24645b07b875bc1294fb4627f01e030690fe baseline version: xen 9b436680f081ae397e8c25ce2c23d3cd1359ce86 Last test of basis65076 2015-11-24 17:02:33 Z0 days Testing same since65083 2015-11-24 20:02:22 Z0 days1 attempts People who touched revisions under test: Boris Ostrovsky Jan Beulich jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl fail test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. commit 0c3f24645b07b875bc1294fb4627f01e030690fe Author: Boris Ostrovsky Date: Tue Nov 24 18:33:08 2015 +0100 x86/VPMU: Initialize VPMU's lvtpc vector If a guest sets up performance counters so that they can generate a PMC interrupt but does not initilaize APIC LVTPC register the resulting interrupt will cause an APIC error. Note that a guest deciding to clear LVTPC in order to unduce the error will not be successful in achieving its goal: emulation code only looks at the mask bit and always sets the vector to PMU_APIC_VECTOR. Only the initial value of LVTPC (which is zero) that gets loaded into APIC as result of PMC initialization is the problem. Signed-off-by: Boris Ostrovsky commit c03480cf5c4e96fb4afb2237ad0a3cac7162564a Author: Jan Beulich Date: Tue Nov 24 18:32:20 2015 +0100 x86/vPMU: document as unsupported This is XSA-163. Signed-off-by: Jan Beulich (qemu changes not included) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.6-testing test] 65062: regressions - trouble: blocked/broken/fail/pass
flight 65062 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/65062/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i3865 xen-build fail REGR. vs. 63449 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 64988 REGR. vs. 63449 Tests which are failing intermittently (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 64988 pass in 65028 test-armhf-armhf-xl-multivcpu 6 xen-boot fail in 64988 pass in 65062 test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 64988 pass in 65062 test-armhf-armhf-libvirt-xsm 11 guest-startfail in 65028 pass in 65062 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail in 65028 pass in 65062 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 64988 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 65028 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested 3 host-install(3) broken baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail blocked in 63449 Tests which did not succeed, but are not blocking: build-i386-rumpuserxen1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-raw1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 65028 never pass test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 65028 never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 65028 never pass test-amd64-i386-libvirt 12 migrate-support-check fail in 65028 never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 65028 never pass test-amd64-i386-libvirt-xsm 12 migrate-support-check fail in 65028 never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail in 65028 never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 65028 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migr
[Xen-devel] [linux-linus test] 65059: regressions - FAIL
flight 65059 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/65059/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 59254 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 59254 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-libvirt 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-xl-raw6 xen-bootfail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested
[Xen-devel] [ovmf test] 65064: all pass - PUSHED
flight 65064 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/65064/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f baseline version: ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6 Last test of basis65031 2015-11-23 02:12:10 Z1 days Testing same since65064 2015-11-24 01:12:13 Z0 days1 attempts People who touched revisions under test: Dandan Bi Eric Dong Heyi Guo Leif Lindholm jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=ovmf + revision=63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f + branch=ovmf + revision=63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=ovmf + xenbranch=xen-unstable + '[' xovmf = xlinux ']' + linuxbranch= + '[' x = x ']' + qemuubranch=qemu-upstream-unstable + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable + prevxenbranch=xen-4.6-testing + '[' x63a9e0d6f98d65b93f2a4cfc1977b1c0c5052b5f = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"} or die $!; ' +++ local cache=git://cache:9419/ +++ '[' xgit://cache:9419/ '!=' x ']' +++ echo 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=
Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion
RFC. Boot tested on VMware Fusion, and on a 2-socket Xeon server. diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h index ea07888..a41ce2d 100644 --- a/xen/include/asm-x86/smp.h +++ b/xen/include/asm-x86/smp.h @@ -67,7 +67,7 @@ extern unsigned int nr_sockets; void set_nr_sockets(void); /* Representing HT and core siblings in each socket. */ -extern cpumask_t **socket_cpumask; +cpumask_t *socket_cpumask(unsigned int socket); #endif /* !__ASSEMBLY__ */ diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c index 0946992..6aadaac 100644 --- a/xen/arch/x86/smpboot.c +++ b/xen/arch/x86/smpboot.c @@ -60,7 +60,7 @@ cpumask_t cpu_online_map __read_mostly; EXPORT_SYMBOL(cpu_online_map); unsigned int __read_mostly nr_sockets; -cpumask_t **__read_mostly socket_cpumask; +static struct radix_tree_root socket_cpumask_tree; static cpumask_t *secondary_socket_cpumask; struct cpuinfo_x86 cpu_data[NR_CPUS]; @@ -81,6 +81,11 @@ static enum cpu_state { void *stack_base[NR_CPUS]; +cpumask_t *socket_cpumask(unsigned int socket) +{ +return radix_tree_lookup(&socket_cpumask_tree, socket); +} + static void smp_store_cpu_info(int id) { struct cpuinfo_x86 *c = cpu_data + id; @@ -92,9 +97,9 @@ static void smp_store_cpu_info(int id) identify_cpu(c); socket = cpu_to_socket(id); -if ( !socket_cpumask[socket] ) +if ( radix_tree_insert(&socket_cpumask_tree, socket, + secondary_socket_cpumask) == 0 ) { -socket_cpumask[socket] = secondary_socket_cpumask; secondary_socket_cpumask = NULL; } } @@ -258,7 +263,7 @@ static void set_cpu_sibling_map(int cpu) cpumask_set_cpu(cpu, &cpu_sibling_setup_map); -cpumask_set_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]); +cpumask_set_cpu(cpu, socket_cpumask(cpu_to_socket(cpu))); if ( c[cpu].x86_num_siblings > 1 ) { @@ -666,11 +671,12 @@ static void cpu_smpboot_free(unsigned int cpu) { unsigned int order, socket = cpu_to_socket(cpu); struct cpuinfo_x86 *c = cpu_data; +cpumask_t *m = socket_cpumask(socket); -if ( cpumask_empty(socket_cpumask[socket]) ) +if ( m && cpumask_empty(m) ) { -xfree(socket_cpumask[socket]); -socket_cpumask[socket] = NULL; +radix_tree_delete(&socket_cpumask_tree, socket); +xfree(m); } c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID; @@ -804,6 +810,8 @@ static struct notifier_block cpu_smpboot_nfb = { void __init smp_prepare_cpus(unsigned int max_cpus) { +cpumask_t *m; + register_cpu_notifier(&cpu_smpboot_nfb); mtrr_aps_sync_begin(); @@ -819,9 +827,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus) set_nr_sockets(); -socket_cpumask = xzalloc_array(cpumask_t *, nr_sockets); -if ( socket_cpumask == NULL || - (socket_cpumask[cpu_to_socket(0)] = xzalloc(cpumask_t)) == NULL ) +radix_tree_init(&socket_cpumask_tree); +if ( (m = xzalloc(cpumask_t)) == NULL || + radix_tree_insert(&socket_cpumask_tree, cpu_to_socket(0), m) != 0 ) panic("No memory for socket CPU siblings map"); if ( !zalloc_cpumask_var(&per_cpu(cpu_sibling_mask, 0)) || @@ -888,7 +896,7 @@ remove_siblinginfo(int cpu) { int sibling; -cpumask_clear_cpu(cpu, socket_cpumask[cpu_to_socket(cpu)]); +cpumask_clear_cpu(cpu, socket_cpumask(cpu_to_socket(cpu))); for_each_cpu ( sibling, per_cpu(cpu_core_mask, cpu) ) { diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c index c0daa2e..7acb3d9 100644 --- a/xen/arch/x86/psr.c +++ b/xen/arch/x86/psr.c @@ -52,14 +52,6 @@ static DEFINE_PER_CPU(struct psr_assoc, psr_assoc); static struct psr_cat_cbm *temp_cos_to_cbm; -static unsigned int get_socket_cpu(unsigned int socket) -{ -if ( likely(socket < nr_sockets) ) -return cpumask_any(socket_cpumask[socket]); - -return nr_cpu_ids; -} - static void __init parse_psr_bool(char *s, char *value, char *feature, unsigned int mask) { @@ -331,7 +323,8 @@ static int write_l3_cbm(unsigned int socket, unsigned int cos, uint64_t cbm) do_write_l3_cbm(&info); else { -unsigned int cpu = get_socket_cpu(socket); +cpumask_t *m = socket_cpumask(socket); +unsigned int cpu = m ? cpumask_any(m) : nr_cpu_ids; if ( cpu >= nr_cpu_ids ) return -ENOTSOCK; @@ -503,8 +496,9 @@ static void cat_cpu_init(void) static void cat_cpu_fini(unsigned int cpu) { unsigned int socket = cpu_to_socket(cpu); +cpumask_t *m = socket_cpumask(socket); -if ( !socket_cpumask[socket] || cpumask_empty(socket_cpumask[socket]) ) +if ( !m || cpumask_empty(m) ) { struct psr_cat_socket_info *info = cat_socket_info + socket; On Tue, Nov 24, 2015 at 7:20 AM, Jan Beulich wrote: On 24.11.15 at 15:13, wrote: >> On Tue, Nov 24, 2015 at 2:34 AM, Jan Beulich wrote: >>> Bottom line - for the moment I do
[Xen-devel] [PATCHv2] 2/3] update outdated header comment on privcmd.h
The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd as well. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein Acked-by: Ian Jackson --- tools/include/xen-sys/FreeBSD/privcmd.h| 2 +- tools/include/xen-sys/Linux/privcmd.h | 2 +- tools/include/xen-sys/NetBSD/privcmd.h | 2 +- tools/include/xen-sys/NetBSDRump/privcmd.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/include/xen-sys/FreeBSD/privcmd.h b/tools/include/xen-sys/FreeBSD/privcmd.h index 0434d4d..cf1241f 100644 --- a/tools/include/xen-sys/FreeBSD/privcmd.h +++ b/tools/include/xen-sys/FreeBSD/privcmd.h @@ -1,7 +1,7 @@ /** * privcmd.h * - * Interface to /proc/xen/privcmd. + * Interface to /dev/xen/privcmd. * * Copyright (c) 2003-2005, K A Fraser * diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h index 5be860a..e4e666a 100644 --- a/tools/include/xen-sys/Linux/privcmd.h +++ b/tools/include/xen-sys/Linux/privcmd.h @@ -1,7 +1,7 @@ /** * privcmd.h * - * Interface to /proc/xen/privcmd. + * Interface to /dev/xen/privcmd. * * Copyright (c) 2003-2005, K A Fraser * diff --git a/tools/include/xen-sys/NetBSD/privcmd.h b/tools/include/xen-sys/NetBSD/privcmd.h index 1296b30..555bad9 100644 --- a/tools/include/xen-sys/NetBSD/privcmd.h +++ b/tools/include/xen-sys/NetBSD/privcmd.h @@ -30,7 +30,7 @@ #ifndef __NetBSD_PRIVCMD_H__ #define __NetBSD_PRIVCMD_H__ -/* Interface to /proc/xen/privcmd */ +/* Interface to /dev/xen/privcmd */ typedef struct privcmd_hypercall { diff --git a/tools/include/xen-sys/NetBSDRump/privcmd.h b/tools/include/xen-sys/NetBSDRump/privcmd.h index 1296b30..555bad9 100644 --- a/tools/include/xen-sys/NetBSDRump/privcmd.h +++ b/tools/include/xen-sys/NetBSDRump/privcmd.h @@ -30,7 +30,7 @@ #ifndef __NetBSD_PRIVCMD_H__ #define __NetBSD_PRIVCMD_H__ -/* Interface to /proc/xen/privcmd */ +/* Interface to /dev/xen/privcmd */ typedef struct privcmd_hypercall { -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2] 1/3] libxc: prefer using privcmd character device
Prefer using the character device over the proc file if the character device exists. This follows similar conversions of xenbus to avoid issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/libxc/xc_linux_osdep.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index 76c55ff..c078b3d 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -46,7 +46,14 @@ static xc_osdep_handle linux_privcmd_open(xc_interface *xch) { int flags, saved_errno; -int fd = open("/proc/xen/privcmd", O_RDWR); +int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer interface */ + +if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || + errno == ENODEV || errno == EACCES )) +{ +/* Fallback to /proc/xen/privcmd */ +fd = open("/proc/xen/privcmd", O_RDWR); +} if ( fd == -1 ) { -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv2] 3/3] xendomains initscript: test for privcmd char device
Allow the init script to continue if either the character device or the proc file is available. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein Acked-by: Ian Jackson --- tools/hotplug/Linux/xendomains.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in index 0603842..686f061 100644 --- a/tools/hotplug/Linux/xendomains.in +++ b/tools/hotplug/Linux/xendomains.in @@ -45,7 +45,7 @@ fi # Correct exit code would probably be 5, but it's enough # if xend complains if we're not running as privileged domain -if ! [ -e /proc/xen/privcmd ]; then +if ! [ -e /dev/xen/privcmd ] || [ -e /proc/xen/privcmd ]; then exit 0 fi -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device
On 11/24/15 1:19 PM, Doug Goldstein wrote: > On 11/24/15 12:53 PM, Ian Jackson wrote: >> Doug Goldstein writes ("[PATCH 3/4] gdbsx: prefer privcmd character device"): >>> Prefer using the character device over the proc file if the character >>> device exists. >> >> I think this common logic (which also appears in your 1/4 patch) >> should be factored out. >> >> Could gdbsx not use a libxc handle ? >> >> Ian. >> > > I agree. I actually emailed the maintainer about this but his address > bounced so I left it as the simpler patch instead. I can make that > chance and resubmit if you'd prefer. > I'll just drop this out of the v2 and look at improving it in another series. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/3] arm: export platform_op XENPF_settime64
On 16/11/15 08:08, Ian Campbell wrote: On Thu, 2015-11-12 at 17:46 +, Stefano Stabellini wrote: Call update_domain_wallclock_time at domain initialization. Set time_offset_seconds to the number of seconds between physical boot and domain initialization: it is going to be used to get/set the wallclock time. Add time_offset_seconds to system_time when before calling do_settime, so that system_time actually accounts for all the time in nsec between machine boot and when the wallclock was set. Expose xsm_platform_op to ARM. Signed-off-by: Stefano Stabellini Acked-by: Ian Campbell An aside:[...] @@ -1332,6 +1332,75 @@ static int flask_deassign_dtdevice(struct domain *d, const char *dtpath) } #endif /* HAS_PASSTHROUGH && HAS_DEVICE_TREE */ +static int flask_platform_op(uint32_t op) +{ +switch ( op ) +{ +#ifdef CONFIG_X86 +/* These operations have their own XSM hooks */ +case XENPF_cpu_online: +case XENPF_cpu_offline: +case XENPF_cpu_hotadd: +case XENPF_mem_hotadd: +return 0; Should this not then be an error (e.g. fail closed)? During the invocation of these operations, two XSM hooks are called: this one (from above the switch) and the individual hook (inside the switch). This hook needs to allow access so that the more detailed hook is called. Also, although only implemented today for x86 they don't seem inherently any more x86 specific than many of the other things below, so maybe the ifdef could be ditched? The #ifdef is there mostly as a failsafe reminder to ensure that the implementation for other architectures actually calls the same XSM hooks that the x86 version does. -- Daniel De Graaf National Security Agency ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] qemu-xen.git trouble with tags of stable branches
Hello, http://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=summary looking at the tags for the 2 stable branches which are involved in the recent patch to xen.gitunifying the qemu trees. tags: qemu-xen-4.6.0qemu-xen-4.5.2 The revisions pointed to in the above tags are not unique and cause wrong results in git queries like:git log --pretty=oneline qemu-xen-4.5.2..HEAD | wc -l -> 8419 git log --pretty=oneline qemu-xen-4.6.0..HEAD | wc -l -> 4168 the last query should eval to about 85. In a quick browse of the web view of the repo I see the same patch commit multiple times, under different hashes.So this repo is new and still only used in staging and if there are errors there is nothing serious, not yet anyway. Thanks for your attention,PryMar56 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable bisection] complete test-amd64-i386-rumpuserxen-i386
branch xen-unstable xenbranch xen-unstable job test-amd64-i386-rumpuserxen-i386 testid guest-start Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: xen git://xenbits.xen.org/xen.git Bug introduced: 81a76e4b12961a9f54f5021809074196dfe6dbba Bug not present: cd353959cdfbe06c2a6abfd73f03f40b84e1e3f1 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/65067/ commit 81a76e4b12961a9f54f5021809074196dfe6dbba Author: Juergen Gross Date: Thu Nov 12 14:43:35 2015 +0100 libxc: rework of domain builder's page table handler In order to prepare a p2m list outside of the initial kernel mapping do a rework of the domain builder's page table handler. The goal is to be able to use common helpers for page table allocation and setup for initial kernel page tables and page tables mapping the p2m list. This is achieved by supporting multiple mapping areas. The mapped virtual addresses of the single areas must not overlap, while the page tables of a new area added might already be partially present. Especially the top level page table is existing only once, of course. Currently restrict the number of mappings to 1 because the only mapping now is the initial mapping created by toolstack. There should not be behaviour change and guest visible change introduced. Signed-off-by: Juergen Gross Reviewed-by: Wei Liu For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-i386-rumpuserxen-i386.guest-start.html Revision IDs in each graph node refer, respectively, to the Trees above. Running cs-bisection-step --graph-out=/home/logs/results/bisect/xen-unstable/test-amd64-i386-rumpuserxen-i386.guest-start --summary-out=tmp/65067.bisection-summary --basis-template=64035 --blessings=real,real-bisect xen-unstable test-amd64-i386-rumpuserxen-i386 guest-start Searching for failure / basis pass: 65029 fail [host=rimava1] / 64335 [host=huxelrebe1] 64205 [host=chardonnay1] 64149 [host=pinot1] 64035 [host=baroque1] 63662 [host=italia0] 63540 [host=italia1] 63475 [host=huxelrebe1] 63400 [host=rimava0] 63375 [host=chardonnay0] 63356 [host=fiano0] 63343 [host=elbling1] 63211 [host=italia0] 63147 [host=chardonnay1] 63080 [host=chardonnay1] 63058 [host=chardonnay1] 63024 [host=baroque1] 63004 [host=italia1] 62990 [host=fiano1] 62968 [host=chardonnay0] 62956 [host=chardonnay0] 62946 [host=huxelrebe1] 62938 [host=merlot0] 62835 [host=fiano0] 62733 [host=huxelrebe0] 62711 [host=italia0] 62646 [host=elbling0] 62583 [host=elbling0] 62500 [host=elbling0] 62416 [host=pinot0] 62322 [host=pinot0] 62265 [host=pinot0] 62156 [host=chardonnay1] 62080 [host=chardonnay1] 62004 [host=chardonnay1] 61821 [host=chardonnay1] 61739 [host=fiano0] 61521 [host=italia0] 61306 [host=pinot1] 61248 [host=pinot1] 61059 [host=pinot1] 60971 [host=huxelrebe1] 60878 [host=merlot1] 60841 [host=italia1] 60810 [host= pinot0] 60775 [host=pinot0] 60711 [host=pinot0] 60683 [host=pinot0] 60662 [host=merlot1] 60647 [host=italia0] 60639 [host=huxelrebe1] 60624 [host=elbling0] 60603 [host=elbling0] 60541 [host=elbling0] 60199 [host=pinot1] 60154 [host=pinot1] 60107 [host=pinot1] 60076 [host=pinot1] 60023 [host=pinot1] 59910 [host=huxelrebe1] 59833 [host=fiano0] 59817 [host=elbling1] 59795 [host=chardonnay0] 59772 [host=elbling0] 59699 [host=fiano1] 59681 [host=fiano1] 59654 ok. Failure / basis pass flights: 65029 / 59654 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://xenbits.xen.org/linux-pvops.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: rumpuserxen git://xenbits.xen.org/rumpuser-xen.git Tree: rumpuserxen_buildrumpsh https://github.com/rumpkernel/buildrump.sh.git Tree: rumpuserxen_netbsdsrc https://github.com/rumpkernel/src-netbsd Tree: xen git://xenbits.xen.org/xen.git Latest 769b79eb206ad5b0249a08665fefb913c3d1998e c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad 47b1a5eef43cce61bf018500bddf751ecf9de38e 17a547ca2943a7d98780a0366966c3aef29093a6 aec38117171b1fef50d6c3cf42dbd176907c7e18 Basis pass 3cdf91941d7490ba1d0a72729a667c42b489b23a c530a75c1e6a472b0eb9558310
Re: [Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device
On 11/24/15 12:53 PM, Ian Jackson wrote: > Doug Goldstein writes ("[PATCH 3/4] gdbsx: prefer privcmd character device"): >> Prefer using the character device over the proc file if the character >> device exists. > > I think this common logic (which also appears in your 1/4 patch) > should be factored out. > > Could gdbsx not use a libxc handle ? > > Ian. > I agree. I actually emailed the maintainer about this but his address bounced so I left it as the simpler patch instead. I can make that chance and resubmit if you'd prefer. -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-upstream-unstable baseline-only test] 38334: regressions - FAIL
This run is configured for baseline tests only. flight 38334 qemu-upstream-unstable real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38334/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-build fail REGR. vs. 38193 build-amd64-xsm 5 xen-build fail REGR. vs. 38193 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-vhd 9 debian-di-install fail REGR. vs. 38193 test-amd64-amd64-pygrub 20 guest-start/debian.repeat fail blocked in 38193 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 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-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail 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-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 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-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-qemuu-nested 16 debian-hvm-install/l1/l2 fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass version targeted for testing: qemuu3fb401edbd8e9741c611bfddf6a2032ca91f55ed baseline version: qemuu816609b2841297925a223ec377c336360e044ee5 Last test of basis38193 2015-10-21 15:19:25 Z 34 days Testing same since38334 2015-11-24 13:50:55 Z0 days1 attempts 346 people touched revisions under test, not listing them all jobs: build-amd64-xsm fail build-armhf-xsm pass build-i386-xsm fail build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-i386-libvirt-
[Xen-devel] [xen-unstable-smoke test] 65076: tolerable all pass - PUSHED
flight 65076 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/65076/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass version targeted for testing: xen 9b436680f081ae397e8c25ce2c23d3cd1359ce86 baseline version: xen cb6be0d5c7e9837154077e737e97e68849d1ab4c Last test of basis65074 2015-11-24 15:01:46 Z0 days Testing same since65076 2015-11-24 17:02:33 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Ian Campbell Ian Jackson Jan Beulich Joe Perches Julien Grall Olaf Hering Paul Durrant Samuel Thibault Wei Liu jobs: build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-amd64-amd64-xl-qemuu-debianhvm-i386 pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : + branch=xen-unstable-smoke + revision=9b436680f081ae397e8c25ce2c23d3cd1359ce86 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x '!=' x/home/osstest/repos/lock ']' ++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock ++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 9b436680f081ae397e8c25ce2c23d3cd1359ce86 + branch=xen-unstable-smoke + revision=9b436680f081ae397e8c25ce2c23d3cd1359ce86 + . ./cri-lock-repos ++ . ./cri-common +++ . ./cri-getconfig +++ umask 002 +++ getrepos getconfig Repos perl -e ' use Osstest; readglobalconfig(); print $c{"Repos"} or die $!; ' +++ local repos=/home/osstest/repos +++ '[' -z /home/osstest/repos ']' +++ '[' '!' -d /home/osstest/repos ']' +++ echo /home/osstest/repos ++ repos=/home/osstest/repos ++ repos_lock=/home/osstest/repos/lock ++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']' + . ./cri-common ++ . ./cri-getconfig ++ umask 002 + select_xenbranch + case "$branch" in + tree=xen + xenbranch=xen-unstable-smoke + qemuubranch=qemu-upstream-unstable + '[' xxen = xlinux ']' + linuxbranch= + '[' xqemu-upstream-unstable = x ']' + select_prevxenbranch ++ ./cri-getprevxenbranch xen-unstable-smoke + prevxenbranch=xen-unstable + '[' x9b436680f081ae397e8c25ce2c23d3cd1359ce86 = x ']' + : tested/2.6.39.x + . ./ap-common ++ : osst...@xenbits.xen.org +++ getconfig OsstestUpstream +++ perl -e ' use Osstest; readglobalconfig(); print $c{"OsstestUpstream"} or die $!; ' ++ : ++ : git://xenbits.xen.org/xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/xen.git ++ : git://xenbits.xen.org/qemu-xen-traditional.git ++ : git://git.kernel.org ++ : git://git.kernel.org/pub/scm/linux/kernel/git ++ : git ++ : git://xenbits.xen.org/libvirt.git ++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git ++ : git://xenbits.xen.org/libvirt.git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : git ++ : git://xenbits.xen.org/rumpuser-xen.git ++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git +++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]' +++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src +++ local 'options=[fetch=try]' getconfig GitCacheProxy perl -e ' use Osstest; readglobalconfig(); print $c{"GitCacheProxy"}
Re: [Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device
Doug Goldstein writes ("[PATCH 3/4] gdbsx: prefer privcmd character device"): > Prefer using the character device over the proc file if the character > device exists. I think this common logic (which also appears in your 1/4 patch) should be factored out. Could gdbsx not use a libxc handle ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 4/4] xendomains initscript: test for privcmd char device
Doug Goldstein writes ("[PATCH 4/4] xendomains initscript: test for privcmd char device"): > Allow the init script to continue if either the character device or the > proc file is available. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/4] libxc: prefer using privcmd character device
Doug Goldstein writes ("[PATCH 1/4] libxc: prefer using privcmd character device"): > Prefer using the character device over the proc file if the character > device exists. This follows similar conversions of xenbus to avoid > issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer. This is a fine change, but > -int fd = open("/proc/xen/privcmd", O_RDWR); > +int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer > interface */ > + > +if ( fd == -1 ) > +{ I think this should check the errno value. I expect that any of ENOENT, ENXIO and ENODEV should be tolerated - but others should probaby be a fatal error. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] update outdated header comment on privcmd.h
Doug Goldstein writes ("[PATCH 2/4] update outdated header comment on privcmd.h"): > The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux > has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd > as well. Acked-by: Ian Jackson ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/4] gdbsx: prefer privcmd character device
Prefer using the character device over the proc file if the character device exists. CC: Mukesh Rathor CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/debugger/gdbsx/xg/xg_main.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/tools/debugger/gdbsx/xg/xg_main.c b/tools/debugger/gdbsx/xg/xg_main.c index 8c8a402..9364aee 100644 --- a/tools/debugger/gdbsx/xg/xg_main.c +++ b/tools/debugger/gdbsx/xg/xg_main.c @@ -127,9 +127,11 @@ xg_init() int flags, saved_errno; XGTRC("E\n"); -if ((_dom0_fd=open("/proc/xen/privcmd", O_RDWR)) == -1) { -perror("Failed to open /proc/xen/privcmd\n"); -return -1; +if ((_dom0_fd=open("/dev/xen/privcmd", O_RDWR)) == -1) { +if ((_dom0_fd=open("/proc/xen/privcmd", O_RDWR)) == -1) { +perror("Failed to open /dev/xen/privcmd or /proc/xen/privcmd\n"); +return -1; +} } /* Although we return the file handle as the 'xc handle' the API * does not specify / guarentee that this integer is in fact -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/4] update outdated header comment on privcmd.h
The BSDs have always accessed privcmd via /dev/xen/privcmd while Linux has used /proc/xen/privcmd but things are shifting to /dev/xen/privcmd as well. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/include/xen-sys/FreeBSD/privcmd.h| 2 +- tools/include/xen-sys/Linux/privcmd.h | 2 +- tools/include/xen-sys/NetBSD/privcmd.h | 2 +- tools/include/xen-sys/NetBSDRump/privcmd.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/include/xen-sys/FreeBSD/privcmd.h b/tools/include/xen-sys/FreeBSD/privcmd.h index 0434d4d..cf1241f 100644 --- a/tools/include/xen-sys/FreeBSD/privcmd.h +++ b/tools/include/xen-sys/FreeBSD/privcmd.h @@ -1,7 +1,7 @@ /** * privcmd.h * - * Interface to /proc/xen/privcmd. + * Interface to /dev/xen/privcmd. * * Copyright (c) 2003-2005, K A Fraser * diff --git a/tools/include/xen-sys/Linux/privcmd.h b/tools/include/xen-sys/Linux/privcmd.h index 5be860a..e4e666a 100644 --- a/tools/include/xen-sys/Linux/privcmd.h +++ b/tools/include/xen-sys/Linux/privcmd.h @@ -1,7 +1,7 @@ /** * privcmd.h * - * Interface to /proc/xen/privcmd. + * Interface to /dev/xen/privcmd. * * Copyright (c) 2003-2005, K A Fraser * diff --git a/tools/include/xen-sys/NetBSD/privcmd.h b/tools/include/xen-sys/NetBSD/privcmd.h index 1296b30..555bad9 100644 --- a/tools/include/xen-sys/NetBSD/privcmd.h +++ b/tools/include/xen-sys/NetBSD/privcmd.h @@ -30,7 +30,7 @@ #ifndef __NetBSD_PRIVCMD_H__ #define __NetBSD_PRIVCMD_H__ -/* Interface to /proc/xen/privcmd */ +/* Interface to /dev/xen/privcmd */ typedef struct privcmd_hypercall { diff --git a/tools/include/xen-sys/NetBSDRump/privcmd.h b/tools/include/xen-sys/NetBSDRump/privcmd.h index 1296b30..555bad9 100644 --- a/tools/include/xen-sys/NetBSDRump/privcmd.h +++ b/tools/include/xen-sys/NetBSDRump/privcmd.h @@ -30,7 +30,7 @@ #ifndef __NetBSD_PRIVCMD_H__ #define __NetBSD_PRIVCMD_H__ -/* Interface to /proc/xen/privcmd */ +/* Interface to /dev/xen/privcmd */ typedef struct privcmd_hypercall { -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 1/4] libxc: prefer using privcmd character device
Prefer using the character device over the proc file if the character device exists. This follows similar conversions of xenbus to avoid issues with FMODE_ATOMIC_POS added in Linux 3.14 and newer. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/libxc/xc_linux_osdep.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c index 76c55ff..fb69770 100644 --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -46,7 +46,13 @@ static xc_osdep_handle linux_privcmd_open(xc_interface *xch) { int flags, saved_errno; -int fd = open("/proc/xen/privcmd", O_RDWR); +int fd = open("/dev/xen/privcmd", O_RDWR); /* prefer this newer interface */ + +if ( fd == -1 ) +{ +/* Fallback to /proc/xen/privcmd */ +fd = open("/proc/xen/privcmd", O_RDWR); +} if ( fd == -1 ) { -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/4] xendomains initscript: test for privcmd char device
Allow the init script to continue if either the character device or the proc file is available. CC: Ian Jackson CC: Stefano Stabellini CC: Ian Campbell CC: Wei Liu Signed-off-by: Doug Goldstein --- tools/hotplug/Linux/xendomains.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/hotplug/Linux/xendomains.in b/tools/hotplug/Linux/xendomains.in index 0603842..686f061 100644 --- a/tools/hotplug/Linux/xendomains.in +++ b/tools/hotplug/Linux/xendomains.in @@ -45,7 +45,7 @@ fi # Correct exit code would probably be 5, but it's enough # if xend complains if we're not running as privileged domain -if ! [ -e /proc/xen/privcmd ]; then +if ! [ -e /dev/xen/privcmd ] || [ -e /proc/xen/privcmd ]; then exit 0 fi -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks
On 24/11/15 18:16, George Dunlap wrote: > On 20/11/15 16:03, Malcolm Crossley wrote: >> This patch series adds per-cpu reader-writer locks as a generic lock >> implementation and then converts the grant table and p2m rwlocks to >> use the percpu rwlocks, in order to improve multi-socket host performance. >> >> CPU profiling has revealed the rwlocks themselves suffer from severe cache >> line bouncing due to the cmpxchg operation used even when taking a read lock. >> Multiqueue paravirtualised I/O results in heavy contention of the grant table >> and p2m read locks of a specific domain and so I/O throughput is bottlenecked >> by the overhead of the cache line bouncing itself. >> >> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data >> area to record a CPU has taken the read lock. Correctness is enforced for >> the >> write lock by using a per lock barrier which forces the per-cpu read lock >> to revert to using a standard read lock. The write lock then polls all >> the percpu data area until active readers for the lock have exited. >> >> Removing the cache line bouncing on a multi-socket Haswell-EP system >> dramatically improves performance, with 16 vCPU network IO performance going >> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 >> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better >> IO improvement. > Impressive -- thanks for doing this work. > > One question: Your description here sounds like you've tested with a > single large domain, but what happens with multiple domains? The test was with two domU's, doing network traffic between them. > > It looks like the "per-cpu-rwlock" is shared by *all* locks of a > particular type (e.g., all domains share the per-cpu p2m rwlock). > (Correct me if I'm wrong here.) The per-pcpu pointer is shared for all locks of a particular type, but allows the individual lock to be distinguished by following the pointer back. Therefore, the locks are not actually shared. > > Which means two things: > > 1) *Any* writer will have to wait for the rwlock of that type to be > released on *all* domains before being able to write. Is there any risk > that on a busy system, this will be an unusually long wait? No. The write-locker looks through all pcpus and ignores any whose per-cpu pointer is not pointing at the intended percpu_rwlock. >From _percpu_write_lock(): /* * Remove any percpu readers not contending on this rwlock * from our check mask. */ if ( per_cpu_ptr(per_cpudata, cpu) != percpu_rwlock ) cpumask_clear_cpu(cpu, &this_cpu(percpu_rwlock_readers)); As a result, two calls to _percpu_write_lock() against different percpu_rwlock_t's will not interact. > > 2) *All* domains will have to take the slow path for reading when a > *any* domain has or is trying to acquire the write lock. What is the > probability that on a busy system that turns out to be "most of the time"? _percpu_read_lock() will only take the slow path if: 1) The intended lock is (or is in the process of being) taken for writing 2) The callpath has nested _percpu_read_lock() of the same type of lock By observation, 2) does not occur currently in the code. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks
On 24/11/15 18:16, George Dunlap wrote: > On 20/11/15 16:03, Malcolm Crossley wrote: >> This patch series adds per-cpu reader-writer locks as a generic lock >> implementation and then converts the grant table and p2m rwlocks to >> use the percpu rwlocks, in order to improve multi-socket host performance. >> >> CPU profiling has revealed the rwlocks themselves suffer from severe cache >> line bouncing due to the cmpxchg operation used even when taking a read lock. >> Multiqueue paravirtualised I/O results in heavy contention of the grant table >> and p2m read locks of a specific domain and so I/O throughput is bottlenecked >> by the overhead of the cache line bouncing itself. >> >> Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data >> area to record a CPU has taken the read lock. Correctness is enforced for >> the >> write lock by using a per lock barrier which forces the per-cpu read lock >> to revert to using a standard read lock. The write lock then polls all >> the percpu data area until active readers for the lock have exited. >> >> Removing the cache line bouncing on a multi-socket Haswell-EP system >> dramatically improves performance, with 16 vCPU network IO performance going >> from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 >> logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better >> IO improvement. > > Impressive -- thanks for doing this work. > > One question: Your description here sounds like you've tested with a > single large domain, but what happens with multiple domains? > > It looks like the "per-cpu-rwlock" is shared by *all* locks of a > particular type (e.g., all domains share the per-cpu p2m rwlock). > (Correct me if I'm wrong here.) Sorry, looking in more detail at the code, it seems I am wrong. The fast-path stores which "slow" lock has been grabbed in the per-cpu variable; so the writer only needs to wait for readers that have grabbed the particular lock it's interested in. So the scenarios I outline below shouldn't really be issues. The description of the algorithm in the changelog could do with a bit more detail. :-) -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean
> On Nov 24, 2015, at 11:30 AM, Jan Beulich wrote: > On 24.11.15 at 18:22, wrote: > >>> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore >> wrote: On Nov 24, 2015, at 11:07 AM, Jan Beulich wrote: >>> On 24.11.15 at 17:56, wrote: > --- a/xen/Makefile > +++ b/xen/Makefile > @@ -88,7 +88,7 @@ _clean: delete-unfresh-files > $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean > $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean > $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean > - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi > $(TARGET)-syms >> *~ core > + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi > $(TARGET)-syms >> *~ core $(DEPS) Is this really a problem only in xen/ ? The referenced commit clearly introduces "stray" *.d files elsewhere. Also there aren't any source files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. >>> >>> So, the files in xen/ were the dependencies files for xen.efi and >>> xen-syms that were getting left behind. $(DEPS) appears to always >>> have ‘.*.d’ in it, based on me putting an echo into the clean rule to >>> print it out. However, looking at this, I am also seeing ‘.d’ files left >>> behind in xen/common/compat that I did not notice before. >> >> Actually, looking closer at it, xen/common/compat does not appear to be >> cleaning at all, so I think that is a separate, unrelated issue. > > That would be quite related, as it would be a result of the same > commit. Yeah, I now see where that change got introduced. I don’t see a clear way of cleaning those objects files since the build system no longer goes into the common/compat directory at all. The existing clean rules walk all of the subdirectories, cleaning object files and dependency files as it goes. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 0/3] Implement per-cpu reader-writer locks
On 20/11/15 16:03, Malcolm Crossley wrote: > This patch series adds per-cpu reader-writer locks as a generic lock > implementation and then converts the grant table and p2m rwlocks to > use the percpu rwlocks, in order to improve multi-socket host performance. > > CPU profiling has revealed the rwlocks themselves suffer from severe cache > line bouncing due to the cmpxchg operation used even when taking a read lock. > Multiqueue paravirtualised I/O results in heavy contention of the grant table > and p2m read locks of a specific domain and so I/O throughput is bottlenecked > by the overhead of the cache line bouncing itself. > > Per-cpu read locks avoid lock cache line bouncing by using a per-cpu data > area to record a CPU has taken the read lock. Correctness is enforced for the > write lock by using a per lock barrier which forces the per-cpu read lock > to revert to using a standard read lock. The write lock then polls all > the percpu data area until active readers for the lock have exited. > > Removing the cache line bouncing on a multi-socket Haswell-EP system > dramatically improves performance, with 16 vCPU network IO performance going > from 15 gb/s to 64 gb/s! The host under test was fully utilising all 40 > logical CPU's at 64 gb/s, so a bigger logical CPU host may see an even better > IO improvement. Impressive -- thanks for doing this work. One question: Your description here sounds like you've tested with a single large domain, but what happens with multiple domains? It looks like the "per-cpu-rwlock" is shared by *all* locks of a particular type (e.g., all domains share the per-cpu p2m rwlock). (Correct me if I'm wrong here.) Which means two things: 1) *Any* writer will have to wait for the rwlock of that type to be released on *all* domains before being able to write. Is there any risk that on a busy system, this will be an unusually long wait? 2) *All* domains will have to take the slow path for reading when a *any* domain has or is trying to acquire the write lock. What is the probability that on a busy system that turns out to be "most of the time"? #2 is of course no worse than it is now, but #1 could be a bit of a bear. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/PCI: make all config space writes subject to XSM checking
On 24/11/15 09:42, Jan Beulich wrote: Now that we intercept them all, there's no reason not to also uniformly hand them to XSM. Reads (which are expected to be of less interest) get handled as before (MMCFG accesses un-audited). Signed-off-by: Jan Beulich Acked-by: Daniel De Graaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 09/28] build: convert HAS_ACPI use to Kconfig
Use the Kconfig generated CONFIG_HAS_ACPI defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk| 1 - xen/common/sysctl.c | 2 +- xen/drivers/Kconfig | 2 ++ xen/drivers/Makefile | 2 +- xen/drivers/acpi/Kconfig | 4 7 files changed, 9 insertions(+), 4 deletions(-) create mode 100644 xen/drivers/acpi/Kconfig diff --git a/xen/Rules.mk b/xen/Rules.mk index 870c548..351a186 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -56,7 +56,6 @@ CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE -CFLAGS-$(HAS_ACPI) += -DHAS_ACPI CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 54124c6..8c24c05 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -4,6 +4,7 @@ config X86_64 config X86 def_bool y select HAS_IOPORTS + select HAS_ACPI select HAS_PASSTHROUGH select HAS_PCI select UART_NS16550 diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 151ed25..166deb9 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -1,7 +1,6 @@ # x86-specific definitions -HAS_ACPI := y HAS_NUMA := y HAS_VGA := y HAS_VIDEO := y diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 47d115e..a3007b8 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) op->u.availheap.avail_bytes <<= PAGE_SHIFT; break; -#ifdef HAS_ACPI +#ifdef CONFIG_HAS_ACPI case XEN_SYSCTL_get_pmstat: ret = do_get_pm_info(&op->u.get_pmstat); break; diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index fe6fcca..eb01d47 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -1,5 +1,7 @@ menu "Device Drivers" +source "drivers/acpi/Kconfig" + source "drivers/char/Kconfig" source "drivers/passthrough/Kconfig" diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile index eb32d69..9f6c18b 100644 --- a/xen/drivers/Makefile +++ b/xen/drivers/Makefile @@ -2,5 +2,5 @@ subdir-y += char subdir-$(HAS_CPUFREQ) += cpufreq subdir-$(CONFIG_HAS_PCI) += pci subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough -subdir-$(HAS_ACPI) += acpi +subdir-$(CONFIG_HAS_ACPI) += acpi subdir-$(HAS_VIDEO) += video diff --git a/xen/drivers/acpi/Kconfig b/xen/drivers/acpi/Kconfig new file mode 100644 index 000..11ab5e4 --- /dev/null +++ b/xen/drivers/acpi/Kconfig @@ -0,0 +1,4 @@ + +# Select HAS_ACPI if ACPI is supported +config HAS_ACPI + bool -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 19/28] build: convert HAS_EXYNOS4210 use to Kconfig
Use the Kconfig generated CONFIG_UART_EXYNOS4210 defines in the code base. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm32.mk | 1 - xen/arch/arm/configs/arm32_defconfig | 1 + xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile| 2 +- 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/config/arm32.mk b/config/arm32.mk index 3bbdd2d..56b71d7 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX := # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: CFLAGS += -marm -HAS_EXYNOS4210 := y HAS_OMAP := y HAS_SCIF := y HAS_MEM_ACCESS := y diff --git a/xen/arch/arm/configs/arm32_defconfig b/xen/arch/arm/configs/arm32_defconfig index 61d6b5d..420602a 100644 --- a/xen/arch/arm/configs/arm32_defconfig +++ b/xen/arch/arm/configs/arm32_defconfig @@ -1,3 +1,4 @@ CONFIG_64BIT=n CONFIG_UART_NS16550=y CONFIG_UART_PL011=y +CONFIG_UART_EXYNOS4210=y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 120525b..7262975 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -22,3 +22,10 @@ config UART_PL011 help This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have an Integrator/PP2, Integrator/CP or Versatile platform, say Y. + +config UART_EXYNOS4210 + bool "Samsung Exynos 4210 UART support" + depends on ARM_32 + help + This selects the Samsung Exynos 4210 UART. If you have a Samsung + Exynos based board, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index 0adb3b7..ebea593 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -2,7 +2,7 @@ obj-y += console.o obj-$(CONFIG_UART_NS16550) += ns16550.o obj-$(CONFIG_UART_CADENCE) += cadence-uart.o obj-$(CONFIG_UART_PL011) += pl011.o -obj-$(HAS_EXYNOS4210) += exynos4210-uart.o +obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o obj-$(HAS_OMAP) += omap-uart.o obj-$(HAS_SCIF) += scif-uart.o obj-$(HAS_EHCI) += ehci-dbgp.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 20/28] build: convert HAS_OMAP use to Kconfig
Use the Kconfig generated CONFIG_UART_OMAP defines in the code base. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm32.mk | 1 - xen/arch/arm/configs/arm32_defconfig | 1 + xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile| 2 +- 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/config/arm32.mk b/config/arm32.mk index 56b71d7..b1de8da 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX := # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: CFLAGS += -marm -HAS_OMAP := y HAS_SCIF := y HAS_MEM_ACCESS := y diff --git a/xen/arch/arm/configs/arm32_defconfig b/xen/arch/arm/configs/arm32_defconfig index 420602a..121c3f6 100644 --- a/xen/arch/arm/configs/arm32_defconfig +++ b/xen/arch/arm/configs/arm32_defconfig @@ -2,3 +2,4 @@ CONFIG_64BIT=n CONFIG_UART_NS16550=y CONFIG_UART_PL011=y CONFIG_UART_EXYNOS4210=y +CONFIG_UART_OMAP=y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 7262975..70f0eee6 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -29,3 +29,10 @@ config UART_EXYNOS4210 help This selects the Samsung Exynos 4210 UART. If you have a Samsung Exynos based board, say Y. + +config UART_OMAP + bool "OMAP UART support" + depends on ARM_32 + help + This selects the Texas Instruments OMAP UART. If you have a Texas + Instruments based CPU, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index ebea593..06d02fb 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -3,7 +3,7 @@ obj-$(CONFIG_UART_NS16550) += ns16550.o obj-$(CONFIG_UART_CADENCE) += cadence-uart.o obj-$(CONFIG_UART_PL011) += pl011.o obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o -obj-$(HAS_OMAP) += omap-uart.o +obj-$(CONFIG_UART_OMAP) += omap-uart.o obj-$(HAS_SCIF) += scif-uart.o obj-$(HAS_EHCI) += ehci-dbgp.o obj-$(CONFIG_ARM) += dt-uart.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 27/28] build: convert CONFIG_COMPAT to Kconfig
Use the Kconfig generated CONFIG_COMPAT defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/x86/Kconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 3842018..7d92a23 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -25,6 +25,13 @@ config ARCH_DEFCONFIG menu "Architecture Features" +config COMPAT + def_bool y + help + 32-bit interface support on 64-bit Xen which is used for both + HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective + of the destination runmode of the guest. + endmenu source "common/Kconfig" -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 17/28] build: convert HAS_CADENCE_UART use to Kconfig
Use the Kconfig generated CONFIG_HAS_CADENCE_UART defines in the code base. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm64.mk | 1 - xen/arch/arm/configs/arm64_defconfig | 1 + xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile| 2 +- 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/config/arm64.mk b/config/arm64.mk index f35f6bf..2d119a6 100644 --- a/config/arm64.mk +++ b/config/arm64.mk @@ -7,7 +7,6 @@ CONFIG_XEN_INSTALL_SUFFIX := CFLAGS += #-marm -march= -mcpu= etc HAS_PL011 := y -HAS_CADENCE_UART := y HAS_MEM_ACCESS := y HAS_GICV3 := y diff --git a/xen/arch/arm/configs/arm64_defconfig b/xen/arch/arm/configs/arm64_defconfig index debc348..1fb8c7b 100644 --- a/xen/arch/arm/configs/arm64_defconfig +++ b/xen/arch/arm/configs/arm64_defconfig @@ -1 +1,2 @@ CONFIG_UART_NS16550=y +CONFIG_UART_CADENCE=y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 8ecea29..5fc44c0 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -8,3 +8,10 @@ config UART_NS16550 config HAS_IOPORTS bool depends on UART_NS16550 + +config UART_CADENCE + bool "Xilinx Zynq Cadence UART support" + depends on ARM_64 + help + This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq + based board, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index 99e8c6f..d396b2e 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -1,6 +1,6 @@ obj-y += console.o obj-$(CONFIG_UART_NS16550) += ns16550.o -obj-$(HAS_CADENCE_UART) += cadence-uart.o +obj-$(CONFIG_UART_CADENCE) += cadence-uart.o obj-$(HAS_PL011) += pl011.o obj-$(HAS_EXYNOS4210) += exynos4210-uart.o obj-$(HAS_OMAP) += omap-uart.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 10/28] build: convert HAS_VIDEO use to Kconfig
Use the Kconfig generated CONFIG_HAS_VIDEO defines in the code base. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/Rules.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/drivers/Kconfig| 2 ++ xen/drivers/Makefile | 2 +- xen/drivers/video/Kconfig | 13 + xen/drivers/video/Makefile | 8 8 files changed, 22 insertions(+), 7 deletions(-) create mode 100644 xen/drivers/video/Kconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index c2e3916..1786769 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -17,6 +17,7 @@ config ARM_64 config ARM def_bool y select HAS_DEVICE_TREE + select HAS_VIDEO select HAS_PASSTHROUGH config ARCH_DEFCONFIG diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 4725374..90b1f24 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -6,7 +6,6 @@ # 'make clean' before rebuilding. # -HAS_VIDEO := y HAS_ARM_HDLCD := y HAS_PDX := y diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 8c24c05..70188de 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -6,6 +6,7 @@ config X86 select HAS_IOPORTS select HAS_ACPI select HAS_PASSTHROUGH + select HAS_VIDEO select HAS_PCI select UART_NS16550 select HAS_GDBSX diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 166deb9..8fda89e 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -3,7 +3,6 @@ HAS_NUMA := y HAS_VGA := y -HAS_VIDEO := y HAS_CPUFREQ := y HAS_EHCI := y HAS_KEXEC := y diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index eb01d47..f0ad01e 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -8,4 +8,6 @@ source "drivers/passthrough/Kconfig" source "drivers/pci/Kconfig" +source "drivers/video/Kconfig" + endmenu diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile index 9f6c18b..01d6b8d 100644 --- a/xen/drivers/Makefile +++ b/xen/drivers/Makefile @@ -3,4 +3,4 @@ subdir-$(HAS_CPUFREQ) += cpufreq subdir-$(CONFIG_HAS_PCI) += pci subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough subdir-$(CONFIG_HAS_ACPI) += acpi -subdir-$(HAS_VIDEO) += video +subdir-$(CONFIG_HAS_VIDEO) += video diff --git a/xen/drivers/video/Kconfig b/xen/drivers/video/Kconfig new file mode 100644 index 000..a88a7a9 --- /dev/null +++ b/xen/drivers/video/Kconfig @@ -0,0 +1,13 @@ + +# Select HAS_VIDEO if video is supported +config HAS_VIDEO + bool + +# Select HAS_VGA if VGA is supported +config HAS_VGA + bool + depends on HAS_VIDEO + +# Select HAS_ARM_HDLCD if ARM HDLCD is supported +config HAS_ARM_HDLCD + bool diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile index a756292..914b6cf 100644 --- a/xen/drivers/video/Makefile +++ b/xen/drivers/video/Makefile @@ -1,7 +1,7 @@ obj-$(HAS_VGA) := vga.o -obj-$(HAS_VIDEO) += font_8x14.o -obj-$(HAS_VIDEO) += font_8x16.o -obj-$(HAS_VIDEO) += font_8x8.o -obj-$(HAS_VIDEO) += lfb.o +obj-$(CONFIG_HAS_VIDEO) += font_8x14.o +obj-$(CONFIG_HAS_VIDEO) += font_8x16.o +obj-$(CONFIG_HAS_VIDEO) += font_8x8.o +obj-$(CONFIG_HAS_VIDEO) += lfb.o obj-$(HAS_VGA) += vesa.o obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 26/28] build: convert HAS_GICV3 use to Kconfig
Use the Kconfig generated CONFIG_HAS_GICV3 defines in the code base. CC: Ian Campbell CC: Stefano Stabellini Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm64.mk | 1 - xen/arch/arm/Kconfig | 5 + xen/arch/arm/Makefile| 2 +- xen/arch/arm/Rules.mk| 2 -- xen/arch/arm/vgic.c | 2 +- xen/include/asm-arm/domain.h | 2 +- xen/include/asm-arm/gic.h| 4 ++-- xen/include/asm-arm/vgic.h | 2 +- 8 files changed, 11 insertions(+), 9 deletions(-) diff --git a/config/arm64.mk b/config/arm64.mk index 1b9a47f..1d7d81d 100644 --- a/config/arm64.mk +++ b/config/arm64.mk @@ -7,7 +7,6 @@ CONFIG_XEN_INSTALL_SUFFIX := CFLAGS += #-marm -march= -mcpu= etc HAS_MEM_ACCESS := y -HAS_GICV3 := y # Use only if calling $(LD) directly. LDFLAGS_DIRECT += -EL diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index b52474e..346b967 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -13,6 +13,7 @@ config ARM_32 config ARM_64 def_bool y depends on 64BIT + select HAS_GICV3 config ARM def_bool y @@ -30,6 +31,10 @@ config ARCH_DEFCONFIG menu "Architecture Features" +# Select HAS_GICV3 if GICv3 is supported +config HAS_GICV3 + bool + endmenu source "common/Kconfig" diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile index e47dd4c..49b6584 100644 --- a/xen/arch/arm/Makefile +++ b/xen/arch/arm/Makefile @@ -13,7 +13,7 @@ obj-y += sysctl.o obj-y += domain_build.o obj-y += gic.o gic-v2.o obj-$(CONFIG_ARM_32) += gic-hip04.o -obj-$(HAS_GICV3) += gic-v3.o +obj-$(CONFIG_HAS_GICV3) += gic-v3.o obj-y += io.o obj-y += irq.o obj-y += kernel.o diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 2158bd8..4947e64 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -32,8 +32,6 @@ ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n) CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE endif -CFLAGS-$(HAS_GICV3) += -DHAS_GICV3 - EARLY_PRINTK := n ifeq ($(debug),y) diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c index 7bb4570..68c77f9 100644 --- a/xen/arch/arm/vgic.c +++ b/xen/arch/arm/vgic.c @@ -90,7 +90,7 @@ int domain_vgic_init(struct domain *d, unsigned int nr_spis) switch ( d->arch.vgic.version ) { -#ifdef HAS_GICV3 +#ifdef CONFIG_HAS_GICV3 case GIC_V3: if ( vgic_v3_init(d) ) return -ENODEV; diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index e7e40da..aa7f283 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -102,7 +102,7 @@ struct arch_domain struct pending_irq *pending_irqs; /* Base address for guest GIC */ paddr_t dbase; /* Distributor base address */ -#ifdef HAS_GICV3 +#ifdef CONFIG_HAS_GICV3 /* GIC V3 addressing */ /* List of contiguous occupied by the redistributors */ struct vgic_rdist_region { diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h index 0116481..598955b 100644 --- a/xen/include/asm-arm/gic.h +++ b/xen/include/asm-arm/gic.h @@ -163,7 +163,7 @@ #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3") -#ifdef HAS_GICV3 +#ifdef CONFIG_HAS_GICV3 /* * GICv3 registers that needs to be saved/restored */ @@ -191,7 +191,7 @@ struct gic_v2 { */ union gic_state_data { struct gic_v2 v2; -#ifdef HAS_GICV3 +#ifdef CONFIG_HAS_GICV3 struct gic_v3 v3; #endif }; diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h index cb51a9e..b477691 100644 --- a/xen/include/asm-arm/vgic.h +++ b/xen/include/asm-arm/vgic.h @@ -251,7 +251,7 @@ extern void vgic_free_virq(struct domain *d, unsigned int virq); void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize, paddr_t vbase, uint32_t aliased_offset); -#ifdef HAS_GICV3 +#ifdef CONFIG_HAS_GICV3 struct rdist_region; void vgic_v3_setup_hw(paddr_t dbase, unsigned int nr_rdist_regions, -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 16/28] build: convert HAS_ARM_HDLCD use to Kconfig
Use the Kconfig generated CONFIG_HAS_ARM_HDLCD defines in the code base. CC: Ian Campbell CC: Stefano Stabellini Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/arm/Kconfig | 1 + xen/arch/arm/Rules.mk | 2 -- xen/drivers/video/Makefile | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 32f57d4..9e7351e 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -18,6 +18,7 @@ config ARM def_bool y select HAS_DEVICE_TREE select HAS_VIDEO + select HAS_ARM_HDLCD select HAS_PASSTHROUGH select HAS_PDX diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 52b1ad4..2158bd8 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -6,8 +6,6 @@ # 'make clean' before rebuilding. # -HAS_ARM_HDLCD := y - CFLAGS += -I$(BASEDIR)/include $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS)) diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile index 0143c4a..b9b5e23 100644 --- a/xen/drivers/video/Makefile +++ b/xen/drivers/video/Makefile @@ -4,4 +4,4 @@ obj-$(CONFIG_HAS_VIDEO) += font_8x16.o obj-$(CONFIG_HAS_VIDEO) += font_8x8.o obj-$(CONFIG_HAS_VIDEO) += lfb.o obj-$(CONFIG_HAS_VGA) += vesa.o -obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o +obj-$(CONFIG_HAS_ARM_HDLCD) += arm_hdlcd.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 24/28] build: convert HAS_MEM_PAGING use to Kconfig
Use the Kconfig generated CONFIG_HAS_MEM_PAGING defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Razvan Cojocaru CC: Tamas K Lengyel CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Razvan Cojocaru Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/x86_32.mk| 1 - config/x86_64.mk| 1 - xen/Rules.mk| 1 - xen/arch/x86/Kconfig| 1 + xen/common/Kconfig | 4 xen/common/memory.c | 2 +- xen/common/vm_event.c | 8 xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h | 4 ++-- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c | 4 ++-- 11 files changed, 16 insertions(+), 14 deletions(-) diff --git a/config/x86_32.mk b/config/x86_32.mk index ed69447..cf3d27f 100644 --- a/config/x86_32.mk +++ b/config/x86_32.mk @@ -6,7 +6,6 @@ CONFIG_MIGRATE := y CONFIG_XCUTILS := y HAS_MEM_ACCESS := y -HAS_MEM_PAGING := y HAS_MEM_SHARING := y CFLAGS += -m32 -march=i686 diff --git a/config/x86_64.mk b/config/x86_64.mk index f74611f..4880681 100644 --- a/config/x86_64.mk +++ b/config/x86_64.mk @@ -7,7 +7,6 @@ CONFIG_MIGRATE := y CONFIG_XCUTILS := y HAS_MEM_ACCESS := y -HAS_MEM_PAGING := y HAS_MEM_SHARING := y CONFIG_XEN_INSTALL_SUFFIX := .gz diff --git a/xen/Rules.mk b/xen/Rules.mk index f5ffe9d..3b8fd66 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -56,7 +56,6 @@ CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE -CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 530563f..34be03f 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -16,6 +16,7 @@ config X86 select HAS_PDX select HAS_KEXEC select HAS_MEM_ACCESS + select HAS_MEM_PAGING config ARCH_DEFCONFIG string diff --git a/xen/common/Kconfig b/xen/common/Kconfig index bdb95f0..f6cfb9e 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -9,6 +9,10 @@ config HAS_DEVICE_TREE config HAS_MEM_ACCESS bool +# Select HAS_MEM_PAGING if mem paging is supported +config HAS_MEM_PAGING + bool + # Select HAS_PDX if PDX is supported config HAS_PDX bool diff --git a/xen/common/memory.c b/xen/common/memory.c index da4eb36..5180fa8 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1282,7 +1282,7 @@ int prepare_ring_for_helper( page = get_page_from_gfn(d, gmfn, &p2mt, P2M_UNSHARE); -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING if ( p2m_is_paging(p2mt) ) { if ( page ) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 0fe93dc..2e59e41 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -403,7 +403,7 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved) break; #endif -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING case VM_EVENT_REASON_MEM_PAGING: p2m_mem_paging_resume(d, &rsp); break; @@ -502,7 +502,7 @@ int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved, return vm_event_grab_slot(ved, (current->domain != d)); } -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING /* Registered with Xen-bound event channel for incoming notifications. */ static void mem_paging_notification(struct vcpu *v, unsigned int port) { @@ -530,7 +530,7 @@ static void mem_sharing_notification(struct vcpu *v, unsigned int port) /* Clean up on domain destruction */ void vm_event_cleanup(struct domain *d) { -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING if ( d->vm_event->paging.ring_page ) { /* Destroying the wait queue head means waking up all @@ -592,7 +592,7 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec, switch ( vec->mode ) { -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING case XEN_DOMCTL_VM_EVENT_OP_PAGING: { struct vm_event_domain *ved = &d->vm_event->paging; diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index 7a9006b..dd7618f 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -568,7 +568,7 @@ static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d) } #endif -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d) { XSM_ASSERT_ACTION(XSM_DM_PRIV); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index a550ae2..b23ecda 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -156,7 +156,7 @@ struct xsm_operations { int (*mem_access) (struct domain *d); #endif -#ifdef HAS_MEM_PAGING +#ifdef CONFIG_HAS_MEM_PAGING int (*mem_paging) (struct domai
[Xen-devel] [PATCHv6] 21/28] build: convert HAS_SCIF use to Kconfig
Use the Kconfig generated CONFIG_UART_SCIF defines in the code base. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm32.mk | 1 - xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/config/arm32.mk b/config/arm32.mk index b1de8da..001b2cd 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX := # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: CFLAGS += -marm -HAS_SCIF := y HAS_MEM_ACCESS := y # Use only if calling $(LD) directly. diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 70f0eee6..d5cc991 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -36,3 +36,10 @@ config UART_OMAP help This selects the Texas Instruments OMAP UART. If you have a Texas Instruments based CPU, say Y. + +config UART_SCIF + bool "SuperH SCI(F) UART support" + depends on ARM_32 + help + This selects the SuperH SCI(F) UART. If you have a SuperH based board, + say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index 06d02fb..68ebc2d 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -4,7 +4,7 @@ obj-$(CONFIG_UART_CADENCE) += cadence-uart.o obj-$(CONFIG_UART_PL011) += pl011.o obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o obj-$(CONFIG_UART_OMAP) += omap-uart.o -obj-$(HAS_SCIF) += scif-uart.o +obj-$(CONFIG_UART_SCIF) += scif-uart.o obj-$(HAS_EHCI) += ehci-dbgp.o obj-$(CONFIG_ARM) += dt-uart.o obj-y += serial.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 07/28] build: convert HAS_NS16550 use to Kconfig
Use the Kconfig generated CONFIG_HAS_NS16550 defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm32.mk | 1 - config/arm64.mk | 1 - xen/arch/arm/configs/arm32_defconfig | 1 + xen/arch/arm/configs/arm64_defconfig | 1 + xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk| 1 - xen/drivers/Kconfig | 2 ++ xen/drivers/char/Kconfig | 5 + xen/drivers/char/Makefile| 2 +- 9 files changed, 11 insertions(+), 4 deletions(-) create mode 100644 xen/drivers/char/Kconfig diff --git a/config/arm32.mk b/config/arm32.mk index cd97e42..f963338 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -13,7 +13,6 @@ HAS_PL011 := y HAS_EXYNOS4210 := y HAS_OMAP := y HAS_SCIF := y -HAS_NS16550 := y HAS_MEM_ACCESS := y # Use only if calling $(LD) directly. diff --git a/config/arm64.mk b/config/arm64.mk index c5deb4e..f35f6bf 100644 --- a/config/arm64.mk +++ b/config/arm64.mk @@ -8,7 +8,6 @@ CFLAGS += #-marm -march= -mcpu= etc HAS_PL011 := y HAS_CADENCE_UART := y -HAS_NS16550 := y HAS_MEM_ACCESS := y HAS_GICV3 := y diff --git a/xen/arch/arm/configs/arm32_defconfig b/xen/arch/arm/configs/arm32_defconfig index 5608ff9..e204bbc 100644 --- a/xen/arch/arm/configs/arm32_defconfig +++ b/xen/arch/arm/configs/arm32_defconfig @@ -1 +1,2 @@ CONFIG_64BIT=n +CONFIG_UART_NS16550=y diff --git a/xen/arch/arm/configs/arm64_defconfig b/xen/arch/arm/configs/arm64_defconfig index e69de29..debc348 100644 --- a/xen/arch/arm/configs/arm64_defconfig +++ b/xen/arch/arm/configs/arm64_defconfig @@ -0,0 +1 @@ +CONFIG_UART_NS16550=y diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 4e1a9da..8039111 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -5,6 +5,7 @@ config X86 def_bool y select HAS_PASSTHROUGH select HAS_PCI + select UART_NS16550 select HAS_GDBSX config ARCH_DEFCONFIG diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 8743509..17d2869 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -7,7 +7,6 @@ HAS_NUMA := y HAS_VGA := y HAS_VIDEO := y HAS_CPUFREQ := y -HAS_NS16550 := y HAS_EHCI := y HAS_KEXEC := y HAS_GDBSX := y diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index 5362e41..fe6fcca 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -1,5 +1,7 @@ menu "Device Drivers" +source "drivers/char/Kconfig" + source "drivers/passthrough/Kconfig" source "drivers/pci/Kconfig" diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig new file mode 100644 index 000..6ed451f --- /dev/null +++ b/xen/drivers/char/Kconfig @@ -0,0 +1,5 @@ + +config UART_NS16550 + bool "16550-series UART support" + help + This selects the 16550-series UART support. For most systems, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index 47fc3f9..99e8c6f 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -1,5 +1,5 @@ obj-y += console.o -obj-$(HAS_NS16550) += ns16550.o +obj-$(CONFIG_UART_NS16550) += ns16550.o obj-$(HAS_CADENCE_UART) += cadence-uart.o obj-$(HAS_PL011) += pl011.o obj-$(HAS_EXYNOS4210) += exynos4210-uart.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 05/28] build: convert HAS_DEVICE_TREE use to Kconfig
Use the Kconfig generated CONFIG_HAS_DEVICE_TREE defines in the code base. CC: Ian Campbell CC: Stefano Stabellini CC: Jan Beulich CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/arm/Kconfig | 1 + xen/arch/arm/Rules.mk| 1 - xen/common/Kconfig | 4 xen/common/Makefile | 4 ++-- xen/drivers/char/ns16550.c | 6 +++--- xen/drivers/passthrough/Makefile | 2 +- xen/drivers/passthrough/iommu.c | 2 +- xen/include/asm-arm/device.h | 2 +- xen/include/xen/hvm/iommu.h | 2 +- xen/include/xen/iommu.h | 4 ++-- xen/include/xsm/dummy.h | 4 ++-- xen/include/xsm/xsm.h| 10 +- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 6 +++--- xen/xsm/xsm_core.c | 2 +- xen/xsm/xsm_policy.c | 4 ++-- 17 files changed, 30 insertions(+), 27 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 07ff563..15dcedc 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -58,7 +58,6 @@ CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE CFLAGS-$(HAS_ACPI) += -DHAS_ACPI CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX -CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index e754adb..c2e3916 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -16,6 +16,7 @@ config ARM_64 config ARM def_bool y + select HAS_DEVICE_TREE select HAS_PASSTHROUGH config ARCH_DEFCONFIG diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 86d7b81..4725374 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -6,7 +6,6 @@ # 'make clean' before rebuilding. # -HAS_DEVICE_TREE := y HAS_VIDEO := y HAS_ARM_HDLCD := y HAS_PDX := y diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 0251856..53ca33f 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -1,4 +1,8 @@ menu "Common Features" +# Select HAS_DEVICE_TREE if device tree is supported +config HAS_DEVICE_TREE + bool + endmenu diff --git a/xen/common/Makefile b/xen/common/Makefile index 3547c8e..5dc2bb2 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -2,7 +2,7 @@ obj-y += bitmap.o obj-$(HAS_CORE_PARKING) += core_parking.o obj-y += cpu.o obj-y += cpupool.o -obj-$(HAS_DEVICE_TREE) += device_tree.o +obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o obj-y += domctl.o obj-y += domain.o obj-y += event_2l.o @@ -70,4 +70,4 @@ subdir-$(x86_64) += hvm subdir-$(coverage) += gcov subdir-y += libelf -subdir-$(HAS_DEVICE_TREE) += libfdt +subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 09abca8..6eab071 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -24,7 +24,7 @@ #include #include #include -#ifdef HAS_DEVICE_TREE +#ifdef CONFIG_HAS_DEVICE_TREE #include #endif #ifdef CONFIG_X86 @@ -1131,7 +1131,7 @@ void __init ns16550_init(int index, struct ns16550_defaults *defaults) ns16550_parse_port_config(uart, (index == 0) ? opt_com1 : opt_com2); } -#ifdef HAS_DEVICE_TREE +#ifdef CONFIG_HAS_DEVICE_TREE static int __init ns16550_uart_dt_init(struct dt_device_node *dev, const void *data) { @@ -1206,7 +1206,7 @@ DT_DEVICE_START(ns16550, "NS16550 UART", DEVICE_SERIAL) .init = ns16550_uart_dt_init, DT_DEVICE_END -#endif /* HAS_DEVICE_TREE */ +#endif /* CONFIG_HAS_DEVICE_TREE */ /* * Local variables: * mode: C diff --git a/xen/drivers/passthrough/Makefile b/xen/drivers/passthrough/Makefile index 16e9027..2bb5afb 100644 --- a/xen/drivers/passthrough/Makefile +++ b/xen/drivers/passthrough/Makefile @@ -6,4 +6,4 @@ subdir-$(arm) += arm obj-y += iommu.o obj-$(x86) += io.o obj-$(HAS_PCI) += pci.o -obj-$(HAS_DEVICE_TREE) += device_tree.o +obj-$(CONFIG_HAS_DEVICE_TREE) += device_tree.o diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index 3d02550..8bb7df0 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -357,7 +357,7 @@ int iommu_do_domctl( ret = iommu_do_pci_domctl(domctl, d, u_domctl); #endif -#ifdef HAS_DEVICE_TREE +#ifdef CONFIG_HAS_DEVICE_TREE if ( ret == -ENODEV ) ret = iommu_do_dt_domctl(domctl, d, u_domctl); #endif diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h index 5d0a4cd..b455bdf 100644 --- a/xen/include/asm-arm/device.h +++ b/xen/include/asm-arm/device.h @@ -16,7 +16,7 @@ struct dev_archdata { struct device { enum device_type type; -#ifdef HAS_DEVICE_TREE +#ifdef CONFIG_HAS_DEVICE_TREE struct
[Xen-devel] [PATCHv6] 18/28] build: convert HAS_PL011 use to Kconfig
Use the Kconfig generated CONFIG_UART_PL011 defines in the code base. The prefix HAS_ does not make sense in this case because these are intended to be user selected options while HAS_ just states that the hardware has this support and is controlled by Xen maintainers. CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/arm32.mk | 1 - config/arm64.mk | 1 - xen/arch/arm/configs/arm32_defconfig | 1 + xen/arch/arm/configs/arm64_defconfig | 1 + xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile| 2 +- 6 files changed, 10 insertions(+), 3 deletions(-) diff --git a/config/arm32.mk b/config/arm32.mk index f963338..3bbdd2d 100644 --- a/config/arm32.mk +++ b/config/arm32.mk @@ -9,7 +9,6 @@ CONFIG_XEN_INSTALL_SUFFIX := # Explicitly specifiy 32-bit ARM ISA since toolchain default can be -mthumb: CFLAGS += -marm -HAS_PL011 := y HAS_EXYNOS4210 := y HAS_OMAP := y HAS_SCIF := y diff --git a/config/arm64.mk b/config/arm64.mk index 2d119a6..1b9a47f 100644 --- a/config/arm64.mk +++ b/config/arm64.mk @@ -6,7 +6,6 @@ CONFIG_XEN_INSTALL_SUFFIX := CFLAGS += #-marm -march= -mcpu= etc -HAS_PL011 := y HAS_MEM_ACCESS := y HAS_GICV3 := y diff --git a/xen/arch/arm/configs/arm32_defconfig b/xen/arch/arm/configs/arm32_defconfig index e204bbc..61d6b5d 100644 --- a/xen/arch/arm/configs/arm32_defconfig +++ b/xen/arch/arm/configs/arm32_defconfig @@ -1,2 +1,3 @@ CONFIG_64BIT=n CONFIG_UART_NS16550=y +CONFIG_UART_PL011=y diff --git a/xen/arch/arm/configs/arm64_defconfig b/xen/arch/arm/configs/arm64_defconfig index 1fb8c7b..4bee0a2 100644 --- a/xen/arch/arm/configs/arm64_defconfig +++ b/xen/arch/arm/configs/arm64_defconfig @@ -1,2 +1,3 @@ CONFIG_UART_NS16550=y CONFIG_UART_CADENCE=y +CONFIG_UART_PL011=y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 5fc44c0..120525b 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -15,3 +15,10 @@ config UART_CADENCE help This selects the Xilinx Zynq Cadence UART. If you have a Xilinx Zynq based board, say Y. + +config UART_PL011 + bool "ARM AMBA PL011 UART support" + depends on ARM + help + This selects the ARM(R) AMBA(R) PrimeCell PL011 UART. If you have + an Integrator/PP2, Integrator/CP or Versatile platform, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index d396b2e..0adb3b7 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -1,7 +1,7 @@ obj-y += console.o obj-$(CONFIG_UART_NS16550) += ns16550.o obj-$(CONFIG_UART_CADENCE) += cadence-uart.o -obj-$(HAS_PL011) += pl011.o +obj-$(CONFIG_UART_PL011) += pl011.o obj-$(HAS_EXYNOS4210) += exynos4210-uart.o obj-$(HAS_OMAP) += omap-uart.o obj-$(HAS_SCIF) += scif-uart.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 04/28] build: convert HAS_PASSTHROUGH use to Kconfig
Use the Kconfig generated HAS_PASSTHROUGH defines for the code base. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk| 1 - xen/arch/arm/Kconfig| 1 + xen/arch/arm/Rules.mk | 1 - xen/arch/x86/Kconfig| 1 + xen/arch/x86/Rules.mk | 1 - xen/common/compat/memory.c | 4 ++-- xen/common/memory.c | 8 xen/drivers/Kconfig | 1 + xen/drivers/Makefile| 2 +- xen/drivers/passthrough/Kconfig | 4 xen/include/xen/sched.h | 4 ++-- xen/include/xsm/dummy.h | 8 xen/include/xsm/xsm.h | 12 ++-- xen/xsm/dummy.c | 4 ++-- xen/xsm/flask/hooks.c | 14 +++--- 15 files changed, 35 insertions(+), 31 deletions(-) create mode 100644 xen/drivers/passthrough/Kconfig diff --git a/xen/Rules.mk b/xen/Rules.mk index 011768a..07ff563 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -58,7 +58,6 @@ CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE CFLAGS-$(HAS_ACPI) += -DHAS_ACPI CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX -CFLAGS-$(HAS_PASSTHROUGH) += -DHAS_PASSTHROUGH CFLAGS-$(HAS_DEVICE_TREE) += -DHAS_DEVICE_TREE CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index a473137..e754adb 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -16,6 +16,7 @@ config ARM_64 config ARM def_bool y + select HAS_PASSTHROUGH config ARCH_DEFCONFIG string diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index b31770c..86d7b81 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -9,7 +9,6 @@ HAS_DEVICE_TREE := y HAS_VIDEO := y HAS_ARM_HDLCD := y -HAS_PASSTHROUGH := y HAS_PDX := y CFLAGS += -I$(BASEDIR)/include diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 47b715d..4ff1f63 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -3,6 +3,7 @@ config X86_64 config X86 def_bool y + select HAS_PASSTHROUGH select HAS_GDBSX config ARCH_DEFCONFIG diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 5b8eaed..09f2844 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -8,7 +8,6 @@ HAS_VGA := y HAS_VIDEO := y HAS_CPUFREQ := y HAS_PCI := y -HAS_PASSTHROUGH := y HAS_NS16550 := y HAS_EHCI := y HAS_KEXEC := y diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c index bb10993..19a914d 100644 --- a/xen/common/compat/memory.c +++ b/xen/common/compat/memory.c @@ -18,7 +18,7 @@ CHECK_TYPE(domid); CHECK_mem_access_op; CHECK_vmemrange; -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH struct get_reserved_device_memory { struct compat_reserved_device_memory_map map; unsigned int used_entries; @@ -340,7 +340,7 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) break; } -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH case XENMEM_reserved_device_memory_map: { struct get_reserved_device_memory grdm; diff --git a/xen/common/memory.c b/xen/common/memory.c index a3bffb7..da4eb36 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -610,7 +610,7 @@ static int xenmem_add_to_physmap(struct domain *d, xatp->gpfn += start; xatp->size -= start; -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH if ( need_iommu(d) ) this_cpu(iommu_dont_flush_iotlb) = 1; #endif @@ -633,7 +633,7 @@ static int xenmem_add_to_physmap(struct domain *d, } } -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH if ( need_iommu(d) ) { this_cpu(iommu_dont_flush_iotlb) = 0; @@ -760,7 +760,7 @@ static int construct_memop_from_reservation( return 0; } -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH struct get_reserved_device_memory { struct xen_reserved_device_memory_map map; unsigned int used_entries; @@ -1204,7 +1204,7 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg) break; } -#ifdef HAS_PASSTHROUGH +#ifdef CONFIG_HAS_PASSTHROUGH case XENMEM_reserved_device_memory_map: { struct get_reserved_device_memory grdm; diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index 7bc7b6e..57311cc 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -1,3 +1,4 @@ menu "Device Drivers" +source "drivers/passthrough/Kconfig" endmenu diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile index 9c70f20..e283870 100644 --- a/xen/drivers/Makefile +++ b/xen/drivers/Makefile @@ -1,6 +1,6 @@ subdir-y += char subdir-$(HAS_CPUFREQ) += cpufreq subdir-$(
[Xen-devel] [PATCHv6] 11/28] build: convert HAS_VGA use to Kconfig
Use the Kconfig generated CONFIG_HAS_VGA defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/drivers/video/Makefile | 4 ++-- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 70188de..0c86a52 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -7,6 +7,7 @@ config X86 select HAS_ACPI select HAS_PASSTHROUGH select HAS_VIDEO + select HAS_VGA select HAS_PCI select UART_NS16550 select HAS_GDBSX diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 8fda89e..47d4dc6 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -2,7 +2,6 @@ # x86-specific definitions HAS_NUMA := y -HAS_VGA := y HAS_CPUFREQ := y HAS_EHCI := y HAS_KEXEC := y diff --git a/xen/drivers/video/Makefile b/xen/drivers/video/Makefile index 914b6cf..0143c4a 100644 --- a/xen/drivers/video/Makefile +++ b/xen/drivers/video/Makefile @@ -1,7 +1,7 @@ -obj-$(HAS_VGA) := vga.o +obj-$(CONFIG_HAS_VGA) := vga.o obj-$(CONFIG_HAS_VIDEO) += font_8x14.o obj-$(CONFIG_HAS_VIDEO) += font_8x16.o obj-$(CONFIG_HAS_VIDEO) += font_8x8.o obj-$(CONFIG_HAS_VIDEO) += lfb.o -obj-$(HAS_VGA) += vesa.o +obj-$(CONFIG_HAS_VGA) += vesa.o obj-$(HAS_ARM_HDLCD) += arm_hdlcd.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 28/28] build: convert kexec options to CONFIG_KEXEC
Replace kexec := y in Rules.mk with a Kconfig option called CONFIG_KEXEC CC: Ian Campbell CC: Ian Jackson CC: Jan Beulich CC: Keir Fraser CC: Tim Deegan Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 6 -- xen/common/Kconfig | 12 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 1999ff5..e31be35 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -10,7 +10,6 @@ lock_profile ?= n crash_debug ?= n frame_pointer ?= n lto ?= n -kexec ?= y -include $(BASEDIR)/include/config/auto.conf @@ -65,11 +64,6 @@ ifneq ($(max_phys_irqs),) CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs) endif -CONFIG_KEXEC-$(CONFIG_HAS_KEXEC) := $(kexec) -CONFIG_KEXEC := $(CONFIG_KEXEC-y) - -CFLAGS-$(CONFIG_KEXEC) += -DCONFIG_KEXEC - AFLAGS-y+= -D__ASSEMBLY__ -include $(BASEDIR)/include/xen/config.h # Clang's built-in assembler can't handle .code16/.code32/.code64 yet diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 58858d2..d46f95f 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -29,4 +29,16 @@ config HAS_KEXEC config HAS_GDBSX bool +# Enable/Disable kexec support +config KEXEC + bool "kexec support" + default y + depends on HAS_KEXEC + ---help--- + Allows a running Xen hypervisor to be replaced with another OS + without rebooting. This is primarily used to execute a crash + environment to collect information on a Xen hypervisor or dom0 crash. + + If unsure, say Y. + endmenu -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 25/28] build: convert HAS_MEM_SHARING use to Kconfig
Use the Kconfig generated CONFIG_HAS_MEM_SHARING defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Razvan Cojocaru CC: Tamas K Lengyel CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Razvan Cojocaru Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- config/x86_32.mk| 1 - config/x86_64.mk| 1 - xen/Rules.mk| 1 - xen/arch/x86/Kconfig| 1 + xen/common/Kconfig | 4 xen/common/memory.c | 2 +- xen/common/vm_event.c | 6 +++--- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h | 4 ++-- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c | 4 ++-- 11 files changed, 15 insertions(+), 13 deletions(-) diff --git a/config/x86_32.mk b/config/x86_32.mk index cf3d27f..29a18ea 100644 --- a/config/x86_32.mk +++ b/config/x86_32.mk @@ -6,7 +6,6 @@ CONFIG_MIGRATE := y CONFIG_XCUTILS := y HAS_MEM_ACCESS := y -HAS_MEM_SHARING := y CFLAGS += -m32 -march=i686 diff --git a/config/x86_64.mk b/config/x86_64.mk index 4880681..ac13bad 100644 --- a/config/x86_64.mk +++ b/config/x86_64.mk @@ -7,7 +7,6 @@ CONFIG_MIGRATE := y CONFIG_XCUTILS := y HAS_MEM_ACCESS := y -HAS_MEM_SHARING := y CONFIG_XEN_INSTALL_SUFFIX := .gz diff --git a/xen/Rules.mk b/xen/Rules.mk index 3b8fd66..1999ff5 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -56,7 +56,6 @@ CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE -CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER ifneq ($(max_phys_cpus),) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 34be03f..3842018 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -17,6 +17,7 @@ config X86 select HAS_KEXEC select HAS_MEM_ACCESS select HAS_MEM_PAGING + select HAS_MEM_SHARING config ARCH_DEFCONFIG string diff --git a/xen/common/Kconfig b/xen/common/Kconfig index f6cfb9e..58858d2 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -13,6 +13,10 @@ config HAS_MEM_ACCESS config HAS_MEM_PAGING bool +# Select HAS_MEM_SHARING if mem sharing is supported +config HAS_MEM_SHARING + bool + # Select HAS_PDX if PDX is supported config HAS_PDX bool diff --git a/xen/common/memory.c b/xen/common/memory.c index 5180fa8..4de6d49 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1291,7 +1291,7 @@ int prepare_ring_for_helper( return -ENOENT; } #endif -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING if ( p2m_is_shared(p2mt) ) { if ( page ) diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index 2e59e41..28a7add 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -518,7 +518,7 @@ static void monitor_notification(struct vcpu *v, unsigned int port) vm_event_resume(v->domain, &v->domain->vm_event->monitor); } -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING /* Registered with Xen-bound event channel for incoming notifications. */ static void mem_sharing_notification(struct vcpu *v, unsigned int port) { @@ -549,7 +549,7 @@ void vm_event_cleanup(struct domain *d) destroy_waitqueue_head(&d->vm_event->monitor.wq); (void)vm_event_disable(d, &d->vm_event->monitor); } -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING if ( d->vm_event->share.ring_page ) { destroy_waitqueue_head(&d->vm_event->share.wq); @@ -682,7 +682,7 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec, } break; -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING case XEN_DOMCTL_VM_EVENT_OP_SHARING: { struct vm_event_domain *ved = &d->vm_event->share; diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index dd7618f..d6051a4 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -576,7 +576,7 @@ static XSM_INLINE int xsm_mem_paging(XSM_DEFAULT_ARG struct domain *d) } #endif -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING static XSM_INLINE int xsm_mem_sharing(XSM_DEFAULT_ARG struct domain *d) { XSM_ASSERT_ACTION(XSM_DM_PRIV); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index b23ecda..0a4c34f 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -160,7 +160,7 @@ struct xsm_operations { int (*mem_paging) (struct domain *d); #endif -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING int (*mem_sharing) (struct domain *d); #endif @@ -617,7 +617,7 @@ static inline int xsm_mem_paging (xsm_default_t def, struct domain *d) } #endif -#ifdef HAS_MEM_SHARING +#ifdef CONFIG_HAS_MEM_SHARING static inline int xsm_mem_sharing (xsm_default_t def, struct domain *d) { return xsm_ops->mem_sharing(d); diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c index 2f50b
[Xen-devel] [PATCHv6] 12/28] build: convert HAS_CPUFREQ use to Kconfig
Use the Kconfig generated CONFIG_HAS_CPUFREQ defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Liu Jinsong Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/x86/Kconfig| 1 + xen/arch/x86/Rules.mk | 1 - xen/drivers/Kconfig | 2 ++ xen/drivers/Makefile| 2 +- xen/drivers/cpufreq/Kconfig | 4 5 files changed, 8 insertions(+), 2 deletions(-) create mode 100644 xen/drivers/cpufreq/Kconfig diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 0c86a52..7585c82 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -8,6 +8,7 @@ config X86 select HAS_PASSTHROUGH select HAS_VIDEO select HAS_VGA + select HAS_CPUFREQ select HAS_PCI select UART_NS16550 select HAS_GDBSX diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 47d4dc6..645d44c 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -2,7 +2,6 @@ # x86-specific definitions HAS_NUMA := y -HAS_CPUFREQ := y HAS_EHCI := y HAS_KEXEC := y HAS_GDBSX := y diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index f0ad01e..bc3a54f 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -4,6 +4,8 @@ source "drivers/acpi/Kconfig" source "drivers/char/Kconfig" +source "drivers/cpufreq/Kconfig" + source "drivers/passthrough/Kconfig" source "drivers/pci/Kconfig" diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile index 01d6b8d..7bbb654 100644 --- a/xen/drivers/Makefile +++ b/xen/drivers/Makefile @@ -1,5 +1,5 @@ subdir-y += char -subdir-$(HAS_CPUFREQ) += cpufreq +subdir-$(CONFIG_HAS_CPUFREQ) += cpufreq subdir-$(CONFIG_HAS_PCI) += pci subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough subdir-$(CONFIG_HAS_ACPI) += acpi diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig new file mode 100644 index 000..00be480 --- /dev/null +++ b/xen/drivers/cpufreq/Kconfig @@ -0,0 +1,4 @@ + +# Select HAS_CPUFREQ if CPU frequency scaling is supported +config HAS_CPUFREQ + bool -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 22/28] build: convert HAS_EHCI use to Kconfig
Use the Kconfig generated CONFIG_UART_EHCI defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/drivers/char/Kconfig | 7 +++ xen/drivers/char/Makefile | 2 +- 4 files changed, 9 insertions(+), 2 deletions(-) diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 01cfe69..90d3020 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -11,6 +11,7 @@ config X86 select HAS_CPUFREQ select HAS_PCI select UART_NS16550 + select UART_EHCI select HAS_GDBSX select HAS_PDX select HAS_KEXEC diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 793e1f7..2f12fe8 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -2,7 +2,6 @@ # x86-specific definitions HAS_NUMA := y -HAS_EHCI := y HAS_CORE_PARKING := y xenoprof := y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index d5cc991..c5a40f2 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -43,3 +43,10 @@ config UART_SCIF help This selects the SuperH SCI(F) UART. If you have a SuperH based board, say Y. + +config UART_EHCI + bool "USB EHCI debug port support" + depends on X86 + help + This selects the USB based EHCI debug port to be used as a UART. If + you have an x86 based system with USB, say Y. diff --git a/xen/drivers/char/Makefile b/xen/drivers/char/Makefile index 68ebc2d..f45d453 100644 --- a/xen/drivers/char/Makefile +++ b/xen/drivers/char/Makefile @@ -5,6 +5,6 @@ obj-$(CONFIG_UART_PL011) += pl011.o obj-$(CONFIG_UART_EXYNOS4210) += exynos4210-uart.o obj-$(CONFIG_UART_OMAP) += omap-uart.o obj-$(CONFIG_UART_SCIF) += scif-uart.o -obj-$(HAS_EHCI) += ehci-dbgp.o +obj-$(CONFIG_UART_EHCI) += ehci-dbgp.o obj-$(CONFIG_ARM) += dt-uart.o obj-y += serial.o -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 02/28] build: build Kconfig and config rules
Wire in the Kconfig build and makefile rules to be able to generate valid configuration files to be used by the build process but don't actually use the output for affecting the Xen build. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- .gitignore| 8 xen/Kconfig | 26 xen/Makefile | 17 xen/arch/arm/Kconfig | 31 ++ xen/arch/arm/configs/arm32_defconfig | 1 + xen/arch/arm/configs/arm64_defconfig | 0 xen/arch/x86/Kconfig | 18 xen/arch/x86/configs/x86_64_defconfig | 0 xen/common/Kconfig| 4 ++ xen/drivers/Kconfig | 3 ++ xen/scripts/kconfig/.gitignore| 3 ++ xen/scripts/kconfig/Makefile | 77 +++ 12 files changed, 188 insertions(+) create mode 100644 xen/Kconfig create mode 100644 xen/arch/arm/Kconfig create mode 100644 xen/arch/arm/configs/arm32_defconfig create mode 100644 xen/arch/arm/configs/arm64_defconfig create mode 100644 xen/arch/x86/Kconfig create mode 100644 xen/arch/x86/configs/x86_64_defconfig create mode 100644 xen/common/Kconfig create mode 100644 xen/drivers/Kconfig create mode 100644 xen/scripts/kconfig/Makefile diff --git a/.gitignore b/.gitignore index 91e1430..780df23 100644 --- a/.gitignore +++ b/.gitignore @@ -217,6 +217,11 @@ tools/xentrace/tbctl tools/xentrace/xenctx tools/xentrace/xentrace xen/.banner +xen/.config +xen/.config.old +xen/defconfig +xen/**/*.cmd +xen/**/modules.order xen/System.map xen/arch/arm/asm-offsets.s xen/arch/arm/xen.lds @@ -239,6 +244,9 @@ xen/include/headers++.chk xen/include/asm xen/include/asm-*/asm-offsets.h xen/include/compat/* +xen/include/config.h +xen/include/config/ +xen/include/generated/ xen/include/public/public xen/include/xen/*.new xen/include/xen/acm_policy.h diff --git a/xen/Kconfig b/xen/Kconfig new file mode 100644 index 000..b2d0fe2 --- /dev/null +++ b/xen/Kconfig @@ -0,0 +1,26 @@ +# +# For a description of the syntax of this configuration file, +# see Documentation/kbuild/kconfig-language.txt from the Linux +# kernel source tree. +# +mainmenu "Xen/$SRCARCH $XEN_FULLVERSION Configuration" + +config SRCARCH + string + option env="SRCARCH" + +config ARCH + string + option env="ARCH" + +source "arch/$SRCARCH/Kconfig" + +config XEN_FULLVERSION + string + option env="XEN_FULLVERSION" + +config DEFCONFIG_LIST + string + option defconfig_list + default "$ARCH_DEFCONFIG" + default "arch/$SRCARCH/defconfig" diff --git a/xen/Makefile b/xen/Makefile index c556198..f2f4378 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -17,6 +17,9 @@ export XEN_ROOT := $(BASEDIR)/.. EFI_MOUNTPOINT ?= $(BOOT_DIR)/efi +# Don't break if the build process wasn't called from the top level +XEN_TARGET_ARCH ?= $(shell uname -m) + .PHONY: default default: build @@ -88,6 +91,7 @@ _clean: delete-unfresh-files $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean + $(MAKE) -f scripts/kconfig/Makefile clean rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms *~ core rm -f include/asm-*/asm-offsets.h rm -f .banner @@ -216,3 +220,16 @@ FORCE: %/: FORCE $(MAKE) -f $(BASEDIR)/Rules.mk -C $* built_in.o built_in_bin.o + +kconfig := silentoldconfig oldconfig config menuconfig defconfig \ + nconfig xconfig gconfig savedefconfig listnewconfig olddefconfig +.PHONY: $(kconfig) +$(kconfig): + $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) $@ + +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) silentoldconfig + +# Allow people to just run `make` as before and not force them to configure +$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ; + $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) defconfig diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig new file mode 100644 index 000..a473137 --- /dev/null +++ b/xen/arch/arm/Kconfig @@ -0,0 +1,31 @@ +# Select 32 or 64 bit +config 64BIT + bool "64-bit Xen" if ARCH = "arm64" + default ARCH != "arm32" + help + Say yes to build a 64-bit Xen + Say no to build a 32-bit Xen + +config ARM_32 + def_bool y + depends on !64BIT + +config ARM_64 + def_bool y + depends on 64BIT + +config ARM + def_bool y + +config ARCH_DEFCONFIG + string + default "arch/arm/configs/arm32_defconfig" if ARM_32 + default "arch/arm/configs/arm64
[Xen-devel] [PATCHv6] 08/28] build: convert HAS_IOPORTS use to Kconfig
Use the Kconfig generated CONFIG_HAS_IOPORTS defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/drivers/char/Kconfig | 5 + xen/drivers/char/ns16550.c | 10 +- 5 files changed, 11 insertions(+), 7 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index fb270f6..870c548 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING -CFLAGS-$(HAS_IOPORTS) += -DHAS_IOPORTS CFLAGS-$(HAS_PDX) += -DHAS_PDX CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 8039111..54124c6 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -3,6 +3,7 @@ config X86_64 config X86 def_bool y + select HAS_IOPORTS select HAS_PASSTHROUGH select HAS_PCI select UART_NS16550 diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 17d2869..151ed25 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -1,7 +1,6 @@ # x86-specific definitions -HAS_IOPORTS := y HAS_ACPI := y HAS_NUMA := y HAS_VGA := y diff --git a/xen/drivers/char/Kconfig b/xen/drivers/char/Kconfig index 6ed451f..8ecea29 100644 --- a/xen/drivers/char/Kconfig +++ b/xen/drivers/char/Kconfig @@ -3,3 +3,8 @@ config UART_NS16550 bool "16550-series UART support" help This selects the 16550-series UART support. For most systems, say Y. + +# Select HAS_IOPORTS if 16550 has I/O ports +config HAS_IOPORTS + bool + depends on UART_NS16550 diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 6f197f3..c56361c 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -348,7 +348,7 @@ static void ns16550_delayed_resume(void *data); static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg) { void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift); -#ifdef HAS_IOPORTS +#ifdef CONFIG_HAS_IOPORTS if ( uart->remapped_io_base == NULL ) return inb(uart->io_base + reg); #endif @@ -366,7 +366,7 @@ static u8 ns_read_reg(struct ns16550 *uart, unsigned int reg) static void ns_write_reg(struct ns16550 *uart, unsigned int reg, u8 c) { void __iomem *addr = uart->remapped_io_base + (reg << uart->reg_shift); -#ifdef HAS_IOPORTS +#ifdef CONFIG_HAS_IOPORTS if ( uart->remapped_io_base == NULL ) return outb(c, uart->io_base + reg); #endif @@ -552,7 +552,7 @@ static void __init ns16550_init_preirq(struct serial_port *port) { struct ns16550 *uart = port->uart; -#ifdef HAS_IOPORTS +#ifdef CONFIG_HAS_IOPORTS /* I/O ports are distinguished by their size (16 bits). */ if ( uart->io_base >= 0x1 ) #endif @@ -722,7 +722,7 @@ static void ns16550_resume(struct serial_port *port) static void __init ns16550_endboot(struct serial_port *port) { -#ifdef HAS_IOPORTS +#ifdef CONFIG_HAS_IOPORTS struct ns16550 *uart = port->uart; int rv; @@ -786,7 +786,7 @@ static int __init check_existence(struct ns16550 *uart) { unsigned char status, scratch, scratch2, scratch3; -#ifdef HAS_IOPORTS +#ifdef CONFIG_HAS_IOPORTS /* * We can't poke MMIO UARTs until they get I/O remapped later. Assume that * if we're getting MMIO UARTs, the arch code knows what it's doing. -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 14/28] build: convert HAS_PDX use to Kconfig
Use the Kconfig generated CONFIG_HAS_PDX defines in the code base. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/arm/Kconfig | 1 + xen/arch/arm/Rules.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/common/Kconfig| 4 xen/common/Makefile | 2 +- xen/include/xen/pdx.h | 4 ++-- 8 files changed, 9 insertions(+), 6 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 0ff1a5d..c2a3e15 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -59,7 +59,6 @@ CFLAGS-$(lock_profile) += -DLOCK_PROFILE CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING -CFLAGS-$(HAS_PDX) += -DHAS_PDX CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER ifneq ($(max_phys_cpus),) diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 1786769..32f57d4 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -19,6 +19,7 @@ config ARM select HAS_DEVICE_TREE select HAS_VIDEO select HAS_PASSTHROUGH + select HAS_PDX config ARCH_DEFCONFIG string diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index 90b1f24..52b1ad4 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -7,7 +7,6 @@ # HAS_ARM_HDLCD := y -HAS_PDX := y CFLAGS += -I$(BASEDIR)/include diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 7585c82..a285a1c 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -12,6 +12,7 @@ config X86 select HAS_PCI select UART_NS16550 select HAS_GDBSX + select HAS_PDX config ARCH_DEFCONFIG string diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 009f702..193e7ea 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -4,7 +4,6 @@ HAS_NUMA := y HAS_EHCI := y HAS_KEXEC := y -HAS_PDX := y HAS_CORE_PARKING := y xenoprof := y diff --git a/xen/common/Kconfig b/xen/common/Kconfig index f63284d..b429a64 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -5,6 +5,10 @@ menu "Common Features" config HAS_DEVICE_TREE bool +# Select HAS_PDX if PDX is supported +config HAS_PDX + bool + # Select HAS_GDBSX if GDBSX is supported config HAS_GDBSX bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 5dc2bb2..0acd2b0 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -23,7 +23,7 @@ obj-y += memory.o obj-y += multicall.o obj-y += notifier.o obj-y += page_alloc.o -obj-$(HAS_PDX) += pdx.o +obj-$(CONFIG_HAS_PDX) += pdx.o obj-y += preempt.o obj-y += random.o obj-y += rangeset.o diff --git a/xen/include/xen/pdx.h b/xen/include/xen/pdx.h index 18fe8e5..6f25f90 100644 --- a/xen/include/xen/pdx.h +++ b/xen/include/xen/pdx.h @@ -1,7 +1,7 @@ #ifndef __XEN_PDX_H__ #define __XEN_PDX_H__ -#ifdef HAS_PDX +#ifdef CONFIG_HAS_PDX extern unsigned long max_pdx; extern unsigned long pfn_pdx_bottom_mask, ma_va_bottom_mask; @@ -37,7 +37,7 @@ static inline unsigned long pdx_to_pfn(unsigned long pdx) extern void pfn_pdx_hole_setup(unsigned long); -#endif /* HAS_PDX */ +#endif /* CONFIG_HAS_PDX */ #endif /* __XEN_PDX_H__ */ /* -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 15/28] build: convert HAS_KEXEC use to Kconfig
Use the Kconfig generated CONFIG_HAS_KEXEC defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 2 +- xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk | 1 - xen/common/Kconfig| 4 4 files changed, 6 insertions(+), 2 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index c2a3e15..4d90aca 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -68,7 +68,7 @@ ifneq ($(max_phys_irqs),) CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs) endif -CONFIG_KEXEC-$(HAS_KEXEC) := $(kexec) +CONFIG_KEXEC-$(CONFIG_HAS_KEXEC) := $(kexec) CONFIG_KEXEC := $(CONFIG_KEXEC-y) CFLAGS-$(CONFIG_KEXEC) += -DCONFIG_KEXEC diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index a285a1c..01cfe69 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -13,6 +13,7 @@ config X86 select UART_NS16550 select HAS_GDBSX select HAS_PDX + select HAS_KEXEC config ARCH_DEFCONFIG string diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 193e7ea..793e1f7 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -3,7 +3,6 @@ HAS_NUMA := y HAS_EHCI := y -HAS_KEXEC := y HAS_CORE_PARKING := y xenoprof := y diff --git a/xen/common/Kconfig b/xen/common/Kconfig index b429a64..6987e84 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -9,6 +9,10 @@ config HAS_DEVICE_TREE config HAS_PDX bool +# Select HAS_KEXEC if kexec is supported +config HAS_KEXEC + bool + # Select HAS_GDBSX if GDBSX is supported config HAS_GDBSX bool -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 13/28] build: convert HAS_GDBSX use to Kconfig
Use the Kconfig generated CONFIG_HAS_GDBSX defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/x86/Rules.mk | 1 - xen/common/Kconfig| 4 xen/common/domain.c | 2 +- 4 files changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 351a186..0ff1a5d 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -56,7 +56,6 @@ CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE -CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 645d44c..009f702 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -4,7 +4,6 @@ HAS_NUMA := y HAS_EHCI := y HAS_KEXEC := y -HAS_GDBSX := y HAS_PDX := y HAS_CORE_PARKING := y xenoprof := y diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 53ca33f..f63284d 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -5,4 +5,8 @@ menu "Common Features" config HAS_DEVICE_TREE bool +# Select HAS_GDBSX if GDBSX is supported +config HAS_GDBSX + bool + endmenu diff --git a/xen/common/domain.c b/xen/common/domain.c index f56b7ff..94cb2cc 100644 --- a/xen/common/domain.c +++ b/xen/common/domain.c @@ -772,7 +772,7 @@ void vcpu_end_shutdown_deferral(struct vcpu *v) vcpu_check_shutdown(v); } -#ifdef HAS_GDBSX +#ifdef CONFIG_HAS_GDBSX void domain_pause_for_debugger(void) { struct vcpu *curr = current; -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 00/28] Kconfig conversion
The following series is a follow on to the Kconfig conversion patch series. There are still more components to convert however this is the bare minimal to get everything working and get the options out of the existing makefiles. The CONFIG_HAS_ variables are there to match the behavior of the Linux CONFIG_HAVE_ variables. The purpose is to say that this hardware/profile/env supports this option while the CONFIG_ variable states that this option was requested on/off by user intervention. The UARTs are now uniformly prefixed as CONFIG_UART_ and dropping most of the CONFIG_HAS_ labeling for them. This means they are now user selectable as requested by Julien Grall in the prior review. The question I've got is the old config was just for selecting defaults. Users could enable the OMAP UART for arm64 for example but I'm not sure if that's valid. Currently this patchset makes those UARTs not user selectable if they were not previously defaulted on. But I would like some feedback on this if possible. Ultimately my goal is to allow for more parts of the hypervisor to be turned off at compile time and potentially make it easier to include more experimental features by others which can be turned off by default. Also to provide the one true location for all possible knobs in the source code. The patch series can be grabbed at: https://github.com/cardoe/xen/tree/kconfig_v6 Changes since v5: - added Andrew Cooper's Acked-by and Tested-by - rebased to resolve conflict with NUMA changes in staging (minor conflict) Changes since v4: - v4 was an oops and was a resend of v3. So the 'Changes since v3' apply here. Changes since v3: - fix dependency inversion causing options to appear to flip back on (hi kexec) - separate out wiring up Kconfig and then using it in the build (added patch 3) - dropped the old patch 3 - changed UART configs to be prefixed as CONFIG_UART_ - changed ARM UART defaults Changes since v2: - drop x86_32 support (patch 2) - fix make defconfig (patch 2) - fix 'make -C xen' vs 'cd xen && make' behaving differently (patch 2) - fix for ARM64 builds (added patch 3) - At this point all targets are tested on x86_64, arm32, and arm64 with fresh clones and rebuilds. Changes since v1: - hopefully addressed all review comments - added CCs to all maintainers from get_maintainer.pl as requested - drop Kbuild to build Kconfig and instead port the Makefile to the Xen env - add support for xconfig/gconfig - include Kconfig docs from Linux Doug Goldstein (28): build: import Kbuild/Kconfig from Linux 4.2 build: build Kconfig and config rules build: use generated Kconfig options for Xen build: convert HAS_PASSTHROUGH use to Kconfig build: convert HAS_DEVICE_TREE use to Kconfig build: convert HAS_PCI use to Kconfig build: convert HAS_NS16550 use to Kconfig build: convert HAS_IOPORTS use to Kconfig build: convert HAS_ACPI use to Kconfig build: convert HAS_VIDEO use to Kconfig build: convert HAS_VGA use to Kconfig build: convert HAS_CPUFREQ use to Kconfig build: convert HAS_GDBSX use to Kconfig build: convert HAS_PDX use to Kconfig build: convert HAS_KEXEC use to Kconfig build: convert HAS_ARM_HDLCD use to Kconfig build: convert HAS_CADENCE_UART use to Kconfig build: convert HAS_PL011 use to Kconfig build: convert HAS_EXYNOS4210 use to Kconfig build: convert HAS_OMAP use to Kconfig build: convert HAS_SCIF use to Kconfig build: convert HAS_EHCI use to Kconfig build: convert HAS_MEM_ACCESS use to Kconfig build: convert HAS_MEM_PAGING use to Kconfig build: convert HAS_MEM_SHARING use to Kconfig build: convert HAS_GICV3 use to Kconfig build: convert CONFIG_COMPAT to Kconfig build: convert kexec options to CONFIG_KEXEC .gitignore |8 + config/arm32.mk|5 - config/arm64.mk|4 - config/x86_32.mk |2 - config/x86_64.mk |2 - docs/misc/kconfig-language.txt | 395 docs/misc/kconfig.txt | 237 +++ xen/Kconfig| 26 + xen/Makefile | 25 + xen/Rules.mk | 18 +- xen/arch/arm/Kconfig | 42 + xen/arch/arm/Makefile |2 +- xen/arch/arm/Rules.mk |8 - xen/arch/arm/configs/arm32_defconfig |5 + xen/arch/arm/configs/arm64_defconfig |3 + xen/arch/arm/vgic.c|2 +- xen/arch/x86/Kconfig | 39 + xen/arch/x86/Rules.mk | 12 - xen/arch/x86/configs/x86_64_defconfig |0 xen/common/Kconfig | 44 + xen/common/Makefile|8 +- xen/common/compat/memory.c |4 +- xen/
[Xen-devel] [PATCHv6] 23/28] build: convert HAS_MEM_ACCESS use to Kconfig
Use the Kconfig generated CONFIG_HAS_MEM_ACCESS defines in the code base. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Razvan Cojocaru CC: Tamas K Lengyel CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Razvan Cojocaru Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/arm/Kconfig | 1 + xen/arch/x86/Kconfig | 1 + xen/common/Kconfig | 4 xen/common/Makefile | 2 +- xen/common/domctl.c | 2 +- xen/common/vm_event.c| 2 +- xen/include/xen/mem_access.h | 4 ++-- xen/include/xsm/dummy.h | 2 +- xen/include/xsm/xsm.h| 4 ++-- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 4 ++-- 12 files changed, 17 insertions(+), 12 deletions(-) diff --git a/xen/Rules.mk b/xen/Rules.mk index 4d90aca..f5ffe9d 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -56,7 +56,6 @@ CFLAGS-$(crash_debug) += -DCRASH_DEBUG CFLAGS-$(perfc) += -DPERF_COUNTERS CFLAGS-$(perfc_arrays) += -DPERF_ARRAYS CFLAGS-$(lock_profile) += -DLOCK_PROFILE -CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig index 9e7351e..b52474e 100644 --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -21,6 +21,7 @@ config ARM select HAS_ARM_HDLCD select HAS_PASSTHROUGH select HAS_PDX + select HAS_MEM_ACCESS config ARCH_DEFCONFIG string diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 90d3020..530563f 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -15,6 +15,7 @@ config X86 select HAS_GDBSX select HAS_PDX select HAS_KEXEC + select HAS_MEM_ACCESS config ARCH_DEFCONFIG string diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 6987e84..bdb95f0 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -5,6 +5,10 @@ menu "Common Features" config HAS_DEVICE_TREE bool +# Select HAS_MEM_ACCESS if mem access is supported +config HAS_MEM_ACCESS + bool + # Select HAS_PDX if PDX is supported config HAS_PDX bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 0acd2b0..8ab15ba 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -18,7 +18,7 @@ obj-$(CONFIG_KEXEC) += kexec.o obj-$(CONFIG_KEXEC) += kimage.o obj-y += lib.o obj-y += lzo.o -obj-$(HAS_MEM_ACCESS) += mem_access.o +obj-$(CONFIG_HAS_MEM_ACCESS) += mem_access.o obj-y += memory.o obj-y += multicall.o obj-y += notifier.o diff --git a/xen/common/domctl.c b/xen/common/domctl.c index 46b967e..1fab587 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -1130,7 +1130,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) d->disable_migrate = op->u.disable_migrate.disable; break; -#ifdef HAS_MEM_ACCESS +#ifdef CONFIG_HAS_MEM_ACCESS case XEN_DOMCTL_set_access_required: if ( unlikely(current->domain == d) ) ret = -EPERM; diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c index e1f9580..0fe93dc 100644 --- a/xen/common/vm_event.c +++ b/xen/common/vm_event.c @@ -397,7 +397,7 @@ void vm_event_resume(struct domain *d, struct vm_event_domain *ved) vm_event_register_write_resume(v, &rsp); break; -#ifdef HAS_MEM_ACCESS +#ifdef CONFIG_HAS_MEM_ACCESS case VM_EVENT_REASON_MEM_ACCESS: mem_access_resume(v, &rsp); break; diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h index 111f1fe..90efe01 100644 --- a/xen/include/xen/mem_access.h +++ b/xen/include/xen/mem_access.h @@ -25,7 +25,7 @@ #include #include -#ifdef HAS_MEM_ACCESS +#ifdef CONFIG_HAS_MEM_ACCESS int mem_access_memop(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(xen_mem_access_op_t) arg); @@ -58,7 +58,7 @@ void mem_access_resume(struct vcpu *vcpu, vm_event_response_t *rsp) /* Nothing to do. */ } -#endif /* HAS_MEM_ACCESS */ +#endif /* CONFIG_HAS_MEM_ACCESS */ #endif /* _XEN_ASM_MEM_ACCESS_H */ diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h index 42e696a..7a9006b 100644 --- a/xen/include/xsm/dummy.h +++ b/xen/include/xsm/dummy.h @@ -560,7 +560,7 @@ static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, int return xsm_default_action(action, current->domain, d); } -#ifdef HAS_MEM_ACCESS +#ifdef CONFIG_HAS_MEM_ACCESS static XSM_INLINE int xsm_mem_access(XSM_DEFAULT_ARG struct domain *d) { XSM_ASSERT_ACTION(XSM_DM_PRIV); diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h index c843a41..a550ae2 100644 --- a/xen/include/xsm/xsm.h +++ b/xen/include/xsm/xsm.h @@ -152,7 +152,7 @@ struct xsm_ope
[Xen-devel] [PATCHv6] 03/28] build: use generated Kconfig options for Xen
Switches the build system to rely on the options and flags generated by Kconfig to control what gets built and how. Follow on patches will convert items to be prefixed with CONFIG_. Additionally remove a #define that resulted in a redefined variable when building for arm. CC: Ian Campbell CC: Stefano Stabellini CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper Signed-off-by: Doug Goldstein Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Makefile | 12 ++-- xen/Rules.mk | 2 ++ xen/drivers/passthrough/arm/smmu.c | 4 xen/include/xen/config.h | 2 ++ 4 files changed, 14 insertions(+), 6 deletions(-) diff --git a/xen/Makefile b/xen/Makefile index f2f4378..0f3de72 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -26,6 +26,9 @@ default: build .PHONY: dist dist: install +.PHONY: build +build:: $(BASEDIR)/include/config/auto.conf + .PHONY: build install uninstall clean distclean cscope TAGS tags MAP gtags build install uninstall debug clean distclean cscope TAGS tags MAP gtags:: ifneq ($(XEN_TARGET_ARCH),x86_32) @@ -227,9 +230,14 @@ kconfig := silentoldconfig oldconfig config menuconfig defconfig \ $(kconfig): $(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) $@ -$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd +$(BASEDIR)/include/config/%.conf: $(BASEDIR)/include/config/auto.conf.cmd $(BASEDIR)/.config $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) silentoldconfig # Allow people to just run `make` as before and not force them to configure -$(BASEDIR)/.config $(BASEDIR)/include/config/auto.conf.cmd: ; +$(BASEDIR)/.config: $(Q)$(MAKE) -f $(BASEDIR)/scripts/kconfig/Makefile ARCH=$(XEN_TARGET_ARCH) defconfig + +# Break the dependency chain for the first run +$(BASEDIR)/include/config/auto.conf.cmd: ; + +-include $(BASEDIR)/include/config/auto.conf.cmd diff --git a/xen/Rules.mk b/xen/Rules.mk index e9d03b9..011768a 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -12,6 +12,8 @@ frame_pointer ?= n lto ?= n kexec ?= y +-include $(BASEDIR)/include/config/auto.conf + include $(XEN_ROOT)/Config.mk # Hardcoded configuration implications and dependencies. diff --git a/xen/drivers/passthrough/arm/smmu.c b/xen/drivers/passthrough/arm/smmu.c index bb08827..62da087 100644 --- a/xen/drivers/passthrough/arm/smmu.c +++ b/xen/drivers/passthrough/arm/smmu.c @@ -196,10 +196,6 @@ static inline int pci_for_each_dma_alias(struct pci_dev *pdev, #define PHYS_MASK_SHIFTPADDR_BITS typedef paddr_t phys_addr_t; -#ifdef CONFIG_ARM_64 -# define CONFIG_64BIT -#endif - #define VA_BITS0 /* Only used for configuring stage-1 input size */ /* The macro ACCESS_ONCE start to be replaced in Linux in favor of diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index f7258c7..12a4688 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -12,6 +12,8 @@ #endif #include +#include + #define EXPORT_SYMBOL(var) #define EXPORT_SYMBOL_GPL(var) -- 2.4.10 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv6] 06/28] build: convert HAS_PCI use to Kconfig
Use the Kconfig generated CONFIG_HAS_PCI defines in the code base. CC: Keir Fraser CC: Jan Beulich CC: Andrew Cooper CC: Daniel De Graaf Signed-off-by: Doug Goldstein Acked-by: Daniel De Graaf Acked-by: Andrew Cooper Tested-by: Andrew Cooper --- xen/Rules.mk | 1 - xen/arch/x86/Kconfig | 1 + xen/arch/x86/Rules.mk| 1 - xen/common/sysctl.c | 2 +- xen/drivers/Kconfig | 3 +++ xen/drivers/Makefile | 2 +- xen/drivers/char/ns16550.c | 24 xen/drivers/passthrough/Makefile | 2 +- xen/drivers/passthrough/iommu.c | 2 +- xen/drivers/pci/Kconfig | 4 xen/include/xen/iommu.h | 10 +- xen/include/xsm/dummy.h | 4 ++-- xen/include/xsm/xsm.h| 6 +++--- xen/xsm/dummy.c | 2 +- xen/xsm/flask/hooks.c| 14 +++--- 15 files changed, 42 insertions(+), 36 deletions(-) create mode 100644 xen/drivers/pci/Kconfig diff --git a/xen/Rules.mk b/xen/Rules.mk index 15dcedc..fb270f6 100644 --- a/xen/Rules.mk +++ b/xen/Rules.mk @@ -61,7 +61,6 @@ CFLAGS-$(HAS_GDBSX) += -DHAS_GDBSX CFLAGS-$(HAS_MEM_ACCESS) += -DHAS_MEM_ACCESS CFLAGS-$(HAS_MEM_PAGING) += -DHAS_MEM_PAGING CFLAGS-$(HAS_MEM_SHARING) += -DHAS_MEM_SHARING -CFLAGS-$(HAS_PCI) += -DHAS_PCI CFLAGS-$(HAS_IOPORTS) += -DHAS_IOPORTS CFLAGS-$(HAS_PDX) += -DHAS_PDX CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig index 4ff1f63..4e1a9da 100644 --- a/xen/arch/x86/Kconfig +++ b/xen/arch/x86/Kconfig @@ -4,6 +4,7 @@ config X86_64 config X86 def_bool y select HAS_PASSTHROUGH + select HAS_PCI select HAS_GDBSX config ARCH_DEFCONFIG diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk index 09f2844..8743509 100644 --- a/xen/arch/x86/Rules.mk +++ b/xen/arch/x86/Rules.mk @@ -7,7 +7,6 @@ HAS_NUMA := y HAS_VGA := y HAS_VIDEO := y HAS_CPUFREQ := y -HAS_PCI := y HAS_NS16550 := y HAS_EHCI := y HAS_KEXEC := y diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c index 85e853f..47d115e 100644 --- a/xen/common/sysctl.c +++ b/xen/common/sysctl.c @@ -401,7 +401,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl) break; #endif -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI case XEN_SYSCTL_pcitopoinfo: { xen_sysctl_pcitopoinfo_t *ti = &op->u.pcitopoinfo; diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig index 57311cc..5362e41 100644 --- a/xen/drivers/Kconfig +++ b/xen/drivers/Kconfig @@ -1,4 +1,7 @@ menu "Device Drivers" source "drivers/passthrough/Kconfig" + +source "drivers/pci/Kconfig" + endmenu diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile index e283870..eb32d69 100644 --- a/xen/drivers/Makefile +++ b/xen/drivers/Makefile @@ -1,6 +1,6 @@ subdir-y += char subdir-$(HAS_CPUFREQ) += cpufreq -subdir-$(HAS_PCI) += pci +subdir-$(CONFIG_HAS_PCI) += pci subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough subdir-$(HAS_ACPI) += acpi subdir-$(HAS_VIDEO) += video diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 6eab071..6f197f3 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -16,7 +16,7 @@ #include #include #include -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI #include #include #include @@ -64,7 +64,7 @@ static struct ns16550 { unsigned int timeout_ms; bool_t intr_works; bool_t dw_usr_bsy; -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI /* PCI card parameters. */ bool_t pb_bdf_enable; /* if =1, pb-bdf effective, port behind bridge */ bool_t ps_bdf_enable; /* if =1, ps_bdf effective, port on pci card */ @@ -97,7 +97,7 @@ struct ns16550_config_param { }; -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI enum { param_default = 0, param_trumanage, @@ -475,7 +475,7 @@ static int ns16550_getc(struct serial_port *port, char *pc) static void pci_serial_early_init(struct ns16550 *uart) { -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI if ( !uart->ps_bdf_enable || uart->io_base >= 0x1 ) return; @@ -621,7 +621,7 @@ static void __init ns16550_init_postirq(struct serial_port *port) ns16550_setup_postirq(uart); -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI if ( uart->bar || uart->ps_bdf_enable ) { if ( !uart->enable_ro ) @@ -650,7 +650,7 @@ static void ns16550_suspend(struct serial_port *port) stop_timer(&uart->timer); -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI if ( uart->bar ) uart->cr = pci_conf_read16(0, uart->ps_bdf[0], uart->ps_bdf[1], uart->ps_bdf[2], PCI_COMMAND); @@ -659,7 +659,7 @@ static void ns16550_suspend(struct serial_port *port) static void _ns16550_resume(struct serial_port *port) { -#ifdef HAS_PCI +#ifdef CONFIG_HAS_PCI struct ns16550 *uart = port->uart; if ( uart->bar ) @@ -797,7 +797
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown"): > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > Well so then perhaps we should jsut change libxl__xs_mkdir to use > > WRITE. > > I think the rename to libxl__xs_mknode() is warranted, and will avoid > anyone's belief that the implementer typo-ed the actual XS command :-) OK. > > This rather confusing situation is probably worth a doc > > comment next to the prototype in libxl_internal.h. > > Yep. That sounds like a good idea. I'll do that. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 65054: regressions - FAIL
flight 65054 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/65054/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 64579 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 64579 test-amd64-i386-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 64579 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 64579 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 7 host-ping-check-xen fail REGR. vs. 64579 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 64579 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail blocked in 64579 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-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 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-amd64-i386-libvirt-xsm 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-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 9 debian-di-installfail never pass version targeted for testing: qemuu5522a841cab5f15ac0f8d207b320c21755a7a1a5 baseline version: qemuu9be060f5278dc0d732ebfcf2bf0a293f88b833eb Last test of basis64579 2015-11-17 15:37:49 Z7 days Failing since 64797 2015-11-19 03:03:30 Z5 days4 attempts Testing same since65054 2015-11-23 18:03:36 Z0 days1 attempts People who touched revisions under test: "Dr. David Alan Gilbert" Alberto Garcia Andreas Färber Bandan Das Daniel P. Berrange Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost François Baldassari Gerd Hoffmann Greg Kurz Ildar Isaev John Clarke John Snow Juan Quintela Kevin Wolf Marc-André Lureau Max Reitz Michael Roth Michael S. Tsirkin Pavel Fedin Peter Lieven Peter Maydell Rabin Vincent Richard Henderson Sergey Fedorov Victor Kaplansky Yuanhan Liu Yuri Pudgorodskiy jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 24 November 2015 17:39 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu > Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for > ~/control/shutdown > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() > for ~/control/shutdown"): > > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > > And even if the node did somehow end up with a nonempty value, > nothing > > > would break because no-one would read it. > > > > Maybe. Personally I would have thought a toolstack would want to put > things into a known state and XS_MKDIR just doesn't do that. > > Hrm. > > > > > If you use XS_WRITE then it is and I think that is the correct > > > > semantic here (even though we happen to get away with it at the > > > > moment). I'm happy with the function rename, but would you be > happy > > > > with the change in semantic? > > > > > > XS_MKDIR creates missing parents, which XS_WRITE doesn't. > > > > According to the documentation it does: (from xenstore.txt) > > > > READ| > > WRITE | > > Store and read the octet string at . > > WRITE creates any missing parent paths, with empty values. > > Oh! > > Well so then perhaps we should jsut change libxl__xs_mkdir to use > WRITE. I think the rename to libxl__xs_mknode() is warranted, and will avoid anyone's belief that the implementer typo-ed the actual XS command :-) > This rather confusing situation is probably worth a doc > comment next to the prototype in libxl_internal.h. Yep. That sounds like a good idea. I'll do that. Paul > > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.
>>> On 24.11.15 at 18:17, wrote: > --- a/xen/drivers/passthrough/vtd/quirks.c > +++ b/xen/drivers/passthrough/vtd/quirks.c > @@ -320,6 +320,20 @@ void __init platform_quirks_init(void) > /* Tylersburg interrupt remap quirk */ > if ( iommu_intremap ) > tylersburg_intremap_quirk(); > + > +/* > + * Disable shared EPT ("sharept") on Sandybridge and older processors > + * by default. > + * SandyBridge has no huge page support for IOTLB which leads to fallback > + * on 4k pages and leads to performance degradation. > + * > + * Shared EPT ("sharept") will be disabled only if user has not > + * provided explicit choice on the command line thus iommu_hap_pt_share > is > + * at its initialized value of -1. > + */ > +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F || > + boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) ) > +iommu_hap_pt_share = 0; If we really want to do this, then I think we should key this on EPT but not VT-d having 2M support, instead of on CPU models. Also - with the above only marginally relevant - the line split and/or indentation is wrong. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown"): > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > > And even if the node did somehow end up with a nonempty value, nothing > > would break because no-one would read it. > > Maybe. Personally I would have thought a toolstack would want to put things > into a known state and XS_MKDIR just doesn't do that. Hrm. > > > If you use XS_WRITE then it is and I think that is the correct > > > semantic here (even though we happen to get away with it at the > > > moment). I'm happy with the function rename, but would you be happy > > > with the change in semantic? > > > > XS_MKDIR creates missing parents, which XS_WRITE doesn't. > > According to the documentation it does: (from xenstore.txt) > > READ | > WRITE | > Store and read the octet string at . > WRITE creates any missing parent paths, with empty values. Oh! Well so then perhaps we should jsut change libxl__xs_mkdir to use WRITE. This rather confusing situation is probably worth a doc comment next to the prototype in libxl_internal.h. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Bug: QEMU segfault within vnc
Hi, QEMU segfault while running a Xen guest, the guest is a WinXP. To reproduce, I start the guest, I don't connect to vnc, and after about 2min, QEMU segv. I think it's around the time it take for windows to boot and reach the desktop. The first commit where this happen is: vnc: fix local state init 2e0c90af0a33451498d333d72c06e5429c7cd168 The backtrace associated with this commit: #0 0x7f8be2035680 in pixman_image_get_width () from /usr/lib/libpixman-1.so.0 #1 0x5576b9cd1fc7 in vnc_refresh_server_surface (vd=0x7f8be2dd9010) at ui/vnc.c:2873 #2 0x5576b9ccd413 in vnc_dpy_copy (dcl=0x7f8be2dd9048, src_x=116, src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/vnc.c:934 #3 0x5576b9cc1761 in dpy_gfx_copy (con=0x5576bccbbc50, src_x=116, src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/console.c:1533 #4 0x5576b9cc2b26 in qemu_console_copy (con=0x5576bccbbc50, src_x=116, src_y=379, dst_x=116, dst_y=367, w=16, h=3) at ui/console.c:2040 #5 0x5576b9b9baf8 in cirrus_do_copy (s=0x5576bcb5a100, dst=1127772, src=1164636, w=16, h=3) at hw/display/cirrus_vga.c:772 #6 0x5576b9b9bbcc in cirrus_bitblt_videotovideo_copy (s=0x5576bcb5a100) at hw/display/cirrus_vga.c:791 #7 0x5576b9b9c0a1 in cirrus_bitblt_videotovideo (s=0x5576bcb5a100) at hw/display/cirrus_vga.c:913 #8 0x5576b9b9c80f in cirrus_bitblt_start (s=0x5576bcb5a100) at hw/display/cirrus_vga.c:1054 #9 0x5576b9b9c898 in cirrus_write_bitblt (s=0x5576bcb5a100, reg_value=2) at hw/display/cirrus_vga.c:1075 #10 0x5576b9b9d588 in cirrus_vga_write_gr (s=0x5576bcb5a100, reg_index=49, reg_value=2) at hw/display/cirrus_vga.c:1577 #11 0x5576b9b9de03 in cirrus_mmio_blt_write (s=0x5576bcb5a100, address=64, value=2 '\002') at hw/display/cirrus_vga.c:1931 #12 0x5576b9b9e32b in cirrus_vga_mem_write (opaque=0x5576bcb5a100, addr=98368, mem_value=2, size=1) at hw/display/cirrus_vga.c:2099 #13 0x5576b99e2bc5 in memory_region_write_accessor (mr=0x5576bcb6b0a0, addr=98368, value=0x7fff47d22618, size=1, shift=0, mask=255, attrs=...) at /root/work/qemu/memory.c:450 #14 0x5576b99e2d64 in access_with_adjusted_size (addr=98368, value=0x7fff47d22618, size=1, access_size_min=1, access_size_max=1, access=0x5576b99e2b54 , mr=0x5576bcb6b0a0, attrs=...) at /root/work/qemu/memory.c:506 #15 0x5576b99e55cb in memory_region_dispatch_write (mr=0x5576bcb6b0a0, addr=98368, data=2, size=1, attrs=...) at /root/work/qemu/memory.c:1158 #16 0x5576b999eba2 in address_space_rw (as=0x5576ba2a0ec0 , addr=753728, attrs=..., buf=0x7fff47d22818 "\002", len=1, is_write=true) at /root/work/qemu/exec.c:2497 #17 0x5576b999eed9 in cpu_physical_memory_rw (addr=753728, buf=0x7fff47d22818 "\002", len=1, is_write=1) at /root/work/qemu/exec.c:2580 #18 0x5576b9a024b2 in rw_phys_req_item (addr=753728, req=0x7fff47d22810, i=0, val=0x7fff47d22818, rw=1) at /root/work/qemu/xen-hvm.c:797 #19 0x5576b9a02520 in write_phys_req_item (addr=753728, req=0x7fff47d22810, i=0, val=0x7fff47d22818) at /root/work/qemu/xen-hvm.c:808 #20 0x5576b9a0285c in cpu_ioreq_move (req=0x7fff47d22810) at /root/work/qemu/xen-hvm.c:862 #21 0x5576b9a02cec in handle_ioreq (state=0x5576bb888960, req=0x7fff47d22810) at /root/work/qemu/xen-hvm.c:944 #22 0x5576b9a02ffa in handle_buffered_iopage (state=0x5576bb888960) at /root/work/qemu/xen-hvm.c:1026 #23 0x5576b9a030d1 in cpu_handle_ioreq (opaque=0x5576bb888960) at /root/work/qemu/xen-hvm.c:1052 #24 0x5576b9d03123 in aio_dispatch (ctx=0x5576bb856470) at aio-posix.c:160 #25 0x5576b9cf3421 in aio_ctx_dispatch (source=0x5576bb856470, callback=0x0, user_data=0x0) at async.c:226 #26 0x7f8bdeb78dc7 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #27 0x5576b9d01805 in glib_pollfds_poll () at main-loop.c:211 #28 0x5576b9d018e0 in os_host_main_loop_wait (timeout=477440) at main-loop.c:256 #29 0x5576b9d0198d in main_loop_wait (nonblocking=0) at main-loop.c:504 #30 0x5576b9ade524 in main_loop () at vl.c:1890 #31 0x5576b9ae63f8 in main (argc=44, argv=0x7fff47d22df8, envp=0x7fff47d22f60) at vl.c:4644 QEMU also segfault if I connect briefly to VNC at guest boot time and disconnect before it finishes booting. You may find a report from osstest here: http://lists.xen.org/archives/html/xen-devel/2015-11/msg02688.html Thanks, -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] console: make printk() line continuation tracking per-CPU
This avoids cases where split messages (with other than the initial part not carrying a log level; single line messages only of course) issued on multiple CPUs interfere with each other, causing messages to be issued which are supposed to be suppressed due to the log level setting. E.g. CPU A CPU B XENLOG_G_DEBUG "abc" XENLOG_G_DEBUG "def\n" "xyz\n" would cause the last message to be logged despite this obviously not being intended (at default log levels). Suggested-by: Boris Ostrovsky Signed-off-by: Jan Beulich Tested-by: Boris Ostrovsky --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -620,15 +620,18 @@ static void printk_start_of_line(const c static void vprintk_common(const char *prefix, const char *fmt, va_list args) { +struct vps { +bool_t continued, do_print; +}*state; +static DEFINE_PER_CPU(struct vps, state); static char buf[1024]; -static intstart_of_line = 1, do_print; - char *p, *q; unsigned long flags; /* console_lock can be acquired recursively from __printk_ratelimit(). */ local_irq_save(flags); spin_lock_recursive(&console_lock); +state = &this_cpu(state); (void)vsnprintf(buf, sizeof(buf), fmt, args); @@ -637,30 +640,30 @@ static void vprintk_common(const char *p while ( (q = strchr(p, '\n')) != NULL ) { *q = '\0'; -if ( start_of_line ) -do_print = printk_prefix_check(p, &p); -if ( do_print ) +if ( !state->continued ) +state->do_print = printk_prefix_check(p, &p); +if ( state->do_print ) { -if ( start_of_line ) +if ( !state->continued ) printk_start_of_line(prefix); __putstr(p); __putstr("\n"); } -start_of_line = 1; +state->continued = 0; p = q + 1; } if ( *p != '\0' ) { -if ( start_of_line ) -do_print = printk_prefix_check(p, &p); -if ( do_print ) +if ( !state->continued ) +state->do_print = printk_prefix_check(p, &p); +if ( state->do_print ) { -if ( start_of_line ) +if ( !state->continued ) printk_start_of_line(prefix); __putstr(p); } -start_of_line = 0; +state->continued = 1; } spin_unlock_recursive(&console_lock); console: make printk() line continuation tracking per-CPU This avoids cases where split messages (with other than the initial part not carrying a log level; single line messages only of course) issued on multiple CPUs interfere with each other, causing messages to be issued which are supposed to be suppressed due to the log level setting. E.g. CPU A CPU B XENLOG_G_DEBUG "abc" XENLOG_G_DEBUG "def\n" "xyz\n" would cause the last message to be logged despite this obviously not being intended (at default log levels). Suggested-by: Boris Ostrovsky Signed-off-by: Jan Beulich Tested-by: Boris Ostrovsky --- a/xen/drivers/char/console.c +++ b/xen/drivers/char/console.c @@ -620,15 +620,18 @@ static void printk_start_of_line(const c static void vprintk_common(const char *prefix, const char *fmt, va_list args) { +struct vps { +bool_t continued, do_print; +}*state; +static DEFINE_PER_CPU(struct vps, state); static char buf[1024]; -static intstart_of_line = 1, do_print; - char *p, *q; unsigned long flags; /* console_lock can be acquired recursively from __printk_ratelimit(). */ local_irq_save(flags); spin_lock_recursive(&console_lock); +state = &this_cpu(state); (void)vsnprintf(buf, sizeof(buf), fmt, args); @@ -637,30 +640,30 @@ static void vprintk_common(const char *p while ( (q = strchr(p, '\n')) != NULL ) { *q = '\0'; -if ( start_of_line ) -do_print = printk_prefix_check(p, &p); -if ( do_print ) +if ( !state->continued ) +state->do_print = printk_prefix_check(p, &p); +if ( state->do_print ) { -if ( start_of_line ) +if ( !state->continued ) printk_start_of_line(prefix); __putstr(p); __putstr("\n"); } -start_of_line = 1; +state->continued = 0; p = q + 1; } if ( *p != '\0' ) { -if ( start_of_line ) -do_print = printk_prefix_check(p, &p); -if ( do_print ) +if ( !state->continued ) +state->do_print = printk_prefix_check(p, &p); +if ( state->do_print ) { -if ( start_of_line ) +if ( !state->continued ) printk_start_of_line(prefix); __putstr(p); } -start_of_line = 0; +state->
Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean
>>> On 24.11.15 at 18:22, wrote: >> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore > wrote: >>> On Nov 24, 2015, at 11:07 AM, Jan Beulich wrote: >> On 24.11.15 at 17:56, wrote: --- a/xen/Makefile +++ b/xen/Makefile @@ -88,7 +88,7 @@ _clean: delete-unfresh-files $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms > *~ core + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi $(TARGET)-syms > *~ core $(DEPS) >>> >>> Is this really a problem only in xen/ ? The referenced commit clearly >>> introduces "stray" *.d files elsewhere. Also there aren't any source >>> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. >> >> So, the files in xen/ were the dependencies files for xen.efi and >> xen-syms that were getting left behind. $(DEPS) appears to always >> have ‘.*.d’ in it, based on me putting an echo into the clean rule to >> print it out. However, looking at this, I am also seeing ‘.d’ files left >> behind in xen/common/compat that I did not notice before. > > Actually, looking closer at it, xen/common/compat does not appear to be > cleaning at all, so I think that is a separate, unrelated issue. That would be quite related, as it would be a result of the same commit. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 24 November 2015 17:24 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu > Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for > ~/control/shutdown > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() > for ~/control/shutdown"): > > [Ian Jackson:] > > > I'm not sure I follow this argument. What did you think of my idea > > > of renaming libxl__xs_mkdir to libxl__xs_mknode ? > > > > The issue, as I said, is the initial state of the node. If you use > > XS_MKDIR then it is not guaranteed to be empty. > > It is guaranteed to be empty if nothing ever wrote anything non-empty > to it. I think participants in xenstore protocols, and users of > xenstore to store things, are entitled to assume that no-one writes > nonempty values to nodes that aren't supposed to have nonempty values. > > And even if the node did somehow end up with a nonempty value, nothing > would break because no-one would read it. Maybe. Personally I would have thought a toolstack would want to put things into a known state and XS_MKDIR just doesn't do that. > > > If you use XS_WRITE then it is and I think that is the correct > > semantic here (even though we happen to get away with it at the > > moment). I'm happy with the function rename, but would you be happy > > with the change in semantic? > > XS_MKDIR creates missing parents, which XS_WRITE doesn't. > According to the documentation it does: (from xenstore.txt) READ| WRITE | Store and read the octet string at . WRITE creates any missing parent paths, with empty values. Paul > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore operation failure...
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 24 November 2015 16:49 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Ian Campbell; Wei Liu > Subject: Re: [Xen-devel] [PATCH v2 2/3] libxl: check for underlying xenstore > operation failure... > > (Added CC to Ian C and Wei.) > > Paul Durrant writes ("[Xen-devel] [PATCH v2 2/3] libxl: check for underlying > xenstore operation failure..."): > > ...in libxl__xs_writev_perms() and libxl__xs_printf() > > Thanks for looking at this. > > > > ERROR_FAIL is returned when any underlying operation fails. This is a > > semantic change in the case of a vasprintf() failure in libxl__xs_printf(), > > but appears to be better than returning a hardcoded -1. > > This is what libxl__alloc_failed is for. But, surely it would be > better to replace the call to vasprintf with one to libxl__vsprintf ? > Ah yes, that would work nicely. > > path = libxl__sprintf(gc, "%s/%s", dir, kvs[i]); > > if (path && kvs[i + 1]) { > > int length = strlen(kvs[i + 1]); > > -xs_write(ctx->xsh, t, path, kvs[i + 1], length); > > -if (perms) > > -xs_set_permissions(ctx->xsh, t, path, perms, num_perms); > > +if (!xs_write(ctx->xsh, t, path, kvs[i + 1], length)) > > +return ERROR_FAIL; > > This is a good change semantically but I'm not keen on this error > handling style. CODING_STYLE says: > > * Function calls which might fail (ie most function calls) are > handled by putting the return/status value into a variable, and > then checking it in a separate statement: > char *dompath = libxl__xs_get_dompath(gc, bl->domid); > if (!dompath) { rc = ERROR_FAIL; goto out; } > > In this case the libxenstore return value variable should be called > `r', I think. CODING_STYLE says: > > int r; /* the return value from a system call (or libxc call) */ > > > +if (perms && > > +!xs_set_permissions(ctx->xsh, t, path, perms, num_perms)) > > +return ERROR_FAIL; > > And this is worse, I'm afraid. Nested ifs are not expensive and there > is no risk of overloading the compiler. So I would like to see this: > > if (perms) { > r = xs_set ... > if (r) ... > } > > > I won't insist on you changing the error exits to use `goto out', > although I tend to think that would be better. > I'm completely happy with that style. I'll fix accordingly. Paul > > Thanks, > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown"): > [Ian Jackson:] > > I'm not sure I follow this argument. What did you think of my idea > > of renaming libxl__xs_mkdir to libxl__xs_mknode ? > > The issue, as I said, is the initial state of the node. If you use > XS_MKDIR then it is not guaranteed to be empty. It is guaranteed to be empty if nothing ever wrote anything non-empty to it. I think participants in xenstore protocols, and users of xenstore to store things, are entitled to assume that no-one writes nonempty values to nodes that aren't supposed to have nonempty values. And even if the node did somehow end up with a nonempty value, nothing would break because no-one would read it. > If you use XS_WRITE then it is and I think that is the correct > semantic here (even though we happen to get away with it at the > moment). I'm happy with the function rename, but would you be happy > with the change in semantic? XS_MKDIR creates missing parents, which XS_WRITE doesn't. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean
> On Nov 24, 2015, at 11:16 AM, Jonathan Creekmore > wrote: > >> >> On Nov 24, 2015, at 11:07 AM, Jan Beulich wrote: >> > On 24.11.15 at 17:56, wrote: >>> --- a/xen/Makefile >>> +++ b/xen/Makefile >>> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files >>> $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean >>> $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean >>> $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean >>> - rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >>> $(TARGET)-syms *~ core >>> + rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >>> $(TARGET)-syms *~ core $(DEPS) >> >> Is this really a problem only in xen/ ? The referenced commit clearly >> introduces "stray" *.d files elsewhere. Also there aren't any source >> files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. > > So, the files in xen/ were the dependencies files for xen.efi and > xen-syms that were getting left behind. $(DEPS) appears to always > have ‘.*.d’ in it, based on me putting an echo into the clean rule to > print it out. However, looking at this, I am also seeing ‘.d’ files left > behind in xen/common/compat that I did not notice before. Actually, looking closer at it, xen/common/compat does not appear to be cleaning at all, so I think that is a separate, unrelated issue. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for ~/control/shutdown
> -Original Message- > From: Ian Jackson [mailto:ian.jack...@eu.citrix.com] > Sent: 24 November 2015 16:35 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; Stefano Stabellini; Ian Campbell; Wei Liu > Subject: RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() for > ~/control/shutdown > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using libxl__xs_mkdir() > for ~/control/shutdown"): > > [Ian Jackson] > > > Paul Durrant writes ("RE: [RFC PATCH 2/6] libxl: stop using > libxl__xs_mkdir() > > > for ~/control/shutdown"): > > > > [Ian Jackson:] > > > > > Maybe it would be easier to rename libxl__xs_mkdir to > > > > > libxl__xs_mknode ? (It's probably too late to rename XS_MKDIR.) > > > > > > > > There is still the need to set the path to an empty value though, which > is > > > not implicitly done by the XS_MKDIR. > > > > > > Under what circumstances would this path not contain an empty value > > > after XS_MKDIR ? > > > > In this case I believe you are correct, but my feeling was that > > people reading the code would be lulled into a false sense of > > security that XS_MKDIR always did the right thing to initialize a > > new path. > > I'm not sure I follow this argument. What did you think of my idea > of renaming libxl__xs_mkdir to libxl__xs_mknode ? > The issue, as I said, is the initial state of the node. If you use XS_MKDIR then it is not guaranteed to be empty. If you use XS_WRITE then it is and I think that is the correct semantic here (even though we happen to get away with it at the moment). I'm happy with the function rename, but would you be happy with the change in semantic? Paul > Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors.
From: Anshul Makkar Sandybridge or earlier processors don't have huge page support for IOTLB which leads to fallback on 4k pages and causes performance issues. Shared EPT will be disabled only if the user has not provided explicit choice on the command line. Signed-off-by: Anshul Makkar --- v2: * Removed the use of extra variable to control the shared EPT and made the existent variable as tristate. * Narrowed down the check for processors to Sandybridge and older including Atom processors. docs/misc/xen-command-line.markdown | 2 +- xen/drivers/passthrough/iommu.c | 2 +- xen/drivers/passthrough/vtd/quirks.c | 14 ++ xen/include/xen/iommu.h | 2 +- 4 files changed, 17 insertions(+), 3 deletions(-) diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown index a2e427c..6b69ba2 100644 --- a/docs/misc/xen-command-line.markdown +++ b/docs/misc/xen-command-line.markdown @@ -896,7 +896,7 @@ debug hypervisor only). > `sharept` -> Default: `true` +> Default: `true` if newer than SandyBridge or `false` if Sandybridge or earlier. >> Control whether CPU and IOMMU page tables should be shared. diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index d5137733..9367987 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -51,7 +51,7 @@ bool_t __read_mostly iommu_passthrough; bool_t __read_mostly iommu_snoop = 1; bool_t __read_mostly iommu_qinval = 1; bool_t __read_mostly iommu_intremap = 1; -bool_t __read_mostly iommu_hap_pt_share = 1; +s8 __read_mostly iommu_hap_pt_share = -1; bool_t __read_mostly iommu_debug; bool_t __read_mostly amd_iommu_perdev_intremap = 1; diff --git a/xen/drivers/passthrough/vtd/quirks.c b/xen/drivers/passthrough/vtd/quirks.c index 143..7d63c8d 100644 --- a/xen/drivers/passthrough/vtd/quirks.c +++ b/xen/drivers/passthrough/vtd/quirks.c @@ -320,6 +320,20 @@ void __init platform_quirks_init(void) /* Tylersburg interrupt remap quirk */ if ( iommu_intremap ) tylersburg_intremap_quirk(); + +/* + * Disable shared EPT ("sharept") on Sandybridge and older processors + * by default. + * SandyBridge has no huge page support for IOTLB which leads to fallback + * on 4k pages and leads to performance degradation. + * + * Shared EPT ("sharept") will be disabled only if user has not + * provided explicit choice on the command line thus iommu_hap_pt_share is + * at its initialized value of -1. + */ +if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F || + boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) ) +iommu_hap_pt_share = 0; } /* diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h index 8f3a20e..d52d06f 100644 --- a/xen/include/xen/iommu.h +++ b/xen/include/xen/iommu.h @@ -31,7 +31,7 @@ extern bool_t iommu_enable, iommu_enabled; extern bool_t force_iommu, iommu_verbose; extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough; extern bool_t iommu_snoop, iommu_qinval, iommu_intremap; -extern bool_t iommu_hap_pt_share; +extern s8 iommu_hap_pt_share; extern bool_t iommu_debug; extern bool_t amd_iommu_perdev_intremap; -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 02/11] xen/arm: vgic-v3: Don't try to emulate IROUTER which doesn't exist in the spec
On Wed, 2015-11-18 at 17:27 +, Julien Grall wrote: Subject: ... which do not exist in the ... > The range of valid IROUTER are n = 32 - 1019 (see 8.9.13 in IHI 0069A) > which correspond to the offset 0x6100-0x7FD8. > > Other offset are invalid and therefore should not be emulated. "offsets" > > Also remove the now unused label read_as_zero_64 and write_ignore_64. > > Note that GICD_IROUTER is kept to accomadate the GICv3 drivers which has "accommodate" > been in part taken from Linux. > > Signed-off-by: Julien Grall Accesses to 0x6000-0x60FF are going to be noisy now, I suppose that is OK. Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean
> On Nov 24, 2015, at 11:07 AM, Jan Beulich wrote: > On 24.11.15 at 17:56, wrote: >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files >> $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean >> $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean >> $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean >> -rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >> $(TARGET)-syms *~ core >> +rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >> $(TARGET)-syms *~ core $(DEPS) > > Is this really a problem only in xen/ ? The referenced commit clearly > introduces "stray" *.d files elsewhere. Also there aren't any source > files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. So, the files in xen/ were the dependencies files for xen.efi and xen-syms that were getting left behind. $(DEPS) appears to always have ‘.*.d’ in it, based on me putting an echo into the clean rule to print it out. However, looking at this, I am also seeing ‘.d’ files left behind in xen/common/compat that I did not notice before. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 01/11] xen/arm: vgic-v2: Implement correctly ICFGR{0, 1} read-only
On Wed, 2015-11-18 at 17:27 +, Julien Grall wrote: > Each ITARGETSR register are 4-byte wide and the offset is in byte. "is 4-bytes" ... "is in bytes". > > The current implementation is computing the offset of ICFGR1 and ICFG2 > wonrgly result to emulate only the first 2 byte of the ICFGR range wrongly > read-only. The rest will be treated as read-write. > > For convenience introduce ITARGETSR1 and ITARGETSR2. > > Signed-off-by: Julien Grall > --- > > We only store the value of ICFGR registers for the guest own > purpose > today. Xen is not using it at all. So I don't think it's worth to > backport > it. > > Changes in v2: > - This patch was supposed to be in v1, but messed up the > git format-patch command > --- > xen/arch/arm/vgic-v2.c| 6 -- > xen/include/asm-arm/gic.h | 2 ++ > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c > index c94f0f3..4fb954b 100644 > --- a/xen/arch/arm/vgic-v2.c > +++ b/xen/arch/arm/vgic-v2.c > @@ -507,10 +507,12 @@ static int vgic_v2_distr_mmio_write(struct vcpu *v, > mmio_info_t *info, > > case GICD_ICFGR: /* SGIs */ > goto write_ignore_32; > -case GICD_ICFGR + 1: /* PPIs */ > + > +case GICD_ICFGR1: This should have a /* PPIs */ comment I think? I think I could add that on commit if you agree. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen: sched: fix (ACPI S3) resume with cpupools with different schedulers.
On Tue, 2015-11-24 at 15:32 +, George Dunlap wrote: > On 13/11/15 17:10, Dario Faggioli wrote: > > > > During suspend, the pCPUs are not removed from their > > pools with the standard procedure (which would involve > > schedule_cpu_switch(). During resume, they: > > 1) are assigned to the default cpupool (CPU_UP_PREPARE > > phase); > > 2) are moved to the pool they were in before suspend, > > via schedule_cpu_switch() (CPU_ONLINE phase) > > > > During resume, scheduling (even if just the idle loop) > > can happen right after the CPU_STARTING phase(before > > CPU_ONLINE), i.e., before the pCPU is put back in its > > pool. > > So why are we restoring scheduling stuff during CPU_STARTING, but > only > putting cpus back in their pools at CPU_ONLINE? > Indeed. Much worse: we open the CPU for scheduling before it's back in its pool (this is all what this bug is about!). this never made much sense to me. > At some point I think I knew the answer to this, but it's worth > revisiting it. > So, I once had a look, and tried shuffling things around, in a way in which the order made more sense to me, but it does not work 'out of the box'. The issues have, AFAICR, to do with the fact that memory allocations (for the per-pCPU scheduling data, need IRQs enabled (which means CPU_UP_PREPARE, much rather than CPU_STARTING, is what we want) on the scheduling side, and other data that need to be ready and initialized in order to setup cpupools (e.g., per_cpu(cpupool, cpu)). As said, I don't recall all the details, sorry. I recall thinking that a solution would involve putting the CPU in the pool earlier, but that in turn calls for other work (e.g., tweaking the priorities of the callbacks for avoiding races). It's on my list of things to do, but not with super high priority. Are you saying that we should drop this patch, and do the callback reordering/refactoring first? Thanks and Regards, Dario -- <> (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] build: remove .d files from xen/ on a clean
On 11/24/15 11:07 AM, Jan Beulich wrote: On 24.11.15 at 17:56, wrote: >> --- a/xen/Makefile >> +++ b/xen/Makefile >> @@ -88,7 +88,7 @@ _clean: delete-unfresh-files >> $(MAKE) -f $(BASEDIR)/Rules.mk -C xsm clean >> $(MAKE) -f $(BASEDIR)/Rules.mk -C crypto clean >> $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) clean >> -rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >> $(TARGET)-syms *~ core >> +rm -f include/asm *.o $(TARGET) $(TARGET).gz $(TARGET).efi >> $(TARGET)-syms *~ core $(DEPS) > > Is this really a problem only in xen/ ? The referenced commit clearly > introduces "stray" *.d files elsewhere. Also there aren't any source > files in xen/, so I'd expect $(DEPS) to be empty. Please clarify. > > Jan > Andrew Cooper, myself and the author see the following after running make && make clean without this patch: $ ls -la xen total 124 drwxrwxr-x 10 doug doug 4096 Nov 24 11:09 . drwxrwxr-x 12 doug doug 4096 Nov 24 10:53 .. drwxrwxr-x 4 doug doug 4096 Sep 16 10:48 arch drwxrwxr-x 10 doug doug 12288 Nov 24 11:09 common -rw-rw-r-- 1 doug doug 19116 Jul 31 09:55 COPYING drwxrwxr-x 2 doug doug 4096 Nov 24 11:09 crypto drwxrwxr-x 8 doug doug 4096 Nov 24 11:09 drivers drwxrwxr-x 13 doug doug 4096 Nov 24 11:09 include -rw-rw-r-- 1 doug doug 502 Nov 24 10:53 Kconfig -rw-rw-r-- 1 doug doug 8639 Nov 24 10:53 Makefile -rw-rw-r-- 1 doug doug 5840 Nov 24 10:55 Rules.mk drwxrwxr-x 3 doug doug 4096 Nov 24 10:53 scripts drwxrwxr-x 2 doug doug 4096 Nov 24 11:09 tools -rw-rw-r-- 1 doug doug 279 Nov 24 11:00 ..xen.efi.0r.o.d -rw-rw-r-- 1 doug doug 374 Nov 24 11:00 ..xen.efi.0s.o.d -rw-rw-r-- 1 doug doug 279 Nov 24 11:00 ..xen.efi.1r.o.d -rw-rw-r-- 1 doug doug 374 Nov 24 11:00 ..xen.efi.1s.o.d -rw-rw-r-- 1 doug doug 374 Nov 24 11:00 ..xen-syms.0.o.d -rw-rw-r-- 1 doug doug 374 Nov 24 11:00 ..xen-syms.1.o.d drwxrwxr-x 3 doug doug 4096 Nov 24 11:09 xsm -- Doug Goldstein signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Xen Security Advisory 163 - virtual PMU is unsupported
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xen Security Advisory XSA-163 virtual PMU is unsupported ISSUE DESCRIPTION = The Virtual Performance Measurement Unit feature has been documented as unsupported, so far only on Intel CPUs. Further issues have been found or are suspected which would also (or exclusively) affect AMD CPUs. We believe that the functionality is mostly intended for non-production use anyway. Therefore this functionality is hereby documented as generally unsupported security-wise. IMPACT == Use of the feature may have unknown effects, ranging from information leaks through Denial of Service to privilege escalation. VULNERABLE SYSTEMS == Only systems which enable the VPMU feature are affected. That is, only systems with a `vpmu' setting on the hypervisor command line. Xen versions from 3.3 onwards are affected. Only x86 systems are affected. ARM systems do not currently implement vPMU and are therefore currently unaffected; should this functionality be added to ARM in the future it would be covered by this exclusion. In Xen versions prior to 4.6 only HVM guests can take advantage of this unsupported functionality. In Xen versions from 4.6 onwards all guest kinds can use this unsupported functionality. MITIGATION == Not enabling vPMU support (by omitting the "vpmu" hypervisor command line option) will avoid using and exposing the unsupported functionality. RESOLUTION == Applying the attached patch documents the situation. The patch does not fix any security issues. xsa163.patch xen-unstable $ sha256sum xsa163* b9185a45a41f31e7c2f85b79a669b8b1dbf00c6b40a79b00c779b344ccab45b7 xsa163.patch $ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWVJqRAAoJEIP+FMlX6CvZba8H/23BreIs2Gxkh+9Jty8EEMdp nk3hSpEgxIb101XsbZ4JNwMO8QqBoTi1Bt0+k4bnjdRsU1G/vImacaN9LlefmLJc jn3n4Ce9ODGQvCEp1LPwWQusduFhMUIaUK6cwB2LclYxUnxCgUpLBFReOp9QIbgZ Bv+rrw9gcNb8zUKT53FZ7bOApRoU28rSFX1XE72ELPDdGbpTVXxlvQZtKsQY7N7O Se1COml0MDhufWRf3SNxO2MmqZsg43fsjvJaJgGoXE+4gslcLBMjiwgoUDX2k9CG Pi4M5uLNLxXJZkgbo1qi8ueQB9yck6tMg+o6f3wDFz28SFfu8/D2szXGOblpE5w= =2Wqz -END PGP SIGNATURE- xsa163.patch Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel