Re: Is QEMU's vmxnet3 still being used?

From: Markus Armbruster <armbru@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
	Dmitry Fleytman <dmitry.fleytman@gmail.com>,
	Yuri Benditovich <yuri.benditovich@daynix.com>,
	Jason Wang <jasowang@redhat.com>,
	Leonid Bloch <leonid@daynix.com>,
	Andrew Melnychenko <andrew@daynix.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Alexander Bulekov <alxndr@bu.edu>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: Is QEMU's vmxnet3 still being used?
Date: Tue, 24 Aug 2021 08:14:25 +0200	[thread overview]
Message-ID: <87h7ffpdxa.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <YR4b9J7jlfrd84BK@redhat.com> ("Daniel P. =?utf-8?Q?Berrang?= =?utf-8?Q?=C3=A9=22's?= message of "Thu, 19 Aug 2021 09:53:08 +0100")

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Aug 18, 2021 at 03:42:23PM +0200, Thomas Huth wrote:
>> 
>>  Hi all,
>> 
>> I recently noticed that we have quite a bunch of tickets against the vmxnet3
>> device in our bug trackers, which indicate that this device could be used to
>> crash QEMU in various ways:
>> 
>>  https://gitlab.com/qemu-project/qemu/-/issues?state=opened&search=vmxnet3
>> 
>>  https://bugs.launchpad.net/qemu?field.searchtext=vmxnet3
>
> IIUC, all except 3 of those bugs, are issues from the device fuzzer.
>
> It is nice that we find those, but if we don't consider this a device
> targetted at virtualization use cases, I don't think they're a reason
> to remove the device.
>
>> Having hardly any knowledge about this device and its usage at all, I wonder
>> how much it is still used out there in the wild? If there are still many
>> users of this device, is there anybody interested here in helping to get
>> these crashes fixed in the near future? Otherwise, should we maybe rather
>> mark this device as deprecated and remove it in a couple of releases? What
>> do you think?
>
> We've got countless NIC models in QEMU most of which have minimal users,
> are possibly buggy, not actively maintained, but exist to support
> non-virtualization use cases. We've especially not had "how many users
> are there" as a criteria for acceptance or removal of a device.

I accept "good enough for intended use", and that certain kinds of bugs
are much less serious in emulation use than in virtualization use.

Still, there's a difference between "possibly buggy" and "perennially
unmaintained / can't even be bothered to fix known bugs".  Why should we
carry code that isn't of sufficient interest to anyone to motivate basic
care?

Moreover, having drastically different code quality requirements in the
tree is problematic.  Compounded by them being less than obvious.  If
people knew nobody cared for bugs in hw/mumble/mutter.c, they could save
themselves the trouble of fuzzing or otherwise examining it.  They might
even be dissuaded from copying (quite possibly bad) code from it.

I do believe the way we operate promotes misallocation of (scarce)
resources.