From: "Alex Bennée" <alex.bennee@linaro.org>
To: Bug 1830872 <1830872@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG
Date: Mon, 03 Jun 2019 12:56:11 +0100 [thread overview]
Message-ID: <874l56c278.fsf@zen.linaroharston> (raw)
In-Reply-To: <875zpodsi2.fsf@zen.linaroharston>
Alex Bennée <alex.bennee@linaro.org> writes:
> Laszlo Ersek (Red Hat) <lersek@redhat.com> writes:
>
>> Possibly related:
>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
>>
>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
>> QEMU is built for i686)
>>
>> Note to self: try to reprodouce the present issue with QEMU built at
>> eed5664238ea^ -- this LP has originally been filed about the tree at
>> a4f667b67149, and that commit contains eed5664238ea. So checking at
>> eed5664238ea^ might reveal a difference.
>
> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
> cases.
Actually I do see something with i386 host running the aarch64 memory
test (although so far not with a armv7 host):
./qemu-system-aarch64 -monitor none -display none -M virt -cpu max -display none -semihosting -kernel tests/memory
Gives:
Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249, 248, 255Test complete: FAILED
--
Alex Bennée
WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG
Date: Mon, 03 Jun 2019 11:56:11 -0000 [thread overview]
Message-ID: <874l56c278.fsf@zen.linaroharston> (raw)
Message-ID: <20190603115611.FA-xvyTnSVy2GZk8NtTFGmF70tO4CqiW5AgVvjL-e8A@z> (raw)
In-Reply-To: 875zpodsi2.fsf@zen.linaroharston
Alex Bennée <alex.bennee@linaro.org> writes:
> Laszlo Ersek (Red Hat) <lersek@redhat.com> writes:
>
>> Possibly related:
>> [Qemu-devel] "accel/tcg: demacro cputlb" break qemu-system-x86_64
>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07362.html
>>
>> (qemu-system-x86_64 fails to boot 64-bit kernel under TCG accel when
>> QEMU is built for i686)
>>
>> Note to self: try to reprodouce the present issue with QEMU built at
>> eed5664238ea^ -- this LP has originally been filed about the tree at
>> a4f667b67149, and that commit contains eed5664238ea. So checking at
>> eed5664238ea^ might reveal a difference.
>
> Oops. Looks like tests/tcg/multiarch/system/memory.c didn't cover enough
> cases.
Actually I do see something with i386 host running the aarch64 memory
test (although so far not with a armv7 host):
./qemu-system-aarch64 -monitor none -display none -M virt -cpu max
-display none -semihosting -kernel tests/memory
Gives:
Reading u64 from 0x40213004 (offset 4):....Error 0, 0, 0, 0, 250, 249,
248, 255Test complete: FAILED
--
Alex Bennée
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830872
Title:
AARCH64 to ARMv7 mistranslation in TCG
Status in QEMU:
New
Bug description:
The following guest code:
https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S
implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
Development Kit II) library function. (CopyMem() basically has memmove()
semantics, to provide a standard C analog here.) The relevant functions
are InternalMemCopyMem() and __memcpy().
When TCG translates this aarch64 code to x86_64, everything works
fine.
When TCG translates this aarch64 code to ARMv7, the destination area of
the translated CopyMem() function becomes corrupted -- it differs from
the intended source contents. Namely, in every 4096 byte block, the
8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
instead of receiving the intended source value.
I'm attaching two hexdumps of the same destination area:
- "good.txt" is a hexdump of the destination area when CopyMem() was
translated to x86_64,
- "bad.txt" is a hexdump of the destination area when CopyMem() was
translated to ARMv7.
In order to assist with the analysis of this issue, I disassembled the
aarch64 binary with "objdump". Please find the listing in
"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.
And, I ran the guest on the ARMv7 host with "-d
in_asm,op,op_opt,op_ind,out_asm". Please find the log in
"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.
The TBs that correspond to (parts of) the InternalMemCopyMem() and
__memcpy() functions are scattered over the TCG log file, but the offset
between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
TBs in the TCG log, can be determined from the fact that there is a
single prfm instruction in the entire binary. The instruction's offset
is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
difference (= the load address of DxeCore.efi) is 0x472a7000.
QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).
The reproducer command line is (on an ARMv7 host):
qemu-system-aarch64 \
-display none \
-machine virt,accel=tcg \
-nodefaults \
-nographic \
-drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
-drive if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
-cpu cortex-a57 \
-chardev stdio,signal=off,mux=on,id=char0 \
-mon chardev=char0,mode=readline \
-serial chardev:char0
The apparent symptom is an assertion failure *in the guest*, such as
> ASSERT [DxeCore]
> /home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength
but that is only a (distant) consequence of the CopyMem()
mistranslation, and resultant destination area corruption.
Originally reported in the following two mailing list messages:
- http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com
- http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions
next prev parent reply other threads:[~2019-06-03 11:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 9:13 [Qemu-devel] [Bug 1830872] [NEW] AARCH64 to ARMv7 mistranslation in TCG Laszlo Ersek (Red Hat)
2019-05-29 12:08 ` [Qemu-devel] [Bug 1830872] " Philippe Mathieu-Daudé
2019-06-02 10:19 ` Laszlo Ersek (Red Hat)
2019-06-02 13:30 ` Alex Bennée
2019-06-02 13:30 ` Alex Bennée
2019-06-03 11:56 ` Alex Bennée [this message]
2019-06-03 11:56 ` Alex Bennée
2019-06-02 14:54 ` Alex Bennée
2019-06-03 15:01 ` [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load Alex Bennée
2019-06-03 15:01 ` [Qemu-devel] [Bug 1830872] " Alex Bennée
2019-06-03 15:35 ` [Qemu-devel] " Andrew Randrianasulu
2019-06-03 15:35 ` [Qemu-devel] [Bug 1830872] " Andrew Randrianasulu
2019-06-04 9:43 ` [Qemu-devel] " Alex Bennée
2019-06-04 9:43 ` [Qemu-devel] [Bug 1830872] " Alex Bennée
2019-06-03 18:29 ` Laszlo Ersek (Red Hat)
2019-06-03 18:29 ` [Qemu-devel] " Laszlo Ersek
2019-06-03 22:01 ` Richard Henderson
2019-06-04 6:52 ` Philippe Mathieu-Daudé
2019-06-04 11:42 ` Igor Mammedov
2019-06-04 11:42 ` [Qemu-devel] [Bug 1830872] " Igor
2019-06-03 15:27 ` [Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG Laszlo Ersek (Red Hat)
2019-06-03 15:45 ` Laszlo Ersek (Red Hat)
2019-06-03 15:51 ` Alex Bennée
2019-06-03 16:53 ` Andrew Randrianasulu
2019-06-03 17:03 ` Andrew Randrianasulu
2019-06-17 18:21 ` Alex Bennée
2019-08-16 5:04 ` Thomas Huth
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=874l56c278.fsf@zen.linaroharston \
--to=alex.bennee@linaro.org \
--cc=1830872@bugs.launchpad.net \
--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.