From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yang Zhang Subject: Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking Date: Mon, 14 Dec 2015 10:27:35 +0800 Message-ID: <566E2917.7050705@gmail.com> References: <20151213212557.5410.48577.stgit@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tianyu.lan@intel.com, konrad.wilk@oracle.com, mst@redhat.com, agraf@suse.de, dgilbert@redhat.com, alex.williamson@redhat.com To: Alexander Duyck , 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 Return-path: In-Reply-To: <20151213212557.5410.48577.stgit@localhost.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org 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