On 07.04.25 11:11, David Hildenbrand wrote:
On 07.04.25 10:58, Michael S. Tsirkin wrote:
On Mon, Apr 07, 2025 at 10:54:00AM +0200, David Hildenbrand wrote:
On 07.04.25 10:49, Michael S. Tsirkin wrote:
On Mon, Apr 07, 2025 at 10:44:21AM +0200, David Hildenbrand wrote:
> Whoever adds new feat_X *must be aware* about all previous features, > otherwise we'd be reusing feature bits and everything falls to pieces.
The knowledge is supposed be limited to which feature bit to use.
I think we also have to know which virtqueue bits can be used, right?
what are virtqueue bits? vq number?
Yes, sorry.
I got confused myself, it's vq index actually now, we made the spec consistent with that terminology. used to be number/index interchangeably.
Assume cross-vm as an example. It would make use of virtqueue indexes 5+6 with their VIRTIO_BALLOON_F_WS_REPORTING.
crossvm guys really should have reserved the feature bit even if they did not bother specifying it. Let's reserve it now at least?
Along with the virtqueue indices, right?
Note that there was
https://lists.gnu.org/archive/html/qemu-devel/2023-05/msg02503.html
and
https://groups.oasis-open.org/communities/community-home/digestviewer/viewth...
But it only was RFC, and as the QEMU implementation didn't materialize, nobody seemed to care ...
Heh, but that one said:
+\item[ VIRTIO_BALLOON_F_WS_REPORTING(6) ] The device has support for Working Set
Which does not seem to reflect reality ...