On 5/6/25 1:55 AM, 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.
Virtio devices are not the only one who will need to be extended to
support such a scenario.
What happens when a disk or network card is added to the machine?
Should it be shared?
Should it be mapped only for one cpu address space?
Should address spaces be mixed or independent?
Per cluster, per cpu, per architure?
Having a concrete prototype will allow us to answer to those questions,
and many others, and find solutions for the situations we meet.
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.
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.
An important mantra will be to keep that compatible with existing
command line (potentially extending it to support those new use cases,
in both the existing *and* the new binary).
The last thing we want to introduce is "yet another QEMU".
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.
