From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752431AbbLNEyM (ORCPT ); Sun, 13 Dec 2015 23:54:12 -0500 Received: from mail-io0-f180.google.com ([209.85.223.180]:35004 "EHLO mail-io0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752032AbbLNEyK (ORCPT ); Sun, 13 Dec 2015 23:54:10 -0500 MIME-Version: 1.0 In-Reply-To: <566E2917.7050705@gmail.com> References: <20151213212557.5410.48577.stgit@localhost.localdomain> <566E2917.7050705@gmail.com> Date: Sun, 13 Dec 2015 20:54:09 -0800 Message-ID: Subject: Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking From: Alexander Duyck To: Yang Zhang Cc: Alexander Duyck , kvm@vger.kernel.org, "linux-pci@vger.kernel.org" , x86@kernel.org, "linux-kernel@vger.kernel.org" , qemu-devel@nongnu.org, Lan Tianyu , "Michael S. Tsirkin" , konrad.wilk@oracle.com, "Dr. David Alan Gilbert" , Alexander Graf , Alex Williamson Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang wrote: > 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 guest has no way of currently knowing that the hypervisor is doing dirty page logging, and the log dirty mechanism currently has no way of tracking device DMA accesses. This change is meant to bridge the two so that the guest device driver will force the SWIOTLB DMA API to mark pages written to by the device as dirty. >> 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? Yes. For right now this only supports SWIOTLB. The assumption here is that SWIOTLB is in use for most cases where an IOMMU is not present. If an IOMMU is present in a virtualized guest then most likely the IOMMU might be able to provide a separate mechanism for dirty page tracking. - Alex