From patchwork Thu Dec 13 12:11:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Bonzini X-Patchwork-Id: 1871971 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 1415C3FC71 for ; Thu, 13 Dec 2012 12:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753597Ab2LMMME (ORCPT ); Thu, 13 Dec 2012 07:12:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26288 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753401Ab2LMMMC (ORCPT ); Thu, 13 Dec 2012 07:12:02 -0500 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBDCC1m1008857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Dec 2012 07:12:01 -0500 Received: from yakj.usersys.redhat.com (ovpn-112-24.ams2.redhat.com [10.36.112.24]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qBDCBxTT015242; Thu, 13 Dec 2012 07:12:00 -0500 From: Paolo Bonzini To: kvm@vger.kernel.org Cc: mtosatti@redhat.com, Nadav Amit Subject: [PATCH kvm-unit-tests] emulator: test 64-bit mov with immediate operand Date: Thu, 13 Dec 2012 13:11:55 +0100 Message-Id: <1355400716-21359-1-git-send-email-pbonzini@redhat.com> X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org MOV immediate instruction (opcodes 0xB8-0xBF) may take 64-bit operand. Some hypervisor implementations assumed the operand is 32-bit. This should never happen because the instruction has no memory operand, but (like the existing test_mmx_movq_mf) the testcase tricks the emulator into executing one by mismatching the page tables and the corresponding TLB entry. Cc: Nadav Amit Signed-off-by: Paolo Bonzini --- x86/emulator.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/x86/emulator.c b/x86/emulator.c index 969944a..d578347 100644 --- a/x86/emulator.c +++ b/x86/emulator.c @@ -694,6 +694,38 @@ static void test_mmx_movq_mf(uint64_t *mem, uint8_t *insn_page, handle_exception(MF_VECTOR, 0); } +static void test_movabs(uint64_t *mem, uint8_t *insn_page, + uint8_t *alt_insn_page, void *insn_ram) +{ + uint64_t val = 0; + ulong *cr3 = (ulong *)read_cr3(); + + // Pad with RET instructions + memset(insn_page, 0xc3, 4096); + memset(alt_insn_page, 0xc3, 4096); + // Place a trapping instruction in the page to trigger a VMEXIT + insn_page[0] = 0x89; // mov %eax, (%rax) + insn_page[1] = 0x00; + // Place the instruction we want the hypervisor to see in the alternate + // page. A buggy hypervisor will fetch a 32-bit immediate and return + // 0xffffffffc3c3c3c3. + alt_insn_page[0] = 0x48; // mov $0xc3c3c3c3c3c3c3c3, %rcx + alt_insn_page[1] = 0xb9; + + // Load the code TLB with insn_page, but point the page tables at + // alt_insn_page (and keep the data TLB clear, for AMD decode assist). + // This will make the CPU trap on the insn_page instruction but the + // hypervisor will see alt_insn_page. + install_page(cr3, virt_to_phys(insn_page), insn_ram); + // Load code TLB + invlpg(insn_ram); + asm volatile("call *%0" : : "r"(insn_ram + 3)); + // Trap, let hypervisor emulate at alt_insn_page + install_page(cr3, virt_to_phys(alt_insn_page), insn_ram); + asm volatile("call *%1" : "=c"(val) : "r"(insn_ram), "a"(mem), "c"(0)); + report("64-bit mov imm", val == 0xc3c3c3c3c3c3c3c3); +} + static void test_crosspage_mmio(volatile uint8_t *mem) { volatile uint16_t w, *pw; @@ -759,6 +791,7 @@ int main() test_shld_shrd(mem); test_mmx_movq_mf(mem, insn_page, alt_insn_page, insn_ram); + test_movabs(mem, insn_page, alt_insn_page, insn_ram); test_crosspage_mmio(mem);