From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: How to do fast accesses to LAPIC TPR under kvm? Date: Mon, 22 Oct 2012 16:10:30 +0200 Message-ID: <508553D6.8030709@redhat.com> References: <201210172124.26939.sf@sfritsch.de> <20121018093513.GF20788@redhat.com> <507FF5B9.6060605@redhat.com> <201210200039.16412.sf@sfritsch.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Stefan Fritsch Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62328 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754503Ab2JVOKh (ORCPT ); Mon, 22 Oct 2012 10:10:37 -0400 In-Reply-To: <201210200039.16412.sf@sfritsch.de> Sender: kvm-owner@vger.kernel.org List-ID: On 10/20/2012 12:39 AM, Stefan Fritsch wrote: > On Thursday 18 October 2012, Avi Kivity wrote: >> On 10/18/2012 11:35 AM, Gleb Natapov wrote: >> > You misunderstood the description. V_INTR_MASKING=1 means that >> > CR8 writes are not propagated to real HW APIC. >> > >> > But KVM does not trap access to CR8 unconditionally. It enables >> > CR8 intercept only when there is pending interrupt in IRR that >> > cannot be immediately delivered due to current TPR value. This >> > should eliminate 99% of CR8 intercepts. >> >> Right. You will need to expose the alternate encoding of cr8 (IIRC >> lock mov reg, cr0) on AMD via cpuid, but otherwise it should just >> work. Be aware that this will break cross-vendor migration. > > I get an exception and I am not sure why: > > kvm_entry: vcpu 0 > kvm_exit: reason write_cr8 rip 0xd0203788 info 0 0 > kvm_emulate_insn: 0:d0203788: f0 0f 22 c0 (prot32) > kvm_inj_exception: #UD (0x0) > > This is qemu-kvm 1.1.2 on Linux 3.2. > > When I look at arch/x86/kvm/emulate.c (both the current and the v3.2 > version), I don't see any special case handling for "lock mov reg, > cr0" to mean "mov reg, cr8". emulate.c will #UD is the Lock flag is missing in the instruction decode table. > Before I spend lots of time on debugging my code, can you verify if > the alternate encoding of cr8 is actually supported in kvm or if it is > maybe missing? Thanks in advance. With the decode table fix I think it should work. -- error compiling committee.c: too many arguments to function