Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And

Re: [Xen-devel] [PATCH 1/2] VMX: fix VMCS race on context-switch paths

On Wed, 2017-02-15 at 08:15 -0700, Jan Beulich wrote: > > > > On 15.02.17 at 15:55, wrote: > > > > On Wed, 2017-02-15 at 06:20 -0700, Jan Beulich wrote: > > > > > > On 15.02.17 at 11:27, wrote: > > > > > > > > This is what I'm getting during

Re: [Xen-devel] Install of Xen 4.8 on Fedora 25 makes the box unbootable.. which is due to /var/run/xen being created, instead of /run/xen

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Thu, 16 Feb 2017 08:58:01 +0100 schrieb Juergen Gross : > You can't assume ./configure is running on the same system as Xen is > being built for. I think its easy to decide at build time if the target has and/or uses "/run". And

[Xen-devel] [PATCH v2] xen/arm: increase default dom0_mem to 512M

The default dom0_mem is 128M which is not sufficient to boot an Ubuntu based Dom0. Increase it to 512M. Signed-off-by: Stefano Stabellini --- Changes in v2: use MB macro --- xen/arch/arm/domain_build.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Xen-devel] Xen on ARM IRQ latency and scheduler overhead

On Thu, 16 Feb 2017, Stefano Stabellini wrote: > > > > >     AVG MIN MAX WARM MAX > > > > > > > > > > NODEBUG no WFI  1890    1800    3170    2070 > > > > > NODEBUG WFI 4850    4810    7030    4980 > > > > > NODEBUG no WFI credit2  2217    2090  

Re: [Xen-devel] [PATCH v4 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on next-20170216] [also build test ERROR on v4.10-rc8] [cannot apply to tip/x86/core kvm/linux-next tip/auto-latest v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

[Xen-devel] [PATCH V3 6/7] COLO-Proxy: Add secondary userspace colo-proxy start args

Qemu need this args to start userspace colo-proxy. Signed-off-by: Zhang Chen --- tools/libxl/libxl_dm.c | 34 ++ tools/libxl/libxl_nic.c | 27 +++ tools/libxl/libxl_types.idl | 15 ++-

[Xen-devel] [PATCH V3 2/7] COLO-Proxy: Setup userspace colo-proxy on primary side

In this patch we close kernel COLO-Proxy on primary side. Signed-off-by: Zhang Chen --- tools/libxl/libxl_colo_proxy.c | 27 +++ tools/libxl/libxl_colo_save.c | 9 +++-- 2 files changed, 34 insertions(+), 2 deletions(-) diff --git

[Xen-devel] [PATCH V3 4/7] COLO-Proxy: Setup userspace colo-proxy on secondary side

In this patch we add a function to close COLO kernel Proxy on secondary side. Signed-off-by: Zhang Chen --- tools/libxl/libxl_colo_restore.c | 8 ++-- tools/libxl/libxl_create.c | 8 ++-- tools/libxl/libxl_types.idl | 1 +

[Xen-devel] [PATCH V3 7/7] COLO-Proxy: Use socket to get checkpoint event.

We use kernel colo proxy's way to get the checkpoint event from qemu colo-compare. Qemu colo-compare need add a API to support this(I will add this in qemu). Signed-off-by: Zhang Chen --- tools/libxl/libxl_colo.h | 2 + tools/libxl/libxl_colo_proxy.c |

[Xen-devel] [PATCH V3 5/7] COLO-Proxy: Add primary userspace colo proxy start args

Qemu need this args to start userspace colo-proxy. Signed-off-by: Zhang Chen --- tools/libxl/libxl_dm.c | 98 + tools/libxl/libxl_nic.c | 78 tools/libxl/libxl_types.idl | 31

[Xen-devel] [PATCH V3 0/7] COLO-Proxy: Make Xen COLO use userspace colo-proxy

Because of some reason, We no longer support COLO kernel proxy. So we send this patch set to make Xen use userspace colo-proxy in qemu. Below is a COLO userspace proxy ascii figure: Primary qemu Secondary qemu

[Xen-devel] [PATCH V3 1/7] COLO-Proxy: Add remus command to open userspace proxy

Add remus '-p' to enable userspace colo proxy(in qemu). Signed-off-by: Zhang Chen --- docs/man/xl.pod.1.in | 5 + tools/libxl/libxl.h | 6 ++ tools/libxl/libxl_colo.h | 5 + tools/libxl/libxl_colo_save.c | 2 ++

[Xen-devel] [PATCH V3 3/7] tools/libxl: refactor do_domain_create()

We use params->colo_proxy_script to make do_domain_create() doesn't take "colo_proxy_script" anymore. Signed-off-by: Zhang Chen --- tools/libxl/libxl_create.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git

[Xen-devel] [xtf test] 105859: all pass - PUSHED

flight 105859 xtf real [real] http://logs.test-lab.xenproject.org/osstest/logs/105859/ Perfect :-) All tests in this flight passed as required version targeted for testing: xtf 2b8c78575cb534908ccc8824d76904376b9c38a5 baseline version: xtf

[Xen-devel] [xen-4.4-testing baseline-only test] 68569: regressions - FAIL

This run is configured for baseline tests only. flight 68569 xen-4.4-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68569/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pygrub 13

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

flight 105853 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/105853/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 105796 Regressions

[Xen-devel] [xen-unstable-smoke test] 105864: regressions - trouble: broken/fail/pass

flight 105864 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105864/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852

[Xen-devel] [xen-4.5-testing test] 105847: tolerable FAIL - PUSHED

flight 105847 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105847/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-armhf-armhf-xl7 host-ping-check-xen fail in 105827 pass in 105847

[Xen-devel] [linux-linus test] 105845: regressions - FAIL

flight 105845 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/105845/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254

Re: [Xen-devel] [PATCH v3] x86/shadow: Correct guest behaviour when creating PTEs above maxphysaddr

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com] > Sent: Thursday, February 16, 2017 11:46 PM > > XSA-173 (c/s 8b1764833) introduces gfn_bits, and an upper limit which might be > lower than the real maxphysaddr, to avoid overflowing the superpage shadow > backpointer. > > However, plenty

Re: [Xen-devel] [PATCH] ACPICA: ACPI 6.0: Add support for IORT table.

On Wed, 15 Feb 2017, Sameer Goel wrote: > From: Lv Zheng > > ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca > > This patch adds support for IORT (IO Remapping Table) in iasl. > > Note that some field names are modified to shrink their length or the > decompiled IORT

Re: [Xen-devel] [PATCH v4 2/2] arm: proper ordering for correct execution of gic_update_one_lr and vgic_store_itargetsr

On Thu, 16 Feb 2017, Julien Grall wrote: > Hi Stefano, > > On 11/02/17 02:05, Stefano Stabellini wrote: > > Concurrent execution of gic_update_one_lr and vgic_store_itargetsr can > > result in the wrong pcpu being set as irq target, see > > http://marc.info/?l=xen-devel=148218667104072. > > > >

[Xen-devel] [PATCH v4 3/4] x86: Make the GDT remapping read-only on 64-bit

This patch makes the GDT remapped pages read-only to prevent corruption. This change is done only on 64-bit. The native_load_tr_desc function was adapted to correctly handle a read-only GDT. The LTR instruction always writes to the GDT TSS entry. This generates a page fault if the GDT is

Re: [Xen-devel] [PATCH v4 1/4] x86/mm: Adapt MODULES_END based on Fixmap section size

Hi Thomas, [auto build test ERROR on next-20170216] [also build test ERROR on v4.10-rc8] [cannot apply to tip/x86/core kvm/linux-next tip/auto-latest v4.9-rc8 v4.9-rc7 v4.9-rc6] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [Xen-devel] [PATCH v4 2/2] arm: proper ordering for correct execution of gic_update_one_lr and vgic_store_itargetsr

On 16/02/2017 22:10, Stefano Stabellini wrote: On Thu, 16 Feb 2017, Julien Grall wrote: Hi Stefano, On 11/02/17 02:05, Stefano Stabellini wrote: Concurrent execution of gic_update_one_lr and vgic_store_itargetsr can result in the wrong pcpu being set as irq target, see

[Xen-devel] [xen-unstable-smoke test] 105862: regressions - trouble: broken/fail/pass

flight 105862 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105862/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

On Thu, Feb 16, 2017 at 02:29:45AM -0700, Jan Beulich wrote: > >>> On 15.02.17 at 22:53, wrote: > > On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote: > >> >>> On 14.02.17 at 19:38, wrote: > >> > --- a/xen/arch/x86/boot/head.S > >> >

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

This run is configured for baseline tests only. flight 68568 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68568/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf fd12acdeff7a04ad34ccb95103eb6204b8901749 baseline

Re: [Xen-devel] (resend) qemu crashes during VCPU hotplug

On 02/16/2017 04:19 PM, Stefano Stabellini wrote: On Thu, 16 Feb 2017, Boris Ostrovsky wrote: On 02/15/2017 11:20 PM, Boris Ostrovsky wrote: (Now with correct address for Stefano) Upstream qemu appears to be crashing during VCPU hotplug. I think this is something relatively new since I have

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

Le 16/02/2017 à 14:36, Konrad Rzeszutek Wilk a écrit : Is it time now to officially remove Dom0 support? So we do have an prototype implementation of netback but it is waiting for review of xen-devel to the spec. And I believe the implementation does utilize some of the dom0 parts of code in

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

On Thu, Feb 16, 2017 at 03:56:21PM -0600, Doug Goldstein wrote: > On 2/16/17 3:49 PM, Daniel Kiper wrote: > > On Thu, Feb 16, 2017 at 02:29:45AM -0700, Jan Beulich wrote: > > On 15.02.17 at 22:53, wrote: > >>> On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich

Re: [Xen-devel] (resend) qemu crashes during VCPU hotplug

On Thu, 16 Feb 2017, Boris Ostrovsky wrote: > On 02/16/2017 04:19 PM, Stefano Stabellini wrote: > > On Thu, 16 Feb 2017, Boris Ostrovsky wrote: > > > On 02/15/2017 11:20 PM, Boris Ostrovsky wrote: > > > > (Now with correct address for Stefano) > > > > > > > > Upstream qemu appears to be crashing

Re: [Xen-devel] [PATCH v4 2/2] arm: proper ordering for correct execution of gic_update_one_lr and vgic_store_itargetsr

On Thu, 16 Feb 2017, Julien Grall wrote: > On 16/02/2017 22:10, Stefano Stabellini wrote: > > On Thu, 16 Feb 2017, Julien Grall wrote: > > > Hi Stefano, > > > > > > On 11/02/17 02:05, Stefano Stabellini wrote: > > > > Concurrent execution of gic_update_one_lr and vgic_store_itargetsr can > > > >

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

flight 105854 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/105854/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf b173ad78519b2ade309019614b52e1453727e20d baseline version: ovmf

Re: [Xen-devel] [PATCH v15 05/10] x86: add multiboot2 protocol support for EFI platforms

On 2/16/17 3:49 PM, Daniel Kiper wrote: > On Thu, Feb 16, 2017 at 02:29:45AM -0700, Jan Beulich wrote: > On 15.02.17 at 22:53, wrote: >>> On Wed, Feb 15, 2017 at 03:22:02AM -0700, Jan Beulich wrote: >>> On 14.02.17 at 19:38, wrote: >

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 5:32 PM > > >>> On 15.02.17 at 20:30, wrote: > > On Wed, Feb 15, 2017 at 3:03 AM, Jan Beulich wrote: > > On 15.02.17 at 00:21, wrote:

Re: [Xen-devel] [PATCH v2 2/2] x86: package up context switch hook pointers

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 7:16 PM > > They're all solely dependent on guest type, so we don't need to repeat > all the same three pointers in every vCPU control structure. Instead use > static const structures, and store pointers to them in

[Xen-devel] [PATCH 04/19] xen/mce: remove unused x86_mcinfo_add()

Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mce.c | 16

[Xen-devel] [PATCH 05/19] x86/mce: merge loops to get Intel extended MC MSR

The second loop that gets MSR_IA32_MCG_R8 to MSR_IA32_MCG_R15 was surrounded by '#ifdef __X86_64__ ... #endif' and had to be seperated from the first loop that gets MSR_IA32_MCG_EAX to MSR_IA32_MCG_MISC. Because Xen had dropped support for 32-bit x86 host, these two loops can be merged now.

[Xen-devel] [PATCH 18/19] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mce.c | 16

[Xen-devel] [PATCH 01/19] x86/mce: fix indentation style in xen-mca.h and mce.h

Replace tab indentation by whitespace. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper ---

[Xen-devel] [PATCH 11/19] tools/xen-mceinj: fix the type of cpu number

Use uint32_t rather than int to align to the type of xen_mc_physcpuinfo.ncpus. Signed-off-by: Haozhong Zhang --- Cc: Ian Jackson Cc: Wei Liu --- tools/tests/mce-test/tools/xen-mceinj.c | 13 - 1 file

[Xen-devel] [PATCH 17/19] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

If LMCE is supported by host and "lmce = 1" is present in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP. By default, LMCE is not exposed to guest so as to keep the backwards migration compatibility. Signed-off-by: Haozhong Zhang --- Cc: Ian

[Xen-devel] [PATCH 09/19] x86/vmce: fill MSR_IA32_MCG_STATUS on all vcpus in broadcast case

The current implementation only fills MC MSRs on vcpu0 and leaves MC MSRs on other vcpus empty in the broadcast case. When guest reads 0 from MSR_IA32_MCG_STATUS on vcpuN (N > 0), it may think it's not possible to recover the execution on that vcpu and then get panic, although MSR_IA32_MCG_STATUS

[Xen-devel] [PATCH 00/19] MCE code cleanup and add LMCE support

This patch series adds LMCE support to Xen, although more than half patches are for code cleanup and bug fix. LMCE -- Intel Local MCE (LMCE) is a feature on Intel Skylake Server CPU that can deliver MCE to a single processor thread instead of

[Xen-devel] [PATCH 19/19] tools/xen-mceinj: support injecting LMCE

If option '-l' or '--lmce' is specified and the host supports LMCE, xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c' is not present). Signed-off-by: Haozhong Zhang --- Cc: Ian Jackson Cc: Wei Liu ---

[Xen-devel] [PATCH 10/19] x86/mce: always write 0 to MSR_IA32_MCG_STATUS on Intel CPU

An attemp to write to MSR_IA32_MCG_STATUS with any value other than 0 would result in #GP on Intel CPU. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew

[Xen-devel] [PATCH 08/19] x86/mce: set mcinfo_comm.type and .size in x86_mcinfo_reserve()

All existing calls to x86_mcinfo_reserve() are followed by statements that set the size and the type of the reserved space, so move them into x86_mcinfo_reserve() to simplify the code. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu

[Xen-devel] [PATCH 06/19] x86/mce: merge intel_default_mce_dhandler/uhandler()

Implementations of these two functions are effectively the same, so unify them by a common intel_default_mce_handler(). Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich

[Xen-devel] [PATCH 13/19] x86/mce_intel: detect and enable LMCE on Intel host

Enable LMCE if it's supported by the host CPU. If Xen boot parameter "mce_fb = 1" is present, LMCE will be disabled forcibly. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich

[Xen-devel] [PATCH 12/19] x86/mce: handle LMCE locally

LMCE is sent to only one CPU thread, so MCE handler, barriers and softirq handler should go without waiting for other CPUs, when handling LMCE. Note LMCE is still broadcast to all vcpus as regular MCE on Intel CPU right now. Signed-off-by: Haozhong Zhang --- Cc:

[Xen-devel] [PATCH 03/19] x86/mce: remove unnecessary braces around intel_get_extended_msrs()

Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/mce.c | 7 ++- 1 file changed, 2

[Xen-devel] [PATCH 02/19] x86/mce: remove declarations of non-existing functions in mce.h

Remove declarations of functions intel_mcheck_timer() mce_intel_feature_init() mce_cap_init() x86_mcinfo_getptr() whose definitions had been removed long time ago. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong

[Xen-devel] [PATCH 14/19] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those bits are set before SW can enable LMCE. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong

[Xen-devel] [PATCH 15/19] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest to read/write MSR_IA32_MCG_EXT_CTL. Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc:

[Xen-devel] [PATCH 07/19] x86/vmce: include domain/vcpu id in debug messages

Signed-off-by: Haozhong Zhang --- Cc: Christoph Egger Cc: Liu Jinsong Cc: Jan Beulich Cc: Andrew Cooper --- xen/arch/x86/cpu/mcheck/vmce.c | 35

Re: [Xen-devel] qemu-upstream triggering OOM killer

>>> On 16.02.17 at 19:38, wrote: > On Thu, 16 Feb 2017, Jan Beulich wrote: >> >>> On 16.02.17 at 16:23, wrote: >> On 14.02.17 at 15:56, wrote: >> >> On Fri, Feb 10, 2017 at 02:54:23AM -0700, Jan Beulich wrote: >> >>> Not

[Xen-devel] [PATCH 2/2] x86/xen: use capabilities instead of fake cpuid values

When running as pv domain xen_cpuid() is being used instead of native_cpuid(). In xen_cpuid() the aperf/mperf feature is indicated as not being present by special casing the related cpuid leaf. Instead of delivering fake cpuid values clear the cpu capability bit for aperf/mperf instead.

[Xen-devel] [PATCH 1/2] x86/xen: don't indicate DCA support in pv domains

Xen doesn't support DCA (direct cache access) for pv domains. Clear the corresponding capability indicator. Signed-off-by: Juergen Gross --- arch/x86/xen/enlighten.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, February 16, 2017 8:36 PM > > >>> On 16.02.17 at 13:27, wrote: > > On 16/02/17 11:15, Jan Beulich wrote: > >> When __context_switch() is being bypassed during original context > >> switch handling, the

[Xen-devel] [xen-unstable-smoke test] 105866: regressions - trouble: broken/fail/pass

flight 105866 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/105866/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 14 guest-saverestorefail REGR. vs. 105852

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

flight 105855 xen-4.7-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105855/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-rtds 9 debian-install fail REGR. vs. 105661

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

flight 105861 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/105861/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 105840 Regressions which

[Xen-devel] [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

To enable eventual removal of pr_warning This makes pr_warn use consistent for arch/x86 Prior to this patch, there were 46 uses of pr_warning and 122 uses of pr_warn in arch/x86 Miscellanea: o Coalesce a few formats and realign arguments o Convert a couple of multiple line printks to single

[Xen-devel] [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn

There are ~4300 uses of pr_warn and ~250 uses of the older pr_warning in the kernel source tree. Make the use of pr_warn consistent across all kernel files. This excludes all files in tools/ as there is a separate define pr_warning for that directory tree and pr_warn is not used in tools/. Done

[Xen-devel] [PATCH 0/2] x86/xen: cpuid() cleanup

Reduce special casing of xen_cpuid() and disable DCA feature for pv domains as it isn't supported under Xen. Juergen Gross (2): x86/xen: don't indicate DCA support in pv domains x86/xen: use capabilities instead of fake cpuid values arch/x86/xen/enlighten.c | 14 ++ 1 file

Re: [Xen-devel] Unshared IOMMU issues

>>> On 16.02.17 at 19:09, wrote: > On 16/02/17 16:34, Jan Beulich wrote: > On 16.02.17 at 17:11, wrote: >>> On 16/02/17 15:52, Jan Beulich wrote: >>> On 16.02.17 at 16:02, wrote: > On Thu, Feb 16, 2017 at 11:36 AM, Jan

[Xen-devel] JSON format of >xl list< does not provide state information

Hello Folks, Sorry, forgot to mention the version: > # xl info > [...] > release: 4.9.3-200.186.fc25.x86_64 plain "xl list" produces: > # xl list > NameID Mem VCPUsStateTime(s) > Domain-0 0

[Xen-devel] JSON format of >xl list< does not provide state information

Hello Folks, plain "xl list" produces: > # xl list > NameID Mem VCPUsStateTime(s) > Domain-0 0 2048 1 r- > 108.2 and "xl list -l" produces: > # xl list -l > [ > { > "domid": 0, >

Re: [Xen-devel] Unable to boot Xen 4.8 with iommu=0

> From: Tian, Kevin > Sent: Friday, February 17, 2017 11:35 AM > > >> > > >> Or wait - do you have the same issue if you use > > >> "iommu=no,no-intremap"? In which case the problem would be > > >> that "iommu=no" should clear more than just "iommu_enable", or > > >> code checking iommu_intremap

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 12:46 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew > Cooper ; George Dunlap >

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Dear Paul, > Many moons ago there were patches to use rbtree for rangesets. Perhaps it > would be worth reviving that idea? rbtree is a thing I think of now for our needs. Even more, currently I think of refactoring ARM mmio ranges managing to use rbtree one day. Currently there is a static

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Dear Jan, > If this is meant to be per-domain management - how many such > ranges do you expect to be necessary for any one domain? We've > had attempts before to (ab)use rangesets for such a purpose. It is meant to be the per-domain management. To handle per-domain vcoproc register access

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 13:24 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew > Cooper ; George Dunlap >

Re: [Xen-devel] [PATCH] [RFC] x86/kconfig: Introduce CONFIG_PV and CONFIG_HVM

>>> On 15.02.17 at 20:41, wrote: > Making PV and HVM guests individually compilable is useful as a reduction in > hypervisor size, and as an aid to enforcing clean API boundaries. > > Introduce CONFIG_PV and CONFIG_HVM, although there is a lot of work to do > until

Re: [Xen-devel] [PATCH 3/3] xen/include: Include xen/kconfig.h automatically

>>> On 16.02.17 at 12:59, wrote: > On 16/02/17 11:10, Jan Beulich wrote: > On 16.02.17 at 12:01, wrote: >>> On 16/02/17 10:48, Jan Beulich wrote: >>> On 16.02.17 at 11:40, wrote: > On 16/02/17 10:27,

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Dear Paul, > The cleanup seems a good thing to do to me. So I would collect comments, rebase it to latest master and push the second version without RFC. > Any particular reason this series is RFC? The reason to make this series was an intention to use rangesets to manage mmio ranges in our

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

>>> On 16.02.17 at 13:45, wrote: > Dear Paul, > >> The cleanup seems a good thing to do to me. > > So I would collect comments, rebase it to latest master and push the > second version without RFC. > >> Any particular reason this series is RFC? > > The reason to make

Re: [Xen-devel] [PATCH v2] libxl: correct xenstore entry for empty cdrom

On Wed, Feb 15, 2017 at 12:11:12PM +0100, Juergen Gross wrote: > Specifying an empty cdrom device will result in a Xenstore entry > > params = aio:(null) > > as the physical device path isn't existing. This lets a domain booted > via OVMF hang as OVMF is checking for "aio:" only in order to

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

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

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

flight 105831 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105831/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 105685

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Dear Jan, I'm really sorry, but I did not get your point here: > This concern makes me assume there might be quite many of them, > which then makes this a no-go for unprivileged domains. Could you please provide wider explanation. Sincerely, Andrii Anisov.

Re: [Xen-devel] [PATCH 1/1] xen/arm: Add pl011 uart support in Xen for guest domains

Hi, On 15/02/17 15:38, Konrad Rzeszutek Wilk wrote: On Wed, Feb 15, 2017 at 12:53:34PM +0530, Bhupinder Thakur wrote: Hi Konrad, Thanks for the feedback. On 7 February 2017 at 00:05, Konrad Rzeszutek Wilk wrote: On Mon, Feb 06, 2017 at 11:39:08PM +0530, Bhupinder

Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure

On 16/02/17 15:12, Andrew Cooper wrote: > On 16/02/17 13:52, Boris Ostrovsky wrote: >> >> >> On 02/16/2017 02:47 AM, Juergen Gross wrote: >>> There have been reports that Fedora 25 uses /run instead of /var/run. >>> >>> Add a --with-rundir option ito configure to be able to specify that >>>

Re: [Xen-devel] [RFC 1/6] rangeset_new() refactoring

>> +if ( d != NULL ) > > Shouldn't d == NULL be a hard error now, in which you could pass d->rangesets > directly into rangeset_new() (under lock). It definitely should. Because this is a domain specific code. Sincerely, Andrii Anisov. ___

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

On Thu, Feb 16, 2017 at 12:06:18PM +0100, Thomas Monjalon wrote: > 2016-11-11 04:49, Tan, Jianfeng: > > Hi Thomas and Konrad, > > > > On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote: > > > On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon wrote: > > >> 2016-11-07 07:38, Jianfeng Tan: > > >>> As

Re: [Xen-devel] [dpdk-dev] [PATCH] maintainers: claim responsability for xen

Le 16/02/2017 à 12:06, Thomas Monjalon a écrit : The request (6 month ago) was to give more time for feedbacks: http://dpdk.org/ml/archives/dev/2016-July/044847.html Is it time now to officially remove Dom0 support? yes ___ Xen-devel mailing

Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure

On 02/16/2017 02:47 AM, Juergen Gross wrote: There have been reports that Fedora 25 uses /run instead of /var/run. Add a --with-rundir option ito configure to be able to specify that directory. Default is still /var/run. As discussed on the other thread, why not make default be the location

Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure

On 16/02/17 13:52, Boris Ostrovsky wrote: > > > On 02/16/2017 02:47 AM, Juergen Gross wrote: >> There have been reports that Fedora 25 uses /run instead of /var/run. >> >> Add a --with-rundir option ito configure to be able to specify that >> directory. Default is still /var/run. > > As discussed

Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

> -Original Message- > From: Andrii Anisov [mailto:andrii.ani...@gmail.com] > Sent: 16 February 2017 14:26 > To: Paul Durrant > Cc: xen-de...@lists.xenproject.org; andrii_ani...@epam.com; Andrew > Cooper ; George Dunlap >

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

> The relevant patch is: > > https://lists.xenproject.org/archives/html/xen-devel/2015-12/msg01619.html Thank you for the link. I would try to realize why it is left unmerged. Sincerely, Andrii Anisov. 2017-02-16 16:02 GMT+02:00 Paul Durrant : >> -Original

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

>>> On 16.02.17 at 14:42, wrote: > I'm really sorry, but I did not get your point here: > >> This concern makes me assume there might be quite many of them, >> which then makes this a no-go for unprivileged domains. > > Could you please provide wider explanation. Well,

Re: [Xen-devel] [PATCH v2 2/2] x86: package up context switch hook pointers

On 16/02/17 11:16, Jan Beulich wrote: > They're all solely dependent on guest type, so we don't need to repeat > all the same three pointers in every vCPU control structure. Instead use > static const structures, and store pointers to them in the domain > control structure. > > Since touching it

Re: [Xen-devel] [PATCH] x86/VMX: sanitize VM86 TSS handling

>>> On 16.02.17 at 12:14, wrote: On 15.02.17 at 12:21, wrote: >> At 01:18 -0700 on 15 Feb (1487121525), Jan Beulich wrote: >>> >>> On 14.02.17 at 18:33, wrote: >>> >> TBD: Do we really want to re-init the TSS every time we are about to >>> >>

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

flight 105827 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/105827/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 104590 Tests

Re: [Xen-devel] [PATCH v2 1/2] VMX: fix VMCS race on context-switch paths

>>> On 16.02.17 at 13:27, wrote: > On 16/02/17 11:15, Jan Beulich wrote: >> When __context_switch() is being bypassed during original context >> switch handling, the vCPU "owning" the VMCS partially loses control of >> it: It will appear non-running to remote CPUs, and

Re: [Xen-devel] [RFC 0/6] Rangeset generalisation

Paul, > Many moons ago there were patches to use rbtree for rangesets. Perhaps it > would be worth reviving that idea? Do you have a link to look at those patches? Sincerely, Andrii Anisov. ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH] build: add --with-rundir option to configure

On 16/02/17 14:52, Boris Ostrovsky wrote: > > > On 02/16/2017 02:47 AM, Juergen Gross wrote: >> There have been reports that Fedora 25 uses /run instead of /var/run. >> >> Add a --with-rundir option ito configure to be able to specify that >> directory. Default is still /var/run. > > As

Re: [Xen-devel] [RFC 2/6] rangeset_destroy() refactoring

Dear Paul, >> It is still left a rangesets list functionality: rangeset_destroy() >> will remove itself from a list. If a spinlock is provided it will be >> held for list deletion operation. This would be reconsidered further. >> > > Maybe use the same scheme in patch #1 then and pass the lock,

  1   2   3   >