From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: kvm PCI assignment & VFIO ramblings Date: Thu, 4 Aug 2011 12:35:43 +0200 Message-ID: <20110804103543.GB22329@8bytes.org> References: <1311983933.8793.42.camel@pasglop> <1312050011.2265.185.camel@x201.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Benjamin Herrenschmidt , kvm@vger.kernel.org, Anthony Liguori , David Gibson , Paul Mackerras , Alexey Kardashevskiy , "linux-pci@vger.kernel.org" , linuxppc-dev , iommu , benve@cisco.com, aafabbri , chrisw , qemu-devel To: Alex Williamson Return-path: Content-Disposition: inline In-Reply-To: <1312050011.2265.185.camel@x201.home> Sender: linux-pci-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote: > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote: > > - The -minimum- granularity of pass-through is not always a single > > device and not always under SW control > > But IMHO, we need to preserve the granularity of exposing a device to a > guest as a single device. That might mean some devices are held hostage > by an agent on the host. Thats true. There is a difference between unassign a group from the host and make single devices in that PE visible to the guest. But we need to make sure that no device in a PE is used by the host while at least one device is assigned to a guest. Unlike the other proposals to handle this in libvirt, I think this belongs into the kernel. Doing this in userspace may break the entire system if done wrong. For example, if one device from e PE is assigned to a guest while another one is not unbound from its host driver, the driver may get very confused when DMA just stops working. This may crash the entire system or lead to silent data corruption in the guest. The behavior is basically undefined then. The kernel must not not allow that. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from 8bytes.org (8bytes.org [88.198.83.132]) by ozlabs.org (Postfix) with ESMTP id 909F1B6F86 for ; Thu, 4 Aug 2011 20:35:45 +1000 (EST) Date: Thu, 4 Aug 2011 12:35:43 +0200 From: Joerg Roedel To: Alex Williamson Subject: Re: kvm PCI assignment & VFIO ramblings Message-ID: <20110804103543.GB22329@8bytes.org> References: <1311983933.8793.42.camel@pasglop> <1312050011.2265.185.camel@x201.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1312050011.2265.185.camel@x201.home> Cc: chrisw , Alexey Kardashevskiy , kvm@vger.kernel.org, Paul Mackerras , qemu-devel , David Gibson , aafabbri , iommu , Anthony Liguori , "linux-pci@vger.kernel.org" , linuxppc-dev , benve@cisco.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote: > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote: > > - The -minimum- granularity of pass-through is not always a single > > device and not always under SW control > > But IMHO, we need to preserve the granularity of exposing a device to a > guest as a single device. That might mean some devices are held hostage > by an agent on the host. Thats true. There is a difference between unassign a group from the host and make single devices in that PE visible to the guest. But we need to make sure that no device in a PE is used by the host while at least one device is assigned to a guest. Unlike the other proposals to handle this in libvirt, I think this belongs into the kernel. Doing this in userspace may break the entire system if done wrong. For example, if one device from e PE is assigned to a guest while another one is not unbound from its host driver, the driver may get very confused when DMA just stops working. This may crash the entire system or lead to silent data corruption in the guest. The behavior is basically undefined then. The kernel must not not allow that. Joerg From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QovHK-0002k4-8Y for qemu-devel@nongnu.org; Thu, 04 Aug 2011 06:35:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QovHG-00031d-46 for qemu-devel@nongnu.org; Thu, 04 Aug 2011 06:35:50 -0400 Received: from 8bytes.org ([88.198.83.132]:40880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QovHF-00031N-TN for qemu-devel@nongnu.org; Thu, 04 Aug 2011 06:35:46 -0400 Date: Thu, 4 Aug 2011 12:35:43 +0200 From: Joerg Roedel Message-ID: <20110804103543.GB22329@8bytes.org> References: <1311983933.8793.42.camel@pasglop> <1312050011.2265.185.camel@x201.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1312050011.2265.185.camel@x201.home> Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw , Alexey Kardashevskiy , kvm@vger.kernel.org, Paul Mackerras , qemu-devel , David Gibson , aafabbri , iommu , "linux-pci@vger.kernel.org" , linuxppc-dev , benve@cisco.com On Sat, Jul 30, 2011 at 12:20:08PM -0600, Alex Williamson wrote: > On Sat, 2011-07-30 at 09:58 +1000, Benjamin Herrenschmidt wrote: > > - The -minimum- granularity of pass-through is not always a single > > device and not always under SW control > > But IMHO, we need to preserve the granularity of exposing a device to a > guest as a single device. That might mean some devices are held hostage > by an agent on the host. Thats true. There is a difference between unassign a group from the host and make single devices in that PE visible to the guest. But we need to make sure that no device in a PE is used by the host while at least one device is assigned to a guest. Unlike the other proposals to handle this in libvirt, I think this belongs into the kernel. Doing this in userspace may break the entire system if done wrong. For example, if one device from e PE is assigned to a guest while another one is not unbound from its host driver, the driver may get very confused when DMA just stops working. This may crash the entire system or lead to silent data corruption in the guest. The behavior is basically undefined then. The kernel must not not allow that. Joerg