From: Cornelia Huck <cohuck@redhat.com>
To: Kirti Wankhede <kwankhede@nvidia.com>
Cc: kevin.tian@intel.com, yi.l.liu@intel.com, cjia@nvidia.com,
kvm@vger.kernel.org, eskultet@redhat.com, ziye.yang@intel.com,
qemu-devel@nongnu.org, Zhengxiao.zx@Alibaba-inc.com,
shuangtai.tst@alibaba-inc.com, dgilbert@redhat.com,
zhi.a.wang@intel.com, mlevitsk@redhat.com, pasic@linux.ibm.com,
aik@ozlabs.ru, alex.williamson@redhat.com, eauger@redhat.com,
felipe@nutanix.com, jonathan.davies@nutanix.com,
yan.y.zhao@intel.com, changpeng.liu@intel.com, Ken.Xue@amd.com
Subject: Re: [PATCH v12 Kernel 1/7] vfio: KABI for migration interface for device state
Date: Fri, 14 Feb 2020 11:21:00 +0100 [thread overview]
Message-ID: <20200214112100.4e73722b.cohuck@redhat.com> (raw)
In-Reply-To: <1581104554-10704-2-git-send-email-kwankhede@nvidia.com>
On Sat, 8 Feb 2020 01:12:28 +0530
Kirti Wankhede <kwankhede@nvidia.com> wrote:
(...)
Minor wording nits:
> +/*
> + * Structure vfio_device_migration_info is placed at 0th offset of
"...at the 0th offset..."
> + * VFIO_REGION_SUBTYPE_MIGRATION region to get/set VFIO device related migration
> + * information. Field accesses from this structure are only supported at their
> + * native width and alignment, otherwise the result is undefined and vendor
> + * drivers should return an error.
> + *
> + * device_state: (read/write)
> + * - User application writes this field to inform vendor driver about the
I'd probably add a definitive article before "user application",
"vendor driver", etc. Not sure if it's too much churn.
> + * device state to be transitioned to.
> + * - Vendor driver should take necessary actions to change device state.
> + * On successful transition to given state, vendor driver should return
> + * success on write(device_state, state) system call. If device state
> + * transition fails, vendor driver should return error, -EFAULT.
> + * - On user application side, if device state transition fails, i.e. if
> + * write(device_state, state) returns error, read device_state again to
> + * determine the current state of the device from vendor driver.
> + * - Vendor driver should return previous state of the device unless vendor
> + * driver has encountered an internal error, in which case vendor driver
> + * may report the device_state VFIO_DEVICE_STATE_ERROR.
> + * - User application must use the device reset ioctl in order to recover
> + * the device from VFIO_DEVICE_STATE_ERROR state. If the device is
> + * indicated in a valid device state via reading device_state, the user
> + * application may decide attempt to transition the device to any valid
> + * state reachable from the current state or terminate itself.
> + *
> + * device_state consists of 3 bits:
> + * - If bit 0 set, indicates _RUNNING state. When it's clear, that
> + * indicates _STOP state. When device is changed to _STOP, driver should
> + * stop device before write() returns.
"If set, bit 0 indicates _RUNNING state. If unset, it indicates _STOP
state. When the device is changed to _STOP state, the driver should
stop the device before write() returns."
?
> + * - If bit 1 set, indicates _SAVING state. When set, that indicates driver
> + * should start gathering device state information which will be provided
> + * to VFIO user application to save device's state.
"If set, bit 1 indicates _SAVING state. When it is set, the driver
should start to gather the device state information that will be
provided to the VFIO user application to save the device's state."
?
> + * - If bit 2 set, indicates _RESUMING state. When set, that indicates
> + * prepare to resume device, data provided through migration region
> + * should be used to resume device.
"If set, bit 2 indicates _RESUMING state. When it is set, the driver
should prepare to resume the device, using the data provided via the
migration region."
?
> + * Bits 3 - 31 are reserved for future use. In order to preserve them,
> + * user application should perform read-modify-write operation on this
> + * field when modifying the specified bits.
"In order to preserve them, the user application should use a
read-modify-write operation on the device_state field when modifying
the state."
?
(...)
next prev parent reply other threads:[~2020-02-14 10:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 19:42 [PATCH v12 Kernel 0/7] KABIs to support migration for VFIO devices Kirti Wankhede
2020-02-07 19:42 ` [PATCH v12 Kernel 1/7] vfio: KABI for migration interface for device state Kirti Wankhede
2020-02-10 17:25 ` Alex Williamson
2020-02-12 20:56 ` Kirti Wankhede
2020-02-14 10:21 ` Cornelia Huck [this message]
2020-02-27 8:58 ` Yan Zhao
2020-02-07 19:42 ` [PATCH v12 Kernel 2/7] vfio iommu: Remove atomicity of ref_count of pinned pages Kirti Wankhede
2020-02-07 19:42 ` [PATCH v12 Kernel 3/7] vfio iommu: Add ioctl definition for dirty pages tracking Kirti Wankhede
2020-02-07 19:42 ` [PATCH v12 Kernel 4/7] vfio iommu: Implementation of ioctl to " Kirti Wankhede
2020-02-10 9:49 ` Yan Zhao
2020-02-10 19:44 ` Alex Williamson
2020-02-11 2:52 ` Yan Zhao
2020-02-11 3:45 ` Alex Williamson
2020-02-11 4:11 ` Yan Zhao
2020-02-10 17:25 ` Alex Williamson
2020-02-12 20:56 ` Kirti Wankhede
2020-02-12 23:13 ` Alex Williamson
2020-02-13 20:11 ` Kirti Wankhede
2020-02-13 23:20 ` Alex Williamson
2020-02-17 19:13 ` Kirti Wankhede
2020-02-17 20:55 ` Alex Williamson
2020-02-18 5:58 ` Kirti Wankhede
2020-02-18 21:41 ` Alex Williamson
2020-02-19 4:21 ` Kirti Wankhede
2020-02-19 4:53 ` Alex Williamson
2020-02-07 19:42 ` [PATCH v12 Kernel 5/7] vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap Kirti Wankhede
2020-02-10 17:48 ` Alex Williamson
2020-02-07 19:42 ` [PATCH v12 Kernel 6/7] vfio iommu: Adds flag to indicate dirty pages tracking capability support Kirti Wankhede
2020-02-07 19:42 ` [PATCH v12 Kernel 7/7] vfio: Selective dirty page tracking if IOMMU backed device pins pages Kirti Wankhede
2020-02-10 18:14 ` Alex Williamson
2020-03-09 7:46 ` [PATCH v12 Kernel 0/7] KABIs to support migration for VFIO devices Zengtao (B)
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=20200214112100.4e73722b.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=Ken.Xue@amd.com \
--cc=Zhengxiao.zx@Alibaba-inc.com \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=changpeng.liu@intel.com \
--cc=cjia@nvidia.com \
--cc=dgilbert@redhat.com \
--cc=eauger@redhat.com \
--cc=eskultet@redhat.com \
--cc=felipe@nutanix.com \
--cc=jonathan.davies@nutanix.com \
--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=yan.y.zhao@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).