On Tue, 31 May 2016 15:15:21 +0200 Paolo Bonzini <pbonz...@redhat.com> 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. > Exactly ! > >> > 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. > I was referring to the current situation where virtio_access_is_big_endian() silently lost its ability to support endian changing guests with: --- a/include/qemu-common.h +++ b/include/qemu-common.h @@ -22,11 +22,6 @@ #include "qemu/option.h" -/* FIXME: Remove NEED_CPU_H. */ -#ifdef NEED_CPU_H -#include "cpu.h" -#endif /* !defined(NEED_CPU_H) */ - which then leads to the usual ENOMEM errors in the guest: [ 8.959600] blk-mq: failed to allocate request map [ 8.960171] virtio_blk: probe of virtio0 failed with error -12 > Anyway because of poison.h your solution isn't fragile either, so > At least, if someone tries to include virtio-access.h in common-obj-y, she gets a build break. > Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> > > Paolo > Thanks ! -- Greg
