All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Sukrit Bhatnagar <skrtbhtngr@gmail.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [GSoC] Help needed in implementing live migration
Date: Fri, 28 Jun 2019 12:18:37 +0100	[thread overview]
Message-ID: <20190628111837.GA2987@work-vm> (raw)
In-Reply-To: <20190628093828.GD3316@stefanha-x1.localdomain>

* Stefan Hajnoczi (stefanha@gmail.com) wrote:
> On Thu, Jun 27, 2019 at 05:02:33AM +0530, Sukrit Bhatnagar wrote:
> > On Tue, 25 Jun 2019 at 00:11, Dr. David Alan Gilbert
> > <dgilbert@redhat.com> wrote:
> > >
> > > * Sukrit Bhatnagar (skrtbhtngr@gmail.com) wrote:
> > > > Hi David,
> > > >
> > > > I am Sukrit, GSoC participant working on PVRDMA live migration.
> > > > We had a short chat about vmxnet3 migration about a week ago
> > > > on the IRC channel.
> > > >
> > > > I am facing an issue while doing migration of the pvrdma device.
> > > > While loading the device state, we need to perform a few dma
> > > > mappings on the destination. But on the destination, the migration
> > > > fails due a BounceBuffer being locked (in_use). This global
> > > > BounceBuffer is used in address_space_map/unmap functions
> > > > which the rdma_pci_dma_map/unmap calls.
> > > > Essentially, we need a way to remap guest physical address on
> > > > the destination after migration.
> > > >
> > > > I had posted an RFC a while ago on the list:
> > > > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04924.html
> > > > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg04923.html
> > > >
> > > > My mentors (Marcel and Yuval) told me to ask you for help
> > > > regarding this. It would be really great if you can guide me in
> > > > finding a workaround for this.
> > >
> > > Hi,
> > >   I'll have a look; I need to get some other things finished first.
> > 
> > Adding cc: qemu-devel, sorry for the private email.
> 
> I haven't looked deeply but it's surprising that you're hitting
> BounceBuffer.  My understanding is that's an old mechanism for
> supporting exotic things like DMAing to/from device MMIO registers.
> 
> Modern machines and guest software usually don't do this.  I wonder why
> you're hitting this case.
> 
> If you look at the BounceBuffer code there's an API to register a
> callback (cpu_register_map_client()).  That's how the case of multiple
> BounceBuffers is supposed to be handled.
> 
> Can you double-check your code and figure out how it got here?  I don't
> think it should be taking this path.

Looking at address_space_map I see it uses bounce buffers if
!memory_access_is_direct, and that seems to be a check to see if
the memory region is actually a normal block of RAM.

Dave

> Stefan


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


      reply	other threads:[~2019-06-28 12:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAMzgYoMG1ic-5yiS2ehnDLna+UKgCtMBcSVNmKQx1oxRZqT=yQ@mail.gmail.com>
     [not found] ` <20190624184133.GW2726@work-vm>
2019-06-26 23:32   ` [Qemu-devel] [GSoC] Help needed in implementing live migration Sukrit Bhatnagar
2019-06-28  9:38     ` Stefan Hajnoczi
2019-06-28 11:18       ` Dr. David Alan Gilbert [this message]

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=20190628111837.GA2987@work-vm \
    --to=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=skrtbhtngr@gmail.com \
    --cc=stefanha@gmail.com \
    /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.