This series eliminates target specifics in hw/virtio and replace them
with runtime functions where needed.

v3:
- include missing SPAPR_MAX_RAM_SLOTS patch
v2:
- Reduce runtime calls for performance
v1:
https://lore.kernel.org/qemu-devel/20260131020100.1115203-1-pierrick.bouvier@linaro.org/

Philippe Mathieu-Daudé (6):
  hw/virtio: Constify virtio_is_big_endian() argument
  hw/virtio: Introduce VirtIODevice::access_is_big_endian boolean field
  hw/virtio: Use VirtIODevice::access_is_big_endian field
  hw/virtio: Reduce virtio_access_is_big_endian() scope
  hw/virtio: Check target supports legacy bi-endianness at runtime
  hw/virtio: Replace TARGET_BIG_ENDIAN -> target_big_endian()

Pierrick Bouvier (5):
  target-info: add target_base_ppc, target_ppc and target_ppc64
  hw/ppc/spapr: extract SPAPR_MAX_RAM_SLOTS in a new header
  hw/virtio/vhost-user: make compilation unit common
  hw/virtio/virtio-qmp: make compilation unit common
  hw/virtio: make all compilation units common

 include/hw/ppc/spapr.h            |  8 +---
 include/hw/ppc/spapr_common.h     | 17 ++++++++
 include/hw/virtio/virtio-access.h | 46 ++++++--------------
 include/hw/virtio/virtio.h        |  7 +++-
 include/qemu/target-info.h        | 21 ++++++++++
 hw/virtio/vhost-user.c            | 11 ++---
 hw/virtio/virtio-qmp.c            | 70 -------------------------------
 hw/virtio/virtio.c                | 25 ++++++++++-
 target-info.c                     | 21 ++++++++++
 hw/virtio/meson.build             | 17 ++++----
 10 files changed, 113 insertions(+), 130 deletions(-)
 create mode 100644 include/hw/ppc/spapr_common.h

-- 
2.52.0

On Mon, Feb 02, 2026 at 12:29:12AM +0100, Philippe Mathieu-Daudé wrote:
> This series eliminates target specifics in hw/virtio and replace them
> with runtime functions where needed.


This is not bad at all. I feel we do need to have the performance impact
tested, however, just to be sure, since it's probably the hottest path
for I/O.


> v3:
> - include missing SPAPR_MAX_RAM_SLOTS patch
> v2:
> - Reduce runtime calls for performance
> v1:
> https://lore.kernel.org/qemu-devel/20260131020100.1115203-1-pierrick.bouvier@linaro.org/
> 
> Philippe Mathieu-Daudé (6):
>   hw/virtio: Constify virtio_is_big_endian() argument
>   hw/virtio: Introduce VirtIODevice::access_is_big_endian boolean field
>   hw/virtio: Use VirtIODevice::access_is_big_endian field
>   hw/virtio: Reduce virtio_access_is_big_endian() scope
>   hw/virtio: Check target supports legacy bi-endianness at runtime
>   hw/virtio: Replace TARGET_BIG_ENDIAN -> target_big_endian()
> 
> Pierrick Bouvier (5):
>   target-info: add target_base_ppc, target_ppc and target_ppc64
>   hw/ppc/spapr: extract SPAPR_MAX_RAM_SLOTS in a new header
>   hw/virtio/vhost-user: make compilation unit common
>   hw/virtio/virtio-qmp: make compilation unit common
>   hw/virtio: make all compilation units common
> 
>  include/hw/ppc/spapr.h            |  8 +---
>  include/hw/ppc/spapr_common.h     | 17 ++++++++
>  include/hw/virtio/virtio-access.h | 46 ++++++--------------
>  include/hw/virtio/virtio.h        |  7 +++-
>  include/qemu/target-info.h        | 21 ++++++++++
>  hw/virtio/vhost-user.c            | 11 ++---
>  hw/virtio/virtio-qmp.c            | 70 -------------------------------
>  hw/virtio/virtio.c                | 25 ++++++++++-
>  target-info.c                     | 21 ++++++++++
>  hw/virtio/meson.build             | 17 ++++----
>  10 files changed, 113 insertions(+), 130 deletions(-)
>  create mode 100644 include/hw/ppc/spapr_common.h
> 
> -- 
> 2.52.0

On 2/2/26 00:29, Philippe Mathieu-Daudé wrote:
> This series eliminates target specifics in hw/virtio and replace them
> with runtime functions where needed.


> Philippe Mathieu-Daudé (6):
>    hw/virtio: Constify virtio_is_big_endian() argument
>    hw/virtio: Introduce VirtIODevice::access_is_big_endian boolean field
>    hw/virtio: Use VirtIODevice::access_is_big_endian field
>    hw/virtio: Reduce virtio_access_is_big_endian() scope
>    hw/virtio: Check target supports legacy bi-endianness at runtime
>    hw/virtio: Replace TARGET_BIG_ENDIAN -> target_big_endian()
> 
> Pierrick Bouvier (5):
>    target-info: add target_base_ppc, target_ppc and target_ppc64
>    hw/ppc/spapr: extract SPAPR_MAX_RAM_SLOTS in a new header
>    hw/virtio/vhost-user: make compilation unit common
>    hw/virtio/virtio-qmp: make compilation unit common
>    hw/virtio: make all compilation units common

FTR I worked on v2 and v3 without previously discussing with Pierrick,
hoping it would help to get a closure on this painful (for me, since
I try to get that fixed since at least 3 years now) topic. I didn't
meant to be disrepectful, and understand this is not a proper teamwork
approach. I will let Pierrick, who kindly offered to help here, follow
his line of work without intervening. Hopefully I won't have to touch
this virtio code ever again.

Regards,

Phil.

On 2/2/26 3:16 AM, Philippe Mathieu-Daudé wrote:
> On 2/2/26 00:29, Philippe Mathieu-Daudé wrote:
>> This series eliminates target specifics in hw/virtio and replace them
>> with runtime functions where needed.
> 
> 
>> Philippe Mathieu-Daudé (6):
>>     hw/virtio: Constify virtio_is_big_endian() argument
>>     hw/virtio: Introduce VirtIODevice::access_is_big_endian boolean field
>>     hw/virtio: Use VirtIODevice::access_is_big_endian field
>>     hw/virtio: Reduce virtio_access_is_big_endian() scope
>>     hw/virtio: Check target supports legacy bi-endianness at runtime
>>     hw/virtio: Replace TARGET_BIG_ENDIAN -> target_big_endian()
>>
>> Pierrick Bouvier (5):
>>     target-info: add target_base_ppc, target_ppc and target_ppc64
>>     hw/ppc/spapr: extract SPAPR_MAX_RAM_SLOTS in a new header
>>     hw/virtio/vhost-user: make compilation unit common
>>     hw/virtio/virtio-qmp: make compilation unit common
>>     hw/virtio: make all compilation units common
> 
> FTR I worked on v2 and v3 without previously discussing with Pierrick,
> hoping it would help to get a closure on this painful (for me, since
> I try to get that fixed since at least 3 years now) topic. I didn't
> meant to be disrepectful, and understand this is not a proper teamwork
> approach. I will let Pierrick, who kindly offered to help here, follow
> his line of work without intervening. Hopefully I won't have to touch
> this virtio code ever again.
>

Please do not feel bad about it Philippe, we (including myself) now you 
just want to help here. It might just not be the best way to collaborate 
though, since we are not sure of which direction things should take from 
there.

As said previously, your change is valid and worth testing in addition 
to the single-binary series: it just seems to be two different topics 
accidently reaching the same goal.

For the first step, I still would prefer to stick to the simple "convert 
to runtime" approach, benchmark it, and get it merged asap if Michael is 
happy with it. In parallel, it's totally valid to send a separate series 
taking the approach you offered. First merged in, and we all win.

I'll benchmark the v1, and eventually repost this as v4 with the results 
to keep it clear for mailing list users.

> Regards,
> 
> Phil.

Regards,
Pierrick