Re: [RFC 2/2] vhost: IFC VF vdpa layer

From: Jason Wang
Date: Wed Oct 23 2019 - 02:39:39 EST



On 2019/10/23 äå2:19, Zhu, Lingshan wrote:

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


Yes.

Thanks