From: Zhao Yan <yan.y.zhao@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "cjia@nvidia.com" <cjia@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"aik@ozlabs.ru" <aik@ozlabs.ru>,
"Zhengxiao.zx@Alibaba-inc.com" <Zhengxiao.zx@Alibaba-inc.com>,
"shuangtai.tst@alibaba-inc.com" <shuangtai.tst@alibaba-inc.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"kwankhede@nvidia.com" <kwankhede@nvidia.com>,
"eauger@redhat.com" <eauger@redhat.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"eskultet@redhat.com" <eskultet@redhat.com>,
"Yang, Ziye" <ziye.yang@intel.com>,
"mlevitsk@redhat.com" <mlevitsk@redhat.com>,
"pasic@linux.ibm.com" <pasic@linux.ibm.com>,
"arei.gonglei@huawei.com" <arei.gonglei@huawei.com>,
"felipe@nutanix.com" <felipe@nutanix.com>,
"Wang, Zhi A" <zhi.a.wang@intel.com>,
"Tian, Kevin" <kevin.tian@intel.com>,
"dgilbert@redhat.com" <dgilbert@redhat.com>,
"intel-gvt-dev@lists.freedesktop.org"
<intel-gvt-dev@lists.freedesktop.org>, "
Subject: Re: [PATCH 0/5] QEMU VFIO live migration
Date: Tue, 12 Mar 2019 21:13:01 -0400 [thread overview]
Message-ID: <20190313011301.GA16072@joy-OptiPlex-7040> (raw)
In-Reply-To: <20190312025747.GI21353@joy-OptiPlex-7040>
hi Alex
Any comments to the sequence below?
Actaully we have some concerns and suggestions to userspace-opaque migration
data.
1. if data is opaque to userspace, kernel interface must be tightly bound to
migration.
e.g. vendor driver has to know state (running + not logging) should not
return any data, and state (running + logging) should return whole
snapshot first and dirty later. it also has to know qemu migration will
not call GET_BUFFER in state (running + not logging), otherwise, it has
to adjust its behavior.
2. vendor driver cannot ensure userspace get all the data it intends to
save in pre-copy phase.
e.g. in stop-and-copy phase, vendor driver has to first check and send
data in previous phase.
3. if all the sequence is tightly bound to live migration, can we remove the
logging state? what about adding two states migrate-in and migrate-out?
so there are four states: running, stopped, migrate-in, migrate-out.
migrate-out is for source side when migration starts. together with
state running and stopped, it can substitute state logging.
migrate-in is for target side.
Thanks
Yan
On Tue, Mar 12, 2019 at 10:57:47AM +0800, Zhao Yan wrote:
> hi Alex
> thanks for your reply.
>
> So, if we choose migration data to be userspace opaque, do you think below
> sequence is the right behavior for vendor driver to follow:
>
> 1. initially LOGGING state is not set. If userspace calls GET_BUFFER to
> vendor driver, vendor driver should reject and return 0.
>
> 2. then LOGGING state is set, if userspace calls GET_BUFFER to vendor
> driver,
> a. vendor driver shoud first query a whole snapshot of device memory
> (let's use this term to represent device's standalone memory for now),
> b. vendor driver returns a chunk of data just queried to userspace,
> while recording current pos in data.
> c. vendor driver finds all data just queried is finished transmitting to
> userspace, and queries only dirty data in device memory now.
> d. vendor driver returns a chunk of data just quered (this time is dirty
> data )to userspace while recording current pos in data
> e. if all data is transmited to usespace and still GET_BUFFERs come from
> userspace, vendor driver starts another round of dirty data query.
>
> 3. if LOGGING state is unset then, and userpace calls GET_BUFFER to vendor
> driver,
> a. if vendor driver finds there's previously untransmitted data, returns
> them until all transmitted.
> b. vendor driver then queries dirty data again and transmits them.
> c. at last, vendor driver queris device config data (which has to be
> queried at last and sent once) and transmits them.
>
>
> for the 1 bullet, if LOGGING state is firstly set and migration aborts
> then, vendor driver has to be able to detect that condition. so seemingly,
> vendor driver has to know more qemu's migration state, like migration
> called and failed. Do you think that's acceptable?
>
>
> Thanks
> Yan
>
>
next prev parent reply other threads:[~2019-03-13 1:13 UTC|newest]
Thread overview: 133+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 8:50 [PATCH 0/5] QEMU VFIO live migration Yan Zhao
2019-02-19 8:50 ` [Qemu-devel] " Yan Zhao
2019-02-19 8:52 ` [PATCH 1/5] vfio/migration: define kernel interfaces Yan Zhao
2019-02-19 8:52 ` [Qemu-devel] " Yan Zhao
2019-02-19 13:09 ` Cornelia Huck
2019-02-19 13:09 ` [Qemu-devel] " Cornelia Huck
2019-02-20 7:36 ` Zhao Yan
2019-02-20 7:36 ` [Qemu-devel] " Zhao Yan
2019-02-20 17:08 ` Cornelia Huck
2019-02-20 17:08 ` [Qemu-devel] " Cornelia Huck
2019-02-21 1:47 ` Zhao Yan
2019-02-21 1:47 ` [Qemu-devel] " Zhao Yan
2019-02-19 8:52 ` [PATCH 2/5] vfio/migration: support device of device config capability Yan Zhao
2019-02-19 8:52 ` [Qemu-devel] " Yan Zhao
2019-02-19 11:01 ` Dr. David Alan Gilbert
2019-02-19 11:01 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-20 5:12 ` Zhao Yan
2019-02-20 5:12 ` [Qemu-devel] " Zhao Yan
2019-02-20 10:57 ` Dr. David Alan Gilbert
2019-02-20 10:57 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-19 14:37 ` Cornelia Huck
2019-02-19 14:37 ` [Qemu-devel] " Cornelia Huck
2019-02-20 22:54 ` Zhao Yan
2019-02-20 22:54 ` [Qemu-devel] " Zhao Yan
2019-02-21 10:56 ` Cornelia Huck
2019-02-21 10:56 ` [Qemu-devel] " Cornelia Huck
2019-02-19 8:52 ` [PATCH 3/5] vfio/migration: tracking of dirty page in system memory Yan Zhao
2019-02-19 8:52 ` [Qemu-devel] " Yan Zhao
2019-02-19 8:52 ` [PATCH 4/5] vfio/migration: turn on migration Yan Zhao
2019-02-19 8:52 ` [Qemu-devel] " Yan Zhao
2019-02-19 8:53 ` [PATCH 5/5] vfio/migration: support device memory capability Yan Zhao
2019-02-19 8:53 ` [Qemu-devel] " Yan Zhao
2019-02-19 11:25 ` Dr. David Alan Gilbert
2019-02-19 11:25 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-20 5:17 ` Zhao Yan
2019-02-20 5:17 ` [Qemu-devel] " Zhao Yan
2019-02-19 14:42 ` Christophe de Dinechin
2019-02-19 14:42 ` [Qemu-devel] " Christophe de Dinechin
2019-02-20 7:58 ` Zhao Yan
2019-02-20 7:58 ` [Qemu-devel] " Zhao Yan
2019-02-20 10:14 ` Christophe de Dinechin
2019-02-20 10:14 ` [Qemu-devel] " Christophe de Dinechin
2019-02-21 0:07 ` Zhao Yan
2019-02-21 0:07 ` [Qemu-devel] " Zhao Yan
2019-02-19 11:32 ` [PATCH 0/5] QEMU VFIO live migration Dr. David Alan Gilbert
2019-02-19 11:32 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-20 5:28 ` Zhao Yan
2019-02-20 5:28 ` [Qemu-devel] " Zhao Yan
2019-02-20 11:01 ` Dr. David Alan Gilbert
2019-02-20 11:01 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-20 11:28 ` Gonglei (Arei)
2019-02-20 11:28 ` [Qemu-devel] " Gonglei (Arei)
2019-02-20 11:42 ` Cornelia Huck
2019-02-20 11:42 ` [Qemu-devel] " Cornelia Huck
2019-02-20 12:07 ` Gonglei (Arei)
2019-02-20 12:07 ` [Qemu-devel] " Gonglei (Arei)
2019-03-27 6:35 ` Zhao Yan
2019-03-27 20:18 ` Dr. David Alan Gilbert
2019-03-27 22:10 ` Alex Williamson
2019-03-28 8:36 ` Zhao Yan
2019-03-28 9:21 ` Erik Skultety
2019-03-28 16:04 ` Alex Williamson
2019-03-29 2:47 ` Zhao Yan
2019-03-29 14:26 ` Alex Williamson
2019-03-29 23:10 ` Zhao Yan
2019-03-30 14:14 ` Alex Williamson
2019-04-01 2:17 ` Zhao Yan
2019-04-01 8:14 ` Cornelia Huck
2019-04-01 8:14 ` [Qemu-devel] " Cornelia Huck
2019-04-01 8:40 ` Yan Zhao
2019-04-01 8:40 ` [Qemu-devel] " Yan Zhao
2019-04-01 14:15 ` Alex Williamson
2019-04-01 14:15 ` [Qemu-devel] " Alex Williamson
2019-02-21 0:31 ` Zhao Yan
2019-02-21 0:31 ` [Qemu-devel] " Zhao Yan
2019-02-21 9:15 ` Dr. David Alan Gilbert
2019-02-21 9:15 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-02-20 11:56 ` Gonglei (Arei)
2019-02-20 11:56 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 0:24 ` Zhao Yan
2019-02-21 0:24 ` [Qemu-devel] " Zhao Yan
2019-02-21 1:35 ` Gonglei (Arei)
2019-02-21 1:35 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 1:58 ` Zhao Yan
2019-02-21 1:58 ` [Qemu-devel] " Zhao Yan
2019-02-21 3:33 ` Gonglei (Arei)
2019-02-21 3:33 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 4:08 ` Zhao Yan
2019-02-21 4:08 ` [Qemu-devel] " Zhao Yan
2019-02-21 5:46 ` Gonglei (Arei)
2019-02-21 5:46 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 2:04 ` Zhao Yan
2019-02-21 2:04 ` [Qemu-devel] " Zhao Yan
2019-02-21 3:16 ` Gonglei (Arei)
2019-02-21 3:16 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 4:21 ` Zhao Yan
2019-02-21 4:21 ` [Qemu-devel] " Zhao Yan
2019-02-21 5:56 ` Gonglei (Arei)
2019-02-21 5:56 ` [Qemu-devel] " Gonglei (Arei)
2019-02-21 20:40 ` Alex Williamson
2019-02-21 20:40 ` [Qemu-devel] " Alex Williamson
2019-02-25 2:22 ` Zhao Yan
2019-02-25 2:22 ` [Qemu-devel] " Zhao Yan
2019-03-06 0:22 ` Zhao Yan
2019-03-06 0:22 ` [Qemu-devel] " Zhao Yan
2019-03-07 17:44 ` Alex Williamson
2019-03-07 17:44 ` [Qemu-devel] " Alex Williamson
2019-03-07 23:20 ` Tian, Kevin
2019-03-07 23:20 ` [Qemu-devel] " Tian, Kevin
2019-03-08 16:11 ` Alex Williamson
2019-03-08 16:11 ` [Qemu-devel] " Alex Williamson
2019-03-08 16:21 ` Dr. David Alan Gilbert
2019-03-08 16:21 ` [Qemu-devel] " Dr. David Alan Gilbert
2019-03-08 22:02 ` Alex Williamson
2019-03-08 22:02 ` [Qemu-devel] " Alex Williamson
2019-03-11 2:33 ` Tian, Kevin
2019-03-11 2:33 ` [Qemu-devel] " Tian, Kevin
2019-03-11 20:19 ` Alex Williamson
2019-03-11 20:19 ` [Qemu-devel] " Alex Williamson
2019-03-12 2:48 ` Tian, Kevin
2019-03-12 2:48 ` [Qemu-devel] " Tian, Kevin
2019-03-13 19:57 ` Alex Williamson
2019-03-12 2:57 ` Zhao Yan
2019-03-12 2:57 ` [Qemu-devel] " Zhao Yan
2019-03-13 1:13 ` Zhao Yan [this message]
2019-03-13 19:14 ` Alex Williamson
2019-03-14 1:12 ` Zhao Yan
2019-03-14 22:44 ` Alex Williamson
2019-03-14 23:05 ` Zhao Yan
2019-03-15 2:24 ` Alex Williamson
2019-03-18 2:51 ` Zhao Yan
2019-03-18 3:09 ` Alex Williamson
2019-03-18 3:27 ` Zhao Yan
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=20190313011301.GA16072@joy-OptiPlex-7040 \
--to=yan.y.zhao@intel.com \
--cc=Zhengxiao.zx@Alibaba-inc.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=cjia@nvidia.com \
--cc=dgilbert@redhat.com \
--cc=eauger@redhat.com \
--cc=eskultet@redhat.com \
--cc=felipe@nutanix.com \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=mlevitsk@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=shuangtai.tst@alibaba-inc.com \
--cc=yi.l.liu@intel.com \
--cc=zhi.a.wang@intel.com \
--cc=ziye.yang@intel.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.