From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm PCI assignment & VFIO ramblings Date: Tue, 02 Aug 2011 11:32:52 +0300 Message-ID: <4E37B634.90902@redhat.com> References: <1311983933.8793.42.camel@pasglop> <4E356221.6010302@redhat.com> <1312230476.2653.395.camel@bling.home> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Benjamin Herrenschmidt , kvm@vger.kernel.org, Anthony Liguori , David Gibson , Paul Mackerras , Alexey Kardashevskiy , "linux-pci@vger.kernel.org" , linuxppc-dev To: Alex Williamson Return-path: In-Reply-To: <1312230476.2653.395.camel@bling.home> Sender: linux-pci-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 08/01/2011 11:27 PM, Alex Williamson wrote: > On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote: > > On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote: > > > Due to our paravirt nature, we don't need to masquerade the MSI-X table > > > for example. At all. If the guest configures crap into it, too bad, it > > > can only shoot itself in the foot since the host bridge enforce > > > validation anyways as I explained earlier. Because it's all paravirt, we > > > don't need to "translate" the interrupt vectors& addresses, the guest > > > will call hyercalls to configure things anyways. > > > > So, you have interrupt redirection? That is, MSI-x table values encode > > the vcpu, not pcpu? > > > > Alex, with interrupt redirection, we can skip this as well? Perhaps > > only if the guest enables interrupt redirection? > > It's not clear to me how we could skip it. With VT-d, we'd have to > implement an emulated interrupt remapper and hope that the guest picks > unused indexes in the host interrupt remapping table before it could do > anything useful with direct access to the MSI-X table. Yeah. We need the interrupt remapping hardware to indirect based on the source of the message, not just the address and data. > Maybe AMD IOMMU > makes this easier? Thanks, > No idea. -- error compiling committee.c: too many arguments to function From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ozlabs.org (Postfix) with ESMTP id BDF76B71C3 for ; Tue, 2 Aug 2011 18:33:07 +1000 (EST) Message-ID: <4E37B634.90902@redhat.com> Date: Tue, 02 Aug 2011 11:32:52 +0300 From: Avi Kivity MIME-Version: 1.0 To: Alex Williamson Subject: Re: kvm PCI assignment & VFIO ramblings References: <1311983933.8793.42.camel@pasglop> <4E356221.6010302@redhat.com> <1312230476.2653.395.camel@bling.home> In-Reply-To: <1312230476.2653.395.camel@bling.home> Content-Type: text/plain; charset=UTF-8; format=flowed Cc: Alexey Kardashevskiy , kvm@vger.kernel.org, Paul Mackerras , David Gibson , Anthony Liguori , "linux-pci@vger.kernel.org" , linuxppc-dev List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 08/01/2011 11:27 PM, Alex Williamson wrote: > On Sun, 2011-07-31 at 17:09 +0300, Avi Kivity wrote: > > On 07/30/2011 02:58 AM, Benjamin Herrenschmidt wrote: > > > Due to our paravirt nature, we don't need to masquerade the MSI-X table > > > for example. At all. If the guest configures crap into it, too bad, it > > > can only shoot itself in the foot since the host bridge enforce > > > validation anyways as I explained earlier. Because it's all paravirt, we > > > don't need to "translate" the interrupt vectors& addresses, the guest > > > will call hyercalls to configure things anyways. > > > > So, you have interrupt redirection? That is, MSI-x table values encode > > the vcpu, not pcpu? > > > > Alex, with interrupt redirection, we can skip this as well? Perhaps > > only if the guest enables interrupt redirection? > > It's not clear to me how we could skip it. With VT-d, we'd have to > implement an emulated interrupt remapper and hope that the guest picks > unused indexes in the host interrupt remapping table before it could do > anything useful with direct access to the MSI-X table. Yeah. We need the interrupt remapping hardware to indirect based on the source of the message, not just the address and data. > Maybe AMD IOMMU > makes this easier? Thanks, > No idea. -- error compiling committee.c: too many arguments to function