[Xen-devel] [PATCH v5 08/10] virtio_pci: Use the DMA API if enabled

This switches to vring_create_virtqueue, simplifying the driver and adding DMA API support. This fixes virtio-pci on platforms and busses that have IOMMUs. This will break the experimental QEMU Q35 IOMMU support until QEMU is fixed. In exchange, it fixes physical virtio hardware as well as

[Xen-devel] [PATCH v5 10/10] vring: Add a module parameter to force-enable the DMA API

This will be useful for testing. Signed-off-by: Andy Lutomirski --- drivers/virtio/virtio_ring.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index 305c05cc249a..46fb77d824e9 100644 ---

[Xen-devel] [PATCH v5 01/10] dma: Provide simple noop dma ops

From: Christian Borntraeger We are going to require dma_ops for several common drivers, even for systems that do have an identity mapping. Lets provide some minimal no-op dma_ops that can be used for that purpose. Signed-off-by: Christian Borntraeger

[Xen-devel] [PATCH v5 04/10] vring: Introduce vring_use_dma_api()

This is a kludge, but no one has come up with a a better idea yet. We'll introduce DMA API support guarded by vring_use_dma_api(). Eventually we may be able to return true on more and more systems, and hopefully we can get rid of vring_use_dma_api() entirely some day. Signed-off-by: Andy

[Xen-devel] [PATCH v5 03/10] s390/dma: Allow per device dma ops

From: Christian Borntraeger As virtio-ccw will have dma ops, we can no longer default to the zPCI ones. Make use of dev_archdata to keep the dma_ops per device. The pci devices now use that to override the default, and the default is changed to use the noop ops for

[Xen-devel] [PATCH v5 07/10] virtio_mmio: Use the DMA API if enabled

This switches to vring_create_virtqueue, simplifying the driver and adding DMA API support. Signed-off-by: Andy Lutomirski --- drivers/virtio/virtio_mmio.c | 67 ++-- 1 file changed, 15 insertions(+), 52 deletions(-) diff --git

[Xen-devel] [PATCH v5 09/10] vring: Use the DMA API on Xen

Signed-off-by: Andy Lutomirski --- drivers/virtio/virtio_ring.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c index c169c6444637..305c05cc249a 100644 --- a/drivers/virtio/virtio_ring.c +++

[Xen-devel] [PATCH v5 06/10] virtio: Add improved queue allocation API

This leaves vring_new_virtqueue alone for compatbility, but it adds two new improved APIs: vring_create_virtqueue: Creates a virtqueue backed by automatically allocated coherent memory. (Some day it this could be extended to support non-coherent memory, too, if there ends up being a platform on

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

> -Original Message- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Friday, January 29, 2016 12:38 AM > To: Wu, Feng > Cc: Andrew Cooper ; Dario Faggioli > ; George Dunlap ; >

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

> -Original Message- > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex > Williamson > Sent: Thursday, January 28, 2016 11:36 AM > To: Gerd Hoffmann; qemu-de...@nongnu.org > Cc: igv...@ml01.01.org; xen-de...@lists.xensource.com; Eduardo Habkost; > Stefano Stabellini;

[Xen-devel] [PATCH v5 05/10] virtio_ring: Support DMA APIs

virtio_ring currently sends the device (usually a hypervisor) physical addresses of its I/O buffers. This is okay when DMA addresses and physical addresses are the same thing, but this isn't always the case. For example, this never works on Xen guests, and it is likely to fail if a physical

[Xen-devel] [PATCH v5 02/10] alpha/dma: use common noop dma ops

From: Christian Borntraeger Some of the alpha pci noop dma ops are identical to the common ones. Use them. Signed-off-by: Christian Borntraeger Reviewed-by: Joerg Roedel --- arch/alpha/kernel/pci-noop.c | 46

Re: [Xen-devel] [iGVT-g] [vfio-users] [PATCH v3 00/11] igd passthrough chipset tweaks

On Fri, 2016-01-29 at 02:22 +, Kay, Allen M wrote: >  > > -Original Message- > > From: iGVT-g [mailto:igvt-g-boun...@lists.01.org] On Behalf Of Alex > > Williamson > > Sent: Thursday, January 28, 2016 11:36 AM > > To: Gerd Hoffmann; qemu-de...@nongnu.org > > Cc: igv...@ml01.01.org;

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

This run is configured for baseline tests only. flight 38711 qemu-mainline real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38711/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm

Re: [Xen-devel] [PATCH v2] build: specify minimum versions of make and binutils

>>> On 28.01.16 at 14:02, wrote: > On Thu, 2016-01-28 at 05:49 -0700, Jan Beulich wrote: >> > > > On 28.01.16 at 00:12, wrote: >> > To help people avoid having to figure out what versions of make and >> > binutils need to be supported document them

[Xen-devel] [PATCH] vm_event: make sure the domain is paused in key domctls

This patch pauses the domain for all writes through the 'ad' pointer in monitor_domctl(), defers a domain_unpause() call until after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG case, and makes sure that the domain is paused for both vm_event enable and disable cases in

Re: [Xen-devel] [PATCH] vm_event: make sure the domain is paused in key domctls

On 28/01/16 13:52, Razvan Cojocaru wrote: > This patch pauses the domain for all writes through the 'ad' > pointer in monitor_domctl(), defers a domain_unpause() call until > after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG > case, and makes sure that the domain is paused for both

[Xen-devel] [PATCH v2] Reset runstate_guest handles on soft reset

runstate_guest handles need to be reset to prevent update_runstate_area() corrupting guest's memory after we resume the guest. Signed-off-by: Vitaly Kuznetsov --- Changes since v1: - use set_xen_guest_handle() instead of raw memset() [Jan Beulich] --- xen/common/domain.c |

Re: [Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

>>> On 27.01.16 at 21:06, wrote: > --- a/xen/arch/x86/mm/p2m.c > +++ b/xen/arch/x86/mm/p2m.c > @@ -1572,7 +1572,9 @@ void p2m_mem_access_emulate_check(struct vcpu *v, > bool_t violation = 1; > const struct vm_event_mem_access *data = >u.mem_access; > > -

Re: [Xen-devel] [PATCH] ARM: Support for guest-request vm-events

On 01/28/2016 03:03 PM, Ian Campbell wrote: > On Thu, 2016-01-28 at 14:57 +0200, Corneliu ZUZU wrote: >> >> >> Ok, great. I'll try it tonight and post a patch series ASAP. >> Concerning the CC list, Razvan actually noticed me earlier that he and >> Tamas should have >> been on it for this

Re: [Xen-devel] [PATCH] vm_event: make sure the domain is paused in key domctls

On 01/28/2016 04:10 PM, Andrew Cooper wrote: > On 28/01/16 13:52, Razvan Cojocaru wrote: >> This patch pauses the domain for all writes through the 'ad' >> pointer in monitor_domctl(), defers a domain_unpause() call until >> after the CRs are updated for the MONITOR_EVENT_WRITE_CTRLREG >> case,

Re: [Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

On 01/28/2016 05:12 PM, Lengyel, Tamas wrote: > > On Jan 28, 2016 8:02 AM, "Razvan Cojocaru" > wrote: >> >> On 01/28/2016 04:42 PM, Lengyel, Tamas wrote: >> > >> > On Jan 28, 2016 6:38 AM, "Jan Beulich"

Re: [Xen-devel] [PATCH v11 1/2] vmx: VT-d posted-interrupt core logic handling

>>> On 28.01.16 at 06:12, wrote: > --- a/xen/arch/x86/hvm/vmx/vmx.c > +++ b/xen/arch/x86/hvm/vmx/vmx.c > @@ -83,7 +83,140 @@ static int vmx_msr_write_intercept(unsigned int msr, > uint64_t msr_content); > static void vmx_invlpg_intercept(unsigned long vaddr); > static int

Re: [Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

>>> On 28.01.16 at 15:42, wrote: > On Jan 28, 2016 6:38 AM, "Jan Beulich" wrote: >> >>> On 27.01.16 at 21:06, wrote: >> > --- a/xen/arch/x86/mm/p2m.c >> > +++ b/xen/arch/x86/mm/p2m.c >> > @@ -1572,7 +1572,9 @@ void

Re: [Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

On Jan 28, 2016 7:56 AM, "Jan Beulich" wrote: > > >>> On 28.01.16 at 15:42, wrote: > > On Jan 28, 2016 6:38 AM, "Jan Beulich" wrote: > >> >>> On 27.01.16 at 21:06, wrote: > >> > --- a/xen/arch/x86/mm/p2m.c > >> >

Re: [Xen-devel] [PATCH 2/2] altp2m: Implement p2m_get_mem_access for altp2m views

On 01/28/2016 04:42 PM, Lengyel, Tamas wrote: > > On Jan 28, 2016 6:38 AM, "Jan Beulich" > wrote: >> >> >>> On 27.01.16 at 21:06, > wrote: >> > --- a/xen/arch/x86/mm/p2m.c >> > +++

Re: [Xen-devel] schedulers and topology exposing questions

On Wed, 2016-01-27 at 10:27 -0500, Konrad Rzeszutek Wilk wrote: > On Wed, Jan 27, 2016 at 03:10:01PM +, George Dunlap wrote: > >  > > I'm not sure I understand the situation right, but it sounds a bit > > like > > what you're seeing is just a quirk of the fact that Linux doesn't > > always > >

[Xen-devel] [PATCH v7 16/18] tools/libxl: store remus_ops in checkpoint device state

Checkpoint device is an abstract layer to do checkpoint. COLO can also use it to do checkpoint. But there are still some codes in checkpoint device which touch remus. This patch and: tools/libxl: move remus state into a seperate structure tools/libxl: seperate device init/cleanup from

[Xen-devel] [PATCH v7 11/18] 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 v7 18/18] tools/libxl: seperate device init/cleanup from checkpoint device layer

we call (init|cleanup)_subkind_nic and (init|cleanup)_subkind_drbd_disk directly in checkpoint device. Move them to libxl_remus.c, Call them before calling libxl__checkpoint_devices_setup() or after calling libxl__checkpoint_devices_teardown(). it is pure refactoring and no functional changes.

[Xen-devel] [PATCH v7 07/18] migration/save: pass checkpointed_stream from libxl to libxc

Pass checkpointed_stream from libxl to libxc. It won't affact legacy migration because legacy migration won't use this param. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang CC: Ian Campbell CC: Ian Jackson

[Xen-devel] [PATCH v7 03/18] tools/libxl: move save/restore code into libxl_dom_save.c

This is purely code motion. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang CC: Ian Jackson CC: Wei Liu Acked-by: Ian Campbell --- tools/libxl/Makefile

[Xen-devel] [PATCH v7 06/18] tools/libxl: introduce enum type libxl_checkpointed_stream

Introduce enum type libxl_checkpointed_stream in IDL. rename the last argument of migrate_receive from "remus" to "checkpointed" since the semantics of this parameter has changed. NOTE: libxl_domain_restore_params and domain_create aren't changed here, checkpointed_stream is still an int.

[Xen-devel] [PATCH v7 04/18] libxl/save: Refactor libxl__domain_suspend_state

Currently struct libxl__domain_suspend_state contains 2 type of states, one is save state, another is suspend state. This patch separates those two out. The motivation of this is that COLO will need to do suspend/resume continuously, we need a more common suspend state. After this change, dss

[Xen-devel] [PATCH v7 02/18] tools/libxl: move remus code into libxl_remus.c

After previous refactoring, we are now able to move all remus code into a separate file libxl_remus.c. Export following functions for internal use: - Remus callbacks * libxl__remus_domain_suspend_callback * libxl__remus_domain_resume_callback * libxl__remus_domain_save_checkpoint_callback

[Xen-devel] [PATCH v7 00/18] Prerequisite patches for COLO

This patchset is Prerequisite for COLO feature. Refer to: http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping Patch status: 1. Acked patches: patch 2, 3, 4, 9, 10, 15, 16, 18 2. Reviewd patches: patch 1, 10, 13, 15, 16, 17, 18 3. New patches: none Note: patch 4 is updated to fix a bug You

[Xen-devel] [PATCH v7 08/18] 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 v7 13/18] tools/libxl: rename remus device to checkpoint device

This patch is auto generated by the following commands: 1. git mv tools/libxl/libxl_remus_device.c tools/libxl/libxl_checkpoint_device.c 2. perl -pi -e 's/libxl_remus_device/libxl_checkpoint_device/g' tools/libxl/Makefile 3. perl -pi -e 's/\blibxl__remus_devices/libxl__checkpoint_devices/g'

[Xen-devel] [PATCH v7 15/18] tools/libxl: adjust the indentation

This is just tidying up after the "tools/libxl: rename remus device to checkpoint device" patch automatic renaming. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang Acked-by: Ian Campbell Reviewed-by: Konrad

[Xen-devel] [PATCH v7 17/18] tools/libxl: move remus state into a seperate structure

Add a new structure remus state, and move concrete layer's private member to remus state. it is pure refactoring and no functional changes. Init interval in libxl__remus_setup(). It is safe to move this initialisation, because this value is only used for remus, and remus will use this value after

[Xen-devel] [PATCH v7 05/18] tools/libxc: support to resume uncooperative HVM guests

Before this patch: 1. suspend a. PVHVM and PV: we use the same way to suspend the guest (send the suspend request to the guest). If the guest doesn't support evtchn, the xenstore variant will be used, suspending the guest via XenBus control node. b. pure HVM: we call xc_domain_shutdown(...,

[Xen-devel] [PATCH v7 12/18] 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 v7 09/18] 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 v7 10/18] tools/libxl: export logdirty_init

We need to enable logdirty on secondary, so we export logdirty_init for internal use. Rename it to libxl__logdirty_init. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang Acked-by: Ian Campbell Reviewed-by:

[Xen-devel] [PATCH v7 14/18] tools/libxl: fix backword compatibility after the automatic renaming

The error code ERROR_REMUS_XXX was introduced in Xen 4.5, and changed to ERROR_CHECKPOINT_XXX after previous renaming. The patch fix the backword compatibility. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang --- tools/libxl/libxl.h |

[Xen-devel] [PATCH v7 01/18] libxl/remus: init checkpoint_callback in Remus setup callback

init stream {read/write} state checkpoint_callback in Remus setup callback. There's no functional change, it's just refactoring so that we can move all remus code into one file. Signed-off-by: Yang Hongyang Signed-off-by: Wen Congyang CC: Andrew

<    1   2