On Mon, 07 Apr 2025 15:28:13 +0200 Cornelia Huck cohuck@redhat.com wrote:
Staring at the cross-vmm, including the adding+removing of features and queues that are not in the spec, I am wondering if (in a world with fixed virtqueues)
Feature bits must be reserved before used.
Queue indices must be reserved before used.
It all smells like a problem similar to device IDs ...
Indeed, we need a rule "reserve a feature bit/queue index before using it, even if you do not plan to spec it properly".
What definition of usage do you guys have in mind? Would an RFC patch constitute usage.
I think reserving/allocating an identifier of this type before relying on it for anything remotely serious is very basic common sense.
Frankly I would go even further and advocate for the following rule: we don't accept anything virtio into Linux unless it is reasonably/properly spec-ed. My train of thought is following: if a virtio thing gains traction with Linux it has a fair chance of becoming a de-facto standard.
Consider our thinking on this one. Despite the fact that what is spec-ed is obviously nicer, we almost decided to change the spec to fit what is implemented and fielded out there. And IMHO for good reason. For any rule we come up with, I think one of the most crucial questions is, who is going to enforce it if anybody. The Linux (and probably also QEMU) virtio maintainers are in my opinion the most reasonable point of enforcement. Another thing to consider. After the code is in and things work, I speculate that the motivation for writing a proper spec may wane. I hope we do strive for consistency between the spec and the implementations we are talking about. Having and eye on the spec while looking at and trying to understand the code suits my workflow better at least than the other way around. And licensing-wise getting the spec merged first is probably the better option.
Regards, Halil