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

Performance has been measured with this automated fio benchmark, with
original instructions from Stefan [1].

$ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
$ cd qemu-linux-stack
$ ./build.sh
$ ./run.sh /path/to/qemu-system-x86_64

[1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/

Results are on 20 runs and expressed in kIOPS:
reference: mean=239.2 std_dev=3.48
with_series: mean=238.5 std_dev=3.46

Performance is on par, and within standard deviation.

v4
--

- Include Philippe patches computing once device endianness to skip runtime
  checks on every access.

Philippe Mathieu-Daudé (3):
  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

Pierrick Bouvier (6):
  target-info: add target_base_ppc, target_ppc and target_ppc64
  include/hw/virtio/virtio-access.h: remove target specifics define
  include/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     | 16 +++++++
 include/hw/virtio/virtio-access.h | 50 +++++++++++-----------
 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                |  5 ++-
 target-info.c                     | 21 ++++++++++
 hw/virtio/meson.build             | 17 ++++----
 10 files changed, 104 insertions(+), 122 deletions(-)
 create mode 100644 include/hw/ppc/spapr_common.h

-- 
2.47.3

On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
> This series eliminates target specifics in hw/virtio and replace them with
> runtime functions where needed.
> 
> Performance has been measured with this automated fio benchmark, with
> original instructions from Stefan [1].
> 
> $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
> $ cd qemu-linux-stack
> $ ./build.sh
> $ ./run.sh /path/to/qemu-system-x86_64
> 
> [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
> 
> Results are on 20 runs and expressed in kIOPS:
> reference: mean=239.2 std_dev=3.48
> with_series: mean=238.5 std_dev=3.46
> 
> Performance is on par, and within standard deviation.
> 
> v4
> --
> 
> - Include Philippe patches computing once device endianness to skip runtime
>    checks on every access.
> 
> Philippe Mathieu-Daudé (3):
>    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
> 
> Pierrick Bouvier (6):
>    target-info: add target_base_ppc, target_ppc and target_ppc64
>    include/hw/virtio/virtio-access.h: remove target specifics define
>    include/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     | 16 +++++++
>   include/hw/virtio/virtio-access.h | 50 +++++++++++-----------
>   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                |  5 ++-
>   target-info.c                     | 21 ++++++++++
>   hw/virtio/meson.build             | 17 ++++----
>   10 files changed, 104 insertions(+), 122 deletions(-)
>   create mode 100644 include/hw/ppc/spapr_common.h
> 

Sent v5 fixing the issue found:
https://lore.kernel.org/qemu-devel/20260206221908.1451528-1-pierrick.bouvier@linaro.org/T/#t

Regards,
Pierrick

On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
> This series eliminates target specifics in hw/virtio and replace them with
> runtime functions where needed.
> 
> Performance has been measured with this automated fio benchmark, with
> original instructions from Stefan [1].
> 
> $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
> $ cd qemu-linux-stack
> $ ./build.sh
> $ ./run.sh /path/to/qemu-system-x86_64
> 
> [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
> 
> Results are on 20 runs and expressed in kIOPS:
> reference: mean=239.2 std_dev=3.48
> with_series: mean=238.5 std_dev=3.46
> 
> Performance is on par, and within standard deviation.
>

Does it look better to you Michael?

Regards,
Pierrick

On Wed, Feb 04, 2026 at 09:27:10PM -0800, Pierrick Bouvier wrote:
> On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
> > This series eliminates target specifics in hw/virtio and replace them with
> > runtime functions where needed.
> > 
> > Performance has been measured with this automated fio benchmark, with
> > original instructions from Stefan [1].
> > 
> > $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
> > $ cd qemu-linux-stack
> > $ ./build.sh
> > $ ./run.sh /path/to/qemu-system-x86_64
> > 
> > [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
> > 
> > Results are on 20 runs and expressed in kIOPS:
> > reference: mean=239.2 std_dev=3.48
> > with_series: mean=238.5 std_dev=3.46
> > 
> > Performance is on par, and within standard deviation.
> > 
> 
> Does it look better to you Michael?
> 
> Regards,
> Pierrick


better for sure. is there a reason you dropped stefanha
from CC? he suggested these tests...

-- 
MST

On 2/4/26 10:43 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 04, 2026 at 09:27:10PM -0800, Pierrick Bouvier wrote:
>> On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
>>> This series eliminates target specifics in hw/virtio and replace them with
>>> runtime functions where needed.
>>>
>>> Performance has been measured with this automated fio benchmark, with
>>> original instructions from Stefan [1].
>>>
>>> $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
>>> $ cd qemu-linux-stack
>>> $ ./build.sh
>>> $ ./run.sh /path/to/qemu-system-x86_64
>>>
>>> [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
>>>
>>> Results are on 20 runs and expressed in kIOPS:
>>> reference: mean=239.2 std_dev=3.48
>>> with_series: mean=238.5 std_dev=3.46
>>>
>>> Performance is on par, and within standard deviation.
>>>
>>
>> Does it look better to you Michael?
>>
>> Regards,
>> Pierrick
> 
> 
> better for sure. is there a reason you dropped stefanha
> from CC? he suggested these tests...
> 

I didn't to that intentionally, it seems like he was not added by 
default from the file set when I posted v4.

Stefan, please see cover letter above and let us know if that sounds 
acceptable to you.

Regards,
Pierrick

On Thu, Feb 05, 2026 at 09:17:03AM -0800, Pierrick Bouvier wrote:
> On 2/4/26 10:43 PM, Michael S. Tsirkin wrote:
> > On Wed, Feb 04, 2026 at 09:27:10PM -0800, Pierrick Bouvier wrote:
> > > On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
> > > > This series eliminates target specifics in hw/virtio and replace them with
> > > > runtime functions where needed.
> > > > 
> > > > Performance has been measured with this automated fio benchmark, with
> > > > original instructions from Stefan [1].
> > > > 
> > > > $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
> > > > $ cd qemu-linux-stack
> > > > $ ./build.sh
> > > > $ ./run.sh /path/to/qemu-system-x86_64
> > > > 
> > > > [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
> > > > 
> > > > Results are on 20 runs and expressed in kIOPS:
> > > > reference: mean=239.2 std_dev=3.48
> > > > with_series: mean=238.5 std_dev=3.46
> > > > 
> > > > Performance is on par, and within standard deviation.
> > > > 
> > > 
> > > Does it look better to you Michael?
> > > 
> > > Regards,
> > > Pierrick
> > 
> > 
> > better for sure. is there a reason you dropped stefanha
> > from CC? he suggested these tests...
> > 
> 
> I didn't to that intentionally, it seems like he was not added by default
> from the file set when I posted v4.
> 
> Stefan, please see cover letter above and let us know if that sounds
> acceptable to you.

Yes, the results you posted look fine. Thanks!

Stefan

On 2/5/26 10:38 AM, Stefan Hajnoczi wrote:
> On Thu, Feb 05, 2026 at 09:17:03AM -0800, Pierrick Bouvier wrote:
>> On 2/4/26 10:43 PM, Michael S. Tsirkin wrote:
>>> On Wed, Feb 04, 2026 at 09:27:10PM -0800, Pierrick Bouvier wrote:
>>>> On 2/3/26 12:56 PM, Pierrick Bouvier wrote:
>>>>> This series eliminates target specifics in hw/virtio and replace them with
>>>>> runtime functions where needed.
>>>>>
>>>>> Performance has been measured with this automated fio benchmark, with
>>>>> original instructions from Stefan [1].
>>>>>
>>>>> $ git clone https://github.com/pbo-linaro/qemu-linux-stack -b x86_64_io_benchmark
>>>>> $ cd qemu-linux-stack
>>>>> $ ./build.sh
>>>>> $ ./run.sh /path/to/qemu-system-x86_64
>>>>>
>>>>> [1] https://lore.kernel.org/qemu-devel/20260202185233.GC405548@fedora/
>>>>>
>>>>> Results are on 20 runs and expressed in kIOPS:
>>>>> reference: mean=239.2 std_dev=3.48
>>>>> with_series: mean=238.5 std_dev=3.46
>>>>>
>>>>> Performance is on par, and within standard deviation.
>>>>>
>>>>
>>>> Does it look better to you Michael?
>>>>
>>>> Regards,
>>>> Pierrick
>>>
>>>
>>> better for sure. is there a reason you dropped stefanha
>>> from CC? he suggested these tests...
>>>
>>
>> I didn't to that intentionally, it seems like he was not added by default
>> from the file set when I posted v4.
>>
>> Stefan, please see cover letter above and let us know if that sounds
>> acceptable to you.
> 
> Yes, the results you posted look fine. Thanks!
> 
> Stefan

Thanks for your answer.

Please don't pull this for now, I found issues with patch 3, which I 
didn't double check before including it in v4, sorry.
I'll find issue and post a v5.

Regards,
Pierrick