Re: [RFC PATCH 0/3] x86: Add support for guest DMA dirty page tracking

[Yang Zhang]

On 2015/12/14 12:54, Alexander Duyck wrote:
> On Sun, Dec 13, 2015 at 6:27 PM, Yang Zhang <yang.zhang.wz@xxxxxxxxx> 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.

OK. This is what we called "dummy write mechanism". Actually, this is 
just a workaround before iommu dirty bit ready. Eventually, we need to 
change to use the hardware dirty bit. Besides, we may still lost the 
data if dma happens during/just before stop and copy phase.

> > > 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


--
best regards
yang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/