From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 0/4] move irq protection role to separate lock v2 Date: Thu, 21 May 2009 10:26:57 +0300 Message-ID: <4A150241.8070408@redhat.com> References: <4A1413C3.4020606@redhat.com> <20090520184841.954066003@localhost.localdomain> <20090521045015.GA1104@amt.cnet> <200905210855.53470.borntrae@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Marcelo Tosatti , Christian Ehrhardt , Carsten Otte , kvm@vger.kernel.org, Christian Borntraeger To: =?ISO-8859-1?Q?Christian_Borntr=E4ger?= Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36506 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbZEUH1A (ORCPT ); Thu, 21 May 2009 03:27:00 -0400 In-Reply-To: <200905210855.53470.borntrae@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntr=E4ger wrote: >> @@ -2053,6 +2054,9 @@ static long kvm_vm_ioctl(struct file *fi >> >> if (kvm->mm !=3D current->mm) >> return -EIO; >> + >> + mutex_lock(&kvm->vm_ioctl_lock); >> + >> switch (ioctl) { >> case KVM_CREATE_VCPU: >> r =3D kvm_vm_ioctl_create_vcpu(kvm, arg); >> @@ -2228,6 +2232,7 @@ static long kvm_vm_ioctl(struct file *fi >> r =3D kvm_arch_vm_ioctl(filp, ioctl, arg); >> } >> out: >> + mutex_unlock(&kvm->vm_ioctl_lock); >> return r; >> } >> =20 > > The thing that looks worrysome is that the s390 version of kvm_arch_v= m_ioctl=20 > has KVM_S390_INTERRUPT. This allows userspace to inject interrupts - = which=20 > would be serialized. The thing is, that external interrupts and I/O i= nterrupts=20 > are floating - which means they can arrive on all cpus. This is somew= hat of a=20 > fast path. > On the other hand, kvm_s390_inject_vm already takes the kvm->lock to = protect=20 > agains hotplug. With this patch we might be able to remove the kvm->l= ock in=20 > kvm_s390_inject_vm - that would reduce the impact.=20 > > This needs more thinking on our side. > =20 x86 actually shares the same problem. KVM_IRQ_LINE interrupts may=20 arrive at any vcpu. Furthermore, with irqfd interrupts may be injected= =20 from userspace (the vm process or other processes) or from the kernel=20 (assigned device, kernel virtio-net device). So we have the same=20 motivation to drop this lock and replace it by rcu for the fast paths. --=20 error compiling committee.c: too many arguments to function