[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH] virtio: move bi-endian target support to a single

From: Paolo Bonzini
Subject: Re: [Qemu-ppc] [PATCH] virtio: move bi-endian target support to a single location
Date: Tue, 31 May 2016 15:15:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0

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 <address@hidden>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]