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
