On Thu, Nov 02, 2023 at 02:00:46PM +0200, Yuri Benditovich wrote: > > > On Thu, Nov 2, 2023 at 1:26 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > On Thu, Nov 02, 2023 at 12:20:39PM +0200, Yuri Benditovich wrote: > > > > > > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin <m...@redhat.com> > wrote: > > > > On Thu, Nov 02, 2023 at 11:09:27AM +0200, Yuri Benditovich wrote: > > > Probably we mix two different patches in this discussion. > > > Focusing on the patch in the e-mail header: > > > > > > IMO it is not acceptable to fail QEMU run for one feature that we > can't > > make > > > active when we silently drop all other features in such a case. > > > > If the feature is off by default then it seems more reasonable > > and silent masking can be seen as a bug. > > Most virtio features are on by default this is why it's > > reasonable to mask them. > > > > > > > > If we are talking about RSS: setting it initially off is the development > time > > decision. > > When it will be completely stable there is no reason to keep it off by > default, > > so this is more a question of time and of a readiness of libvirt. > > Well when we flip the default we'll need compat machinery for sure ;) > > > Of course, on the flip or default we'll need to keep compatibility to earlier > machine types. > But, because in the perspective it makes sense to make the RSS is on by > default, I do not think we need _now_ to make qemu fail to start if the ebpf > can't be loaded. >
Generally if user asks for something and we can't do it, we must fail. If we can't apply a default we need a better default. qemu has a bug in that it can't generally distinguish between default set automatically and same default given on command line. -- MST
