Re: [Qemu-devel] [PATCH v7 1/8] virtio: endian-ambivalent targets using legacy virtio

[Michael S. Tsirkin]

On Thu, Apr 17, 2014 at 08:54:12AM +0200, Greg Kurz wrote:
> On Wed, 16 Apr 2014 20:32:07 +0300
> "Michael S. Tsirkin" <address@hidden> wrote:
> 
> > On Wed, Apr 16, 2014 at 05:42:22PM +0100, Peter Maydell wrote:
> > > On 16 April 2014 17:34, Michael S. Tsirkin <address@hidden> wrote:
> > > > so it looks like virtio is currently compiled per-target.
> > > > So why isn't it reasonable to keep it per-target for
> > > > purpose of this enhancement?
> > > > What am I missing?
> > > 
> > > "virtio" is more than one C file. Currently per-target:
> > > hw/virtio/virtio.c
> > > hw/virtio/virtio-balloon.c
> > > hw/scsi/virtio-scsi.c
> > > hw/block/virtio-blk.c
> > > hw/char/virtio-serial-bus.c
> > > hw/net/virtio-net.c
> > > 
> > > Currently built once:
> > > hw/char/virtio-console.c
> > > hw/virtio/virtio-bus.c
> > > hw/virtio/virtio-mmio.c
> > > hw/virtio/virtio-pci.c
> > > hw/virtio/virtio-rng.c
> > > 
> > > If we can move files from the first group to the second
> > > that's cool.
> > 
> > But doesn't have to be part of this series, yes?
> > I would say let's at least have virtio 1.0 out
> > and implemented in qemu and linux guests, then
> > we can start deprecate virtio 0.X in favor of it.
> > 
> > > Moving files from the second to the first is
> > > what I'd like to avoid...
> > > 
> > > thanks
> > > -- PMM
> > 
> > Absolutely.
> > 
> > Looks like we are in agreement after all.
> > 
> > So as far as I could see the only issue is with config access
> > e.g. in virtio-pci?
> > That one already has a branch around virtio_is_big_endian,
> > so it's not a problem, there's no need to optimize that.
> > 
> 
> It is because you haven't looked at the other patches... When
> the whole serie is applied, all virtio files use inlined helpers
> from virtio-access.h to access memory and fix endianness. That is
> why we'd rather not add target dependency here...

Right, so what I'm saying is very simple: there are two types of helpers:
- per target ones for guest memory access
- generic ones for config access


One way to implement generic ones is as out of line wrappers
for inline per target ones, another way is a separate implementation.


> This being said, if you have an insight to have branch-less code
> for fixed endian targets, and dedicated code for ambivalent endian
> targets, please send something.
> 
> Cheers.
> 
> --
> Greg

Sure but I'm a bit busy otherwise - if above hints are insufficient,
expect something by Tuesday.