From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: event injection MACROs Date: Thu, 14 May 2009 12:27:57 +0300 Message-ID: <4A0BE41D.3060809@redhat.com> References: <9832F13BD22FB94A829F798DA4A8280501A80F02A3@pdsmsx503.ccr.corp.intel.com> <20090503105330.GL9795@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A8E83@pdsmsx503.ccr.corp.intel.com> <20090508095336.GD25357@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A8EFE@pdsmsx503.ccr.corp.intel.com> <9832F13BD22FB94A829F798DA4A8280501A81A8F02@pdsmsx503.ccr.corp.intel.com> <20090508122358.GF25357@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A8F2B@pdsmsx503.ccr.corp.intel.com> <20090508184417.GA27255@redhat.com> <9832F13BD22FB94A829F798DA4A8280501A81A9078@pdsmsx503.ccr.corp.intel.com> <4A07C304.2000208@redhat.com> <9832F13BD22FB94A829F798DA4A8280501B24E54F0@pdsmsx503.ccr.corp.intel.com> <4A0A97A5.7070508@redhat.com> <9832F13BD22FB94A829F798DA4A8280501B24E5C3A@pdsmsx503.ccr.corp.inte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kvm@vger.kernel.org" To: "Dong, Eddie" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:45247 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751185AbZENJ16 (ORCPT ); Thu, 14 May 2009 05:27:58 -0400 In-Reply-To: <9832F13BD22FB94A829F798DA4A8280501B24E5C3A@pdsmsx503.ccr.corp.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Dong, Eddie wrote: > OK. > Also back to Gleb's question, the reason I want to do that is to simplify event > generation mechanism in current KVM. > > Today KVM use additional layer of exception/nmi/interrupt such as > vcpu.arch.exception.pending, vcpu->arch.interrupt.pending & vcpu->arch.nmi_injected. > All those additional layer is due to compete of VM_ENTRY_INTR_INFO_FIELD > write to inject the event. Both SVM & VMX has only one resource to inject the virtual event > but KVM generates 3 catagory of events in parallel which further requires additional > logic to dictate among them. I thought of using a queue to hold all pending events (in a common format), sort it by priority, and inject the head. > One example is that exception has higher priority > than NMI/IRQ injection in current code which is not true in reality. > I don't think it matters in practice, since the guest will see it as a timing issue. NMIs and IRQs are asynchronous (even those generated by the guest through the local APIC). > Another issue is that an failed event from previous injection say IRQ or NMI may be > discarded if an virtual exception happens in the EXIT handling now. With the patch of > generic double fault handling, this case should be handled as normally. > Discarding an exception is usually okay as it will be regenerated. I don't think we discard interrupts or NMIs. -- error compiling committee.c: too many arguments to function