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

[Peter Maydell]

On Thu, 8 May 2025 at 09:37, Akihiko Odaki <akihiko.odaki@daynix.com> wrote:
>
> On 2025/05/06 17:55, Philippe Mathieu-Daudé wrote:
> > 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.

> It may not be too early as QEMU may already support heterogeneous
> endianness.
>
> An Arm CPU have a register to switch the endianness, which depends on
> the current Exception level, and QEMU already implements it at least
> enough to switch the endianness for virtio if I read the code correctly.
>
> This means QEMU should already be able to handle cases where the
> endianness changes depending on:
> - timing (due to writes to SCLR or switches among Exception levels) or
> - vCPUs (as each vCPU has its own register instance).

Mmm -- the virtio code uses 'current_cpu' to get the CPU which
did the device access to it, and then queries that CPU for
which endianness it should be assuming the data to be.
That ought to also work in a fully heterogenous setup with
e.g. multiple Arm and microblaze cores, I think ?

There is however also a function virtio_default_endian()
which seems to get used in contexts where the device
isn't being directly accessed by a CPU, such as system reset,
and which looks at target_big_endian(). That I think will
need attention for a heterogenous setup. (For runtime-endian
change setups like Arm it doesn't matter, because when the
OS resets the virtio device it will set the endianness that
way. But AIUI target_big_endian() becomes kind of meaningless
in the heterogenous single binary setup?)

Note that in practice nobody's going to be actively flipping
endianness and expecting the virtio device to keep up: the
use cases are "the OS sets things up once at bootup before
it touches any virtio device", and "the CPU boots up in
big-endian mode (i.e. the opposite of the target_big_endian()
compile time value) because the board/SoC model configures it
that way".

thanks
-- PMM