Re: [RFC PATCH] hw/virtio: Introduce CONFIG_VIRTIO_LEGACY to disable legacy support

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, May 06, 2025 at 09:04:50AM +0100, Daniel P. Berrangé wrote:
> On Fri, May 02, 2025 at 03:24:41PM +0200, Philippe Mathieu-Daudé wrote:
> > Legacy VirtIO devices don't have their endianness clearly defined.
> > QEMU infers it taking the endianness of the (target) binary, or,
> > when a target support switching endianness at runtime, taking the
> > endianness of the vCPU accessing the device.
> > 
> > Devices modelling shouldn't really change depending on a property
> > of a CPU accessing it.
> > 
> > For heterogeneous systems, it is simpler to break such dev <-> cpu
> > dependency, only allowing generic device models, with no knowledge
> > of CPU (or DMA controller) accesses.
> > 
> > Therefore we introduce the VIRTIO_LEGACY Kconfig key. We keep the
> > current default (enabled).
> > New binaries can set CONFIG_VIRTIO_LEGACY=n to restrict models to
> > the VirtIO version 1 spec.
> 
> IMHO that isn't acceptable. In order to be able to provide an
> upgrade path from the old binaries, we need the need the new
> binaries to be able to serve the same use cases & disabling
> virtio 0.9 support prevents that. I don't see a compelling
> technical reason why we can't support virtio 0.9 from this
> endian point.
> 
> Yes may be more ugly/messy than we would like, but that's par
> for the course with QEMU emulating arbitrary device models.
> If the new binaries can't cope with messy devices then I think
> we are doing something wrong.
> 
> With regards,
> Daniel


To be more specific, having a kconfig knob modifying the device
without regards for machine types, means it is no longer
enough to inspect the command line to figure out the
compatiblity. That's a problem.

-- 
MST