From: Yuval Shaia <yuval.shaia@oracle.com>
To: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
stefanha@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 1/1] hw/pvrdma: Add live migration support
Date: Mon, 1 Jul 2019 15:08:36 +0300 [thread overview]
Message-ID: <20190701120835.GA8626@lap1> (raw)
In-Reply-To: <CAMzgYoML=BR4GnLYs_+cRzn__Rqytu5pnbDn-YhqByPn_X7v-w@mail.gmail.com>
> > >
> > > @Marcel, @Yuval: As David has suggested, what if we just read the dma
> > > addresses in pvrdma_load(), and let the load_dsr() do the mapping?
> > > In pvrdma_regs_write(), we can check if dev->dsr_info.dma is already set, so
> > > that its value is not overwritten.
> >
> > Have you tried that? Did it works?
>
> I haven't tried it, but in the dest, the guest will not call pvrdma_regs_write()
> for DSR again as it calls it only when the guest driver probes pci.
> load_dsr() will not be called then.
> So, I guess my assumption was wrong.
To clarify. The guest is not "calling" pvrdma_regs_write() directly, it
writes into a register and this triggers the function.
So my thinking was that you meant to hook into *any* such register-write
and call "load_dsr" indirectly, i.e. to simulate a guest writing into DSR
register.
This might work and it is nice idea, just wondering whether you actually
give that a try.
>
> > So it is like a lazy load and the first command will be bit slower, we can
> > live with that i guess.
That is way i called it "lazy load".
> >
next prev parent reply other threads:[~2019-07-01 12:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 14:45 [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device Sukrit Bhatnagar
2019-06-21 14:45 ` [Qemu-devel] [RFC 1/1] hw/pvrdma: Add live migration support Sukrit Bhatnagar
2019-06-25 15:32 ` Yuval Shaia
2019-06-28 11:26 ` Dr. David Alan Gilbert
2019-06-29 12:45 ` Sukrit Bhatnagar
2019-06-30 8:13 ` Yuval Shaia
2019-07-01 2:15 ` Sukrit Bhatnagar
2019-07-01 12:08 ` Yuval Shaia [this message]
2019-07-08 10:54 ` Dr. David Alan Gilbert
2019-06-25 15:38 ` Yuval Shaia
2019-06-21 17:55 ` [Qemu-devel] [RFC 0/1] Add live migration support to the PVRDMA device no-reply
2019-06-25 8:14 ` Marcel Apfelbaum
2019-06-25 8:39 ` Dmitry Fleytman
2019-06-25 8:49 ` Marcel Apfelbaum
2019-06-25 9:11 ` Dr. David Alan Gilbert
2019-06-25 11:39 ` Marcel Apfelbaum
2019-06-25 10:25 ` Dmitry Fleytman
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=20190701120835.GA8626@lap1 \
--to=yuval.shaia@oracle.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=skrtbhtngr@gmail.com \
--cc=stefanha@redhat.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.