tests/acpi-test: do not run iasl on big endian machines
PATCH v3 1/1 tests/acpi-test: do not run iasl on big endian machines
There is an issue with iasl on big endian machines: It cannot disassemble acpi tables taken from little endian machines, so we cannot check the expected tables.
Do not run iasl on those machines until this problem is solved by the acpica community.
---
V2 -> V3:
Addressed Michael S. Tsirkin's review:
- tests don't need to re-run detection, use configure to figure out if it is an LE machine.
V1 -> V2:
Addressed an offline tip for a much cleaner macro line, thanks!
configure | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
configure +4 -1
@@ -4656,7 +4656,10 @@ else fi echo "PYTHON=$python" >> $config_host_mak echo "CC=$cc" >> $config_host_mak -if $iasl -h > /dev/null 2>&1; then +# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); then echo "IASL=$iasl" >> $config_host_mak fi echo "CC_I386=$cc_i386" >> $config_host_mak
Signature · 1 line
1.8.3.1
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); then
lscpu is not portable.
Paolo
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
I'll try to come up with something else.
Thanks,
Marcel
Quoted 2 lines
Paolo
Quoted 9 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
echo "trivial iasl source" | iasl --compile-options | iasl --disassemble-options | grep "error"
Fill in the handwaving with actual syntax ;-)
thanks
-- PMM
Quoted 9 lines · Peter Maydell
Quoted 8 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
Quoted 6 lines
Quoted 1 line
I am open to suggestions...
echo "trivial iasl source" | iasl --compile-options | iasl --disassemble-options | grep "error"
Fill in the handwaving with actual syntax ;-)
Thanks Peter!
Problem with this solution is that if we start from the source, it will compile into a *wrong* AML (e.g header length will be BE and not LE), then the disassemble will *succeed* (!!!).
However, the expected AML file will be in the right format and fail :(.
I can use one of the expected AML files, but it would not be elegant to use a test file in the configuration script.
What about Laszlo's idea? Would something like:
X=$(printf '\336\255\276\357' | od -A n -t x4) be acceptable ?
Thanks,
Marcel
Quoted 3 lines
thanks
-- PMM
Quoted 10 lines · Marcel Apfelbaum
Quoted 4 lines · Peter Maydell
echo "trivial iasl source" | iasl --compile-options | iasl --disassemble-options | grep "error"
Fill in the handwaving with actual syntax ;-)
Problem with this solution is that if we start from the source, it will compile into a *wrong* AML (e.g header length will be BE and not LE), then the disassemble will *succeed* (!!!).
However, the expected AML file will be in the right format and fail :(.
Well, grep for 'some integer that comes out wrong due to the iasl bug', if it doesn't always result in an error like the case you reported to the iasl mailing list.
You need to write this code at some point because we do need to be able to configure-time detect whether we have a working iasl or a broken one, once fixed ones get out into the wild. It doesn't seem like it ought to be that hard to just do it right to start with...
thanks
-- PMM
Quoted 16 lines · Peter Maydell
Quoted 10 lines · Marcel Apfelbaum
Quoted 4 lines · Peter Maydell
echo "trivial iasl source" | iasl --compile-options | iasl --disassemble-options | grep "error"
Fill in the handwaving with actual syntax ;-)
Problem with this solution is that if we start from the source, it will compile into a *wrong* AML (e.g header length will be BE and not LE), then the disassemble will *succeed* (!!!).
However, the expected AML file will be in the right format and fail :(.Well, grep for 'some integer that comes out wrong due to the iasl bug', if it doesn't always result in an error like the case you reported to the iasl mailing list.
Quoted 8 lines
You need to write this code at some point because we do need to be able to configure-time detect whether we have a working iasl or a broken one, once fixed ones get out into the wild. It doesn't seem like it ought to be that hard to just do it right to start with...
thanks
-- PMM
Hard to predict the future: it's possible that some distros will ship partially broken iasl on BE.
We really need to see a working one to be sure ...
Signature · 1 line
MST
Quoted 3 lines · Michael S. Tsirkin
Hard to predict the future: it's possible that some distros will ship partially broken iasl on BE.
We really need to see a working one to be sure ...
Well at the moment we have a known broken iasl, and we have a known OK iasl (in the sense that we know what the correct behaviour is, it should match what it does on LE hosts). So we can write a test that distinguishes the two. In the future if somebody fixes half the bugs for some reason we will then be able to tighten up the test if we have to.
But I think a test that correctly distinguishes the two cases we have currently is better than one which marks them both as "broken".
thanks
-- PMM
Quoted 11 lines · Peter Maydell
Quoted 9 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
Quoted 7 lines
echo "trivial iasl source" | iasl --compile-options | iasl --disassemble-options | grep "error"
Fill in the handwaving with actual syntax ;-)
thanks
-- PMM
True but whatever test we write, it's possible that a buggy iasl passes it by luck.
Let's wait for a working iasl to appear on some BE machines. When that happens, we'll be able to write a robust detection script.
Signature · 1 line
MST
Quoted 10 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
I'll try to come up with something else.
The printf and od utilities are portable. You can use printf to print a character string, and use od to group that character string into multibyte integers in the native byte order.
Example:
X=$(printf '\336\255\276\357' | od -A n -t x4)
This sets X to " efbeadde" on little endian, and " deadbeef" on big endian.
Laszlo
Quoted 12 lines · Laszlo Ersek
Quoted 10 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
I'll try to come up with something else.
Quoted 7 lines
The printf and od utilities are portable. You can use printf to print a character string, and use od to group that character string into multibyte integers in the native byte order.
Example:
X=$(printf '\336\255\276\357' | od -A n -t x4)
Hi Laszlo,
Thanks for the help!
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
Thanks!
Marcel
Quoted 4 lines
This sets X to " efbeadde" on little endian, and " deadbeef" on big endian.
Laszlo
Quoted 20 lines · Marcel Apfelbaum
Quoted 12 lines · Laszlo Ersek
Quoted 10 lines · Marcel Apfelbaum
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
I'll try to come up with something else.Quoted 7 lines
The printf and od utilities are portable. You can use printf to print a character string, and use od to group that character string into multibyte integers in the native byte order.
Example:
X=$(printf '\336\255\276\357' | od -A n -t x4)
Quoted 8 lines
Hi Laszlo,
Thanks for the help!I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
For ultimate pedantry, don't depend on the number and kind of blanks on the left hand side of the output. If you set LC_ALL to POSIX, then only <space> and <tab> count as blank; but even that way you should be prepared to see any number of them on the LHS. Probably just use grep:
if printf '\336\255\276\357' | od -A n -t x4 | grep -q deadbeef; then
printf 'big endian\n' >&2
fi
Laszlo
Il 20/03/2014 23:33, Marcel Apfelbaum ha scritto:
Quoted 5 lines
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
If all you're looking for is bigendian (disabling iasl disassembly on bigendian makes sense), your patch v2 is fine.
Assembling ASL on bigendian is supported by at least Fedora and Debian (and hence Ubuntu).
Paolo
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 23:33, Marcel Apfelbaum ha scritto:
Quoted 5 lines
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
Quoted 7 lines
If all you're looking for is bigendian (disabling iasl disassembly on bigendian makes sense), your patch v2 is fine.
Assembling ASL on bigendian is supported by at least Fedora and Debian (and hence Ubuntu).
Paolo
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fi
If only the dis-assembler is broken, we should only detect that when running tests. Using expected files for this should be fine.
Signature · 1 line
MST
Quoted 7 lines · Michael S. Tsirkin
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fi
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.
thanks
-- PMM
Quoted 9 lines · Peter Maydell
Quoted 7 lines · Michael S. Tsirkin
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fi
Quoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis 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.
By the way, considering what Paolo said that the iasl compiler does work for BE machines (the dis-assembler has the problem), leads me to see this issue as the test's problem.
So I am going to leave the 'configure' with no modifications
and check inside the test itself that the expected files can be disassembled.
Thanks,
Marcel
Quoted 3 lines
thanks
-- PMM
Quoted 16 lines · Marcel Apfelbaum
Quoted 9 lines · Peter Maydell
Quoted 7 lines · Michael S. Tsirkin
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fiQuoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis true, but the iasl you use in the build process will be running on a little endian machine.
Quoted 4 lines
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.
"host" for QEMU means "the machine QEMU will run on"
(as opposed to "target" meaning "the machine QEMU is emulating"). Those can both be different from the machine you're building on.
Example: you can be on an x86_64 machine cross-compiling a qemu-system-mips intended to run on PPC hosts:
build system: x86_64 (we don't currently try to identify its endianness) host system: PPC ("$bigendian" is set to endianness)
target system: mips ("$target_bigendian" is set to endianness)
bigendian is set by cross-compiling a test object, which produces a PPC object file that we then examine to see which endianness the PPC system we're building for is.target_bigendian is set for the target machine by just hard-coding it -- in this case it would be set because 'mips' is a bigendian target. The iasl we use in the build process is the x86_64 native binary, so neither $bigendian nor $target_bigendian are correct.
thanks
-- PMM
Quoted 31 lines · Peter Maydell
Quoted 16 lines · Marcel Apfelbaum
Quoted 9 lines · Peter Maydell
Quoted 7 lines · Michael S. Tsirkin
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fiQuoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis true, but the iasl you use in the build process will be running on a little endian machine.Quoted 4 lines
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."host" for QEMU means "the machine QEMU will run on"
(as opposed to "target" meaning "the machine QEMU is emulating"). Those can both be different from the machine you're building on.
Example: you can be on anx86_64machine cross-compiling a qemu-system-mips intended to run on PPC hosts:
build system:x86_64(we don't currently try to identify its endianness) host system: PPC ("$bigendian" is set to endianness)
target system: mips ("$target_bigendian" is set to endianness)
Quoted 7 lines
bigendian is set by cross-compiling a test object, which produces a PPC object file that we then examine to see which endianness the PPC system we're building for is.
target_bigendianis set for the target machine by just hard-coding it -- in this case it would be set because 'mips' is a bigendian target. The iasl we use in the build process is thex86_64native binary, so neither $bigendian nor $target_bigendian are correct.
Thanks for the detailed answer! It really helped!
I missed the build machine != host machine != target machine :(
Marcel
Quoted 3 lines
thanks
-- PMM
Il 23/03/2014 13:32, Marcel Apfelbaum ha scritto:
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis 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.
Paolo
Quoted 21 lines · Paolo Bonzini
Il 23/03/2014 13:32, Marcel Apfelbaum ha scritto:
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis 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_ORDERcheck 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.
Quoted 5 lines
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
Quoted 1 line
Paolo
Quoted 31 lines · Marcel Apfelbaum
Quoted 21 lines · Paolo Bonzini
Il 23/03/2014 13:32, Marcel Apfelbaum ha scritto:
Quoted 9 lines
Quoted 5 lines
Quoted 5 lines
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_64cross-compiling for PPC thenHOST_WORDS_BIGENDIANis 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_ORDERcheck 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.
Quoted 5 lines
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 :)
Quoted 7 lines
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.
The last option seems best to me.
It will automatically start working when iasl disassembler is fixed and will handle any other case of breakage, not just BE.
Quoted 13 lines
2. If iasl causes problems to run a
x86_64guest 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 machinesIs everyone OK with this?
Thanks,
MarcelQuoted 1 line
Paolo
Am 23.03.2014 10:49, schrieb Michael S. Tsirkin:
Quoted 17 lines · Paolo Bonzini
Quoted 7 lines
Il 20/03/2014 23:33, Marcel Apfelbaum ha scritto:
Quoted 5 lines
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
Quoted 7 lines
If all you're looking for is bigendian (disabling iasl disassembly on bigendian makes sense), your patch v2 is fine.
Assembling ASL on bigendian is supported by at least Fedora and Debian (and hence Ubuntu).
Paolo
Quoted 7 lines
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fi
Careful, this is about the endianness of the built target binary, which may be different from the endianness of the build system. However I would hope the tests will not be executed for cross-builds.
Alexey, you're using cross-builds for ppc, right? Have you ever tested running make check there?
Cheers,
Andreas
Signature · 2 lines
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Quoted 26 lines · Andreas Färber
Am 23.03.2014 10:49, schrieb Michael S. Tsirkin:
Quoted 17 lines · Paolo Bonzini
Quoted 7 lines
Il 20/03/2014 23:33, Marcel Apfelbaum ha scritto:
Quoted 5 lines
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
Quoted 7 lines
If all you're looking for is bigendian (disabling iasl disassembly on bigendian makes sense), your patch v2 is fine.
Assembling ASL on bigendian is supported by at least Fedora and Debian (and hence Ubuntu).
Paolo
Quoted 7 lines
At this point I'm confused.
If iasl compiler is broken, we should detect and fix that. It might be ok to just detect endian-ness as a quick work-around. BTW configure already has code to detect endian-ness:
if test "$bigendian" = "yes" ; then
echo "HOST_WORDS_BIGENDIAN=y" >> $config_host_mak
fi
Quoted 6 lines
Careful, this is about the endianness of the built target binary, which may be different from the endianness of the build system. However I would hope the tests will not be executed for cross-builds.
Alexey, you're using cross-builds for ppc, right? Have you ever tested running make check there?
"make check" on what? ppc64-softmmu target compiled on x86_64? That fails because of errors like this:
tests/check-qjson: tests/check-qjson: cannot execute binary file
make: *** [check-tests/check-qstring] Error 1
Signature · 1 line
Alexey
Quoted 9 lines · Paolo Bonzini
Il 20/03/2014 23:33, Marcel Apfelbaum ha scritto:
Quoted 5 lines
I've seen something like that somewhere, but I didn't quite like it. I was looking for something more elegant as I was *almost* sure this kind of solution will not pass the reviews :)
But maybe I'll try this, let's see what happens,
If all you're looking for is bigendian (disabling iasl disassembly on bigendian makes sense), your patch v2 is fine.
Thanks Paolo, I thought so too, but Michael NACKED it having a valid point:
We should check this at configure time... .
Anyway, if only iasl dis-assembler has issues, this can be seen as acpi test's problem and handled inside the test.
Thanks,
Marcel
Quoted 5 lines
Assembling ASL on bigendian is supported by at least Fedora and Debian (and hence Ubuntu).
Paolo
Quoted 7 lines · Paolo Bonzini
Il 20/03/2014 22:14, Marcel Apfelbaum ha scritto:
configure else · line 4662
Quoted 4 lines
configure +4
-0+# All known versions of iasl on BE machines are broken. +# TODO: add detection code once a non-broken version makes an appearance. +if ($iasl -h > /dev/null 2>&1) && + (lscpu | grep "Byte Order" | grep --quiet "Little Endian" ); thenlscpu is not portable.
I am open to suggestions...
I'll try to come up with something else.
Thanks,
Marcel
Quoted 2 lines
Paolo