All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] virtio: move bi-endian target support to a single location
Date: Fri, 3 Jun 2016 11:16:04 +1000	[thread overview]
Message-ID: <20160603011604.GE1087@voom.fritz.box> (raw)
In-Reply-To: <20160602180437.02f3ed85@bahia.huguette.org>

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

On Thu, Jun 02, 2016 at 06:04:37PM +0200, Greg Kurz wrote:
> On Wed, 1 Jun 2016 12:33:28 +1000
> David Gibson <david@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 <pbonzini@redhat.com>  
> > 
> > Should I take this through my tree?
> > 
> 
> That would be great !

Actually, that was a question for Paolo..


-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Alexander Graf <agraf@suse.de>,
	qemu-arm@nongnu.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] virtio: move bi-endian target support to a single location
Date: Fri, 3 Jun 2016 11:16:04 +1000	[thread overview]
Message-ID: <20160603011604.GE1087@voom.fritz.box> (raw)
In-Reply-To: <20160602180437.02f3ed85@bahia.huguette.org>

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

On Thu, Jun 02, 2016 at 06:04:37PM +0200, Greg Kurz wrote:
> On Wed, 1 Jun 2016 12:33:28 +1000
> David Gibson <david@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 <pbonzini@redhat.com>  
> > 
> > Should I take this through my tree?
> > 
> 
> That would be great !

Actually, that was a question for Paolo..


-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-06-03  1:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31  8:09 [Qemu-arm] [PATCH] virtio: move bi-endian target support to a single location Greg Kurz
2016-05-31  8:09 ` [Qemu-devel] " Greg Kurz
2016-05-31  9:19 ` [Qemu-arm] " Cédric Le Goater
2016-05-31  9:19   ` Cédric Le Goater
2016-05-31 11:54 ` [Qemu-arm] " Paolo Bonzini
2016-05-31 11:54   ` [Qemu-devel] " Paolo Bonzini
2016-05-31 13:10   ` [Qemu-arm] " Greg Kurz
2016-05-31 13:10     ` [Qemu-devel] " Greg Kurz
2016-05-31 13:14     ` [Qemu-arm] " Peter Maydell
2016-05-31 13:14       ` [Qemu-devel] " Peter Maydell
2016-05-31 14:10       ` [Qemu-arm] " Greg Kurz
2016-05-31 14:10         ` [Qemu-devel] " Greg Kurz
2016-05-31 13:15     ` [Qemu-arm] " Paolo Bonzini
2016-05-31 13:15       ` [Qemu-devel] " Paolo Bonzini
2016-05-31 14:10       ` [Qemu-arm] " Greg Kurz
2016-05-31 14:10         ` [Qemu-devel] " Greg Kurz
2016-06-01  2:33       ` [Qemu-arm] " David Gibson
2016-06-01  2:33         ` [Qemu-devel] " David Gibson
2016-06-01  8:30         ` [Qemu-arm] " Paolo Bonzini
2016-06-01  8:30           ` [Qemu-devel] " Paolo Bonzini
2016-06-02 16:04         ` [Qemu-arm] " Greg Kurz
2016-06-02 16:04           ` [Qemu-devel] " Greg Kurz
2016-06-03  1:16           ` David Gibson [this message]
2016-06-03  1:16             ` David Gibson
2016-06-03  6:05             ` [Qemu-arm] " Greg Kurz
2016-06-03  6:05               ` [Qemu-devel] " Greg Kurz
2016-06-06 13:41             ` [Qemu-arm] " Paolo Bonzini
2016-06-06 13:41               ` [Qemu-devel] " Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160603011604.GE1087@voom.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=agraf@suse.de \
    --cc=gkurz@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.