All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yang Zhang <yang.zhang.wz@gmail.com>
To: Alexander Duyck <aduyck@mirantis.com>,
	kvm@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, alexander.duyck@gmail.com,
	qemu-devel@nongnu.org
Cc: tianyu.lan@intel.com, mst@redhat.com, konrad.wilk@oracle.com,
	dgilbert@redhat.com, agraf@suse.de, alex.williamson@redhat.com
Subject: Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking
Date: Mon, 14 Dec 2015 10:27:35 +0800	[thread overview]
Message-ID: <566E2917.7050705@gmail.com> (raw)
In-Reply-To: <20151213212557.5410.48577.stgit@localhost.localdomain>

On 2015/12/14 5:28, Alexander Duyck wrote:
> This patch set is meant to be the guest side code for a proof of concept
> involving leaving pass-through devices in the guest during the warm-up
> phase of guest live migration.  In order to accomplish this I have added a
> new function called dma_mark_dirty that will mark the pages associated with
> the DMA transaction as dirty in the case of either an unmap or a
> sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
> DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
> the stop-and-copy phase, however allowing the device to be present should
> significantly improve the performance of the guest during the warm-up
> period.
>
> This current implementation is very preliminary and there are number of
> items still missing.  Specifically in order to make this a more complete
> solution we need to support:
> 1.  Notifying hypervisor that drivers are dirtying DMA pages received
> 2.  Bypassing page dirtying when it is not needed.
>

Shouldn't current log dirty mechanism already cover them?


> The two mechanisms referenced above would likely require coordination with
> QEMU and as such are open to discussion.  I haven't attempted to address
> them as I am not sure there is a consensus as of yet.  My personal
> preference would be to add a vendor-specific configuration block to the
> emulated pci-bridge interfaces created by QEMU that would allow us to
> essentially extend shpc to support guest live migration with pass-through
> devices.
>
> The functionality in this patch set is currently disabled by default.  To
> enable it you can select "SWIOTLB page dirtying" from the "Processor type
> and features" menu.

Only SWIOTLB is supported?

>
> ---
>
> Alexander Duyck (3):
>        swiotlb: Fold static unmap and sync calls into calling functions
>        xen/swiotlb: Fold static unmap and sync calls into calling functions
>        x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest
>
>
>   arch/arm/include/asm/dma-mapping.h       |    3 +
>   arch/arm64/include/asm/dma-mapping.h     |    5 +-
>   arch/ia64/include/asm/dma.h              |    1
>   arch/mips/include/asm/dma-mapping.h      |    1
>   arch/powerpc/include/asm/swiotlb.h       |    1
>   arch/tile/include/asm/dma-mapping.h      |    1
>   arch/unicore32/include/asm/dma-mapping.h |    1
>   arch/x86/Kconfig                         |   11 ++++
>   arch/x86/include/asm/swiotlb.h           |   26 ++++++++
>   drivers/xen/swiotlb-xen.c                |   92 +++++++++++++-----------------
>   lib/swiotlb.c                            |   83 ++++++++++++---------------
>   11 files changed, 123 insertions(+), 102 deletions(-)
>
> --
>


-- 
best regards
yang

WARNING: multiple messages have this Message-ID (diff)
From: Yang Zhang <yang.zhang.wz@gmail.com>
To: Alexander Duyck <aduyck@mirantis.com>,
	kvm@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, alexander.duyck@gmail.com,
	qemu-devel@nongnu.org
Cc: tianyu.lan@intel.com, konrad.wilk@oracle.com, mst@redhat.com,
	agraf@suse.de, dgilbert@redhat.com, alex.williamson@redhat.com
Subject: Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking
Date: Mon, 14 Dec 2015 10:27:35 +0800	[thread overview]
Message-ID: <566E2917.7050705@gmail.com> (raw)
In-Reply-To: <20151213212557.5410.48577.stgit@localhost.localdomain>

On 2015/12/14 5:28, Alexander Duyck wrote:
> This patch set is meant to be the guest side code for a proof of concept
> involving leaving pass-through devices in the guest during the warm-up
> phase of guest live migration.  In order to accomplish this I have added a
> new function called dma_mark_dirty that will mark the pages associated with
> the DMA transaction as dirty in the case of either an unmap or a
> sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
> DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
> the stop-and-copy phase, however allowing the device to be present should
> significantly improve the performance of the guest during the warm-up
> period.
>
> This current implementation is very preliminary and there are number of
> items still missing.  Specifically in order to make this a more complete
> solution we need to support:
> 1.  Notifying hypervisor that drivers are dirtying DMA pages received
> 2.  Bypassing page dirtying when it is not needed.
>

Shouldn't current log dirty mechanism already cover them?


> The two mechanisms referenced above would likely require coordination with
> QEMU and as such are open to discussion.  I haven't attempted to address
> them as I am not sure there is a consensus as of yet.  My personal
> preference would be to add a vendor-specific configuration block to the
> emulated pci-bridge interfaces created by QEMU that would allow us to
> essentially extend shpc to support guest live migration with pass-through
> devices.
>
> The functionality in this patch set is currently disabled by default.  To
> enable it you can select "SWIOTLB page dirtying" from the "Processor type
> and features" menu.

Only SWIOTLB is supported?

>
> ---
>
> Alexander Duyck (3):
>        swiotlb: Fold static unmap and sync calls into calling functions
>        xen/swiotlb: Fold static unmap and sync calls into calling functions
>        x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest
>
>
>   arch/arm/include/asm/dma-mapping.h       |    3 +
>   arch/arm64/include/asm/dma-mapping.h     |    5 +-
>   arch/ia64/include/asm/dma.h              |    1
>   arch/mips/include/asm/dma-mapping.h      |    1
>   arch/powerpc/include/asm/swiotlb.h       |    1
>   arch/tile/include/asm/dma-mapping.h      |    1
>   arch/unicore32/include/asm/dma-mapping.h |    1
>   arch/x86/Kconfig                         |   11 ++++
>   arch/x86/include/asm/swiotlb.h           |   26 ++++++++
>   drivers/xen/swiotlb-xen.c                |   92 +++++++++++++-----------------
>   lib/swiotlb.c                            |   83 ++++++++++++---------------
>   11 files changed, 123 insertions(+), 102 deletions(-)
>
> --
>


-- 
best regards
yang

WARNING: multiple messages have this Message-ID (diff)
From: Yang Zhang <yang.zhang.wz@gmail.com>
To: Alexander Duyck <aduyck@mirantis.com>,
	kvm@vger.kernel.org, linux-pci@vger.kernel.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, alexander.duyck@gmail.com,
	qemu-devel@nongnu.org
Cc: tianyu.lan@intel.com, konrad.wilk@oracle.com, mst@redhat.com,
	agraf@suse.de, dgilbert@redhat.com, alex.williamson@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking
Date: Mon, 14 Dec 2015 10:27:35 +0800	[thread overview]
Message-ID: <566E2917.7050705@gmail.com> (raw)
In-Reply-To: <20151213212557.5410.48577.stgit@localhost.localdomain>

On 2015/12/14 5:28, Alexander Duyck wrote:
> This patch set is meant to be the guest side code for a proof of concept
> involving leaving pass-through devices in the guest during the warm-up
> phase of guest live migration.  In order to accomplish this I have added a
> new function called dma_mark_dirty that will mark the pages associated with
> the DMA transaction as dirty in the case of either an unmap or a
> sync_.*_for_cpu where the DMA direction is either DMA_FROM_DEVICE or
> DMA_BIDIRECTIONAL.  The pass-through device must still be removed before
> the stop-and-copy phase, however allowing the device to be present should
> significantly improve the performance of the guest during the warm-up
> period.
>
> This current implementation is very preliminary and there are number of
> items still missing.  Specifically in order to make this a more complete
> solution we need to support:
> 1.  Notifying hypervisor that drivers are dirtying DMA pages received
> 2.  Bypassing page dirtying when it is not needed.
>

Shouldn't current log dirty mechanism already cover them?


> The two mechanisms referenced above would likely require coordination with
> QEMU and as such are open to discussion.  I haven't attempted to address
> them as I am not sure there is a consensus as of yet.  My personal
> preference would be to add a vendor-specific configuration block to the
> emulated pci-bridge interfaces created by QEMU that would allow us to
> essentially extend shpc to support guest live migration with pass-through
> devices.
>
> The functionality in this patch set is currently disabled by default.  To
> enable it you can select "SWIOTLB page dirtying" from the "Processor type
> and features" menu.

Only SWIOTLB is supported?

>
> ---
>
> Alexander Duyck (3):
>        swiotlb: Fold static unmap and sync calls into calling functions
>        xen/swiotlb: Fold static unmap and sync calls into calling functions
>        x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest
>
>
>   arch/arm/include/asm/dma-mapping.h       |    3 +
>   arch/arm64/include/asm/dma-mapping.h     |    5 +-
>   arch/ia64/include/asm/dma.h              |    1
>   arch/mips/include/asm/dma-mapping.h      |    1
>   arch/powerpc/include/asm/swiotlb.h       |    1
>   arch/tile/include/asm/dma-mapping.h      |    1
>   arch/unicore32/include/asm/dma-mapping.h |    1
>   arch/x86/Kconfig                         |   11 ++++
>   arch/x86/include/asm/swiotlb.h           |   26 ++++++++
>   drivers/xen/swiotlb-xen.c                |   92 +++++++++++++-----------------
>   lib/swiotlb.c                            |   83 ++++++++++++---------------
>   11 files changed, 123 insertions(+), 102 deletions(-)
>
> --
>


-- 
best regards
yang

  parent reply	other threads:[~2015-12-14  2:27 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-13 21:28 [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking Alexander Duyck
2015-12-13 21:28 ` [Qemu-devel] " Alexander Duyck
2015-12-13 21:28 ` [RFC PATCH 1/3] swiotlb: Fold static unmap and sync calls into calling functions Alexander Duyck
2015-12-13 21:28   ` [Qemu-devel] " Alexander Duyck
2015-12-13 21:28 ` [RFC PATCH 2/3] xen/swiotlb: " Alexander Duyck
2015-12-13 21:28   ` [Qemu-devel] " Alexander Duyck
2015-12-13 21:28 ` [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest Alexander Duyck
2015-12-13 21:28   ` [Qemu-devel] " Alexander Duyck
2015-12-14 14:00   ` Michael S. Tsirkin
2015-12-14 14:00     ` [Qemu-devel] " Michael S. Tsirkin
2015-12-14 16:34     ` Alexander Duyck
2015-12-14 16:34       ` [Qemu-devel] " Alexander Duyck
2015-12-14 17:20       ` Michael S. Tsirkin
2015-12-14 17:20         ` [Qemu-devel] " Michael S. Tsirkin
2015-12-14 17:59         ` Alexander Duyck
2015-12-14 17:59           ` [Qemu-devel] " Alexander Duyck
2015-12-14 20:52           ` Michael S. Tsirkin
2015-12-14 20:52             ` [Qemu-devel] " Michael S. Tsirkin
2015-12-14 22:32             ` Alexander Duyck
2015-12-14 22:32               ` [Qemu-devel] " Alexander Duyck
2015-12-14  2:27 ` Yang Zhang [this message]
2015-12-14  2:27   ` [Qemu-devel] [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking Yang Zhang
2015-12-14  2:27   ` Yang Zhang
2015-12-14  4:54   ` Alexander Duyck
2015-12-14  4:54     ` [Qemu-devel] " Alexander Duyck
2015-12-14  4:54     ` Alexander Duyck
2015-12-14  5:22     ` Yang Zhang
2015-12-14  5:22       ` [Qemu-devel] " Yang Zhang
2015-12-14  5:22       ` Yang Zhang
2015-12-14  5:46       ` Alexander Duyck
2015-12-14  5:46         ` [Qemu-devel] " Alexander Duyck
2015-12-14  5:46         ` Alexander Duyck
2015-12-14  7:20         ` Yang Zhang
2015-12-14  7:20           ` [Qemu-devel] " Yang Zhang
2015-12-14 14:02           ` Michael S. Tsirkin
2015-12-14 14:02             ` [Qemu-devel] " Michael S. Tsirkin
2015-12-14 14:02             ` Michael S. Tsirkin
2016-01-04 20:41 ` Konrad Rzeszutek Wilk
2016-01-04 20:41   ` [Qemu-devel] " Konrad Rzeszutek Wilk
2016-01-05  3:11   ` Alexander Duyck
2016-01-05  3:11     ` [Qemu-devel] " Alexander Duyck
2016-01-05  9:40     ` Michael S. Tsirkin
2016-01-05  9:40       ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 10:01       ` Dr. David Alan Gilbert
2016-01-05 10:01         ` [Qemu-devel] " Dr. David Alan Gilbert
2016-01-05 10:35         ` Michael S. Tsirkin
2016-01-05 10:35           ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 10:35           ` Michael S. Tsirkin
2016-01-05 10:45           ` Dr. David Alan Gilbert
2016-01-05 10:45             ` [Qemu-devel] " Dr. David Alan Gilbert
2016-01-05 10:59             ` Michael S. Tsirkin
2016-01-05 10:59               ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 11:03               ` Dr. David Alan Gilbert
2016-01-05 11:03                 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-01-05 11:11                 ` Michael S. Tsirkin
2016-01-05 11:11                   ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 11:06               ` Michael S. Tsirkin
2016-01-05 11:06                 ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 11:05             ` Michael S. Tsirkin
2016-01-05 11:05               ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 12:43               ` Dr. David Alan Gilbert
2016-01-05 12:43                 ` [Qemu-devel] " Dr. David Alan Gilbert
2016-01-05 13:16                 ` Michael S. Tsirkin
2016-01-05 13:16                   ` [Qemu-devel] " Michael S. Tsirkin
2016-01-05 18:42                   ` Konrad Rzeszutek Wilk
2016-01-05 18:42                     ` [Qemu-devel] " Konrad Rzeszutek Wilk
2016-01-05 16:18       ` Alexander Duyck
2016-01-05 16:18         ` [Qemu-devel] " Alexander Duyck
2016-06-06  9:18         ` Zhou Jie
2016-06-06  9:18           ` Zhou Jie
2016-06-06 16:04           ` Alex Duyck
2016-06-06 16:04             ` Alex Duyck
2016-06-09 10:14             ` Zhou Jie
2016-06-09 15:39               ` Alexander Duyck
2016-06-12  3:03                 ` Zhou Jie
2016-06-13  1:28                   ` Alexander Duyck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566E2917.7050705@gmail.com \
    --to=yang.zhang.wz@gmail.com \
    --cc=aduyck@mirantis.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=alexander.duyck@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tianyu.lan@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.