On 03/06/2016 03:16, David Gibson wrote: > On Thu, Jun 02, 2016 at 06:04:37PM +0200, Greg Kurz wrote: >> On Wed, 1 Jun 2016 12:33:28 +1000 >> David Gibson <da...@gibson.dropbear.id.au> wrote: >> >>> On Tue, May 31, 2016 at 03:15:21PM +0200, Paolo Bonzini wrote: >>>> >>>> >>>> On 31/05/2016 15:10, Greg Kurz wrote: >>>>>>>>> +#if defined(TARGET_PPC64) || defined(TARGET_ARM) >>>>>>>>> +#define LEGACY_VIRTIO_IS_BIENDIAN 1 >>>>>>>>> +#endif >>>>>>> >>>>>>> These will only be correct if something else includes cpu.h. Instead >>>>>>> of >>>>> Unless I missed something, the TARGET_* macros come from the generated >>>>> config-target.h header, which is in turn included by qemu/osdep.h and >>>>> thus included by most of the code. >>>> >>>> You're right. Problems _could_ happen if virtio-access.h is included in >>>> a file compiled without -DNEED_CPU_H (i.e. with common-obj-y instead of >>>> obj-y) but include/exec/poison.h should take care of that. >>>> >>>>>>> defining this, you should add >>>>>>> >>>>>>> #include "cpu.h" >>>>>>> >>>>>>> at the top of include/hw/virtio-access.h and leave the definitions in >>>>>>> target-*/cpu.h. >>>>>>> >>>>> All this bi-endian stuff is really an old-virtio-only thing... it is >>>>> only to be used by virtio_access_is_big_endian(). The fact that it >>>>> broke silently with your cleanup series is yet another proof that >>>>> this workaround is fragile. >>>> >>>> It is not fragile actually. cpu.h doesn't exist in common-obj-y, so the >>>> TARGET_IS_BIENDIAN define can be safely taken from cpu.h. >>>> >>>> Anyway because of poison.h your solution isn't fragile either, so >>>> >>>> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> >>> >>> Should I take this through my tree? >>> >> >> That would be great ! > > Actually, that was a question for Paolo..
It would be more of a question for mst; I do not maintain virtio (that's why I wrote R-b and not Acked-by). Thanks, Paolo
