All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Re: [PATCH] pc: e820 qemu_cfg tables need to be packed
Date: Thu, 14 Oct 2010 14:59:04 -0600	[thread overview]
Message-ID: <1287089944.2987.33.camel@x201> (raw)
In-Reply-To: <201010142220.26329.arnd@arndb.de>

On Thu, 2010-10-14 at 22:20 +0200, Arnd Bergmann wrote:
> On Thursday 14 October 2010 21:58:08 Alex Williamson wrote:
> > If it works anywhere (I assume it works on 32bit), then it's only
> > because it happened to get the alignment right.  This just makes 64bit
> > hosts get it right too.  I don't see any compatibility issues,
> > non-packed + 64bit = broken.  Thanks,
> 
> I would actually assume that only x86-32 hosts got it right, because
> all 32 bit hosts I've seen other than x86 also define 8 byte alignment
> for uint64_t.
> 
> You might however consider making it 
> 
> __attribute((__packed__, __aligned__(4)))
> 
> instead of just packed, because otherwise you make the alignment one byte,
> which is not only different from what it used to be on x86-32 but also
> will cause inefficient compiler outpout on platforms that don't have unaligned
> word accesses in hardware.

The structs in question only contain 4 & 8 byte elements, so there
shouldn't be any change on x86-32 using one-byte aligned packing.
AFAIK, e820 is x86-only, so we don't need to worry about breaking anyone
else.  Performance isn't much of a consideration for this type of
interface since it's only used pre-boot.  In fact, the channel between
qemu and the bios is only one byte wide, so wider alignment can cost
extra emulated I/O accesses.  Thanks,

Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jes@gnu.org, kvm@vger.kernel.org, qemu-devel@nongnu.org,
	Sorensen <Jes.Sorensen@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH] pc: e820 qemu_cfg tables need to be packed
Date: Thu, 14 Oct 2010 14:59:04 -0600	[thread overview]
Message-ID: <1287089944.2987.33.camel@x201> (raw)
In-Reply-To: <201010142220.26329.arnd@arndb.de>

On Thu, 2010-10-14 at 22:20 +0200, Arnd Bergmann wrote:
> On Thursday 14 October 2010 21:58:08 Alex Williamson wrote:
> > If it works anywhere (I assume it works on 32bit), then it's only
> > because it happened to get the alignment right.  This just makes 64bit
> > hosts get it right too.  I don't see any compatibility issues,
> > non-packed + 64bit = broken.  Thanks,
> 
> I would actually assume that only x86-32 hosts got it right, because
> all 32 bit hosts I've seen other than x86 also define 8 byte alignment
> for uint64_t.
> 
> You might however consider making it 
> 
> __attribute((__packed__, __aligned__(4)))
> 
> instead of just packed, because otherwise you make the alignment one byte,
> which is not only different from what it used to be on x86-32 but also
> will cause inefficient compiler outpout on platforms that don't have unaligned
> word accesses in hardware.

The structs in question only contain 4 & 8 byte elements, so there
shouldn't be any change on x86-32 using one-byte aligned packing.
AFAIK, e820 is x86-only, so we don't need to worry about breaking anyone
else.  Performance isn't much of a consideration for this type of
interface since it's only used pre-boot.  In fact, the channel between
qemu and the bios is only one byte wide, so wider alignment can cost
extra emulated I/O accesses.  Thanks,

Alex

  reply	other threads:[~2010-10-14 20:59 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-14 18:33 [PATCH] pc: e820 qemu_cfg tables need to be packed Alex Williamson
2010-10-14 18:33 ` [Qemu-devel] " Alex Williamson
2010-10-14 19:44 ` Jes Sorensen
2010-10-14 19:44   ` [Qemu-devel] " Jes Sorensen
2010-10-14 19:48   ` Anthony Liguori
2010-10-14 19:58     ` Alex Williamson
2010-10-14 19:59       ` Anthony Liguori
2010-10-14 20:20       ` Arnd Bergmann
2010-10-14 20:20         ` [Qemu-devel] " Arnd Bergmann
2010-10-14 20:59         ` Alex Williamson [this message]
2010-10-14 20:59           ` Alex Williamson
2010-10-14 21:19           ` Arnd Bergmann
2010-10-14 21:19             ` Arnd Bergmann
2010-10-15  4:01             ` Alex Williamson
2010-10-15  4:01               ` Alex Williamson
2010-10-15  4:08 ` [PATCH v2] " Alex Williamson
2010-10-15  4:08   ` [Qemu-devel] " Alex Williamson
2010-10-15 10:20   ` Arnd Bergmann
2010-10-15 10:20     ` [Qemu-devel] " Arnd Bergmann

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=1287089944.2987.33.camel@x201 \
    --to=alex.williamson@redhat.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=arnd@arndb.de \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@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.