Re: [PATCH 0/3] hw/virtio/virtio-access.h: remove target specific code

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 24, 2026 at 11:21:09AM -0800, 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.
> > 
> > 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.

I refer to all of affected device here. Not just the single function.

> 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,

Not exclude - have a separate slower version of virtio for that.

> 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.

ok

> 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

Merely pointing out a fallback approach.
-- 
MST