On 10/22/2019 9:05 PM, Jason Wang wrote:
On 2019/10/22 下午2:53, Zhu Lingshan wrote:
On 10/21/2019 6:19 PM, Jason Wang wrote:
On 2019/10/21 下午5:53, Zhu, Lingshan wrote:
On 10/16/2019 6:19 PM, Jason Wang wrote:
On 2019/10/16 上午9:30, Zhu Lingshan wrote:
This commit introduced IFC VF operations for vdpa, which complys to
vhost_mdev interfaces, handles IFC VF initialization,
configuration and removal.
Signed-off-by: Zhu Lingshan <lingshan.zhu@xxxxxxxxx>
---
[...]
+}
+
+static int ifcvf_mdev_set_features(struct mdev_device *mdev, u64
features)
+{
+ struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+ struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+ vf->req_features = features;
+
+ return 0;
+}
+
+static u64 ifcvf_mdev_get_vq_state(struct mdev_device *mdev, u16
qid)
+{
+ struct ifcvf_adapter *adapter = mdev_get_drvdata(mdev);
+ struct ifcvf_hw *vf = IFC_PRIVATE_TO_VF(adapter);
+
+ return vf->vring[qid].last_avail_idx;
Does this really work? I'd expect it should be fetched from hw
since it's an internal state.
for now, it's working, we intend to support LM in next version
drivers.
I'm not sure I understand here, I don't see any synchronization
between the hardware and last_avail_idx, so last_avail_idx should
not change.
Btw, what did "LM" mean :) ?
I can add bar IO operations here, LM = live migration, sorry for the
abbreviation.
Just make sure I understand here, I believe you mean reading
last_avail_idx through IO bar here?
Thanks
Hi Jason,
Yes, I mean last_avail_idx. is that correct?
THanks
