From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/7] Consolidate vcpu ioctl locking Date: Sun, 16 May 2010 12:47:46 +0300 Message-ID: <4BEFBF42.6020208@redhat.com> References: <1273749459-622-1-git-send-email-avi@redhat.com> <4BEBEA25.8080309@redhat.com> <4BEBEA7E.80202@redhat.com> <4BEBEAAE.9030502@redhat.com> <24423079-CDE0-4DEA-BC73-3B6976BE0CA6@suse.de> <4BEBF0BF.2020404@redhat.com> <4BEE3C56.2070007@redhat.com> <4BEE544B.50405@redhat.com> <20442124-2400-4273-A256-6846017D3141@suse.de> <4BEEDA37.2080209@redhat.com> <6BE91F3A-C60C-47C0-9EA4-E5F5971B09C2@suse.de> <4BEFAB6D.9000904@redhat.com> <4BEFB666.50107@redhat.com> <04ED5A08-BE13-4C60-B152-EA5541975779@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "kvm-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "carsteno-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org" To: Alexander Graf Return-path: In-Reply-To: <04ED5A08-BE13-4C60-B152-EA5541975779-l3A5Bk7waGM@public.gmane.org> Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org On 05/16/2010 12:35 PM, Alexander Graf wrote: > >> >>> So let me think this through. With remote interrupt injection we have. >>> >>> * thread 1 does vcpu_run >>> * thread 2 triggers KVM_INTERRUPT on fd >>> * thread 2 signals thread 1 so we're sure the interrupt gets injected >>> * thread 1 exits into qemu >>> >>> >> This doesn't seem necessary. The kernel can own the interrupt line, so it remembers it from the last KVM_INTERRUPT. >> > It's not? With s/signals/IPIs/. > On signals we always exit to userspace, no? > Yes (if the signal isn't blocked). >>> * thread 1 goes back into the vcpu, triggering an interrupt >>> >>> Without we have: >>> >>> * thread 1 does vcpu_run >>> * thread 2 wants to trigger an an interrupt, sets the qemu internal bit >>> * thread 2 signals thread 1 so we're sure the interrupt gets processed >>> * thread 1 exits into qemu >>> * thread 1 triggers KVM_INTERRUPT on fd >>> * thread 1 goes into the vcpu >>> >>> So we don't really buy anything from doing the remote injection. Hrm. >>> >>> >> Not if you make interrupt injection a lightweight exit. >> > Please elaborate. > 1: vcpu_run 2: KVM_INTERRUPT 2k: sets flag, if msr.ee IPIs 1 or wakes up 1 if halted 1k: notices flag, if msr.ee injects interrupt ... 1g: acks 1k: forwards ack to userspace 1: completes interrupt >>> What's somewhat striking me here though is - why do we need KVM_INTERRUPT when there's all those kvm_run fields? Can't we just do interrupt injection by setting run->trigger_interrupt? There's only a single "interrupt line" on the CPU anyways. That way we'd save the ioctl and get rid of the locking problem altogether. >>> >>> >> That's what x86 does. However, it's synchronous. >> > For everyone except for the vcpu thread executing the interrupt, it's asynchronous, right? For everyone other than the vcpu thread, it's off limits. kvm_run is only read on KVM_RUN entries and written on KVM_RUN exits. > The same applies to an in-kernel pic. > The in-kernel pic doesn't use kvm_run. -- error compiling committee.c: too many arguments to function