Hi Stefan,
On 24/2/26 20:21, Pierrick Bouvier wrote:
On 2/24/26 11:07 AM, Michael S. Tsirkin wrote:
On Tue, Feb 24, 2026 at 07:33:14PM +0100, Philippe Mathieu-Daudé wrote:
Hi Pierrick,
On 13/2/26 00:45, Pierrick Bouvier wrote:
This series eliminates some target specifics in hw/virtio and
replace them with
runtime functions where needed, to be able to link virtio code in
single-binary.
After a first try on a series [0] doing this change and making all
virtio files
common, Richard asked to refactor this part, thus this independent
series.
Pierrick Bouvier (3):
hw/virtio: add virtio_vdev_is_{modern, legacy}
hw/virtio: rename virtio_is_big_endian to virtio_vdev_is_big_endian
hw/virtio: remove virtio_access_is_big_endian
Patch #2 has been merged as commit 6325407f67d.
Since we don't have feedback from the maintainers Cc'ed, I took
the liberty to rebase your series, trying to address Zoltan's
concerns on patch #1.
So as I said, main use-case where we would worry about perf is
virtio storage. So it's mostly for storage guys to ack.
Did not get Stefan's feedback yet on whether he is happy.
Are you available to discuss this topic during our next community
call (Tue March 3, 2pm UTC)?
I don't understand if we always want to build a single binary though.
If not we could address all perf worries by having both generic
and target specific implementations by using linker tricks (weak
symbols or
whatnot).
This is not possible unfortunately, since concerned function is declared
static inline. If we want to follow the linker approach, we would still
have to pay for an indirect function call. That's why we insist so much
to change the current definition, as it's the only way to move forward.
The other solution is to exclude virtio completely from single-binary,
but we don't want to have specific config for this, and we worked hard
to keep our promise over all other subsystems we touched with satisfying
compromises for concerned maintainers.
Virtio and vfio are the last two left. After that, there is nothing
really blocking the path towards the goal.
I invite you to watch the presentation we did with Philippe in latest
KVM Forum, it will probably answers on some of your questions.
Especially, you'll see we insist on single binary being a recollection
of existing compilation units, and not yet another configuration to
build (and potentially fail).
Regards,
Pierrick
