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

flight 83396 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/83396/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12

[Xen-devel] [qemu-upstream-4.6-testing test] 83369: regressions - FAIL

flight 83369 qemu-upstream-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83369/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-xsm5 xen-buildfail in 83043 REGR. vs. 82482 Tests

Re: [Xen-devel] [PATCH 8/9] x86/rtc: replace paravirt_enabled() check with subarch check

On Fri, Feb 19, 2016 at 03:48:41PM +0100, Luis R. Rodriguez wrote: > On Fri, Feb 19, 2016 at 02:22:12PM +0100, Juergen Gross wrote: > > On 19/02/16 14:08, Luis R. Rodriguez wrote: > > > The current check is a super long winded way of asking if this > > > is on lguest. The flags is used for legacy

[Xen-devel] [PATCH v4 01/11] xen: make xen loader callable multiple times

The loader for xen paravirtualized environment isn't callable multiple times as it won't free any memory in case of failure. Call grub_relocator_unload() as other modules do it before allocating a new relocator or when unloading the module. Signed-off-by: Juergen Gross --- V4:

[Xen-devel] [PATCH v4 03/11] xen: reduce number of global variables in xen loader

The loader for xen paravirtualized environment is using lots of global variables. Reduce the number by making them either local or by putting them into a single state structure. Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper ---

[Xen-devel] [PATCH v4 00/11] grub-xen: support booting huge pv-domains

The Xen hypervisor supports starting a dom0 with large memory (up to the TB range) by not including the initrd and p2m list in the initial kernel mapping. Especially the p2m list can grow larger than the available virtual space in the initial mapping. The started kernel is indicating the support

[Xen-devel] [PATCH v4 05/11] xen: synchronize xen header

Get actual version of include/xen/xen.h from the Xen repository in order to be able to use constants defined there. Signed-off-by: Juergen Gross Reviewed-by: Daniel Kiper --- include/xen/arch-x86/xen-x86_32.h | 22 +++

[Xen-devel] [PATCH v4 10/11] xen: modify page table construction

Modify the page table construction to allow multiple virtual regions to be mapped. This is done as preparation for removing the p2m list from the initial kernel mapping in order to support huge pv domains. This allows a cleaner approach for mapping the relocator page by using this capability.

[Xen-devel] [PATCH v4 09/11] xen: add capability to load initrd outside of initial mapping

Modern pvops linux kernels support an initrd not covered by the initial mapping. This capability is flagged by an elf-note. In case the elf-note is set by the kernel don't place the initrd into the initial mapping. This will allow to load larger initrds and/or support domains with larger memory,

[Xen-devel] [PATCH v4 02/11] xen: avoid memleaks on error

When loading a Xen pv-kernel avoid memory leaks in case of errors. Signed-off-by: Juergen Gross --- grub-core/loader/i386/xen.c| 2 +- grub-core/loader/i386/xen_fileXX.c | 17 +++-- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git

[Xen-devel] [PATCH v4 04/11] xen: add elfnote.h to avoid using numbers instead of constants

Various features and parameters of a pv-kernel are specified via elf notes in the kernel image. Those notes are part of the interface between the Xen hypervisor and the kernel. Instead of using num,bers in the code when interpreting the elf notes make use of the header supplied by Xen for that

[Xen-devel] [PATCH v4 11/11] xen: add capability to load p2m list outside of kernel mapping

Modern pvops linux kernels support a p2m list not covered by the kernel mapping. This capability is flagged by an elf-note specifying the virtual address the kernel is expecting the p2m list to be mapped to. In case the elf-note is set by the kernel don't place the p2m list into the kernel

[Xen-devel] [PATCH v4 06/11] xen: factor out p2m list allocation into separate function

Do the p2m list allocation of the to be loaded kernel in a separate function. This will allow doing the p2m list allocation at different times of the boot preparations depending on the features the kernel is supporting. While at this remove superfluous setting of first_p2m_pfn and nr_p2m_frames

[Xen-devel] [PATCH v4 07/11] xen: factor out allocation of special pages into separate function

Do the allocation of special pages (start info, console and xenbus ring buffers) in a separate function. This will allow to do the allocation at different times of the boot preparations depending on the features the kernel is supporting. Signed-off-by: Juergen Gross Reviewed-by:

[Xen-devel] [PATCH 3/3] x86/xsaves: ebx may return wrong value using CPUID eax=0xdh, ecx =1

Refer to SDM 13.4.3 Extended Region of an XSAVE Area. The value return by ecx[1] with cpuid function 0xdh and sub-fucntion i (i>1) indicates the alignment of the state component i when the compacted format of the extended region of an xsave area is used. So when hvm guest using CPUID

[Xen-devel] [PATCH 0/3] x86/xsaves: bugs fix

This patch fix bugs caused by previous patch: 1. xstate_comp_offset should be caculated based on xcomp_bv 2. non-lazy/lazy xsave[sc] may overwiting xsave area 3. ebx may return wrong value using CPUID eax=0xdh,ecx =1 The fist and second bugs is found by Jan. Thanks to Jan. Shuai Ruan (3):

[Xen-devel] [PATCH 1/3] x86/xsaves: caculate the xstate_comp_offsets base on xcomp_bv

Previous patch using all available features caculate xstate_comp_offsets. This is wrong.This patch fix this bug by caculating the xstate_comp_offset based on xcomp_bv of current guest. Also, the xstate_comp_offset should take alignment into consideration. Signed-off-by: Shuai Ruan

[Xen-devel] [PATCH 2/3] x86/xsaves: fix overwriting between non-lazy/lazy xsave[sc]

The offset at which components xsaved by xsave[sc] are not fixed. So when when a save with v->fpu_dirtied set is followed by one with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data written by the lazy one. When xsave[sc] is enable, vcpu_xsave_mask will return XSTATE_ALL when

[Xen-devel] [qemu-upstream-4.5-testing test] 83346: regressions - FAIL

flight 83346 qemu-upstream-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83346/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 5 xen-install fail REGR. vs. 82621

Re: [Xen-devel] [RFC v2 4/7] asm/sections: add a generic push_section_tbl()

On 02/19/16 13:06, Luis R. Rodriguez wrote: >> >> I think the \n\t is unnecessary. > > Super! I wonder if we we can just use this on s390 as well without it pooping? > I ask as this would set a precedent. > Ask Heike, but I think just ; or \n ought be be fine. I do not know of *any* case where

Re: [Xen-devel] [PATCH] MAINTAINERS: Drop myself as xen netback maintainer

From: Ian Campbell Date: Fri, 19 Feb 2016 11:44:51 + > Wei has been picking this up for quite a while now. > > Signed-off-by: Ian Campbell Applied, thanks Ian. ___ Xen-devel mailing list

[Xen-devel] [PATCH v10 03/31] tools/libxl: Add back channel to allow migration target send data back

In COLO mode, secondary needs to send the following data to primary: 1. In libxl Secondary sends the following CHECKPOINT_CONTEXT to primary: CHECKPOINT_SVM_SUSPENDED, CHECKPOINT_SVM_READY and CHECKPOINT_SVM_RESUMED 2. In libxc Secondary sends the dirty pfn list to primary But the io_fd

[Xen-devel] [PATCH v10 02/31] tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty()

Secondary vm is running in COLO mode, we need to send secondary vm's dirty page information to primary host at checkpoint, so we have to enable qemu logdirty on secondary. libxl__domain_suspend_common_switch_qemu_logdirty() is to enable qemu logdirty. But it uses libxl__domain_save_state, and

[Xen-devel] [PATCH v10 15/31] tools/libx{l, c}: add postcopy/suspend callback to restore side

Secondary(restore side) is running under COLO, we also need postcopy/suspend callbacks. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxc/include/xenguest.h | 10 ++ tools/libxl/libxl_save_msgs_gen.pl | 4

[Xen-devel] [PATCH v10 07/31] docs/libxl: Introduce CHECKPOINT_CONTEXT to support migration v2 colo streams

It is the negotiation record for COLO. Primary->Secondary: control_id 0x: Secondary VM is out of sync, start a new checkpoint Secondary->Primary: 0x0001: Secondary VM is suspended 0x0002: Secondary VM is ready 0x0003:

[Xen-devel] [PATCH v10 06/31] docs: add colo readme

add colo readme, refer to http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping Signed-off-by: Yang Hongyang Acked-by: Ian Campbell Signed-off-by: Wen Congyang --- docs/README.colo | 9 + 1 file changed, 9

[Xen-devel] [PATCH v10 11/31] tools/libxl: write checkpoint_state records into the stream

write checkpoint_state records into the stream, used by both primary and secondary to send colo context. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_internal.h | 5 tools/libxl/libxl_stream_write.c |

[Xen-devel] [PATCH v10 01/31] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state

In normal migration, the qemu state is passed to qemu as a parameter. With COLO, secondary vm is running. So we will do the following steps at every checkpoint: 1. suspend both primary vm and secondary vm 2. sync the state 3. resume both primary vm and secondary vm Primary will send qemu's state

[Xen-devel] [PATCH v10 20/31] send store gfn and console gfn to xl before resuming secondary vm

We will call libxl__xc_domain_restore_done() to rebuild secondary vm. But we need store gfn and console gfn when rebuilding secondary vm. So make restore_results a function pointer in callback struct and struct {save,restore}_callbacks, and use this callback to send store gfn and console gfn to

[Xen-devel] [PATCH v10 08/31] libxc/migration: Specification update for DIRTY_PFN_LIST records

Used by secondary to send it's dirty bitmap to primary under COLO. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- docs/specs/libxc-migration-stream.pandoc | 24 ++- tools/libxc/xc_sr_common.c | 31

[Xen-devel] [PATCH v10 19/31] libxc/restore: send dirty pfn list to primary when checkpoint under colo

Send dirty pfn list to primary when checkpoint under colo. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxc/xc_sr_common.h | 4 ++ tools/libxc/xc_sr_restore.c | 120 +++- 2

[Xen-devel] [PATCH v10 00/31] COarse-grain LOck-stepping Virtual Machines for Non-stop Service

This patchset implemented the COLO feature for Xen. For detail/install/use of COLO feature, refer to: http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping This patchset is based on: 1. http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02515.html You can get the codes from

[Xen-devel] [PATCH v10 17/31] primary vm suspend/resume/checkpoint code

We will do the following things again and again: 1. Suspend primary vm a. Suspend primary vm b. do postsuspend c. Read CHECKPOINT_SVM_SUSPENDED sent by secondary 2. Resume primary vm a. Read CHECKPOINT_SVM_READY from slave b. Do presume c. Resume primary vm d. Read

[Xen-devel] [PATCH v10 22/31] implement the cmdline for COLO

Add a new option -c to the command 'xl remus'. If you want to use COLO HA instead of Remus HA, please use -c option. Update man pages to reflect the addition of a new option to 'xl remus' command. Also add a new option -c to the internal command 'xl migrate-receive'. Signed-off-by: Wen Congyang

[Xen-devel] [PATCH v10 31/31] cmdline switches and config vars to control colo-proxy

Add cmdline switches to 'xl migrate-receive' command to specify a domain-specific hotplug script to setup COLO proxy. Add a new config var 'colo.default.agentscript' to xl.conf, that allows the user to override the default global script used to setup COLO proxy. Signed-off-by: Yang Hongyang

[Xen-devel] [PATCH v10 16/31] secondary vm suspend/resume/checkpoint code

Secondary vm is running in colo mode. So we will do the following things again and again: 1. Resume secondary vm a. Send CHECKPOINT_SVM_READY to master. b. If it is not the first resume, call libxl__checkpoint_devices_preresume(). c. If it is the first resume(resume right after live

[Xen-devel] [PATCH v10 27/31] COLO proxy: preresume, postresume and checkpoint

preresume, postresume and checkpoint Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_colo.h | 4 +++ tools/libxl/libxl_colo_proxy.c | 62 ++ 2 files changed, 66

[Xen-devel] [PATCH v10 26/31] COLO proxy: implement setup/teardown of COLO proxy module

setup/teardown of COLO proxy module. we use netlink to communicate with proxy module. About colo-proxy module: https://lkml.org/lkml/2015/6/18/32 How to use: http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping Signed-off-by: Yang Hongyang Signed-off-by: Wen

[Xen-devel] [PATCH v10 10/31] tools/libxl: add back channel support to write stream

Add back channel support to write stream. If the write stream is a back channel stream, this means the write stream is used by Secondary to send some records back. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang ---

[Xen-devel] [PATCH v10 12/31] tools/libxl: add back channel support to read stream

This is used by primay to read records sent by secondary. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_create.c | 1 + tools/libxl/libxl_internal.h| 1 + tools/libxl/libxl_stream_read.c | 27

[Xen-devel] [PATCH v10 25/31] COLO: use qemu block replication

Use qemu block replication as our block replication solution. Note that guest must be paused before starting COLO, otherwise, the disk won't be consistent between primary and secondary. Signed-off-by: Wen Congyang Signed-off-by: Yang Hongyang

[Xen-devel] [PATCH v10 28/31] COLO nic: implement COLO nic subkind

implement COLO nic subkind. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/hotplug/Linux/Makefile | 1 + tools/hotplug/Linux/colo-proxy-setup | 135 +++ tools/libxl/Makefile | 1 +

[Xen-devel] [PATCH v10 09/31] libxc/migration: export read_record for common use

read_record() could be used by primary to read dirty bitmap record sent by secondary under COLO. When used by save side, we need to pass the backchannel fd instead of ctx->fd to read_record(), so we added a fd param to it. No functional changes. Signed-off-by: Yang Hongyang

[Xen-devel] [PATCH v10 24/31] Support colo mode for qemu disk

Usage: disk = ['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...'] For QEMU block replication details: http://wiki.qemu.org/Features/BlockReplication Signed-off-by: Wen Congyang Signed-off-by: Yang Hongyang

[Xen-devel] [PATCH v10 18/31] libxc/restore: support COLO restore

call the callbacks resume/checkpoint/suspend while secondary vm status is consistent with primary. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang CC: Andrew Cooper --- tools/libxc/xc_sr_common.h | 4 +--

[Xen-devel] [PATCH v10 23/31] COLO: introduce new API to prepare/start/do/get_error/stop replication

We will use qemu block replication, and qemu provides some qmp commands to prepare replication, start replication, get replication error, and stop replication. Introduce new API to execute these qmp commands. Signed-off-by: Wen Congyang --- tools/libxl/libxl_internal.h |

[Xen-devel] [PATCH v10 13/31] tools/libxl: handle checkpoint_state records in a libxl migration v2 read stream

Read a checkpoint_state and call stream->checkpoint_callback to handle it. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_internal.h| 3 +++ tools/libxl/libxl_stream_read.c | 57

[Xen-devel] [PATCH v10 30/31] setup and control colo proxy on secondary side

setup and control colo proxy on secondary side Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_colo_restore.c | 28 +--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git

[Xen-devel] [PATCH v10 05/31] tools/libx{l, c}: add back channel to libxc

In COLO mode, both VMs are running, and are considered in sync if the visible network traffic is identical. After some time, they fall out of sync. At this point, the two VMs have definitely diverged. Lets call the primary dirty bitmap set A, while the secondary dirty bitmap set B. Sets A and

[Xen-devel] [PATCH v10 04/31] tools/libxl: Introduce new helper function dup_fd_helper()

It is pure refactoring and no functional changes. Signed-off-by: Wen Congyang --- tools/libxl/libxl_save_callout.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/tools/libxl/libxl_save_callout.c

[Xen-devel] [PATCH v10 14/31] tools/libx{l, c}: introduce wait_checkpoint callback

Under COLO, we are doing checkpoint on demand, if this callback returns 1, we will take another checkpoint. 0 indicates unexpected error. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxc/include/xenguest.h | 18

[Xen-devel] [PATCH v10 21/31] libxc/save: support COLO save

After suspend primary vm, get dirty bitmap on secondary vm, and send pages both dirty on primary/secondary to secondary. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang CC: Andrew Cooper ---

[Xen-devel] [PATCH v10 29/31] setup and control colo proxy on primary side

setup and control colo proxy on primary side Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl_colo_save.c | 124 +++--- tools/libxl/libxl_internal.h | 1 + 2 files changed,

[Xen-devel] [seabios test] 83298: tolerable FAIL - PUSHED

flight 83298 seabios real [real] http://logs.test-lab.xenproject.org/osstest/logs/83298/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 80975 Tests which did not succeed, but

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

flight 83289 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/83289/ 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. 82825 Regressions which

Re: [Xen-devel] [RFC v2 7/7] kprobes: port to linker table

>From: Luis R. Rodriguez [mailto:mcg...@kernel.org] > >kprobe makes use of two custom sections: > >type name beginend >init.data _kprobe_blacklist __start_kprobe_blacklist __stop_kprobe_blacklist >text .kprobes.text __kprobes_text_start

[Xen-devel] [PATCH v2 0/5] xen: avoid module usage in non-modular code

This series of commits is a part of a larger project to ensure people don't reference modular support functions in non-modular code. Overall there was roughly 5k lines of dead code in the kernel due to this. So far we've fixed several areas, like tty, x86, net, ... and we continue to work on

[Xen-devel] [PATCH v2 1/5] xen: audit usages of module.h ; remove unnecessary instances

Code that uses no modular facilities whatsoever should not be sourcing module.h at all, since that header drags in a bunch of other headers with it. Similarly, code that is not explicitly using modular facilities like module_init() but only is declaring module_param setup variables should be

[Xen-devel] [PATCH v2 2/5] drivers/xen: make [xen-]ballon explicitly non-modular

The Makefile / Kconfig currently controlling compilation here is: obj-y += grant-table.o features.o balloon.o manage.o preempt.o time.o [...] obj-$(CONFIG_XEN_BALLOON) += xen-balloon.o ...with: drivers/xen/Kconfig:config XEN_BALLOON drivers/xen/Kconfig:bool "Xen memory

[Xen-devel] [PATCH v2 5/5] drivers/xen: make platform-pci.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: arch/x86/xen/Kconfig:config XEN_PVHVM arch/x86/xen/Kconfig: def_bool y ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the

[Xen-devel] [PATCH v2 4/5] drivers/xen: make sys-hypervisor.c explicitly non-modular

The Kconfig currently controlling compilation of this code is: config XEN_SYS_HYPERVISOR bool "Create xen entries under /sys/hypervisor" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading

[Xen-devel] [PATCH v2 3/5] drivers/xen: make xenbus_dev_[front/back]end explicitly non-modular

The Makefile / Kconfig currently controlling compilation here is: obj-y += xenbus_dev_frontend.o [...] obj-$(CONFIG_XEN_BACKEND) += xenbus_dev_backend.o ...with: drivers/xen/Kconfig:config XEN_BACKEND drivers/xen/Kconfig:bool "Backend driver support" ...meaning that they currently are

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

flight 83269 linux-3.10 real [real] http://logs.test-lab.xenproject.org/osstest/logs/83269/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail REGR. vs. 79602

[Xen-devel] [ovmf test] 83274: regressions - FAIL

flight 83274 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/83274/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 65543

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

flight 83246 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/83246/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd 7 host-ping-check-xen fail REGR. vs. 83006 Regressions which

[Xen-devel] [xen-4.4-testing test] 83212: tolerable FAIL - PUSHED

flight 83212 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/83212/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 78789

[Xen-devel] [linux-4.1 test] 83210: regressions - FAIL

flight 83210 linux-4.1 real [real] http://logs.test-lab.xenproject.org/osstest/logs/83210/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399 build-i386-rumpuserxen