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" <m...@redhat.com> wrote: > > > On Wed, Apr 16, 2014 at 05:42:22PM +0100, Peter Maydell wrote: > > > On 16 April 2014 17:34, Michael S. Tsirkin <m...@redhat.com> 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.