Hi all, I'm writing to report a possible bug in the qemu emulation of rex.W-prefixed far jumps. It affects far jumps of this type with both rip-relative and absolute addresses.
The yasm syntax for these instructions: jmp far qword [addr] jmp far qword [addr wrt rip] and the resulting disassembly: 8: 48 ff 2c 25 00 00 00 00 rex.W ljmpq *0x0 c: R_X86_64_32 .text+0x17 10: 48 ff 2d 00 00 00 00 rex.W ljmpq *0x0(%rip) # 0x17 qemu triggers a gpf with error 0xfffc (presumably this is 0xffff masked to 0xfffc by the & on new_cs from target-i386/op_helper.c:helper_ljmp_protected()) It's suspected that qemu is treating the far address as 16:32 instead of 16:64 as it should, since the far address as laid out in memory is: 12 34 56 78 ff ff ff ff 10 00 The far address is intended to be a Linux kernel address, so the upper 32bits are 0xffffffff. If qemu is treating the 16:64 layout as 16:32, you can see why new_cs would have the value of 0xffff. The code only fails on qemu -- it works as expected on real systems. I'm not familiar with your code-base so I have no patch for the issue, but I thought I'd fire off a mail as I imagine it's a simple oversight and easy fix for someone familiar with the code. Thanks for your help, and please keep me on CC for replies -Brad
signature.asc
Description: Digital signature