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 10:55:34AM +0200, Philippe Mathieu-Daudé wrote:
> On 6/5/25 10:12, Michael S. Tsirkin wrote:
> > 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.
> 
> This isn't for the single binary effort, there we are taking a
> lot of care to not introduce any change.
> 
> This is for after it; once we have a single binary (one architecture
> run by an instance) we can start testing heterogeneous emulation
> (different architectures in the same instance).
> 
> > > I don't see a compelling
> > > technical reason why we can't support virtio 0.9 from this
> > > endian point.
> 
> VirtIO 0.9 needs knowledge of the vCPU architecture to get its
> endianness. So we need to somehow propagate that at creation
> time, guarantying which vCPU (or set of vCPUs) will access a
> virtio device.
> 
> The use case I'd like to figure out is how should we model
> plugging a virtio 0.9 device in into a fully emulated
> ZynqMP machine, which has little-endian ARM cores and big
> endian MicroBlaze cores.
> 
> Alex said this is unlikely to happen, and better is to
> ignore this case by not allowing virtio pre-1.0 devices in
> our future heterogeneous emulator.

Indeed. I just do not think this can be done with a kconfig knob,
it's a machine property.

> In this same thread Pierrick pointed me to the reference in
> the spec: '2.4.3 Legacy Interfaces: A Note on Virtqueue Endianness',
> "It is assumed that the host is already aware of the guest endian."
> 
> I suppose this means a pre-1.0 virtio device expect to be used by
> a single guest OS, but it is not clear the guest OS as fixed
> endianness, because the code path checks vCPU endianness at
> runtime, so passing guest endianness as a property to pre-1.0
> devices isn't really an option.
> 
> Anyway I think 1/ I posted this too early, "speculating" as Pierrick
> noticed, and confuse the community w.r.t. "single binary" and
> 2/ I don' t understand legacy virtio and its endianness handling
> enough to figure a clever idea to keep using it heterogeneous
> setup, so I'll let this task to someone more familiar with that tech.
> 
> > > 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.
> 
> > 
> > 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.
> > 
> 
> OK. I won't pursue in this direction. I apologize for mentioning
> this topic again too early.
> 
> Regards,
> 
> Phil.