From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH v4 9/9] KVM: Allow host IRQ sharing for passed-through PCI 2.3 devices Date: Tue, 09 Nov 2010 15:27:54 +0200 Message-ID: <4CD94C5A.1080504@redhat.com> References: <940e3dc8062aa1c9810b5a6eb3e6dd086abc7d59.1289215310.git.jan.kiszka@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm , Alex Williamson , "Michael S. Tsirkin" To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8215 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699Ab0KIN2A (ORCPT ); Tue, 9 Nov 2010 08:28:00 -0500 In-Reply-To: <940e3dc8062aa1c9810b5a6eb3e6dd086abc7d59.1289215310.git.jan.kiszka@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 11/08/2010 01:21 PM, Jan Kiszka wrote: > PCI 2.3 allows to generically disable IRQ sources at device level. This > enables us to share IRQs of such devices between on the host side when > passing them to a guest. This feature is optional, user space has to > request it explicitly. Moreover, user space can inform us about its view > of PCI_COMMAND_INTX_DISABLE so that we can avoid unmasking the interrupt > and signaling it if the guest masked it via the PCI config space. > It's a pity this cannot be done transparently. We could detect multiple devices sharing the line, but what about PCI_COMMAND_INTX_DISABLE? Perhaps we can hook the kernel's handler for this bit? > > /* Depends on KVM_CAP_IOMMU */ > #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1<< 0) > +/* The following two depend on KVM_CAP_PCI_2_3 */ > +#define KVM_DEV_ASSIGN_PCI_2_3 (1<< 1) > +#define KVM_DEV_ASSIGN_MASK_INTX (1<< 2) > + > +If KVM_DEV_ASSIGN_PCI_2_3 is set, the kernel will manage legacy INTx interrupts > +via the PCI-2.3-compliant device-level mask, thus enable IRQ sharing with other > +assigned devices or host devices. KVM_DEV_ASSIGN_MASK_INTX specifies the > +guest's view on the INTx mask, see KVM_ASSIGN_SET_INTX_MASK for details. > > 4.48 KVM_DEASSIGN_PCI_DEVICE > > @@ -1263,6 +1271,23 @@ struct kvm_assigned_msix_entry { > __u16 padding[3]; > }; > > +5.54 KVM_ASSIGN_SET_INTX_MASK 4.54? (54? wow.) > + > +Capability: KVM_CAP_PCI_2_3 > +Architectures: x86 > +Type: vm ioctl > +Parameters: struct kvm_assigned_pci_dev (in) > +Returns: 0 on success, -1 on error > + > +Informs the kernel about the guest's view on the INTx mask. As long as the > +guest masks the legacy INTx, the kernel will refrain from unmasking it at > +hardware level and will not assert the guest's IRQ line. User space is still > +responsible for applying this state to the assigned device's real config space. What if userspace lies? > + > +See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified > +by assigned_dev_id. In the flags field, only KVM_DEV_ASSIGN_MASK_INTX is > +evaluated. > + > > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index fe83eb0..7f1627c 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -468,6 +468,7 @@ struct kvm_assigned_dev_kernel { > unsigned int entries_nr; > int host_irq; > bool host_irq_disabled; > + bool pci_2_3; > struct msix_entry *host_msix_entries; > int guest_irq; > struct msix_entry *guest_msix_entries; > @@ -477,6 +478,7 @@ struct kvm_assigned_dev_kernel { > struct pci_dev *dev; > struct kvm *kvm; > spinlock_t intx_lock; > + struct mutex intx_mask_lock; > char irq_name[32]; > }; I saw no reason this can't be a spinlock, but perhaps I missed something. This would allow us to avoid srcu, which is slightly more expensive than rcu. Since pci 2.3 assigned devices are not a major use case, I'd like not to penalize the mainstream users for this. This patch undoes some of the niceness of the previous patches, but I have no alternative to suggest. -- error compiling committee.c: too many arguments to function