Re: event injection MACROs

From: Avi Kivity <avi@redhat.com>
To: "Dong, Eddie" <eddie.dong@intel.com>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: event injection MACROs
Date: Thu, 14 May 2009 12:27:57 +0300	[thread overview]
Message-ID: <4A0BE41D.3060809@redhat.com> (raw)
In-Reply-To: <9832F13BD22FB94A829F798DA4A8280501B24E5C3A@pdsmsx503.ccr.corp.intel.com>

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