Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1291364

Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest

Path csiph.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!bofh.it!news.nic.it!robomod
From "Michael S. Tsirkin" <mst@redhat.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for DMA by VM guest
Date Mon, 14 Dec 2015 18:30:01 +0100
Message-ID <qFF6F-He-1@gated-at.bofh.it> (permalink)
References <qFmno-5fC-3@gated-at.bofh.it> <qFmnn-5fC-1@gated-at.bofh.it> <qFBZ8-7d6-17@gated-at.bofh.it> <qFEki-9n-17@gated-at.bofh.it>
X-Original-To Alexander Duyck <alexander.duyck@gmail.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
X-Scanned-By MIMEDefang 2.68 on 10.5.11.23
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 72
Organization linux.* mail to news gateway
X-Original-Cc Alexander Duyck <aduyck@mirantis.com>, kvm@vger.kernel.org, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, x86@kernel.org, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, qemu-devel@nongnu.org, Lan Tianyu <tianyu.lan@intel.com>, Yang Zhang <yang.zhang.wz@gmail.com>, konrad.wilk@oracle.com, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, Alexander Graf <agraf@suse.de>, Alex Williamson <alex.williamson@redhat.com>
X-Original-Date Mon, 14 Dec 2015 19:20:14 +0200
X-Original-Message-ID <20151214191303-mutt-send-email-mst@redhat.com>
X-Original-References <20151213212557.5410.48577.stgit@localhost.localdomain> <20151213212831.5410.84365.stgit@localhost.localdomain> <20151214113016-mutt-send-email-mst@redhat.com> <CAKgT0UdtY5stCPVA=-NoM+1C8Z3b+VXLL1OdrNth=dxvz0A9sQ@mail.gmail.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1291364

Show key headers only | View raw


On Mon, Dec 14, 2015 at 08:34:00AM -0800, Alexander Duyck wrote:
> > This way distro can use a guest agent to disable
> > dirtying until before migration starts.
> 
> Right.  For a v2 version I would definitely want to have some way to
> limit the scope of this.  My main reason for putting this out here is
> to start altering the course of discussions since it seems like were
> weren't getting anywhere with the ixgbevf migration changes that were
> being proposed.

Absolutely, thanks for working on this.

> >> +     unsigned long pg_addr, start;
> >> +
> >> +     start = (unsigned long)addr;
> >> +     pg_addr = PAGE_ALIGN(start + size);
> >> +     start &= ~(sizeof(atomic_t) - 1);
> >> +
> >> +     /* trigger a write fault on each page, excluding first page */
> >> +     while ((pg_addr -= PAGE_SIZE) > start)
> >> +             atomic_add(0, (atomic_t *)pg_addr);
> >> +
> >> +     /* trigger a write fault on first word of DMA */
> >> +     atomic_add(0, (atomic_t *)start);
> >
> > start might not be aligned correctly for a cast to atomic_t.
> > It's harmless to do this for any memory, so I think you should
> > just do this for 1st byte of all pages including the first one.
> 
> You may not have noticed it but I actually aligned start in the line
> after pg_addr.

Yes you did. alignof would make it a bit more noticeable.

>  However instead of aligning to the start of the next
> atomic_t I just masked off the lower bits so that we start at the
> DWORD that contains the first byte of the starting address.  The
> assumption here is that I cannot trigger any sort of fault since if I
> have access to a given byte within a DWORD I will have access to the
> entire DWORD.

I'm curious where does this come from.  Isn't it true that access is
controlled at page granularity normally, so you can touch beginning of
page just as well?

>  I coded this up so that the spots where we touch the
> memory should match up with addresses provided by the hardware to
> perform the DMA over the PCI bus.

Yes but there's no requirement to do it like this from
virt POV. You just need to touch each page.

> Also I intentionally ran from highest address to lowest since that way
> we don't risk pushing the first cache line of the DMA buffer out of
> the L1 cache due to the PAGE_SIZE stride.
> 
> - Alex

Interesting. How does order of access help with this?

By the way, if you are into these micro-optimizations you might want to
limit prefetch, to this end you want to access the last line of the
page.  And it's probably worth benchmarking a bit and not doing it all just
based on theory, keep code simple in v1 otherwise.

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used for  DMA by VM guest Alexander Duyck <aduyck@mirantis.com> - 2015-12-13 22:30 +0100
  Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-14 15:10 +0100
    Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest Alexander Duyck <alexander.duyck@gmail.com> - 2015-12-14 17:40 +0100
      Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-14 18:30 +0100
        Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest Alexander Duyck <alexander.duyck@gmail.com> - 2015-12-14 19:00 +0100
          Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest "Michael S. Tsirkin" <mst@redhat.com> - 2015-12-14 22:00 +0100
            Re: [RFC PATCH 3/3] x86: Create dma_mark_dirty to dirty pages used  for DMA by VM guest Alexander Duyck <alexander.duyck@gmail.com> - 2015-12-14 23:40 +0100

csiph-web