Re: [Qemu-devel] [Bug 757702] Re: Undefined instruction exception starts at offset 0x8 instead of 0x4

[Anup Patel]

Hi,

You are right, I have deliberately used an instruction from a "permanently
UNDEF" space. I have used this instruction because thats this are the only
UNDEF instructions with maximum payload of 20 bits.

Also, the instruction "0xec019800" does not belong to STC instruction space.
GNU object dump does not display it as undefined instruction due to internal
bug, but it is definitely an undefined instruction.
May be the undefined instructions from "permanently UNDEF" space are only
executing from offset 0x8 in QEMU 0.14.0. It used to work fine with QEMU
0.13.0.

PFA, my test elf file. The UNDEF instruction that i have reported is
at location 0x100058 in this elf file. The execution of elf file starts from
0x100000.

I have launched qemu with command: ./qemu-system-arm -s -S -M realview-pb-a8
-serial stdio -kernel ../../../xvisor/tests/armv7/pb-a8/arm_test.elf
I am debugging using gdb command: arm-none-eabi-gdb arm_test.elf
--eval-command="target remote localhost:1234"

Please let me know if you are not able to reproduce the bug.

--Anup

On Tue, Apr 12, 2011 at 3:13 PM, Peter Maydell
<address@hidden>wrote:

> > ARMv7a has lot of undefined instruction from its instruction opcode
> space. This undefined instructions
> >are very useful for replacing sensitive non-priviledged instructions of
> guest operating systems (virtualization).
>
> PS: please don't use arbitrary UNDEF instruction patterns for this (the one
> you quoted is in the STC instruction space  for example). There's an
> officially-defined "permanently UNDEF" space:
>  cond 0111 1111 xxxx xxxx xxxx 1111 xxxx
> available for this purpose, which will mean you don't have to worry about
> newer versions of the architecture allocating the UNDEF patterns you were
> using.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/757702
>
> Title:
>  Undefined instruction exception starts at offset 0x8 instead of 0x4
>
> Status in QEMU:
>  New
>
> Bug description:
>  ARMv7a has lot of undefined instruction from its instruction opcode
>  space. This undefined instructions are very useful for replacing
>  sensitive non-priviledged instructions of guest operating systems
>  (virtualization). The undefined instruction exception executes at
>  <exception_base> + 0x4, where <exception_base> can be 0x0 or
>  0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at
>  0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0,
>  seems like this is a new bug. As as example, if we try to execute
>  value "0xec019800" in qemu 0.14.0 then it should cause undefined
>  exception at <exception_base>+0x4 since "0xec019800" is an undefined
>  instruction.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/qemu/+bug/757702/+subscribe
>


** Attachment added: "arm_test.elf"
   
https://bugs.launchpad.net/bugs/757702/+attachment/2023365/+files/arm_test.elf

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/757702

Title:
  Undefined instruction exception starts at offset 0x8 instead of 0x4

Status in QEMU:
  New

Bug description:
  ARMv7a has lot of undefined instruction from its instruction opcode
  space. This undefined instructions are very useful for replacing
  sensitive non-priviledged instructions of guest operating systems
  (virtualization). The undefined instruction exception executes at
  <exception_base> + 0x4, where <exception_base> can be 0x0 or
  0xfff00000. Currently, in qemu 0.14.0 undefined instruction fault at
  0x8 offset instead of 0x4. This was not a problem with qemu 0.13.0,
  seems like this is a new bug. As as example, if we try to execute
  value "0xec019800" in qemu 0.14.0 then it should cause undefined
  exception at <exception_base>+0x4 since "0xec019800" is an undefined
  instruction.