Re: [Qemu-devel] [PATCHv7 4/9] slirp: Factorizing tcpiphdr structure with an union

On 22.02.2016 02:48, Samuel Thibault wrote: > Hello, > > Thomas Huth, on Fri 19 Feb 2016 14:44:59 +0100, wrote: >>> + m->m_data -= sizeof(struct tcpiphdr) - (sizeof(struct ip) >>> ++ sizeof(struct tcphdr)); >>> + m->m_len += sizeof(struct tcpiphdr) -

Re: [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device

On Mon, Feb 22, 2016 at 07:44:40AM +0100, Andreas Färber wrote: > Am 22.02.2016 um 06:01 schrieb Bharata B Rao: > > sPAPR CPU core device is a container of CPU thread devices. CPU hotplug is > > performed in the granularity of CPU core device by setting the "realized" > > property of this device

Re: [Qemu-devel] [V6 0/4] AMD IOMMU

On 2016-02-22 06:57, David Kiarie wrote: > On Sun, Feb 21, 2016 at 11:20 PM, Jan Kiszka wrote: >> On 2016-02-21 19:10, David Kiarie wrote: >>> Hello there, >>> >>> Repost, AMD IOMMU patches version 6. >>> >>> Changes since version 5 >>> -Fixed macro formating issues >>>

[Qemu-devel] Memory mapping on MIPS

I have some issues when accessing guest Linux kernel memory above 0xC000 by means of cpu_memory_rw_debug (x86_64 host, MIPS guest), and I'm trying to debug it. Here is an excerpt from r4k_map_address(), related to addresses >= 0x8000. Actually, it maps 0x8010 and 0xA010 to the

Re: [Qemu-devel] [PATCH v5 0/2] add avx2 instruction optimization

> Not sure; I could take it from the migration tree if no one objects. > > Amit Thanks, Amit. If rework is needed, just let me know. Liang

Re: [Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device

Am 22.02.2016 um 06:01 schrieb Bharata B Rao: > sPAPR CPU core device is a container of CPU thread devices. CPU hotplug is > performed in the granularity of CPU core device by setting the "realized" > property of this device to "true". When hotplugged, CPU core creates CPU > thread devices. > >

Re: [Qemu-devel] [RFC PATCH v2 08/10] net/colo-proxy: Handle packet and connection

On 02/20/2016 04:04 AM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: From: zhangchen In here we will handle ip packet and connection Signed-off-by: zhangchen Signed-off-by: zhanghailiang

Re: [Qemu-devel] [PATCH v5 0/2] add avx2 instruction optimization

On (Mon) 22 Feb 2016 [06:23:54], Li, Liang Z wrote: > > On 27/01/2016 08:33, Liang Li wrote: > > > buffer_find_nonzero_offset() is a hot function during live migration. > > > Now it use SSE2 instructions for optimization. For platform supports > > > AVX2 instructions, use the AVX2 instructions for

Re: [Qemu-devel] [PATCH qemu] memory: Fix IOMMU replay base address

On Mon, Feb 22, 2016 at 05:09:39PM +1100, Alexey Kardashevskiy wrote: > Since a788f227 "memory: Allow replay of IOMMU mapping notifications" > when new VFIO listener is added, all existing IOMMU mappings are replayed. > However there is a problem that the base address of an IOMMU memory region >

Re: [Qemu-devel] [PATCH v5 0/2] add avx2 instruction optimization

> On 27/01/2016 08:33, Liang Li wrote: > > buffer_find_nonzero_offset() is a hot function during live migration. > > Now it use SSE2 instructions for optimization. For platform supports > > AVX2 instructions, use the AVX2 instructions for optimization can help > > to improve the performance of

[Qemu-devel] [PATCH qemu] memory: Fix IOMMU replay base address

Since a788f227 "memory: Allow replay of IOMMU mapping notifications" when new VFIO listener is added, all existing IOMMU mappings are replayed. However there is a problem that the base address of an IOMMU memory region (IOMMU MR) is ignored which is not a problem for the existing user (which is

Re: [Qemu-devel] [V6 0/4] AMD IOMMU

On Sun, Feb 21, 2016 at 11:20 PM, Jan Kiszka wrote: > On 2016-02-21 19:10, David Kiarie wrote: >> Hello there, >> >> Repost, AMD IOMMU patches version 6. >> >> Changes since version 5 >> -Fixed macro formating issues >> -changed occurences of IO MMU to IOMMU for consistency

Re: [Qemu-devel] [RFC PATCH v2 06/10] net/colo-proxy: add socket used by forward func

On 02/20/2016 04:01 AM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: From: zhangchen Colo need to forward packets we start socket server in secondary and primary connect to secondary in startup the packet recv by primary

Re: [Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug

On Mon, Feb 22, 2016 at 10:31:17AM +0530, Bharata B Rao wrote: > Hi, > > This is an attempt to implement David Gibson's RFC that was posted at > https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg0.html > I am not sure if I have followed all the aspects of the RFC fully, but we > can make

[Qemu-devel] [RFC PATCH v0 3/8] cpu: CPU package abstract device

A minimal abstract device that target machines can create sub-types of to define their own cpu-package devices. Provides a realize routine that walks the child objects and realizes them iteratively. Hence cpu-package interface expects the target implementations to have a hierarchical setup for

[Qemu-devel] [RFC PATCH v0 8/8] hmp: Implement 'info cpu-slots'

Signed-off-by: Bharata B Rao --- hmp-commands-info.hx | 14 ++ hmp.c| 50 ++ hmp.h| 1 + 3 files changed, 65 insertions(+) diff --git a/hmp-commands-info.hx

[Qemu-devel] [RFC PATCH v0 7/8] qmp: Implement query cpu-packages

Signed-off-by: Bharata B Rao --- hw/cpu/package.c| 19 + hw/ppc/spapr.c | 79 + include/hw/boards.h | 1 + qapi-schema.json| 48 4 files changed, 147

[Qemu-devel] [RFC PATCH v0 4/8] spapr: Introduce CPU core device

sPAPR CPU core device is a container of CPU thread devices. CPU hotplug is performed in the granularity of CPU core device by setting the "realized" property of this device to "true". When hotplugged, CPU core creates CPU thread devices. TODO: Right now allows for only homogeneous configurations

[Qemu-devel] [RFC PATCH v0 6/8] spapr: CPU hotplug support

Set up device tree entries for the hotplugged CPU core and use the exising EPOW event infrastructure to send CPU hotplug notification to the guest. Signed-off-by: Bharata B Rao --- hw/ppc/spapr.c | 136 -

[Qemu-devel] [RFC PATCH v0 5/8] spapr: Convert boot CPUs into CPU core device initialization

Initialize boot CPUs specified with -smp option as CPU core devices. Create as many CPU package devices as necessary to fit in max_cpus and populate (i,e., realize) only as many as required. Signed-off-by: Bharata B Rao --- hw/ppc/spapr.c | 31

[Qemu-devel] [RFC PATCH v0 0/8] cpu-package hotplug

Hi, This is an attempt to implement David Gibson's RFC that was posted at https://lists.gnu.org/archive/html/qemu-ppc/2016-02/msg0.html I am not sure if I have followed all the aspects of the RFC fully, but we can make changes going forward. An example cpu-package implementation is done for

[Qemu-devel] [RFC PATCH v0 1/8] cpu: Store CPU typename in MachineState

Storing CPU typename in MachineState lets us to create CPU threads for all architectures in uniform manner from arch-neutral code. TODO: Touching only sPAPR target for now Signed-off-by: Bharata B Rao --- hw/ppc/spapr.c | 2 ++ include/hw/boards.h | 1 + 2

[Qemu-devel] [RFC PATCH v0 2/8] cpu: Don't realize CPU from cpu_generic_init()

Don't do CPU realization from cpu_generic_init(). With this cpu_generic_init() will be used to just create CPU threads and they should be realized separately from realizefn call. Convert the existing callers to do explicit realization. Signed-off-by: Bharata B Rao

Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus

On Fri, Feb 19, 2016 at 04:49:11PM +0100, Igor Mammedov wrote: > On Fri, 19 Feb 2016 15:38:48 +1100 > David Gibson wrote: > > CCing thread a couple of libvirt guys. > > > On Thu, Feb 18, 2016 at 11:37:39AM +0100, Igor Mammedov wrote: > > > On Thu, 18 Feb 2016

Re: [Qemu-devel] [RFC] QMP: add query-hotpluggable-cpus

On Fri, Feb 19, 2016 at 10:51:11AM +0100, Markus Armbruster wrote: > David Gibson writes: > > > On Thu, Feb 18, 2016 at 11:37:39AM +0100, Igor Mammedov wrote: > >> On Thu, 18 Feb 2016 14:39:52 +1100 > >> David Gibson wrote: > >> > >> >

Re: [Qemu-devel] [PATCH] migration: reorder code to make it symmetric

On (Thu) 04 Feb 2016 [22:50:30], Wei Yang wrote: > In qemu_savevm_state_complete_precopy(), it iterates on each device to add > a json object and transfer related status to destination, while the order > of the last two steps could be refined. > > Current order: > > json_start_object() >

[Qemu-devel] [Bug 1548166] [NEW] QEMU crash after send data from Host through serial port

Public bug reported: Hi All I have two computer, one is Win7 32 another is Win7 64, Both computer meet this issue. My QEMU version is qemu-w32-setup-20160215 I want used EDK2 OVMF with Intel UDK Debugger tools to do source level debug I had install com0com Virtual Com Port, and set COM3

[Qemu-devel] [Bug 1423124] Re: QEMU crash after sending data on host serial port

** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1423124 Title: QEMU crash after sending data on host serial port Status in QEMU: Fix

Re: [Qemu-devel] [PATCH 1/3] exec: store RAMBlock pointer into memory region

Hi Fam, > From: Fam Zheng [mailto:f...@redhat.com] > Sent: Monday, February 22, 2016 10:46 AM > > On Sat, 02/20 10:35, Gonglei wrote: > > Each RAM memory region has a unique corresponding RAMBlock. > > In the current realization, the memory region only stored > > the ram_addr which means the

[Qemu-devel] [PATCH v4 1/9] hw/timer: QOM'ify etraxfs_timer

assign etraxfs_timer_init to etraxfs_timer_info.instance_init and drop the SysBusDeviceClass::init Reviewed-by: Edgar E. Iglesias Signed-off-by: xiaoqiang zhao --- hw/timer/etraxfs_timer.c | 14 +++--- 1 file changed, 7 insertions(+), 7

[Qemu-devel] [PATCH v4 8/9] hw/timer: QOM'ify slavio_timer

rename slavio_timer_init1 to slavio_timer_init and assign it to slavio_timer_info.instance_init, then we drop the SysBusDeviceClass::init Signed-off-by: xiaoqiang zhao --- hw/timer/slavio_timer.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git

[Qemu-devel] [PATCH v4 4/9] hw/timer: QOM'ify m48txx_sysbus (pass 1)

* split the old SysBus init function into an instance_init and a Device realize function * use DeviceClass::realize instead of SysBusDeviceClass::init Signed-off-by: xiaoqiang zhao --- hw/timer/m48t59.c | 35 ++- 1 file changed, 18

[Qemu-devel] [PATCH v4 0/9] QOM'ify hw/timer/*

This patch series QOM'ify timer code under hw/timer directory. Main idea is to split the initfn's work, some to TypeInfo.instance_init and some is placed in DeviceClass::realize. Drop the use of SysBusDeviceClass::init if possible. Some patches in v3: hw/timer: QOM'ify arm_timer (pass 1)

[Qemu-devel] [PATCH v4 7/9] hw/timer: QOM'ify puv3_ost

assign puv3_ost_init to puv3_ost_info.instance_init and drop the SysBusDeviceClass::init Signed-off-by: xiaoqiang zhao --- hw/timer/puv3_ost.c | 18 +- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/hw/timer/puv3_ost.c b/hw/timer/puv3_ost.c

[Qemu-devel] [PATCH v4 6/9] hw/timer: QOM'ify milkymist_sysctl

* split the old SysBus init function into an instance_init and a Device realize function * use DeviceClass::realize instead of SysBusDeviceClass::init Reviewed-by: Peter Maydell Signed-off-by: xiaoqiang zhao --- hw/timer/milkymist-sysctl.c | 21

[Qemu-devel] [PATCH v4 9/9] hw/timer: QOM'ify tusb6010

Move majority of old SysBus init's work the into instance_init. Note: musb_init must be called in SysBus's init, otherwise it will break "make check" with error message as follows: qom/object.c:1576:object_get_canonical_path_component: assertion failed: (obj->parent != NULL) Signed-off-by:

[Qemu-devel] [PATCH v4 3/9] hw/timer: QOM'ify lm32_timer

* split the old SysBus init function into an instance_init and a Device realize function * use DeviceClass::realize instead of SysBusDeviceClass::init Reviewed-by: Peter Maydell Signed-off-by: xiaoqiang zhao --- hw/timer/lm32_timer.c | 19

[Qemu-devel] [PATCH v4 2/9] hw/timer: QOM'ify grlib_gptimer

* split the old SysBus init function into an instance_init and a Device realize function * use DeviceClass::realize instead of SysBusDeviceClass::init Signed-off-by: xiaoqiang zhao --- hw/timer/grlib_gptimer.c | 30 ++ 1 file changed, 18

Re: [Qemu-devel] [PATCH v2 1/1] quorum: Change vote rules for 64 bits hash

On 02/20/2016 10:28 PM, Max Reitz wrote: On 19.02.2016 12:24, Alberto Garcia wrote: On Fri 19 Feb 2016 09:26:53 AM CET, Wen Congyang wrote: If quorum has two children(A, B). A do flush sucessfully, but B flush failed. We MUST choice A as winner rather than just pick

Re: [Qemu-devel] [RFC PATCH v2 05/10] net/colo-proxy: Add colo interface to use proxy

On 02/20/2016 03:58 AM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: From: zhangchen Add interface used by migration/colo.c so colo framework can work with proxy Signed-off-by: zhangchen

Re: [Qemu-devel] [RFC PATCH v2 03/10] Colo-proxy: add colo-proxy framework

On 02/20/2016 03:57 AM, Dr. David Alan Gilbert wrote: * Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote: From: zhangchen +static void colo_proxy_setup(NetFilterState *nf, Error **errp) +{ +COLOProxyState *s = FILTER_COLO_PROXY(nf); + +if (!s->addr) {

Re: [Qemu-devel] [PATCH 1/3] exec: store RAMBlock pointer into memory region

On Sat, 02/20 10:35, Gonglei wrote: > Each RAM memory region has a unique corresponding RAMBlock. > In the current realization, the memory region only stored > the ram_addr which means the offset of RAM address space, > We need to qurey the global ram.list to find the ram block > by ram_addr if we

[Qemu-devel] [PATCH COLO-Frame v15 38/38] COLO: Add block replication into colo process

Make sure master start block replication after slave's block replication started. Signed-off-by: zhanghailiang Signed-off-by: Wen Congyang Signed-off-by: Li Zhijian Cc: Stefan Hajnoczi Cc:

[Qemu-devel] [PATCH COLO-Frame v15 36/38] filter-buffer: make filter_buffer_flush() public

We will use it in COLO to flush the buffered packets. Signed-off-by: zhanghailiang Cc: Jason Wang Cc: Yang Hongyang --- v14: - New patch --- include/net/filter.h | 2 ++ net/filter-buffer.c | 2 +- 2 files

[Qemu-devel] [PATCH COLO-Frame v15 13/38] COLO: Load VMState into qsb before restore it

We should not destroy the state of SVM (Secondary VM) until we receive the whole state from the PVM (Primary VM), in case the primary fails in the middle of sending the state, so, here we cache the device state in Secondary before restore it. Besides, we should call qemu_system_reset() before

[Qemu-devel] [PATCH COLO-Frame v15 27/38] migration/savevm: Add new helpers to process the different stages of loadvm

There are several stages during loadvm process. In different stage, migration incoming processes different section. We want to control these stages more accuracy, to optimize the COLO capability. Here we add two new helper functions: qemu_loadvm_state_begin() and qemu_load_device_state().

[Qemu-devel] [PATCH COLO-Frame v15 35/38] COLO: manage the status of buffer filters for PVM

Enable all buffer filters that added by COLO while go into COLO process, and disable them while exit COLO. Signed-off-by: zhanghailiang Cc: Jason Wang Cc: Yang Hongyang --- v15: - Re-implement

[Qemu-devel] [PATCH COLO-Frame v15 28/38] migration/savevm: Export two helper functions for savevm process

We add a new helper functions qemu_savevm_live_state(), and make qemu_save_device_state() public. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian --- v14: - New patch split from previous 'COLO: Separate the process of

[Qemu-devel] [PATCH COLO-Frame v15 16/38] COLO: synchronize PVM's state to SVM periodically

Do checkpoint periodically, the default interval is 200ms. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Reviewed-by: Dr. David Alan Gilbert --- v12: - Add Reviewed-by tag v11: - Fix wrong sleep time for

[Qemu-devel] [PATCH COLO-Frame v15 21/38] qmp event: Add COLO_EXIT event to notify users while exited from COLO

If some errors happen during VM's COLO FT stage, it's important to notify the users of this event. Together with 'x_colo_lost_heartbeat', users can intervene in COLO's failover work immediately. If users don't want to get involved in COLO's failover verdict, it is still necessary to notify users

[Qemu-devel] [PATCH COLO-Frame v15 37/38] COLO: flush buffered packets in checkpoint process or exit COLO

In COLO periodic mode, the packets from VM should not be sent during the time interval of two checkpoints, we will release all these buffered packets after the checkpoint process, before VM is resumed. In this way, we can ensure not to break the network services if COLO goes into failover

[Qemu-devel] [PATCH COLO-Frame v15 26/38] savevm: Introduce two helper functions for save/find loadvm_handlers entry

For COLO's checkpoint process, we will do savevm/loadvm repeatedly. So every time we call qemu_loadvm_section_start_full(), we will add all sections information into loadvm_handlers list for one time. There will be many instances in loadvm_handlers for one section, and this will lead to memory

[Qemu-devel] [PATCH COLO-Frame v15 33/38] net: Add notifier/callback for netdev init

We can register some callback for this notifier, this will be used by COLO to register a callback which will add each netdev a buffer filter. Signed-off-by: zhanghailiang Cc: Jason Wang Cc: Yang Hongyang --- v14:

[Qemu-devel] [PATCH COLO-Frame v15 25/38] COLO: Update the global runstate after going into colo state

If we start qemu with -S, the runstate will change from 'prelaunch' to 'running' after going into colo state. So it is necessary to update the global runstate after going into colo state. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian

[Qemu-devel] [PATCH COLO-Frame v15 34/38] COLO/filter: add each netdev a buffer filter

For COLO periodic mode, it need to buffer packets that sent by VM, and we will not release these packets until finish a checkpoint. Here, we add each netdev a buffer-filter that will be controlled by COLO. It is disabled by default, and the packets will not pass through these filters. If users

[Qemu-devel] [PATCH COLO-Frame v15 22/38] COLO failover: Shutdown related socket fd when do failover

If the net connection between COLO's two sides is broken while colo/colo incoming thread is blocked in 'read'/'write' socket fd. It will not detect this error until connect timeout. It will be a long time. Here we shutdown all the related socket file descriptors to wake up the blocking

[Qemu-devel] [PATCH COLO-Frame v15 32/38] filter-buffer: Accept zero interval

We may want to accept zero interval when VM FT solutions like MC or COLO use this filter to release packets on demand. Signed-off-by: zhanghailiang Reviewed-by: Yang Hongyang Cc: Jason Wang Cc: Yang Hongyang

[Qemu-devel] [PATCH COLO-Frame v15 19/38] COLO: Implement failover work for Primary VM

For PVM, if there is failover request from users. The colo thread will exit the loop while the failover BH does the cleanup work and resumes VM. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Reviewed-by: Dr. David Alan Gilbert

[Qemu-devel] [PATCH COLO-Frame v15 18/38] COLO failover: Introduce state to record failover process

When handling failover, we do different things according to the different stage of failover process, here we introduce a global atomic variable to record the status of failover. We add four failover status to indicate the different stage of failover process. You should use the helpers to get and

[Qemu-devel] [PATCH COLO-Frame v15 29/38] COLO: Separate the process of saving/loading ram and device state

We separate the process of saving/loading ram and device state when do checkpoint, we add new helpers for save/load ram/device. With this change, we can directly transfer ram from master to slave without using QEMUSizeBufferas as assistant, which also reduce the size of extra memory been used

[Qemu-devel] [PATCH COLO-Frame v15 12/38] ram/COLO: Record the dirty pages that SVM received

We record the address of the dirty pages that received, it will help flushing pages that cached into SVM. We record them by re-using migration dirty bitmap. Signed-off-by: zhanghailiang Reviewed-by: Dr. David Alan Gilbert --- v12: - Add

[Qemu-devel] [PATCH COLO-Frame v15 31/38] net/filter: Add a 'status' property for filter object

With this property, users can control if this filter is 'enable' or 'disable'. The default behavior for filter is enabled. We will skip the disabled filter when delivering packets in net layer. Signed-off-by: zhanghailiang Cc: Jason Wang Cc:

[Qemu-devel] [PATCH COLO-Frame v15 30/38] COLO: Split qemu_savevm_state_begin out of checkpoint process

It is unnecessary to call qemu_savevm_state_begin() in every checkponit process. It mainly sets up devices and does the first device state pass. These data will not change during the later checkpoint process. So, we split it out of colo_do_checkpoint_transaction(), in this way, we can reduce these

[Qemu-devel] [PATCH COLO-Frame v15 04/38] migration: Integrate COLO checkpoint process into migration

Add a migrate state: MIGRATION_STATUS_COLO, enter this migration state after the first live migration successfully finished. We reuse migration thread, so if colo is enabled by user, migration thread will go into the process of colo. Signed-off-by: zhanghailiang

[Qemu-devel] [PATCH COLO-Frame v15 00/38] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service (FT)

From: root This is the 15th version of COLO (Still only support periodic checkpoint). Here is only COLO frame part, you can get the whole codes from github: https://github.com/coloft/qemu/commits/colo-v2.6-periodic-mode There are little changes for this series

[Qemu-devel] [PATCH COLO-Frame v15 17/38] COLO failover: Introduce a new command to trigger a failover

We leave users to choose whatever heartbeat solution they want, if the heartbeat is lost, or other errors they detect, they can use experimental command 'x_colo_lost_heartbeat' to tell COLO to do failover, COLO will do operations accordingly. For example, if the command is sent to the PVM, the

[Qemu-devel] [PATCH COLO-Frame v15 24/38] COLO: Process shutdown command for VM in COLO state

If VM is in COLO FT state, we should do some extra work before normal shutdown process. SVM will ignore the shutdown command if this command is issued directly to it, PVM will send the shutdown command to SVM if it gets this command. Cc: Paolo Bonzini Signed-off-by:

[Qemu-devel] [PATCH COLO-Frame v15 15/38] COLO: Add checkpoint-delay parameter for migrate-set-parameters

Add checkpoint-delay parameter for migrate-set-parameters, so that we can control the checkpoint frequency when COLO is in periodic mode. Cc: Luiz Capitulino Cc: Eric Blake Cc: Markus Armbruster Signed-off-by: zhanghailiang

[Qemu-devel] [PATCH COLO-Frame v15 07/38] COLO: Implement colo checkpoint protocol

We need communications protocol of user-defined to control the checkpoint process. The new checkpoint request is started by Primary VM, and the interactive process like below: Checkpoint synchronizing points: Primary Secondary

[Qemu-devel] [PATCH COLO-Frame v15 10/38] COLO: Save PVM state to secondary side when do checkpoint

The main process of checkpoint is to synchronize SVM with PVM. VM's state includes ram and device state. So we will migrate PVM's state to SVM when do checkpoint, just like migration does. We will cache PVM's state in slave, we use QEMUSizedBuffer to store the data, we need to know the size of VM

[Qemu-devel] [PATCH COLO-Frame v15 20/38] COLO: Implement failover work for Secondary VM

If users require SVM to takeover work, colo incoming thread should exit from loop while failover BH helps backing to migration incoming coroutine. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Reviewed-by: Dr. David Alan Gilbert

[Qemu-devel] [PATCH COLO-Frame v15 23/38] COLO failover: Don't do failover during loading VM's state

We should not do failover work while the main thread is loading VM's state, otherwise it will destroy the consistent of VM's memory and device state. Here we add a new failover status 'RELAUNCH' which means we should relaunch the process of failover. Signed-off-by: zhanghailiang

[Qemu-devel] [PATCH COLO-Frame v15 06/38] COLO/migration: Create a new communication path from destination to source

This new communication path will be used for returning messages from destination to source. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Reviewed-by: Dr. David Alan Gilbert --- v13: - Remove useless error

[Qemu-devel] [PATCH COLO-Frame v15 14/38] COLO: Flush PVM's cached RAM into SVM's memory

During the time of VM's running, PVM may dirty some pages, we will transfer PVM's dirty pages to SVM and store them into SVM's RAM cache at next checkpoint time. So, the content of SVM's RAM cache will always be same with PVM's memory after checkpoint. Instead of flushing all content of PVM's RAM

[Qemu-devel] [PATCH COLO-Frame v15 09/38] QEMUSizedBuffer: Introduce two help functions for qsb

Introduce two new QEMUSizedBuffer APIs which will be used by COLO to buffer VM state: One is qsb_put_buffer(), which put the content of a given QEMUSizedBuffer into QEMUFile, this is used to send buffered VM state to secondary. Another is qsb_fill_buffer(), read 'size' bytes of data from the file

[Qemu-devel] [PATCH COLO-Frame v15 08/38] COLO: Add a new RunState RUN_STATE_COLO

Guest will enter this state when paused to save/restore VM state under colo checkpoint. Cc: Eric Blake Cc: Markus Armbruster Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Signed-off-by:

[Qemu-devel] [PATCH COLO-Frame v15 05/38] migration: Integrate COLO checkpoint process into loadvm

Switch from normal migration loadvm process into COLO checkpoint process if COLO mode is enabled. We add three new members to struct MigrationIncomingState, 'have_colo_incoming_thread' and 'colo_incoming_thread' record the colo related threads for secondary VM, 'migration_incoming_co' records the

[Qemu-devel] [PATCH COLO-Frame v15 01/38] configure: Add parameter for configure to enable/disable COLO support

configure --enable-colo/--disable-colo to switch COLO support on/off. COLO support is On by default. Signed-off-by: zhanghailiang Signed-off-by: Li Zhijian Signed-off-by: Gonglei Reviewed-by: Dr. David Alan

[Qemu-devel] [PATCH COLO-Frame v15 11/38] COLO: Load PVM's dirty pages into SVM's RAM cache temporarily

We should not load PVM's state directly into SVM, because there maybe some errors happen when SVM is receving data, which will break SVM. We need to ensure receving all data before load the state into SVM. We use an extra memory to cache these data (PVM's ram). The ram cache in secondary side is

[Qemu-devel] [PATCH COLO-Frame v15 03/38] COLO: migrate colo related info to secondary node

We can know if VM in destination should go into COLO mode by refer to the info that been migrated from PVM. We skip this section if colo is not enabled (i.e. migrate_set_capability colo off), so that, It not break compatibility with migration however the --enable-colo/disable-colo on the

[Qemu-devel] [PATCH COLO-Frame v15 02/38] migration: Introduce capability 'x-colo' to migration

We add helper function colo_supported() to indicate whether colo is supported or not, with which we use to control whether or not showing 'x-colo' string to users, they can use qmp command 'query-migrate-capabilities' or hmp command 'info migrate_capabilities' to learn if colo is supported. Cc:

Re: [Qemu-devel] [PATCHv7 4/9] slirp: Factorizing tcpiphdr structure with an union

Hello, Thomas Huth, on Fri 19 Feb 2016 14:44:59 +0100, wrote: > > + m->m_data -= sizeof(struct tcpiphdr) - (sizeof(struct ip) > > ++ sizeof(struct tcphdr)); > > + m->m_len += sizeof(struct tcpiphdr) - (sizeof(struct ip) > > +

Re: [Qemu-devel] [RFC PATCH 0/2] ARM: add QMP command to query GIC version

On Fri, Feb 19, 2016 at 01:33:09PM +0100, Andrea Bolognani wrote: > I didn't say it would be hard :) > > I just said that such compatibility code would have to be kept > around forever. We already support lots and lots of similar cases > in libvirt, the difference being that in this case we would

Re: [Qemu-devel] [PATCH v3 0/2] Fix migration of old pseries

On Fri, Feb 19, 2016 at 08:59:44AM +0100, Greg Kurz wrote: > On Fri, 19 Feb 2016 11:11:47 +1100 > David Gibson wrote: > > > On Thu, Feb 18, 2016 at 12:32:11PM +0100, Greg Kurz wrote: > > > QEMU 2.4 broke the migration of old pseries machine with the addition > > > of

Re: [Qemu-devel] [PATCH v3 5/7] STM32F205: Connect the ADC devices

On 21 February 2016 at 23:35, Alistair Francis wrote: > On Tue, Feb 2, 2016 at 7:27 AM, Peter Maydell > wrote: >> On 19 January 2016 at 07:23, Alistair Francis wrote: >> You can't just wire multiple irq lines up like this; I

[Qemu-devel] Integrating a Memory Simulator

Hi All, I was trying to integrate the DRAMSim2 memory simulator [1] into QEMU. Basically I wanted to modify the current memory interface of QEMU so that all memory accesses will be directed to DRAMSim2. Can anyone give me hints/comments/thoughts on how to do this? I am targeting x86-64

Re: [Qemu-devel] [PATCH v3 5/7] STM32F205: Connect the ADC devices

On Tue, Feb 2, 2016 at 7:27 AM, Peter Maydell wrote: > On 19 January 2016 at 07:23, Alistair Francis wrote: >> Connect the ADC devices to the STM32F205 SoC. >> >> Signed-off-by: Alistair Francis >> --- >> V2: >> - Fix up

Re: [Qemu-devel] [PATCH v3 4/7] STM32F2xx: Add the SPI device

On Tue, Feb 2, 2016 at 7:30 AM, Peter Maydell wrote: > On 19 January 2016 at 07:23, Alistair Francis wrote: >> Add the STM32F2xx SPI device. >> >> Signed-off-by: Alistair Francis >> --- >> V2: >> - Address Peter C's

Re: [Qemu-devel] [PATCH v3 3/7] STM32F2xx: Add the ADC device

On Tue, Feb 2, 2016 at 7:17 AM, Peter Maydell wrote: > On 19 January 2016 at 07:23, Alistair Francis wrote: >> Add the STM32F2xx ADC device. This device randomly >> generates values on each read. >> >> This also includes creating a hw/adc

Re: [Qemu-devel] [PATCH] gtk: implement set_echo

On 2016-02-17 15:05, Paolo Bonzini wrote: > > > On 17/02/2016 14:53, Kevin Wolf wrote: >> Waiting didn't fix the bug, so I tried a git bisect now and it pointed >> me to this commit. >> >> I'm using HMP with the default vc backend. Starting with this commit, >> the echo is broken sometimes, in a

[Qemu-devel] [Bug 1423124] Re: QEMU crash after sending data on host serial port

Hi All I also meet this issue. I have two computer, one is Win7 32 another is Win7 64, Both computer meet this issue. My QEMU version is qemu-w32-setup-20160215 I want used EDK2 OVMF with Intel UDK Debugger tools to do source level debug I had install com0com Virtual Com Port, and set COM3

Re: [Qemu-devel] [V6 0/4] AMD IOMMU

On 2016-02-21 19:10, David Kiarie wrote: > Hello there, > > Repost, AMD IOMMU patches version 6. > > Changes since version 5 > -Fixed macro formating issues > -changed occurences of IO MMU to IOMMU for consistency > -Fixed capability registers duplication > -Rebased to current master I

Re: [Qemu-devel] [V6 2/4] hw/core: Add AMD IOMMU to machine properties

On 2016-02-21 19:10, David Kiarie wrote: > diff --git a/qemu-options.hx b/qemu-options.hx > index 2f0465e..dad160f 100644 > --- a/qemu-options.hx > +++ b/qemu-options.hx > @@ -38,7 +38,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \ > "kvm_shadow_mem=size of KVM shadow

[Qemu-devel] [PATCH 3/4] hw/i386: ACPI table for AMD IOMMU

Add IVRS table for AMD IOMMU. Generate IVRS or DMAR depending on emulated IOMMU Signed-off-by: David Kiarie --- hw/i386/acpi-build.c| 98 - include/hw/acpi/acpi-defs.h | 55 + 2 files changed,

Re: [Qemu-devel] [V6 3/4] hw/i386: ACPI table for AMD IOMMU

On Sun, Feb 21, 2016 at 9:20 PM, Jan Kiszka wrote: > On 2016-02-21 19:10, David Kiarie wrote: >> Add IVRS table for AMD IOMMU. Generate IVRS or DMAR >> depending on emulated IOMMU >> >> Signed-off-by: David Kiarie >> --- >> hw/i386/acpi-build.c

Re: [Qemu-devel] [V6 3/4] hw/i386: ACPI table for AMD IOMMU

On 2016-02-21 19:10, David Kiarie wrote: > Add IVRS table for AMD IOMMU. Generate IVRS or DMAR > depending on emulated IOMMU > > Signed-off-by: David Kiarie > --- > hw/i386/acpi-build.c| 208 > +--- >

[Qemu-devel] [V6 4/4] hw/pci-host: Emulate AMD IOMMU

Add AMD IOMMU emulation support to q35 chipset Signed-off-by: David Kiarie --- hw/pci-host/piix.c| 1 + hw/pci-host/q35.c | 14 -- include/hw/i386/intel_iommu.h | 1 + 3 files changed, 14 insertions(+), 2 deletions(-) diff --git

[Qemu-devel] [V6 1/4] hw/i386: Introduce AMD IOMMU

Add AMD IOMMU emulaton to Qemu in addition to Intel IOMMU The IOMMU does basic translation, error checking and has a mininal IOTLB implementation Signed-off-by: David Kiarie --- hw/i386/Makefile.objs |1 + hw/i386/amd_iommu.c | 1432

[Qemu-devel] [V6 3/4] hw/i386: ACPI table for AMD IOMMU

Add IVRS table for AMD IOMMU. Generate IVRS or DMAR depending on emulated IOMMU Signed-off-by: David Kiarie --- hw/i386/acpi-build.c| 208 +--- include/hw/acpi/acpi-defs.h | 55 2 files changed, 252

[Qemu-devel] [V6 2/4] hw/core: Add AMD IOMMU to machine properties

Add IOMMU as a string to machine properties which is used to control whether and the type of IOMMU to emulate Signed-off-by: David Kiarie --- hw/core/machine.c | 28 include/hw/boards.h | 3 ++- qemu-options.hx | 6 +++---

  1   2   >