From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] interrupt preemption support Date: Fri, 16 Mar 2007 09:03:40 +0200 Message-ID: <45FA414C.1040703@qumranet.com> References: <45F97019.BA47.005A.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-reply-to: <45F97019.BA47.005A.0-Et1tbQHTxzrQT0dZR+AlfA@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Gregory Haskins wrote: > This patch adds baseline support for interrupt preemption. This lets one context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is currently in guest context when an interrupt is posted. The patch consists of the following: > > 1) Re-worked the vcpu mutex with a new "MPL" construct. This allows updates to the vcpu structure even if the vcpu is currently executing in guest mode. The previous code held a mutex during guest execution. > > Whoa there. kvm can't just add new locking constructs to the kernel. It has to be added to the kernel _first_, you need to justify it with more than just kvm as a user, show correctness, performance, and scalability. Once it's accepted, kvm can use it. Formal issues aside, why is this different from taking nested locks? The paravirt network code congealing in Dor's repo has a spinlock protecting the interrupt bits. The main execution path takes both the vcpu mutex and the irq lock (when necessary), other paths take just the irq lock. This has the added advantage of not requiring a mutex to inject an interrupt, which is often necessary from (host) irq context. > 2) Exposed the previously static kvm_vcpu_ioctl_interrupt() as kvm_vcpu_interrupt so that other mechanisms (PV drivers) can issue interrupts just as the ioctl interface can > It's not enough to issue an interrupt, there is a whole dance involved in the guest side to ack it. You need to go through the apic, which is currently emulated in userspace. We may push it to the kernel later. > > Index: kvm-12/kernel/kvm.h > Please base things off trunk. For kernel code, off the git repository, not the bundled kernel module (which is mangled by the release process in order to accommodate older kernels). > > +typedef enum > +{ > + KVM_MPL_FREE, > + KVM_MPL_VMCS, > + KVM_MPL_VCPU, > + KVM_MPL_FULL = KVM_MPL_VCPU /* Must be equal to the last entry */ > +}kvm_mpl_locktypes_t; > Either you or your mailer mangle whitespace horribly. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV