All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel.a@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Alexey Kardashevskiy" <aik@ozlabs.ru>,
	"Michael Tokarev" <mjt@tls.msk.ru>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Laszlo Ersek" <lersek@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>,
	"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH for-2.0 V3] tests/acpi-test: do not run iasl on big endian machines
Date: Sun, 23 Mar 2014 15:17:32 +0200	[thread overview]
Message-ID: <1395580652.5673.37.camel@localhost.localdomain> (raw)
In-Reply-To: <532ED8EB.4000306@redhat.com>

On Sun, 2014-03-23 at 13:51 +0100, Paolo Bonzini wrote:
> Il 23/03/2014 13:32, Marcel Apfelbaum ha scritto:
> >> > That's the endianness of the machine we're compiling QEMU
> >> > for, not the endianness of the machine we're compiling QEMU
> >> > on. If for instance you're on x86_64 cross-compiling for PPC
> >> > then HOST_WORDS_BIGENDIAN is true, but the iasl you use
> >> > in the build process will be running on a little endian machine.
> > Hi Peter, are you sure about this?
> > I saw the 'target_bigendian' that does what you described above.
> > $bigendian is the result of a little C program that checks *host's* endian-ness.
> > Of course I might have missed something.
> 
> Peter is right.  There are three systems: build (what you run on), host 
> (what you compile for), target (always x86-64 for now for acpi-test). 
> $bigendian and G_BYTE_ORDER check the host system.  If you wanted to 
> test the build system's endianness, Laszlo's suggestion would be fine.
> 
> However, Michael is also right if we assume that iasl on bigendian can 
> assemble, and that the problems are only on disassembling.  This is 
> because in this particular case you'll be running an executable compiled 
> for the host and you know that host == build.
> 
> I think the assumption is sane.  As far as I remember, upstream iasl 
> doesn't compile at all on big-endian machines.  You need specific 
> patches such as those shared by Fedora and Debian's.  Unfortunately, the 
> patches are incomplete, they only fix assembling because that's what was 
> needed so far to cross-compile SeaBIOS.

Hi Paolo, thanks for the help!
I need a decision here :)

1.
If iasl *does* work for the scenarios used by Qemu until now,
I can conclude that the only part that suffers from it is the
test itself, because it dis-assembles AML code. In this case
I can handle it in the test itself by checking the endian-ness
(V2 already posted), or trying to dis-assemble the expected AML
file and not failing the test if this fails.

2. If iasl causes problems to run a x86_64 guest if one or both build/host
machines are BE, we need to tweak the configuration file.

After this discussion it seems that (2.) is not the case, I think maybe re-sending:
 [PATCH for-2.0 V2] tests/acpi-test: do not run iasl on big endian machines

Is everyone OK with this?
Thanks,
Marcel

> Paolo

  reply	other threads:[~2014-03-23 13:17 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-20 21:14 [Qemu-devel] [PATCH for-2.0 V3] tests/acpi-test: do not run iasl on big endian machines Marcel Apfelbaum
2014-03-20 21:57 ` Paolo Bonzini
2014-03-20 22:00   ` Marcel Apfelbaum
2014-03-20 22:06   ` Marcel Apfelbaum
2014-03-20 22:17     ` Peter Maydell
2014-03-20 22:41       ` Marcel Apfelbaum
2014-03-20 23:03         ` Peter Maydell
2014-03-23  9:52           ` Michael S. Tsirkin
2014-03-23 12:31             ` Peter Maydell
2014-03-23  9:51       ` Michael S. Tsirkin
2014-03-20 22:26     ` Laszlo Ersek
2014-03-20 22:33       ` Marcel Apfelbaum
2014-03-20 22:50         ` Laszlo Ersek
2014-03-20 23:16         ` Paolo Bonzini
2014-03-23  9:49           ` Michael S. Tsirkin
2014-03-23 12:14             ` Peter Maydell
2014-03-23 12:32               ` Marcel Apfelbaum
2014-03-23 12:48                 ` Peter Maydell
2014-03-23 13:00                   ` Marcel Apfelbaum
2014-03-23 12:51                 ` Paolo Bonzini
2014-03-23 13:17                   ` Marcel Apfelbaum [this message]
2014-03-23 13:58                     ` Michael S. Tsirkin
2014-03-24 11:02             ` Andreas Färber
2014-03-25  3:48               ` Alexey Kardashevskiy
2014-03-23 12:32           ` Marcel Apfelbaum

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=1395580652.5673.37.camel@localhost.localdomain \
    --to=marcel.a@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=lersek@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=stefanha@redhat.com \
    /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.