-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
virtio.h: add some user-friendly apis #622
base: main
Are you sure you want to change the base?
Conversation
CV-Bowen
commented
Oct 8, 2024
•
edited
Loading
edited
- virtio.h: add new api virtio_has_feature()
- virtio.h: add new feature bit VIRTIO_F_ANY_LAYOUT
0d9c1ce
to
c1646fb
Compare
217ee1d
to
56c5db1
Compare
@arnopo Hi, I meet a CI issue: #define virtio_read_config_member(vdev, structname, member, _ptr) \
virtio_read_config((vdev), metal_offset_of(structname, member), \
_ptr, sizeof(*(_ptr))) This code reports |
return false; | ||
|
||
return (vdev->features & (1UL << feature_bit)) != 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function return valid value only if virtio_negotiate_features has been called first . That also means that it does not work for virtio device role.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I consider assign back the final features to vdev->features
when call virtio_get_feature()
for VIRTIO_DEVICE side, so VIRTIO_DEVICE can use this virtio_has_feature()
after called virtio_get_feature()
. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, @arnopo Could you review again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I consider assign back the final features to
vdev->features
when callvirtio_get_feature()
for VIRTIO_DEVICE side, so VIRTIO_DEVICE can use thisvirtio_has_feature()
after calledvirtio_get_feature()
. What do you think?
This does not prevent the use case where virtio_has_feature
is called before virtio_get_features
.
to be safe virtio_has_feature
should call virtio_get_features
if vdev->features == NULL
60c1fc3
to
3cb3e9c
Compare
Follow the virtio spec, this feature bit indicates that the device accepts arbitrary descriptor layouts. Signed-off-by: Bowen Wang <[email protected]>
virtio_has_feature() can be easily used to heck if the virtio device support a specific feature. And assgin feature to vdev->feature for virtio device role when get features, so the virtio device side can use virtio_has_featrue() to check weather the virtio device support a feature. Signed-off-by: Bowen Wang <[email protected]>
3cb3e9c
to
d4c0152
Compare
return false; | ||
|
||
return (vdev->features & (1UL << feature_bit)) != 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I consider assign back the final features to
vdev->features
when callvirtio_get_feature()
for VIRTIO_DEVICE side, so VIRTIO_DEVICE can use thisvirtio_has_feature()
after calledvirtio_get_feature()
. What do you think?
This does not prevent the use case where virtio_has_feature
is called before virtio_get_features
.
to be safe virtio_has_feature
should call virtio_get_features
if vdev->features == NULL